VPN zwischen zwei 1811 - beide hinter NAT

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Hallo,

Ich hab bei einem Freund zwei 1811 in Betrieb genommen, einen bei ihm im Büro (192.168.100.0), einen daheim (192.168.200.0). Beide sind über VPN gekoppelt. Die Verbindung läuft via Main Mode, da beide Standorte über einen Dyndns Dienst stets den gleichen DNS Namen haben.

Auf beiden Seiten ist das Modem des Providers selbst als Router eingerichtet - rückt also nur eine private IP raus. Somit haben auf beiden Seiten die Lancoms WAN seitig 10.0.0.140 und das Modem des Providers als Gateway. Zusätzlich ist auf dem Modem der Lancom als "DMZ Host" eingetragen - sprich ALLE Ports werden an den Lancom weitergeleitet.

Damit - und mit aktivierten NAT Traversal - war bisher problemlos das VPN zwischen den beiden Netzen möglich und ist seit Jahren gut gelaufen. Seit kurzem aber nicht mehr, obwohl soweit mir bekannt kein Parameter verändert wurde. Es wurde nur mal ein Update auf 8.0 RU2 gemacht, da kann ich aber nicht mehr sagen ob es exakt seit dem nicht mehr geht.

Darstellen tut sich das so das beide Geräte im Lanmonitor "Dynamic VPN - Zeitüberschreitung während Signalisierung oder Authentifizierung (Initiator) [0x1105]" melden. Die jeweilige Gegenseite wird aber korrekt aufgelöst, die aktuelle IP unter "Entfernets Gateway" stimmt.

In einem Trace stellt sich das wie folgt dar:

Code:

IKE info: Phase-2 SA Timeout (Hard-Event) for peer PRIVAT set to 2000 seconds (Initiator)

[VPN-Status] 2010/12/04 15:39:23,100
IKE info: Phase-2 [inititiator] done with 2 SAS for peer PRIVAT rule ipsec-0-PRIVAT-pr0-l0-r0
IKE info: rule:' ipsec 192.168.100.0/255.255.255.0 <-> 192.168.200.0/255.255.255.0 '
IKE info: SA ESP [0x3b1e8171] alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x26573b60] alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1600 sec/160000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 10.0.0.140 dst: 188.23.109.130

[VPN-Status] 2010/12/04 15:39:24,100
VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.109.130)

VPN-Status] 2010/12/04 15:41:13,780
VPN: connection for PRIVAT (188.23.109.130) timed out: no response

[VPN-Status] 2010/12/04 15:41:13,780
VPN: Error: IFC-I-Connection-timeout-dynamic (0x1105) for PRIVAT (188.23.109.130)

[VPN-Status] 2010/12/04 15:41:13,790
selecting next remote gateway using strategy eFirst for PRIVAT
=> no remote gateway selected

was mich hier etwas stutzig macht ist die Zeile "IKE info: tunnel between src: 10.0.0.140 dst: 188.23.109.130". Kann es sein das der gegnerische Lancom versucht die Pakete an 10.0.0.140 zurückzuschicken? Beziehungsweise - jetzt wo ich das so schreibe fällt mir ein: Kann es ein Problem sein das beide Lancoms WAN seitig die selbe Adresse haben? Das war nämlich glaube ich auch nicht immer so als es noch funktionierte.

Ich hab auch schon beide seiten auf SSL Kapselung umgestellt (was bei heiklen NAT Situationen auch schon mal geholfen hat), ändert aber gar nichts an dem Verhalten.

Vielleicht hat sonst noch jemand eine Idee was ich versuchen könnte. Vielen Dank im voraus.

Anmeldungsdatum: 10.02.2010 Beiträge: 436 Wohnort: Hamburg

Hallo tbc233,

was mich wundert das die Verbindung im MainMode funktioniert haben soll.

Denn bei MainMode wird die WAN-Port Adresse, also in Deinem fall eine Private Adresse die mit der DYNDNS Adresse nichts zu tun hat, zum Verbindungsaufbau herangezogen.
Eigendlich sollte es auch nicht funktionieren.

Du solltest auf AgressivMode umstellen ,
auf einer Seite 9999 einstellen und als Gegenstelle die DYNDNS Adresse eintragen
und auf der Gegenstelle
auf 0 stellen und in Gegenstelle 0.0.0.0 eintragen

