6
NAT-T - VPN Problem mit ext Dienstleister
Hallo Admins,
wir haben ein Problem bei einem Kunden, welcher von einem Softwarehaus via VPN Tunnel betreut wird.
Es ist ein extrem abenteuerliches Konstrukt...
SH = Softwarehaus
KD = Kunde
Nun... als erstes stellt das Softwarehaus folgende Anforderung:
Das sie viele Kunden betreuen, werden jedem Kunden ein Netz zugeteilt, welches hinter dem VPN Tunnel via NAT aufgebaut wird. Soweit auch OK.
So ergibt sich vorläufig folgende Kombination:
VPN -> Virtuelles Netz -> NAT -> Physisches Netz
Soweit auch noch kein Problem. Nun NATet das Softwarehaus aber ebenfalls, damit sie bei allen Kunden mit nur einer IP kommen.
Also...
SH Netz -> SH EinheitsIP -> Ext.IP SH -> VPN -> Ext. IP KD -> Virtuelles Netz -> Physisches Netz
Nun, nach kommen die Kollegen vom SH mit der Aussage, das ihr VPN Router hinter einem weiteren Router hängt.
Also...
SH Netz -> SH EinheitsIP und VPN Start -> Ext.IP SH -> Ext. IP KD und VPN Ende -> Virtuelles Netz -> NAT -> Physisches Netz
Oder in Geräten
Rechner -> Bintec -> Cisco -> Internet -> Checkpoint -> Rechner
Das ist eine kranke Konstruktion, aber das SH möchte es so.
Jedenfalls Schwebt das Packet beim SH los, wird auf der Bintec zur EingheitsIP geNATet, geht von da in den Tunnel, welcher über die Cisco zu unserer Checkpoint gespannt ist, fällt aus dem Tunnel beim KD wieder raus, möchte zur virtuellen IP, wird geNATed und erreicht die Physische IP.
Soweit klappt es auch, das Packet kommt bei unserem Server an. Aber nun muss es auch wieder zurück.
Das Packet schwebt beim Server los, wir zurückgenattet, fällt in den Tunnel und verschwindet für meine LOG- Möglichkeiten.
Jetzt fängt das Problem an.
Da der VPN Endpunkt beim SH ja hinter einem anderen Router liegt, müssen wir unser Firewall sagen das der Tunnel mit NAT-T aufgebaut werden muss.
Es gibt aber bei der Safe@Office keine Einstellmöglichkeit um das zu forcen. Wenn ich den Tunnel von uns aufbaue erkennt die Checkpoint automatisch das NAT-T benötigt wird, alles gut.
ABER... Wenn aber das SH den Tunnel aufbaut, erkennt unsere FW quasi nicht, das die NAT-T praktiziert, schaltet es aus und es kommen keine Packete beim SH an.
Jetzt (endlich) die Frage:
Gibt es irgendwas was wir noch tun können, um diesen NAT Irrsinn dochnoch zum laufen zu bringen? Standartmäßig baut ja das SH den Tunnel auf um zu helfen.
Kann ich dem Tunnel irgendwas mitgeben, damit die Packete auf der anderen Seite ankommen? Eine art manuelles NAT-T?
Könne die irgendwas mitgeben, woran unsere FW merkt, das die NAT-T Praktizieren?
Danke für alle die überhaupt bis hierhergekommen sind mit lesen
wir haben ein Problem bei einem Kunden, welcher von einem Softwarehaus via VPN Tunnel betreut wird.
Es ist ein extrem abenteuerliches Konstrukt...
SH = Softwarehaus
KD = Kunde
Nun... als erstes stellt das Softwarehaus folgende Anforderung:
Das sie viele Kunden betreuen, werden jedem Kunden ein Netz zugeteilt, welches hinter dem VPN Tunnel via NAT aufgebaut wird. Soweit auch OK.
So ergibt sich vorläufig folgende Kombination:
VPN -> Virtuelles Netz -> NAT -> Physisches Netz
Soweit auch noch kein Problem. Nun NATet das Softwarehaus aber ebenfalls, damit sie bei allen Kunden mit nur einer IP kommen.
Also...
SH Netz -> SH EinheitsIP -> Ext.IP SH -> VPN -> Ext. IP KD -> Virtuelles Netz -> Physisches Netz
Nun, nach kommen die Kollegen vom SH mit der Aussage, das ihr VPN Router hinter einem weiteren Router hängt.
Also...
SH Netz -> SH EinheitsIP und VPN Start -> Ext.IP SH -> Ext. IP KD und VPN Ende -> Virtuelles Netz -> NAT -> Physisches Netz
Oder in Geräten
Rechner -> Bintec -> Cisco -> Internet -> Checkpoint -> Rechner
Das ist eine kranke Konstruktion, aber das SH möchte es so.
Jedenfalls Schwebt das Packet beim SH los, wird auf der Bintec zur EingheitsIP geNATet, geht von da in den Tunnel, welcher über die Cisco zu unserer Checkpoint gespannt ist, fällt aus dem Tunnel beim KD wieder raus, möchte zur virtuellen IP, wird geNATed und erreicht die Physische IP.
Soweit klappt es auch, das Packet kommt bei unserem Server an. Aber nun muss es auch wieder zurück.
Das Packet schwebt beim Server los, wir zurückgenattet, fällt in den Tunnel und verschwindet für meine LOG- Möglichkeiten.
Jetzt fängt das Problem an.
Da der VPN Endpunkt beim SH ja hinter einem anderen Router liegt, müssen wir unser Firewall sagen das der Tunnel mit NAT-T aufgebaut werden muss.
Es gibt aber bei der Safe@Office keine Einstellmöglichkeit um das zu forcen. Wenn ich den Tunnel von uns aufbaue erkennt die Checkpoint automatisch das NAT-T benötigt wird, alles gut.
ABER... Wenn aber das SH den Tunnel aufbaut, erkennt unsere FW quasi nicht, das die NAT-T praktiziert, schaltet es aus und es kommen keine Packete beim SH an.
Jetzt (endlich) die Frage:
Gibt es irgendwas was wir noch tun können, um diesen NAT Irrsinn dochnoch zum laufen zu bringen? Standartmäßig baut ja das SH den Tunnel auf um zu helfen.
Kann ich dem Tunnel irgendwas mitgeben, damit die Packete auf der anderen Seite ankommen? Eine art manuelles NAT-T?
Könne die irgendwas mitgeben, woran unsere FW merkt, das die NAT-T Praktizieren?
Danke für alle die überhaupt bis hierhergekommen sind mit lesen
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 172889
Url: https://administrator.de/forum/nat-t-vpn-problem-mit-ext-dienstleister-172889.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
6 Kommentare
Neuester Kommentar
NAT-T nutzt UDP 4500. Das musst du entsprechend freigeben, sonst können die Port Informationen die das ESP und IKE nutzt nicht transparent übertragen werden. Wenn das geblockt ist kommt kein Tunnel zustande.
Eine andere Möglichkeit hast du de facto nicht, es sei denn du steigst auf ein VPN protokoll um was erheblich besser per NAT und Firewall behandelt werden kann wie SSL zum Beispiel (Open VPN und SSL VPNs)
Eine andere Möglichkeit hast du de facto nicht, es sei denn du steigst auf ein VPN protokoll um was erheblich besser per NAT und Firewall behandelt werden kann wie SSL zum Beispiel (Open VPN und SSL VPNs)
Der Tunnel kommt ja zu stande, es kommen nur keine Packete an der Gegenstelle an. Dh Pase 1 und 2 werden erfolgreich aufgebaut.
Wie und wo müsste ich denn die Regel positionieren, damit es funktioniert?
Ich hätte versucht: Allow VPN -> Checkpoint : 4500 UDP
Es gibt schon folgende Allow Regeln:
SH VPN -> Physikalisches Netz
Physikalisches Netz -> SH VPN
Diese Reglen greifen erfolgreich wenn wir den Tunnel aufbauen (sieht man im LOG)
Und das SH unterstützt nur das Standart IPSEC.
Wie und wo müsste ich denn die Regel positionieren, damit es funktioniert?
Ich hätte versucht: Allow VPN -> Checkpoint : 4500 UDP
Es gibt schon folgende Allow Regeln:
SH VPN -> Physikalisches Netz
Physikalisches Netz -> SH VPN
Diese Reglen greifen erfolgreich wenn wir den Tunnel aufbauen (sieht man im LOG)
Und das SH unterstützt nur das Standart IPSEC.
Wenn der Tunnel wirklich mit Phase 1 und auch 2 zustande kommt ist es ja de facto kein VPN Problem ! Dann kann es nur noch die Produktivdaten selber betreffen im Tunnel die dann an irgendeiner FW Seite an der sie aus dem Tunnel kommen aufgrund falscher IPs usw. hängenbleiben !!
Bei dem 1000fachen geNATe auch nicht weiter verwunderlich das da ggf. eine Regel falsch ist ?!
Du kannst doch immer mit Traceroute oder Pathping schrittweise sehen wie weit du kommst. Da wo Schluss ist ist auch der Fehler !
Bei dem 1000fachen geNATe auch nicht weiter verwunderlich das da ggf. eine Regel falsch ist ?!
Du kannst doch immer mit Traceroute oder Pathping schrittweise sehen wie weit du kommst. Da wo Schluss ist ist auch der Fehler !
Ja, das dachte ich auch. Aber der kleine und feine Unterschied liegt beim Aufbau des Tunnels.
Wenn wir ihn aufbauen -> Phase 2 erfolgreich, NAT-T Aktiviert -> Alles funktioniert
Wenn SH ihn aufbaut -> Phase 2 erfolgreich, NAT-T Deaktiviert -> Kein durchkommen
Nun liegt mein Verständnissproblem darin, was machte eine FW bei aktivierten NAT-T anders? Ich vermute, dann schickt sie die Packete an eine andere Destination IP in den Tunnel.
Der Verkehr bleibt bei deaktivierten NAT-T sicher an der Cisco hängen. Nur nach Aussage das Admin auf Seiten des SH, kann er da nicht reingucken. Deshalb wissen wir auch nicht, mit welcher IP und/oder welcher Zieladresse wir da ankommen.
Das nervt...
Wenn wir ihn aufbauen -> Phase 2 erfolgreich, NAT-T Aktiviert -> Alles funktioniert
Wenn SH ihn aufbaut -> Phase 2 erfolgreich, NAT-T Deaktiviert -> Kein durchkommen
Nun liegt mein Verständnissproblem darin, was machte eine FW bei aktivierten NAT-T anders? Ich vermute, dann schickt sie die Packete an eine andere Destination IP in den Tunnel.
Der Verkehr bleibt bei deaktivierten NAT-T sicher an der Cisco hängen. Nur nach Aussage das Admin auf Seiten des SH, kann er da nicht reingucken. Deshalb wissen wir auch nicht, mit welcher IP und/oder welcher Zieladresse wir da ankommen.
Das nervt...
Hab es grad nochmal überprüft. Wir bleiben bei einem Tunnel ohne NAT-T an der Cisco hängen, jedenfalls ist bei allen Ablaufverfolgungen bei * * * Schluss, welche die nächste Station nach unserer FW darstellt.
Nein, NAT-T hat nichts mit einem IP Forwarding zu tun, das ist Unsinn. Hier kannst du den Mechanismus nachlesen:
http://www.elektronik-kompendium.de/sites/net/0906191.htm
bzw.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftipsna ...
ESP wird nur in UDP 4500 gekapselt !
Es kann auch nicht richtig sein das wenn die SH den Tunnel aufbaut das dort eine gültige ESP Session zustandekommt. Hast du am Cisco mal den Debugger laufen lassen und dir die Session mal angesehen ?
Kann es ggf. sein das du durch die doppelte Kapselung ein MTU problem hast das die MTU nicht sauber negotiated wird. Ein klasssiches Problem bei VPN und die Symptome sprechen ebenfalls dafür. Aber nur wenn tatsächlich beim SH Aufbau wirklich der Tunnel fehlerfrei zustandekommt !
http://www.elektronik-kompendium.de/sites/net/0906191.htm
bzw.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftipsna ...
ESP wird nur in UDP 4500 gekapselt !
Es kann auch nicht richtig sein das wenn die SH den Tunnel aufbaut das dort eine gültige ESP Session zustandekommt. Hast du am Cisco mal den Debugger laufen lassen und dir die Session mal angesehen ?
Kann es ggf. sein das du durch die doppelte Kapselung ein MTU problem hast das die MTU nicht sauber negotiated wird. Ein klasssiches Problem bei VPN und die Symptome sprechen ebenfalls dafür. Aber nur wenn tatsächlich beim SH Aufbau wirklich der Tunnel fehlerfrei zustandekommt !
