VPN Einwahl mit Lancom Advanced Client klappt nicht

[routerjoe]

Hi,

ich habe hier einen 1711er an einem Business Connect Anschluss hängen. Die VPN-Einwahl wurde per Assistenten weitestgehend mit den Standardeinstellungen getätigt (Shared Key-Verfahren). Wenn ich mich nun mit dem Advanced Client von ausserhalb einwählen möchte, dann zeigt er mir die Meldung "IKE-Phase 1 Fehler" (sinngemäß). Jetzt habe ich mal im Log nachgeschaut und sehe da folgendes:

15.07.2006 14:53:42 Protecting RAS adapter - 0
15.07.2006 14:53:43 IPSDIALCHAN::start building connection
15.07.2006 14:53:43 NCPIKE-phase1:name(SERVER) - outgoing connect request - aggressive mode.
15.07.2006 14:53:43 XMIT_MSG1_AGGRESSIVE - SERVER
15.07.2006 14:53:44 RECV_MSG2_AGGRESSIVE - SERVER
15.07.2006 14:53:44 IKE phase I: Setting LifeTime to 28800 seconds
15.07.2006 14:53:44 IPSDIAL->FINAL_TUNNEL_ENDPOINT: <öffentliche IP-Adresse 1711ers>
15.07.2006 14:53:44 XMIT_MSG3_AGGRESSIVE - SERVER
15.07.2006 14:53:44 Turning on DPD mode - SERVER
15.07.2006 14:53:44 NCPIKE-phase1:name(SERVER) - connected
15.07.2006 14:53:44 Phase1 is Ready: IkeIndex = 0000000f
15.07.2006 14:53:44 XMIT_IKECFG_REQUEST - SERVER
15.07.2006 14:53:44 RECV_IKECFG_REPLY - SERVER
15.07.2006 14:53:44 NCPIKE-xauth:name(SERVER) - IkeCfg: enter state open
15.07.2006 14:53:44 Quick Mode is Ready: IkeIndex = 0000000f , VpnSrcPort = 500
15.07.2006 14:53:44 Assigned IP Address: <lokale IP-Adresse, die mir der 1711er vergibt>
15.07.2006 14:53:44 DNS Server: <lokale IP-Adresse des 1711er>
15.07.2006 14:53:44 XMIT_MSG1_QUICK - SERVER
15.07.2006 14:53:44 NOTIFY : SERVER: RECEIVED : NO_PROPOSAL_CHOSEN
15.07.2006 14:53:44 NCPIKE-phase1:name(SERVER) - error - Delete indication received
15.07.2006 14:53:44 NCPIKE-phase2:name(SERVER) - error - cleared by phase1
15.07.2006 14:53:44 IPSDIAL - disconnected from SERVERon channel 1.

