Site-2-Site-IPSec-Tunnel funktioniert nur zwischen bestimmten Providern

[Flignition]

Hallo,

ich als IT-Security-Engineer in einem internationalen Unternehmen mit mehreren Standorten. Nun habe ich eine Backup-Leitung für einen Standort in Deutschland eingerichtet (Hauptstandort befindet sich in Österreich). Wenn ich nun den Tunnel mit der neuen IP in Deutschland (DHCP) nach Österreich aufbauen will, dann funktioniert das auch. Man kann auch unser ERP-System und andere wichtige Services pingen etc.
Wenn ich aber auf bestimmte Server mittels HTTPs oder RDP zugreifen will, dann laufe ich immer in einen Timeout... Die Firewall-Logs zeigen mir aber an, dass alles erlaubt ist und die Verbindung funktioniert (nichts wird blockiert etc.) Wenn ich in dem Standort in Deutschland wieder auf den anderen Provider umstelle (andere Public-IP), dann baut sich der Tunnel erneut auf und alles funktioniert wieder normal. Das Problem wurde schon bei zwei verschiedenen Providern festgestellt, weder das Techincal Support-Team des Providers, noch unser externen Ansprechpartner unserer Firewall mit deren Technical Support-Teams haben den Fehler gefunden.

Verwendet wird auf beiden Seiten eine Barracuda, Tunnel ist IPSec, Logs steht nichts außergewöhnliches, da die Barracudas ja denken, dass alles normal funktioniert.

Habt ihr irgendwelche Ideen?

 

[daniel_689]

Hey,
ist die Tunnel Konfiguration bis auf die unterschiedliche Public IP auf der einen Seite sonst komplett gleich?
Hört sich für mich so an, als ob nicht alle Phase 2 Entries vorhanden sind, also nicht komplett zwischen den verschiedenen Netzwerken geroutet wird und deshalb nur einige Services erreichbar sind.

 

[jb_alvarado]

Konntest du ermitteln bis wohin noch der Traffic geht und auf welcher Seite es zum Stillstand kommt?, mit tcpdump oder ähnlichem.

Würde auch tippen das es was mit dem Routing zutun hat, vielleicht bleiben die Antwortpakete wo hängen.

 

[Raijin]

Sobald der VPN-Tunnnel vollständig aufgebaut ist, hat der Internet Provider nichts mehr damit am Hut. Alles was dann über die VPN-Verbindung (nicht) funktioniert, obliegt einzig und allein dem Administrator und dessen Konfiguration.

 

[Flignition]

Hallo an alle,
danke schon mal für die schnellen Antworten.
Also die Konfiguration bleibt exakt gleich auf beiden Seiten, einzig die IP zum Aufbauen des Tunnels ändert sich. Nachverfolgt hab ich die Pakete auch schon, gehen von uns raus, kommen bei denen aber nie an. Genauso in die andere Richtung, dürften also irgendwo drinnen einfach verschwinden.
Das Routing wäre auch mein Verdacht gewesen, da sich aber die Konfiguration des Tunnels ja nicht ändert, er die selben Routen verwendet und auch auf das gleiche Ruleset zugreift, schließe ich das derzeit aus.
Bezüglich der Antwort, dass der Provider nach dem Tunnelaufbau nichts mehr damit zu tun hat, ist mir bewusst. Wir haben aber dennoch mit beiden Technical-Teams gesucht, da der Fehler ja schon ziemlich komisch ist...

 

[daniel_689]

Okay, und du bist dir sicher, dass der Tunnel in beiden Fällen vollständig aufgebaut wurde?
In Phase 2 werden ja die Netze definiert zwischen denen geroutet werden soll und wenn du sagst eine Nachverfolgung bleibt jeweils am "Tunneleingang" hängen scheint da was nicht zu stimmen. Oder was meinst du mit "gehen von uns raus"? Von uns raus in den VPN oder vielleicht doch Richtung Internet? Von Firewall Rulesets etc. ganz zu sprechen aber da wirst du zum testen ja erstmal mehr erlaubt haben...
Denn wie schon gesagt wurde, für den Traffic der verschlüsselt durch den Tunnel geht bist alleine du verantwortlich, das ist ja der Sinn von VPN.

 

[iElite]

Hi,
ich hatte tatsächlich die letzten Tage ein ähnliches Problem mit ähnlicher Konstellation. (Hauptstandort DE Vodafone - Niederlassung AT Magenta). Daher denke ich es könnte bei dir vielleicht auch zutreffen.

Mein Problem war die MTU des Magenta Anschlusses in AT. Mit 1400 sind wir jetzt safe, zumindest wenn die Magenta nicht einen komplett Ausfall in AT hat (was gerade der Fall ist).

Melde dich gerne per PN wenn du zum Troubleshooting Unterstützung/Tipps brauchst.

Ich frag mal ganz blöd, kennst du zuverlässige Alternativen zu Magenta Cable in Wien?
Wir haben die Magenta vorgeschlagen bekommen, aber haben abseits der jetzt geklärten MTU Problematik echt viele Probleme. Störung auf der Leitung und jetzt der Ausfall, wirkt irgendwie nicht so gut. Oder ist es gerade einfach ein unglücklicher Zeitraum?

 

[Raijin]

Es klingt in der Tat eher danach, dass die VPN-Verbindung als solche gar nicht vollständig hergestellt wird.