Im AgressivMode fragt er nicht die GegenstellenIP ab und nimmt von jeder IP den Verbindungsaufbau an, der die Richtige PPP Einwahl hat.

Gruss ... Cool

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Danke für Deine Antwort - wie gesagt, in dem Moment wo ich es geschrieben haben kam mir ein ganz ähnlicher Gedanke. Das komische ist aber das es definitiv funktioniert hat. Ich weiß das deswegen so genau weil die Internetzugänge die er vorher hatte kein NAT dazwischen hatte. Als er dann den Produktwechsel gemacht hat, haben wir an der Konfiguration nichts verändert - mit Ausnahme des Portforwardings am Provider-Router - und es wurde problemlos wochenlang weiter über die VPN Strecke gearbeitet...

Ich werd mal den Aggressive Mode probieren.

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Ich hab jetzt mal beide Geräte auf Aggressive Mode umgestellt. Jetzt schauts schon etwas besser aus, Zustande kommen tut die Verbindung aber immer noch nicht:

Code:

[VPN-Status] 2010/12/05 18:34:26,160
IKE info: The remote server 188.23.201.33:443 (TCP) peer PRIVAT id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 188.23.201.33:443 (TCP) peer PRIVAT id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server 188.23.201.33:443 (TCP) peer PRIVAT id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2010/12/05 18:34:26,160
IKE info: Phase-1 remote proposal 1 for peer PRIVAT matched with local proposal 1

[VPN-Status] 2010/12/05 18:34:26,260
IKE info: Phase-1 [inititiator] for peer PRIVAT between initiator id 10.0.0.140, responder id 10.0.0.144 done
IKE info: SA ISAKMP for peer PRIVAT encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)
IKE info: TCP/SSL encapsulation enabled

[VPN-Status] 2010/12/05 18:34:26,260
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer PRIVAT set to 86400 seconds (Initiator)

[VPN-Status] 2010/12/05 18:34:26,260
IKE info: Phase-1 SA Timeout (Hard-Event) for peer PRIVAT set to 108000 seconds (Initiator)

[VPN-Status] 2010/12/05 18:34:26,630
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer PRIVAT set to 1600 seconds (Initiator)

[VPN-Status] 2010/12/05 18:34:26,630
IKE info: Phase-2 SA Timeout (Hard-Event) for peer PRIVAT set to 2000 seconds (Initiator)

[VPN-Status] 2010/12/05 18:34:26,630
IKE info: Phase-2 [inititiator] done with 2 SAS for peer PRIVAT rule ipsec-0-PRIVAT-pr0-l0-r0
IKE info: rule:' ipsec 192.168.100.0/255.255.255.0 <-> 192.168.200.0/255.255.255.0 '
IKE info: SA ESP [0x59fdaac6] alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x123ed48b] alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1600 sec/160000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 10.0.0.140 dst: 188.23.201.33

[VPN-Status] 2010/12/05 18:34:27,630
VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.201.33)

[VPN-Status] 2010/12/05 18:34:28,630
VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.201.33)

[VPN-Status] 2010/12/05 18:34:29,630
VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.201.33)

[VPN-Status] 2010/12/05 18:34:30,630
VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.201.33)

[VPN-Status] 2010/12/05 18:34:31,530
IKE info: Delete Notification received for Phase-2 SA ipsec-0-PRIVAT-pr0-l0-r0 peer PRIVAT spi [0x59fdaac6]

[VPN-Status] 2010/12/05 18:34:31,530
IKE info: Phase-2 SA removed: peer PRIVAT rule ipsec-0-PRIVAT-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [59fdaac6 ] [123ed48b ]

[VPN-Status] 2010/12/05 18:34:31,630
VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.201.33)

[VPN-Status] 2010/12/05 18:34:31,740
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-PRIVAT peer PRIVAT cookies [ba097f639ffb2369 0dd539c5354aa9c8]

[VPN-Status] 2010/12/05 18:34:31,740
IKE info: Phase-1 SA removed: peer PRIVAT rule PRIVAT removed

[VPN-Status] 2010/12/05 18:34:31,740
VPN: PRIVAT (188.23.201.33) disconnected

