VPN mit LANCOM VPN-Client hinter NAT an LANCOM 1722

[Hagen2000]

Ich versuche folgende Konfiguration zum Laufen zu bringen:

Laptop mit LANCOM VPN-Client, betrieben im Home-Office hinter einem Netgear WG834GB Router (mit NAT).

In der Zentrale steht ein LANCOM 1722 DSL-Router. Mit desses Assistenten habe ich einen VPN-Zugang für den VPN-Client konfiguriert und auch die passende .ini-Datei erzeugen lassen. Mit dieser wurde dann auf dem Laptop der VPN-Client aufgesetzt. Die Zentrale registriert sich bei DynDNS um das Fehlen einer statischen IP-Adresse zu umgehen.
Verschiedene VPN-Tunnel zu anderen LANCOM und nicht-LANCOM-Routern funktionieren einwandfrei und sind täglich im Betrieb.

Der Laptop kann jedoch keine Verbindung aufbauen. Ich habe versuchsweise NAT-T auf dem LANCOM 1722 aktiviert, jedoch ohne Verbesserung. Ein Mitschneiden des Netzwerktraffics auf dem Laptop ergibt, dass der LANCOM 1722 auf die isakmp-Anfrage unter UDP-Port 500 mit einer ICMP-Message "Port unreachable" antwortet. Dasselbe passiert bei aktivierter UDP-encapsulation (dann mit UDP-Port 4500).

Bin jetzt ratlos, wie ich den Fehler weiter einkreisen kann.
Ich habe versuchsweise sämtliche Firewalls deaktiviert - ohne Erfolg.
Der Netgear WG834GB ist angeblich VPN-passthrough-fähig.
Ein Router-zu-Router-VPN-Tunnel zwischen Netgear WG834GB und LANCOM 1722 funktioniert ebenfalls.
Kann im LCOS (z.B. über eine ssh-Sitzung) so etwas ähnliches wie ein netstat ausgelöst werden, um zu sehen, welche Dienste/Ports abgehört werden? Andererseits funktionieren ja andere VPN-Tunnel...

[backslash]

Hi Hagen2000

Ein Mitschneiden des Netzwerktraffics auf dem Laptop ergibt, dass der LANCOM 1722 auf die isakmp-Anfrage unter UDP-Port 500 mit einer ICMP-Message "Port unreachable" antwortet

Dann mag das LANCOM etwas an dem IKE-Paket nicht - sobald das IKE-Paket fehlerhaft ist, lehnt das LANCOM es mit einem "Port unreachable" ab, um Portscannern die Arbeit zu erschweren...

Kann im LCOS (z.B. über eine ssh-Sitzung) so etwas ähnliches wie ein netstat ausgelöst werden, um zu sehen, welche Dienste/Ports abgehört werden?

ein netstat gibt es nicht. Du kannst - bzw. solltest - aber einen VPN-Status-Trace (trace # vpn-status) machen um zu sehen, warum das LANCOM die Einwahl ablehnt

Gruß
Backslash

[Hagen2000]

Hallo Backslash,

vielen Dank für die schnelle Antwort!

Hi Hagen2000

Dann mag das LANCOM etwas an dem IKE-Paket nicht - sobald das IKE-Paket fehlerhaft ist, lehnt das LANCOM es mit einem "Port unreachable" ab, um Portscannern die Arbeit zu erschweren...

So etwas ähnliches hatte ich insgeheim schon vermutet.

ein netstat gibt es nicht. Du kannst - bzw. solltest - aber einen VPN-Status-Trace (trace # vpn-status) machen um zu sehen, warum das LANCOM die Einwahl ablehnt.

Werde ich machen.

Weil Du das Thema IKE angesprochen hast:
Der IkeIdStr lautet "FIRMENLAPTOP@xxx.local" (xxx steht für unseren Firmennamen). Kann es eine Rolle spielen, dass diese Id sich auf die lokale Domäne "xxx.local" bezieht?

Der Name der Verbindung sollte doch keine Rolle spielen - oder?
In die .ini-Datei hatte der Setup-Assistent den Namen "Name=XXX-DSL-Router-FIRMENLAPTO" eingetragen, in der Liste der VPN-Verbindungen heißt es jedoch einfach "FIRMENLAPTOP".

[Hagen2000]

Hallo Backslash,

hier nun der Trace:

[VPN-Status] 2008/07/25 21:47:38,080
IKE info: Phase-1 failed for peer HAGENPRIVAT: remote side has AGGRESSIVE mode, local side has MAIN mode
IKE log: 214738 Default exchange_setup_p1: expected exchange type MAIN got AGGRESSIVE


[VPN-Status] 2008/07/25 21:47:45,060
IKE log: 214745 Default message_recv: invalid message id


[VPN-Status] 2008/07/25 21:47:45,060
IKE log: 214745 Default dropped message from 88.217.58.148 port 1 due to notification type INVALID_MESSAGE_ID


[VPN-Status] 2008/07/25 21:47:45,060
IKE info: dropped message from peer unknown 88.217.58.148 port 1 due to notification type INVALID_MESSAGE_ID


Also das Problem scheint zu sein:
Der LANCOM 1722 verwechselt den VPN-Aufbauwunsch für den VPN-Tunnel "FIRMENLAPTOP" mit meinem Router-zu-Router-VPN-Zugang "HAGENPRIVAT". Das liegt wohl daran, dass ich den Laptop bei mir zuhause ins LAN gehängt habe. Der LANCOM 1722 scheint anhand meiner IP-Adresse (im Beispiel 88.217.58.148) den Tunnel "HAGENPRIVAT" zu bevorzugen (dieser hat auch wirklich MAIN mode konfiguriert, so erklären sich die oben stehenden Fehlermeldungen).

Wie kann ich das Problem umgehen?

[backslash]

Hi Hagen2000

hast du einen etwa Tunnel zwischen dem Netgear und dem LANCOM konfiguriert und versuchst parallel dazu mit dem Client eine weitere Verbindung aufzubauen?

Das kann mit Preshared Keys nicht funktionieren... Hier mußt du entweder beide Verbindungen mit Zertifikaten einrichten (wobei natürlich sowohl der Netgear als auch der Client ein eigenes Zertifikat benötigen) oder beide Verbindungen als Aggressive-Mode Verbindungen betreiben oder mit dem Client *durch* den ersten Tunnel hindurch einen weiteren aufbauen.

Gruß
Backslash

[Hagen2000]

Hallo Backslash,

ja, genau das habe ich momentan (unabsichtlich) konfiguriert. Letztlich ist das nur ein Testszenario, denn von meinem Heimnetz aus benutze ich ja normalerweise den Tunnel zwischen Netgear und LANCOM 1722. Ich wollte einfach den VPN-Client von einem Firmen-externen Standort aus testen und habe diesen Versuch von zuhause aus gestartet.

Vielen Dank schon mal für die Hilfe!

Kennst Du eine Website, die detaillierte Informationen über die Authentisierung beim VPN, den Umgang mit Zertifikaten usw. beschreibt?