Man kann auch unser ERP-System und andere wichtige Services pingen etc.
Wenn ich aber auf bestimmte Server mittels HTTPs oder RDP zugreifen will, dann laufe ich immer in einen Timeout... Die Firewall-Logs zeigen mir aber an, dass alles erlaubt ist und die Verbindung funktioniert (nichts wird blockiert etc.)

Hast du dir das denn mal mit WireShark bzw. tcpdump angeschaut? Woher kommt der timeout? Siehst du am Client die ausgehenden Pakete? Siehst du sie am VPN-Gateway? Kommen sie am VPN-Endpoint vorbei? Treffen sie beim jeweiligen Server ein? Wenn ja, geht vom Server eine Antwort raus? Dortiges VPN-Gateway + restlichen Weg bis hin zum Client prüfen.

Am VPN-Gateway am besten sowohl das VPN-Interface wie auch das physische Interface sniffen, um sowohl die eigentliche Datenverbindung (zB HTTPs) als auch den gekapselten Traffic des VPNs auf eventuelle Verbindungsfehler untersuchen.

 

[Flignition]

Hallo,
danke für die Antworten, ich werd eure Vorschläge mal checken und mich danach wieder melden!
Auf jeden Fall sind da einige interessante Ansätze dabei.
LG

 

[Flignition]

Also für alle: Ich hab die MTU nach einem Test auf 1360 gestellt (einmal, auf dem Router auf der deutschen Seite, einmal auf dem Interface der Firewall und einmal direkt am Client), dann funktioniert es problemlos. Dort sind aber ca. 300 Clients, auf denen das umgestellt werden müsste (wär mit SCCM und Group Policies möglich), jedoch wird es dann vielleicht Probleme mit anderen Site2Site-Tunnel geben. Theoretisch müsste es ja am Router + FW reichen oder? Wieso reicht das aber nicht?

 

[nosti]

Ich kenne solche MTU-Probleme vor Allem beim Einsatz von SSL-VPN und Funkanbindungen wie LTE. Für OpenVPN ist deswegen schon die Empfehlung die MTU auf 1300 zu setzen und sich von da ausgehend an einen Wert heranzuarbeiten.

Bei Anpassung der MTU ist es immer die Empfehlung diese über die gesamte Kommunikationsstrecke gleich zu konfigurieren. Bei kleineren Datenpakten fällt das oft noch gar nicht auf, wird die MTU jedoch ausgereizt, kann es vorkommen, dass Pakete fragmentiert werden. Der Kommunikationspartner hat dann eventuell das Problem, dass Paket nicht richtig zusammenbauen zu können.

Grüße

 

[Raijin]

Man muss allerdings unterscheiden von welcher MTU man spricht. Die MTU den TUN-Adapters von OpenVPN lässt sich problemlos auf 50k setzen. Das hat nämlich nichts damit zu tun mit welcher MTU eben dieses VPN-Paket dann auf der physischen Schnittstelle fragmentiert wird und nach draußen geht - das ist Aufgabe des Betriebssystems und der physischen Schnittstelle bzw. dem Betriebssystem ist es egal welche Payload in dem tatsächlichen Paket die Schnittstelle verlässt.
Eine hohe MTU des TUN-Adapters nebst deaktivierter OpenVPN-interner Fragmentierung ist ein klassischer Kniff für das Performance Tuning von OpenVPN.


Daher die Frage: Welche MTU wurde nun geändert?

 

[Flignition]

Eben die MTU auf dem Interface der Firewall, direkt auf dem Ethernet-Interface vom Router (LTE-Box) und die direkt am Ethernet-Interface am Client:
netsh interface ipv4 set subinterface "11" mtu=1360 store=persistent

 

[Flignition]

Anmerkung: es funktionieren nur zwei Server nicht, alle anderen kann ich per RDP erreichen.
Die Server wurden aber standardmäßig aufgesetzt...

 

[Flignition]

Hat noch jemand eine Idee?

 

[nosti]

Mach mal einen Wireshark Mitschnitt auf den betreffenden Maschinen.

 

[Flignition]

Hab ich schon, sagt nichts aus, leider... Wie gesagt, das Problem hab ich ja gefunden. Ich weiß nur nicht, wie ich es lösen kann, ohne dass iich jeden Client eine neue MTU setzen muss...

 

[nosti]

Nach meinem Verständnis muss die MTU bei allen Kommunikationspartner korrekt parametriert sein, da es sich um eine End2End-Kommunikation handelt. Deswegen reicht es nicht aus die Einstellung nur auf der Teilstrecke der IPSec VPN zu setzen.
Die nicht funktionierenden Server sind ansonsten identisch? Die gleichen Treiber, ggf. gleiche Konfiguration auf Hypervisor-Ebene (z.B. in VMWare MTU der PortGroup) etc.?

Erhälst du im Wireshark bei den beiden Servern auch nichts verwertbares? Womöglich ist das "Dont Fragment" Flag gesetzt und die Pakete werden verworfen?

Grüße

 

[Flignition]

Hallo!
Danke für die Antwort! Ich werd mal checken, ob beim Server was unterschiedlich ist und melde mich wieder.
Im Wireshark hab ich schon nach dem "Dont Fragment"-Flag gesucht, leider nichts gefunden...

 

[nosti]

Falls es sich um virtuelle Maschinen handelt, verschieben diese auch mal auf einen anderen Host und beobachte, ob der Fehler "mit wandert"

EDIT: Was mir gerade noch einfällt. Die beiden betreffenden Server sind im gleichen IP-Subnetz, bzw. deren Subnetz ist auch als IPSEC-SA aufgebaut?

Grüße