Übrigens Anmerkung am Rande: Eine Verbindung zu den Standorten mittels VPN-Client funktionert problemlos.

Anmeldungsdatum: 10.02.2010 Beiträge: 436 Wohnort: Hamburg

Hallo tbc233,

wie hast Du das ganze den Eingerichtet, denn etwas stimmt ja nicht.

Alles mit der PPP Anmeldung richtig gemacht und ohne IPSec over HTTPS

Gruß ... Cool

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Im wesentlichen mittels Wizard "Zwei Netze verbinden", anschließend beide auf Aggrssiv umgestellt und bei einem der beiden das Gateway auf 0.0.0.0 gestellt und die Haltezeit auf 0.

ipsec over https hab ich nur mal testweise auf beiden seiten aktiviert in der hoffnung das ich dann besser durch die NAT Situation komme. Wenn ich es abschalte ist das Ergebnis im wesentlichen das selbe mit Ausnahme der https spezifischen Zeilen.

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4568 Wohnort: Aachen

Hi tbc233,

der Punkt ist dieser:

Zitat:

VPN: no dynamic VPN authentication packet recevied so far for PRIVAT (188.23.201.33)

sobald du dynamic VPN aktiviert hast, erwartet das LANCOM auch von der anderten Seite dynamic VPN-Pakete, denn in denen werden DNS- und NBNS-Server übermittelt. Das Ganze funktioniert durch ein NAT aber nur, wenn es über UDP läuft und auf der Responder-Seite auch der UDP-Port 87 auf das LANCOM weitergeleitet wird. Hier scheint auf der Responder-Seite genau dieser Port 87 nicht weitergeleitet zu werden.

In dem Moment, in dem das Portforwarding eingerichtet ist, kannst duach wieder auf Main-Mode umschalten, denn die SA-Aushandlung hat ja auch vorher schon funktioniert (wegen der dyndns-Geschichte, nicht wegen des dynamic VPN)...

Du kannst das dynamic VPN aber auch ganz abschalten und DNS sowie NBNS-Server manuell in der IP-Parameterliste eintragen

Gruß
Backslash

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Hallo Backslash,

Das heisst ich bin mit meiner Meinung nicht auf dem Holzweg das das schonmal funtioniert hat so mit Main Mode?

Zum Dynamic Paket:
Das ist ja auch sowas was ich nicht verstehe - es wär eigentlich auf beiden Seiten "Kein dynamisches VPN" aktiviert. Auch die Weiterleitung des Port 87 sollte durch das Eintragen des Lancoms als "DMZ-Host" beim vorgeschalteten Router gewährleistet sein...

Anmeldungsdatum: 10.02.2010 Beiträge: 436 Wohnort: Hamburg

Hallo tbc233,

nur auf agressivemode reicht so nicht Du musst auf beiden Seiten noch folgendes Einstellen:

Auf beiden Seiten einnen PPP Eintrag mit gegenläufigen Benutzernamen (die muessen zu 100% stimmen) mit Password

und unter VPN auf Dynamisches VPN (UDP)

dann sollte es klappen

Gruss ... Cool

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4568 Wohnort: Aachen

Hi tbc233

Zitat:

es wär eigentlich auf beiden Seiten "Kein dynamisches VPN" aktiviert

dann hast du aber den NetBIOS-Proxy auf den VPN-Tunnel geschaltet. Sobald der NetBIOS-Proxy an ist und für die Verbindung der NBNS-Server der Gegenseite (also die interne IP des gegenüberliegenden LANCOMs) nicht in der IP-Parameterliste eingetragen ist, wird dynamic VPN aktiviert.

Gruß
Backslash

Anmeldungsdatum: 01.02.2005 Beiträge: 275

backslash hat folgendes geschrieben:

Hi tbc233

Dann hast du aber den NetBIOS-Proxy auf den VPN-Tunnel geschaltet. Sobald der NetBIOS-Proxy an ist und für die Verbindung der NBNS-Server der Gegenseite (also die interne IP des gegenüberliegenden LANCOMs) nicht in der IP-Parameterliste eingetragen ist, wird dynamic VPN aktiviert.

