Die Telekom hilft Community zieht um und ist bis zum 8. Januar 2025 nur eingeschränkt zugänglich.
IPSec-VPN-Probleme über Speedport W 502V (Port-Weiterleitung, NAT-T, UDP 4500)
vor 16 Jahren
Hallo T-Online-Team!
(Ist ja rührend, wie nett Ihr Euch um die Probleme der Kunden kümmert, obwohl diese oft ausfallend oder ruppig werden - meist allerdings gerechtfertigt. Bei der Hardware, die Euer Einkauf und Management da so verbockt, ist das sicherlich nicht einfach. Also: Alle Achtung!)
Ich möchte über den "Speedport W 502V Typ A" (Firmware 1.19.00) einen Road-Warrior eine IPSec- VPN -Verbindung aufbauen lassen.
Über unzählige andere, auch niedrigpreisigere, Heim-DSL-Router ist das problemlos möglich. (Auch mit denselben beteiligten PCs und VPN -Gateways.) Daher bitte alle Ideen zu Fehlkonfigurationen an den anderen Komponenten sparen: Diese sind zigfach getestet und funktionieren einwandfrei.
Die IPSec-Verbindung wird normalerweise über UDP, Port 500 aufgebaut und mit NAT-Traversal über UDP, Port 4500 weitergeführt. (Das sollte jeder NAT/PAT-fähige DSL-Router im Schlaf beherrschen.)
(Durch den Einsatz von NAT-T wird nicht das IP-Protokoll ESP benutzt!)
(IPSec- VPN -Client von NCP / LANCOM, verschiedene Versionen;
VPN -Gateway z.B. Openswan, verschiedene Versionen; oder LANCOM-HW-Router)
Nebenbei: Es wird mit Zertifikaten gearbeitet. Keine Shared-Keys; selbstverständlich auch kein AH. Aber das spielt hier sowieso keine Rolle.
Nach dem Abschalten der üblen und versteckten Firewall-Funktionen (http://speedport.ip/hcti_sicherheit_fwall.stm) und dem Einrichten von "Port-Öffnung (dynamisch)" im "W 502V", beginnt bei VPN -Tunnelaufbau-Versuch der Schlüsselaustausch (IKE) über UDP, Port 500. Durch die die Erkennung von NAT wird die Kommunikation entsprechend NAT-Traversal auf UDP, Port 4500 umgeschaltet. Hier werden dann vom "W 502V" offenbar die Datenpakete verfälscht. Es erscheinen Meldungen wie "ISAKMP Hash Payload has an unknown value: xx" und "malformed payload in packet".
(Nebenbei: Dasselbe habe ich statt mit "Port-Öffnung (dynamisch)" auch mit statischer "Port-Weiterleitung" bzw. "Port-Umleitung" getestet. Selbstverständlich auch schön mit Resets des "W 502V". -> Kein Unterschied.)
Offenbar wird "nur" oder hauptsächlich die Kommunikation via Port 4500 versaut, denn ich habe zufällig nochmal das eigentlich problematischere "IPSec _ohne_ NAT-T" getestet. Dabei wird "nur" UDP, Port 500 und das "schwierige" IP-Protokoll ESP verwendet (statt NAT-T: UDP, Port 4500), an welchem viele Billig-DSL-Router scheitern.
Interessanterweise passiert dieser ESP-Verkehr den "W 502V" einigermaßen, und ein VPN -Tunnel kann erfolgreich aufgebaut werden. (Allerdings dauert der Aufbau öfter sehr lange, bis zu z.B. 60 Sekunden.)
IPSec ohne NAT-T von geNATetten Netze aus ist aber keine Option für Road-Warrior, da das mit anderen Problemen behaftet ist.
(Genauso ist Abschaltung des Routerteils des "W 502V" und Einwahl über PPPoE des PCs eine Option, wie hier im Forum öfter blödsinnig empfohlen wurde.)
Wann kann mit einer fehlerbereinigten Firmware für den "W 502V" grechnet werden? (Oder haben Käufer von DTAG -/T-Com-/T-Home-Hardware mit Ihrer Wahl von Produkten des Marktführers einen Fehler gemacht?)
Andere Käufer haben ja auch reichlich Probleme mit einfacher Port-Weiterleitung außerhalb des Ports 80, was wirklich auf erbärmliche Router-Software schließen läßt. (Wer ist eigentlich für diesen Mist verantwortlich?)
Viele Grüße und danke für die Unterstützung (im voraus),
Betatester
P.S. Daß diese Router-Attrappe schon im Neuzustand taiwanischer Elektronikmüll von "Firma" Arcadyan (Mutter: Compal) ist, ist bekannt. (Eigentlich sollte es für sowas minderwertiges Importverbote geben. Wenn nicht direkt wegen der üblen Minderwertigkeit, dann doch wenigstens wegen des Elektroabfallgesetzes.)
(Ist ja rührend, wie nett Ihr Euch um die Probleme der Kunden kümmert, obwohl diese oft ausfallend oder ruppig werden - meist allerdings gerechtfertigt. Bei der Hardware, die Euer Einkauf und Management da so verbockt, ist das sicherlich nicht einfach. Also: Alle Achtung!)
Ich möchte über den "Speedport W 502V Typ A" (Firmware 1.19.00) einen Road-Warrior eine IPSec- VPN -Verbindung aufbauen lassen.
Über unzählige andere, auch niedrigpreisigere, Heim-DSL-Router ist das problemlos möglich. (Auch mit denselben beteiligten PCs und VPN -Gateways.) Daher bitte alle Ideen zu Fehlkonfigurationen an den anderen Komponenten sparen: Diese sind zigfach getestet und funktionieren einwandfrei.
Die IPSec-Verbindung wird normalerweise über UDP, Port 500 aufgebaut und mit NAT-Traversal über UDP, Port 4500 weitergeführt. (Das sollte jeder NAT/PAT-fähige DSL-Router im Schlaf beherrschen.)
(Durch den Einsatz von NAT-T wird nicht das IP-Protokoll ESP benutzt!)
(IPSec- VPN -Client von NCP / LANCOM, verschiedene Versionen;
VPN -Gateway z.B. Openswan, verschiedene Versionen; oder LANCOM-HW-Router)
Nebenbei: Es wird mit Zertifikaten gearbeitet. Keine Shared-Keys; selbstverständlich auch kein AH. Aber das spielt hier sowieso keine Rolle.
Nach dem Abschalten der üblen und versteckten Firewall-Funktionen (http://speedport.ip/hcti_sicherheit_fwall.stm) und dem Einrichten von "Port-Öffnung (dynamisch)" im "W 502V", beginnt bei VPN -Tunnelaufbau-Versuch der Schlüsselaustausch (IKE) über UDP, Port 500. Durch die die Erkennung von NAT wird die Kommunikation entsprechend NAT-Traversal auf UDP, Port 4500 umgeschaltet. Hier werden dann vom "W 502V" offenbar die Datenpakete verfälscht. Es erscheinen Meldungen wie "ISAKMP Hash Payload has an unknown value: xx" und "malformed payload in packet".
(Nebenbei: Dasselbe habe ich statt mit "Port-Öffnung (dynamisch)" auch mit statischer "Port-Weiterleitung" bzw. "Port-Umleitung" getestet. Selbstverständlich auch schön mit Resets des "W 502V". -> Kein Unterschied.)
Offenbar wird "nur" oder hauptsächlich die Kommunikation via Port 4500 versaut, denn ich habe zufällig nochmal das eigentlich problematischere "IPSec _ohne_ NAT-T" getestet. Dabei wird "nur" UDP, Port 500 und das "schwierige" IP-Protokoll ESP verwendet (statt NAT-T: UDP, Port 4500), an welchem viele Billig-DSL-Router scheitern.
Interessanterweise passiert dieser ESP-Verkehr den "W 502V" einigermaßen, und ein VPN -Tunnel kann erfolgreich aufgebaut werden. (Allerdings dauert der Aufbau öfter sehr lange, bis zu z.B. 60 Sekunden.)
IPSec ohne NAT-T von geNATetten Netze aus ist aber keine Option für Road-Warrior, da das mit anderen Problemen behaftet ist.
(Genauso ist Abschaltung des Routerteils des "W 502V" und Einwahl über PPPoE des PCs eine Option, wie hier im Forum öfter blödsinnig empfohlen wurde.)
Wann kann mit einer fehlerbereinigten Firmware für den "W 502V" grechnet werden? (Oder haben Käufer von DTAG -/T-Com-/T-Home-Hardware mit Ihrer Wahl von Produkten des Marktführers einen Fehler gemacht?)
Andere Käufer haben ja auch reichlich Probleme mit einfacher Port-Weiterleitung außerhalb des Ports 80, was wirklich auf erbärmliche Router-Software schließen läßt. (Wer ist eigentlich für diesen Mist verantwortlich?)
Viele Grüße und danke für die Unterstützung (im voraus),
Betatester
P.S. Daß diese Router-Attrappe schon im Neuzustand taiwanischer Elektronikmüll von "Firma" Arcadyan (Mutter: Compal) ist, ist bekannt. (Eigentlich sollte es für sowas minderwertiges Importverbote geben. Wenn nicht direkt wegen der üblen Minderwertigkeit, dann doch wenigstens wegen des Elektroabfallgesetzes.)
15167
5
Das könnte Ihnen auch weiterhelfen
vor 17 Jahren
27214
0
5
Gelöst
1006
0
1
vor 13 Jahren
24865
0
20
vor 16 Jahren
16992
0
3
Telekom hilft Team
vor 16 Jahren
sehr geehrter Kunde,
"betatest" (Nickname) schrieb:
>Ich möchte über den "Speedport W 502V Typ A" (Firmware 1.19.00) einen
>Road-Warrior eine IPSec- VPN -Verbindung aufbauen lassen.
>Schlüsselaustausch (IKE)
Welche Version des Protokolls kommt dabei zum Einsatz?
Mit freundlichen Grüßen
Ihr T-Home-Team
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
http://forum.t-online.de/ -> Service-Foren
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0
Starter*in
vor 16 Jahren
IKEv1 wird verwendet.
Sie spielen wohl auf die Problematik an, daß IKEv2 Probleme mit manchen Routern hat, die "IPSec Passthrough" in Form von simpler Weiterreichung an den ersten IPSec-nutzenden geNATeten PC betreiben (also quasi dafür ungeNATet, besser gesagt: ungePATet, denn eigentlich geht's ja um Port Address Translation). Denn da funktioniert dann NAT-T wieder nicht richtig, weil da die Ports ja gerade eben nicht verändert werden (obwohl sie müßten), meine ich gelesen zu haben (selber nicht genau analysiert) - allerdings sollte diese Port-Nichtveränderung vom Router ja nur für den Port 500 stattfinden, und nur bei der initialen Kontaktaufnahme stören.
Für Port 4500 gibt's ja gar keinen Grund, den nicht ganz normal zu NATen/PATen. Da gab's ja noch nie eine Notwendigkeit, weil kein bestimmter Quellport gefordert war, wenn ich richtig informiert bin.
Und bei meinem Problem sind die Gegenstellen ja bereits auf Port 4500 umgeschwenkt - daher gehe ich von einem Firmwarefehler im "W 502V" aus, der auch Port-4500-Verkehr falsch behandelt.
Eigentlich müßte aber beides gehen, zumindest wenn man nur einen Road-Warrior hinter dem "W 502V" betreibt, denn eigentlich sollte ja alles relevante eben ungefährdet durch Routerbeeinflussung als Payload in UDP-4500-Paketen gekapselt sein.
-
Wenn ich so drüber nachdenke, könnte das o.g. zu IKEv2 ja auch eine Problematik bei herkömmlichem IKEv1 und NAT-T sein. Müßte ich nochmal analysieren.
Grüße,
betatester
0
Telekom hilft Team
vor 16 Jahren
Hallo Betatest,
"betatest" (Nickname) schrieb:
>IKEv1 wird verwendet.
>
>Sie spielen wohl auf die Problematik an, daß IKEv2 Probleme mit manchen
>Routern hat, die "IPSec Passthrough" in Form von simpler Weiterreichung
>an den ersten IPSec-nutzenden geNATeten PC betreiben
Nein, es ging uns darum, dass die Schwierigkeiten von IKEv1 in
Verbindung mit NAT und dynamischen IP-Adressen notorisch sind. Mit
IKEv2 wurden diese Schwierigkeiten angegangen und weitgehend gelöst,
deshalb sollten Sie es vielleicht einmal damit versuchen, sofern Ihnen
eine Umstellung möglich ist.
Mit besten Wünschen für das Weihnachtsfest
Ihr T-Home-Team
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
http://forum.t-online.de/ -> Service-Foren
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0
Starter*in
vor 16 Jahren
> Nein, es ging uns darum, dass die Schwierigkeiten von IKEv1 in
> Verbindung mit NAT und dynamischen IP-Adressen notorisch sind. Mit
> IKEv2 wurden diese Schwierigkeiten angegangen und weitgehend gelöst,
> deshalb sollten Sie es vielleicht einmal damit versuchen, sofern Ihnen
> eine Umstellung möglich ist.
IKEv2 gibt's ja noch gar nicht in allen Produkten. So eine Umstellung ist also eher nicht möglich bzw. nicht wirtschaftlich. Vorher kann man lieber 20 taiwanische Arcadyan-DSL-Router-Attrappen dem Elektroentsorger zuführen (mich dünkt, im Grunde wäre das auch die richtige Adresse gewesen, wo der Importeur sie hätte gleich abliefern sollen
Die Erweiterung "NAT-Traversal" (für IPSec/IKEv1) sorgt ja gerade für die Vermeidung/Umgehung der Probleme mit billigen NAT-Routern (IKE-Quellport zwingend UDP 500 und das nicht weitergeleitete Protokoll ESP).
Ich weiß nicht, was der "W 502V" da abstruses macht: IPSec ohne NAT-T läßt er ja durch (zumindest, wenn sich nur _ein_ Roadwarrior in seinem geNATteten Netz befindet). Warum er UDP-4500-Verkehr behindert, wird mir nicht klar. Das müßte eigentlich genauso IKEv2-Verhandlungen behindern.
Denn IKEv2 ist ja quasi "IKEv1 + NAT-T - ein paar Meldungen".
Ich befürchte, das T-Home-Team möchte den Firmwarefehler nicht mal als solchen erkennen!?
Gruß,
Betatest
0
Telekom hilft Team
vor 16 Jahren
"betatest" (Nickname) schrieb:
>Ich befürchte, das T-Home-Team möchte den Firmwarefehler nicht mal als
>solchen erkennen!?
Das ist richtig - in den von Ihnen (teilweise sehr unsachlich)
geschilderten Schwierigkeiten bei der Einrichtung einer VPN -Verbindung
sehen wir keinen Fehler oder Mangel des Speedport W 502V. Dass der
Speedport W 502V für Ihre Anforderungen nicht das passende Gerät ist,
sehen wir allerdings auch so.
Ein gesundes und erfolgreiches 2009 wünscht
Ihr T-Home-Team
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
http://forum.t-online.de/ -> Service-Foren
-- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0