Gute Tag,
Ich habe einen Lancom 1781-4G soweit dass eine IPSEC Site2Site Tunnel zu einem NCP Gateway aufgebaut wird.
Wenn der Uplink in NAT/PAT Netzwerk ist, erkennt das Lcos sauber und stellt einen NAT-T verbindung her (list /Status/VPN/IKE -> nat-both).
Erhält das Gerät eine public IP (Docsis Modem) wird der Tunnel aufgebaut (isakmp UDP 500) aber das Gerät raportiert No-Nat und schickt die Daten per ESP (Prot 50).
Es ist nicht damit zu Rechnen das dieses VPN Gatewayverhalten Zeitnah verändert werden kann.
Es versteht sich von selbst, dass wir nicht SLL tunnel verwenden möchten.
Fragestellung:
Wie kann ich dem Lancom Router beibringen, UDP 4500 zu verwenden (NAT-T overroule).
gruss steini
VPN NAT-T overroule
Moderator: Lancom-Systems Moderatoren
Ahoi \
Danke für den Input bezüglich RFC 3947.
Zitat RFC:
If there is no NAT box between, there is no point in wasting
bandwidth by adding UDP encapsulation of packets. Thus, UDP-
Encapsulation SHOULD NOT be used.
Also, the initiator SHOULD NOT include both normal tunnel or
transport mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-
Transport in its proposals.
Das ist ein Statement - leider ist dieses Themengebiet so komplex - das es schwierig wird den Aufwand für eine Fehlersuche zu rechtfertigen.
Bei den heutigen Bandbreiten und dem vielen Müll innerhalb der Tunnels haben schon viele resigniert. Darum gibt es auch Produkte wie Riverbed und Optionen wie SSL Tunnel.
Auch Fakt ist dass RoadWarriors mit Public IPv4 immer rarer werden und es für den Support dann ein einfaches ist - der Leistungsfähigen vorOrt infrastruktur die Schuld zuzuweisen. Sie Empfehlen dann Plan B (GSM oder andere Nichtionisierende Strahlungen).
Aus Sicht der Betriebsicherheit wäre eine Option in diese Richtung (NAT-T overroule) einfacher, als ellenlange Versuche mit einem zusätzlichen Masqierten Private Interface oder gar einem seperaten 0815 Soho Router. Leider auch unter Ökonomischen aspekten.
Nun habe ich das RFC etwas abschweifend "Commentiert" - aber das Grundsätzliche Problem bleibt bestehen.
Fragestellung 1: Wo bleibt der ESP (Proto 50) traffic? wir haben keine indizien dass etwas am VPN Gateway ankommt.
Fragestellung 2: Warum wird ein Tunnel aufgebaut und für operativ erklärt (isakmp) obwohl ESP (Proto 50) nicht ankommt ?
Fragestellung 3: Warum kann der NCP Client(Win7) NAT-T an der public IP ?
Einzelne Punkte werde ich bei in den nächsten Tagen etwas vertiefter analysieren.
Gerne würde ich aber auch RFC 1149 implementieren - das beinhaltet auch einige unberechenbare Faktoren (sehr verlockend).
gruss steini
Danke für den Input bezüglich RFC 3947.
Zitat RFC:
If there is no NAT box between, there is no point in wasting
bandwidth by adding UDP encapsulation of packets. Thus, UDP-
Encapsulation SHOULD NOT be used.
Also, the initiator SHOULD NOT include both normal tunnel or
transport mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-
Transport in its proposals.
Das ist ein Statement - leider ist dieses Themengebiet so komplex - das es schwierig wird den Aufwand für eine Fehlersuche zu rechtfertigen.
Bei den heutigen Bandbreiten und dem vielen Müll innerhalb der Tunnels haben schon viele resigniert. Darum gibt es auch Produkte wie Riverbed und Optionen wie SSL Tunnel.
Auch Fakt ist dass RoadWarriors mit Public IPv4 immer rarer werden und es für den Support dann ein einfaches ist - der Leistungsfähigen vorOrt infrastruktur die Schuld zuzuweisen. Sie Empfehlen dann Plan B (GSM oder andere Nichtionisierende Strahlungen).
Aus Sicht der Betriebsicherheit wäre eine Option in diese Richtung (NAT-T overroule) einfacher, als ellenlange Versuche mit einem zusätzlichen Masqierten Private Interface oder gar einem seperaten 0815 Soho Router. Leider auch unter Ökonomischen aspekten.
Nun habe ich das RFC etwas abschweifend "Commentiert" - aber das Grundsätzliche Problem bleibt bestehen.
Fragestellung 1: Wo bleibt der ESP (Proto 50) traffic? wir haben keine indizien dass etwas am VPN Gateway ankommt.
Fragestellung 2: Warum wird ein Tunnel aufgebaut und für operativ erklärt (isakmp) obwohl ESP (Proto 50) nicht ankommt ?
Fragestellung 3: Warum kann der NCP Client(Win7) NAT-T an der public IP ?
Einzelne Punkte werde ich bei in den nächsten Tagen etwas vertiefter analysieren.
Gerne würde ich aber auch RFC 1149 implementieren - das beinhaltet auch einige unberechenbare Faktoren (sehr verlockend).
gruss steini
Hi steini,
Gruß
Backslash
gehen denn vom Absender ESP-Pakete ab? Ist da irgendwo ein Router zwischengeschaltet der ESP blockiert? Frag im Ernstfall deinen Provider und wenn er das bejaht: frag ihn auch, was das soll und drohe ihm ggf. mit Kündigung...Fragestellung 1: Wo bleibt der ESP (Proto 50) traffic? wir haben keine indizien dass etwas am VPN Gateway ankommt.
Weil die IKE-Verhandlung auf UDP-Port 500 läuft. Und wenn dein Provider ESP filtert, dann siehe oben... Normalerweise filtern Provider VPN-Traffic, wenn sie ihn extra vermarkten wollen (i.A. sind das Mobilfunkanbieter)... Dabei sperren sie direkt die UDP-Ports 500 und 4500, so daß du dann auch mit NAT-T nicht weiter kommst...Fragestellung 2: Warum wird ein Tunnel aufgebaut und für operativ erklärt (isakmp) obwohl ESP (Proto 50) nicht ankommt ?
Weil der Client vermutlich hinter einem NAT steht und somit die Bedingungen des RFC 3947 erfüllt sind - ich weiss, das ist nicht das, was du hören wolltest, aber leider weiss ich auch keine bessere Antwort...Fragestellung 3: Warum kann der NCP Client(Win7) NAT-T an der public IP ?
RFC 1149 wurde doch schon implementiert: http://www.blug.linux.no/rfc1149/index.htmlGerne würde ich aber auch RFC 1149 implementieren - das beinhaltet auch einige unberechenbare Faktoren (sehr verlockend).
Gruß
Backslash
Ahoi \
1:
Ja - Wireshark meldet outgoing ESP Proto 50 ans Docsis Modem.
Wir prototypen eine Art RoadWorriorszenario - daher ist der ISP(und Kündigung) irrelevant.
2:
Isakmp UDP 500 und Nat-t UDP 4500 OK.
GSM Fallback geht sauber (ist ein Private Range mit APN)
Monetariesierung des ISP -> SSL Tunnel / Barrierefreiheit / RFC 1149 etc.
3:
Wenn dann eine OS-InterneLösung. Somit suche ich eine gleichartige Funktion im Lancom.
4:
Das Ping und die Refernzuhr sind eindrücklich. Ich liebe das
Resumierend:
Nat-T Overroule wäre ein sinnvoller Workaround für einen KnownError (Itil). Sicher besser als noch komplexere Kontrukte zu implementieren. Zum Glück sind RFC's nicht Naturgesetzte
danke schön für die Antworten
gruss steini
1:
Ja - Wireshark meldet outgoing ESP Proto 50 ans Docsis Modem.
Wir prototypen eine Art RoadWorriorszenario - daher ist der ISP(und Kündigung) irrelevant.
2:
Isakmp UDP 500 und Nat-t UDP 4500 OK.
GSM Fallback geht sauber (ist ein Private Range mit APN)
Monetariesierung des ISP -> SSL Tunnel / Barrierefreiheit / RFC 1149 etc.
3:
Wenn dann eine OS-InterneLösung. Somit suche ich eine gleichartige Funktion im Lancom.
4:
Das Ping und die Refernzuhr sind eindrücklich. Ich liebe das
Resumierend:
Nat-T Overroule wäre ein sinnvoller Workaround für einen KnownError (Itil). Sicher besser als noch komplexere Kontrukte zu implementieren. Zum Glück sind RFC's nicht Naturgesetzte
danke schön für die Antworten
gruss steini
Nachtrag
Ahoi zusammen,
da ich in den letzten tagen mich auch etwas mit ipsec beschäftigt habe ist mir ja wieder eingefallen, dass die sachlage hier auch bei den rfc hängengeblieben ist.
daher möchte ich noch auf folgendes hinweisen.
http://www.shrew.net/static/help-2.1.x/ ... tings.html
gruss steini
da ich in den letzten tagen mich auch etwas mit ipsec beschäftigt habe ist mir ja wieder eingefallen, dass die sachlage hier auch bei den rfc hängengeblieben ist.
daher möchte ich noch auf folgendes hinweisen.
http://www.shrew.net/static/help-2.1.x/ ... tings.html
gruss steini