Stimmt. Das trägt aber der Wizard so ein wenn man Netbios über IP-Routing aktiviert (was ich meistens brauche damit die Leute auf Ihre Shares kommen). Da ich Netz-zu-Netz VPNS meistens über den Wizard mache sind dann wohl alle meine VPNs dymamische welche.

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Hallo,

Ich muss das Thema nochmal anwärmen, da es mir bei verschiedenen Kunden verstärkt Probleme zu machen scheint.

Wenn man zwei Netzwerke via Wizard koppelt und dabei das Häkchen Netbios over IP setzt, dann wird automatisch ein Eintrag auf den Tunnel in der Netbios über IP Routingtabelle erstellt. Da die meisten meiner User auf Freigaben etc. zugreifen möchten, setze ich das Häkchen eigentlich immer.

Durch den Umstand den Backslash erklärt hat (warum das automatisch alle Einstellungen eines VPNs overruled und ein dynamisches VPN macht ist mir nicht klar) sind also somit alle meine bisherigen VPNs seit 2003 dynamisch. Gut - meinetwegen - solange es funktioniert.

In letzter Zeit habe ich aber vermehrt Probleme die aus dieser Richtung kommen. Nicht nur das oben beschriebene. Gerade gestern habe ich ein neues VPN erstellt und musste feststellen das dieses nach erfolgreichem Aufbau nach etwa 30 Sekunden immer wieder abgebaut wurde mit "No Proposal chosen". Dem Trace entnahm ich dann das hier wiederum irgendwelche V2 Auth. Pakete nicht empfangen wurden (obwohl kein NAT oder so). Als ich dann die Einträge aus den Netbios Tabellen entfernt habe, stabilisierte sich das ganze sofort und alles war im Butter.

Kann mir jemand erklären was hier genau schiefläuft? Hat sich hier bei einer LCOS Version mal was getan? Warum überhaupt dieses umswitchen auf Dynamic VPN aufgrund solch eines Eintrages?

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4568 Wohnort: Aachen

Hi tbc233

Zitat:

Kann mir jemand erklären was hier genau schiefläuft? Hat sich hier bei einer LCOS Version mal was getan? Warum überhaupt dieses umswitchen auf Dynamic VPN aufgrund solch eines Eintrages?

die 8.00.0221RU2 erzwingt, daß die Gegenseite dynamic VPN machen muß, wenn der NetBIOS-Proxy aktiv ist und kein Eintrag in der IP-Parameterliste existiert über den der entfertnte NBNS ermittelt werden könnte, denn in den dynamic VPN-Paketen werden DNS und NBNS der Gegenseite übermittelt. Der NetBIOS-Proxy funktioniert schließlich nur dann, wenn der NBNS der Gegenseite bekannt ist. Desweiteren kann der NetBIOS-Proxies nur korrekt genutzt werden, wenn die Gegenseite ein LANCOM ist. Das ist auch der Grund, weshalb dynamic VPN aktiviert wird, sobald der NetBIOS-Proxy auf eine VPN-Verbindung gelegt wird.

Diese Änderung ist aufgrund eines anderen Kunden-"Fehlers" hereingekommen um Fehlkonfigurationen direkt sichtbar zu machen. Leider erweist sie sich als sehr problematisch, weil offenbar viele Leute die Verknüpfung von dynamic VPN und NetBIOS-Proxy nicht kennen und somit ihre VPN-Verbindungen nicht auf dynamisch geschaltet haben, wodurch dann eine eigentlich bestehende Verbindung mit der Meldung "VPN: no dynamic VPN authentication packet received so far for Gegenstelle" wieder abgebaut wird.

Gruß
Backslash

Anmeldungsdatum: 01.02.2005 Beiträge: 275

Oh Mann. Langsam beginne ich das zu verstehen. Eine folgenschwere Änderung meiner Meinung nach.
Übrigens konnte ich auch obigen Fall (2x NAT) wieder wunderbar zum Laufen bringen indem ich die Einträge aus den Netbios Tabellen entfernt habe. Main Mode Verbindung mit 2x hinter NAT läuft wieder wunderbar.

Auch dürfte sich durch diese Änderung in der RU2 eine gewissen Inkompatibilität zu älteren Versionen ergeben haben. Ich beobachtete her entsprechende Probleme bei einem VPN zwischen einer 8.00RU2 und einer 7.70 (was normalerweise kein Problem ist).