Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

NAT-T - VPN Problem mit ext Dienstleister

Frage Sicherheit Firewall

Mitglied: Alchemy

Alchemy (Level 1) - Jetzt verbinden

09.09.2011, aktualisiert 16:04 Uhr, 4334 Aufrufe, 6 Kommentare, 1 Danke

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
Mitglied: aqui
09.09.2011 um 16:39 Uhr
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)
Bitte warten ..
Mitglied: Alchemy
09.09.2011 um 16:56 Uhr
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.
Bitte warten ..
Mitglied: aqui
09.09.2011 um 17:23 Uhr
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 !
Bitte warten ..
Mitglied: Alchemy
09.09.2011 um 17:36 Uhr
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...
Bitte warten ..
Mitglied: Alchemy
09.09.2011 um 18:07 Uhr
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.
Bitte warten ..
Mitglied: aqui
09.09.2011 um 20:19 Uhr
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 !
Bitte warten ..
Neuester Wissensbeitrag
DSL, VDSL

Telekom blockiert immer noch den Port 7547 in ihrem Netz

(3)

Erfahrungsbericht von joachim57 zum Thema DSL, VDSL ...

Ähnliche Inhalte
Router & Routing
FritzBox 7490 VPN Problem ab FritzOS 6.5 (6)

Frage von 1x1speed zum Thema Router & Routing ...

Microsoft
AD Problem und VPN (4)

Frage von Yannosch zum Thema Microsoft ...

Router & Routing
gelöst VPN- Routing - Problem - Netzwer 1 kommt auf 2 aber anders herum nicht (8)

Frage von itschloegl zum Thema Router & Routing ...

Router & Routing
gelöst Netgear FVS338 - NAT VPN (9)

Frage von Multitask zum Thema Router & Routing ...

Heiß diskutierte Inhalte
Windows Userverwaltung
Ausgeschiedene Mitarbeiter im Unternehmen - was tun mit den AD Konten? (34)

Frage von patz223 zum Thema Windows Userverwaltung ...

LAN, WAN, Wireless
gelöst Server erkennt Client nicht wenn er ausserhalb des DHCP Pools liegt (28)

Frage von Mar-west zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
FritzBox, zwei Server, verschiedene Netze (21)

Frage von DavidGl zum Thema LAN, WAN, Wireless ...

Viren und Trojaner
Aufgepasst: Neue Ransomware Goldeneye verbreitet sich rasant (20)

Link von Penny.Cilin zum Thema Viren und Trojaner ...