Das einzige was mit ins Auge sticht ist "NO_PROPOSAL_CHOSEN". Danach habe ich schon bei Lancom gesucht und einen Beitrag gefunden (http://www2.lancom.de/kb.nsf/a5ddf48173 ... sal,German). Er trifft nicht ganz auf mich zu, den der 1711er ist neu "out-of-the-box" mit aktueller Firmware 6.12 (original war 5.x drauf). Es wurde nichts übernommen sondern die VPN-Einwahl frisch mit dem Assistenten eingerichtet. Auffällig ist dabei auch, das er für meine VPN-Einwahl eine neue Proposal-Liste WIZ_ADVCLI... eingerichtet hat mit nur einem AES Eintrag. Ich habe als zweites noch genau den Eintrag hinzugefügt, der auch im oberen Link beschrieben wurde, ebenso habe ich die Reihenfolge noch getauscht (als erstes das Proposal aus dem Link, danach das ursprüngliche). Alles ohne Änderung der Situation, geschweige den Erfolg.

Wie man aus dem Log erkennen kann, erhalte ich vom 1711er bereits die richtige lokale IP-Adresse. Insofern ist der Kontakt schonmal da, nur die Authentifizierung scheint mir zu scheitern.

Wo kann hier der Fehler versteckt sein?

Joe

[backslash]

Hi routerjoe

da stimmen die Netzbeziehungen nicht: das entfernte Netz, daß du im Client eingestellt hast, stimmt nicht mit dem ein, was im LANCOM konfiguriert wurde.

Ein gerne gemachter Fehler ist, im Client gar nichts einzutragen. Dann erwartet der Client nämlich, daß auch der normale Internet-Traffic über ihn abgewickelt wird und versucht einen entsprechenden Tunnel aufzubauen, was vom LANCOM natürlich abgelehnt wird (außer du konfigurierst es passend).

Trage im Client das Netz ein, das sich "hinter" dem LANCOM befindet.

Gruß
Backslash

[routerjoe]

Hi backslash,

super! Das war's. Dann hab ich noch 3 kleine Fragen:
1. ist "nur" das Clientnetzwerk nicht mehr zu erreichen wenn einwählender Client und VPN Gegenstelle die selben IP-Adressbereiche aus z.B. 192.168.40.x mit Subnet-Mask 255.255.255.0 verwenden oder gibt es auch noch größere Probleme?
2. Zertifikate versus Pre-Shared-Key: was brungt mehr Sichherheit deiner Meinung nach?
3. allgemein zum Thema Sicherheit: Gibt es irgendwo eine Checkliste, wo man die Sicherheit der VPN-Verbindung prüfen bzw. verbessern kann (so in der Art nehm diese Schlüssellänge und das Proposal und ...)

Dank dir schonmal. Hast mir das WE gerettet!

Joe

[backslash]

Hi routerjoe

1. ist "nur" das Clientnetzwerk nicht mehr zu erreichen wenn einwählender Client und VPN Gegenstelle die selben IP-Adressbereiche aus z.B. 192.168.40.x mit Subnet-Mask 255.255.255.0 verwenden oder gibt es auch noch größere Probleme?

Der Client erhält eine einzige Adresse und die kann auch problemlos aus dem (lokalen) Netz der VPN-Gegenstelle sein - solange dort Proxy-ARP aktiviert (und die Adresse eindeutig) ist. Kritischer wird es, wenn die Adresse, die der Client zugewiesen bekommt im gleichen Netz liegt in dem auch der PC hängt, auf dem der Client läuft. Was dann passiert ist ganz und gar abhängig, von dem, was M$ als sinnvoll erachtet...

2. Zertifikate versus Pre-Shared-Key: was brungt mehr Sichherheit deiner Meinung nach?

Da braucht es keine Meinung - das ist eindeutig...

Pre-Shared Keys sind einerseits anfällig für Wörterbuch-Attacken, andererseits ist der Aggressive-Mode zusammen mit Pre-Shared-Keys "offline" angreifbar, d.h. ein Angreifer schickt ein einziges Paket an den Router und mit Hilfe der Antwort kann er den Key brechen ohne den Router zu behelligen. Ein "sicherer" Key sorgt zwar auch in diesem Szenario dafür, daß das brechen ein paar Jahrtausende braucht, aber dafür muß es auch ein "sicherer" Key sein (mindestens 16 zufällige Zeichen...)

Also wenn möglich *IMMER* Zertifikate verwenden...

3. allgemein zum Thema Sicherheit: Gibt es irgendwo eine Checkliste, wo man die Sicherheit der VPN-Verbindung prüfen bzw. verbessern kann (so in der Art nehm diese Schlüssellänge und das Proposal und ...)

Zu dem Thema steht selbst im Handbuch was...
generell gilt:

- möglichst mit Zertifikaten arbeiten...

- wenn Pre-Shared-Keys, dann die Regeln für sichere Paßwörter beachten

- Als Verschlüsselung auf 3DES (und erst recht auf DES) verzichten, weil diese mittlerweile "in Echtzeit" zu brechen sind.

- Möglichst lange Schlüssel verwenden (z.B. AES256 und DH Gruppe 2 oder 5)

- PFS aktivieren, damit es keine Schlüssel mehrfach verwendet werden (und auch hier Gruppe 2 oder 5 benutzen)

Gruß
Backslash