Jump to content

VPN, nat-traversal


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

bin gerade auf den Befehl nat-traversal gestossen.

Ich hatte das Problem, dass ich als HomeOfficeUser über einen DSL-Router mit meinem IP-Sec-Client eine Verbindung zu dem Firmen-VPN-Gateway (PIX 500er Series) aufbauen und die freigegeben Ressourcen nutzen kann, mit dem gleichen Rechner hinter einer anderen PIX zwar die VPN-Verbindung zu Stande kam, ich aber auf keine Ressource zugreifen konnte. Nach Konfiguration von nat-traversal auf dem VPN-Gateway läuft dies jetzt auch.

Durch googeln habe ich einiges über den Befehl rausbekommen, klar ist mir aber immer noch nicht, warum es hinter einem "Standard-DSL-Router" ohne nat-traversal funktioniert, hinter einer anderen Firewall - hier auch eine PIX - eben nur mit dem Befehl.

Nach meinem Verständnis mache ich sowohl über den DSL-Router, als auch über die PIX natting, da ich hinter beiden private Netze habe. Offensichtlich scheint es da aber doch einen Unterschied zu geben - welchen??? :confused::confused::confused:

Link zu diesem Kommentar

Hallo in die Runde,

 

ich schliesse mich mal der Frage von hegl an, da ich gerade eine ähnliche Frage zu den Themen VPN-Client-Software, NAT-Traversal und VPN-Passthrough stellen wollte.

Folgende Situation: User sollen sich per CISCO VPN-Client-SW auf einem Router mit EazyVPN-Server einwählen können. User sind sowohl per ISDN und CBC im Internet eingewählt, als auch per DSL hinter einem Router, der NATet.

 

Zuerst mal zur Begriffsklärung:

 

- VPN-Passthrough

Router unterstützt max. eine Verbindung; Portforwarding auf diesen einen Client muss aktiviert sein; Auf welchen Ports läuft die Kommunikation ab; ESP und ISAKMP-Pakete werden genatet/gepatet mit der einen Clientadresse ????

 

- NAT-Traversal

Es wird automatisch erkannt, ob alle beteligten Geräte NAT-T unterstützen durch NAT-T-Discovery-Pakete; ESP-Pakete werden in UDP gekapselt, daher mehrere Clientverbindungen möglich; Kommunikation immer von Port 4500 auf 4500 ????

 

Ebenfalls unklar sind mir die unterschiedlichen Einstellungen im CISCO-VPN-Client. Ich habe mal alle Einstellungen durchprobiert und Pakete mitgesnifft:

 

- Ohne Transparent Tunneling

UDP > 1024 auf 62515 (was ist das für ein spezieller Port?)

UDP 500 auf 500 ISAKMP

UDP 62515 auf 62515

Nur mit dieser Einstellung funktionierten mehrere gleichzeitige Verbindungen durch einen NAT-T-fähigen Router zum VPN-GW

 

- Transparent-Tunneling über UDP

alles wird in UDP gepackt

UDP > 1024 auf 62515

UDP 500 auf 500 ISAKMP

UDP 4500 auf 4500 (hier funktioniert dann anscheinend das NAT-Traversal)

 

- Transparent Tunneling über TCP (10000)

mehere UDP-Verbindungen von >1024 auf 62515

aber keine einige Anfrage an Port 10000???

 

Mir ist es nicht klar, wieso Methode 1 funktioniert hat und Methode 2 und 3 nicht.

Vielleicht kann ja jemand die Einstellungen etwas Erläutern?

Hoffe, dass liest überhaupt noch jemand ;-)

Danke.

 

Stefan

Link zu diesem Kommentar
Ich würde sage, dass der "Standard-DSL" Router NAT-Traversal unterstützt....

 

Grüsse

Thomas

 

Hi Thomas,

 

die PIX unterstützt sehr wohl nat-traversal, meine Frage geht dahin, warum ich auf der Remote-PIX den Befehl eintragen muss, wenn ich vorher auch durch eine PIX ins Netz gehe. Es sieht so aus, als wäre das nat eines Standrad-DSL-Routers anders als das einer PIX :confused:

 

Gruß und Danke

Helmut

Link zu diesem Kommentar

Hi,

 

irgendwie verstehe ich nicht ganz:

 

Du hast in der zentrale eine PIX.

Du hast eine Aussenstelle (HOmeuser), wo vorher ein "Standard-DSL-Router" war, welcher nun durch eine PIX ersetzt wurde; auf welcher NAT-traversal konfiguriert werden muss, damit alles funktioniert.

Vorher hingegen (mit den "Standard-Router) ging alles ohne Konfiguration..

 

Ist dies richtig so??

 

Falls ja, wiederhole ich die Antwort von vorher!

 

..ansonsten stehe ich wohl auf der Leitung heute.. :)

 

Grüsse

Thomas

Link zu diesem Kommentar

so ist das Prinzip: NAT bringt durch die neuen Source/Destination Addressen die Authentifizierungfunkton von ESP oder AH durcheinander: der Hash stimmt nicht mehr - da sich der Header geändert hat, dessen Orginalität ja mit Authentisiert werden sollte.

 

Sobald also NAT auf einer VPN Strecke liegt müssen die ESP oder AH Packete zusätzlich in UDP oder TCP Packete gekapselt werden, deren Adressen oder Ports werden dann nicht mehr "gehashed" und können so munter übersetzt -> "genattet" werden. Man kann entweder eine UDP oder TCP Kapselung fest konfigurieren oder auf die automatische Entdeckung mit NAT-T setzen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...