Problem mit VPN bei VMWare mit gebridgtem VPN-Server

[Wuchtbrumme]

Hallo,
meinen Server habe ich virtualisiert. Tolle Sache. Mit VMWare Fusion Pro 10.1.2. Nutze Netzwerkadapterbridging von VMWare mit dem Ethernetadapter des Mac Mini. Verwendetes OS ist macOS 10.13.6 (und die Server.app 5.6.1).

Jetzt stelle ich fest, dass VPN (L2TP) über den VPN-Server von einem iOS-Gerät von außen nicht mehr funktioniert. Gegencheck vom selben Gerät mit denselben Einstellungen bis auf die Ziel-IP natürlich vom internen LAN - und das geht.

Settings auf der Fritzbox bzgl. weiterzuleitenden Ports sind korrekt (500/udp, 1701/udp, 4500/udp + ESP). Die Einstellungen haben auch schon vorher funktioniert, als der Server noch nicht virtualisiert war, aber da war ja auch kein Bridging. Nach dem Virtualisieren hat sich die Fritzbox verschluckt: die ganzen Portforwardings waren auf einmal auf die IP-Adresse des Hosts gemappt, ließen sich auch nach Löschen nicht mehr die IP-Adresse des Gasts einrichten. Oder besser gesagt, ich richtete sie korrekt ein, speicherte und die FB hat das danach aber trotzdem falsch angezeigt. Letztlich habe ich das durch Disconnects der Rechner, Neustart der FB und das Löschen der Einträge in der Netzwerkliste unter Heimnetzwerk "gelöst" bekommen. Danach ließen sich die Portforwardings einrichten. (Was für eine gequirlte Sch***e.)

Mit Wireshark habe ich - im promiscous mode parallel auf dem Mini Host und dem macOS Server 5.6.1 Guest laufend - den Traffic während beider Verbindungsarten überprüft und stelle fest, dass zwar auf dem Host ESP-Pakete ankommen, auf dem Gast aber nicht. Alles andere geht auch von außerhalb durch. Ein ssh z.B. funktioniert einwandfrei.

Wenn man aus dem LAN den VPN-Connect startet, dann sausen auch auf dem Gast die ESP durch die Aufzeichnung, also scheint es kein grundsätzliches Problem des Bridging zu sein. Gleichzeitig tauchen die ESP auf dem Host auf, d.h. die Fritzbox leitet das schon durch.

Also nochmal:
+VPN intern funktioniert
-VPN von außen nicht funktionierend, Connection attempt wird im ppp-Log nicht mal erwähnt
+Portforwardings korrekt, bis auf ESP nachgewiesen durch Filtern am internen Host
+Paketfilter auf dem Router korrekt, bis auf ESP nachgewiesen durch Filtern am internen Host
+scheinbar alle nötigen Pakete tauchen am Host auf, d.h. liegen an
-die ESP Pakete werden am Gast *nicht* gefiltert

...und jetzt bin ich ratlos.

Vielen Dank für sachdienliche Hinweise.

 

[Wuchtbrumme]

Im Augenblick glaube ich, auch wegen des merkwürdigen Verhaltens beim Verschlucken, dass die Box kein korrektes NAT für die UDP-Verbindungen hinbekommt oder, dass die ESP-Pakete nicht den Weg zurückfinden.

Das VPN-Log zeigt nicht einmal, dass ein Call eingeht.

Mir ist unklar, zu welchem Zeitpunkt es das anzeigen würde (den Loglevel zu definieren ist auch eine Krankheit; von der GUI nicht erreichbar, 0 und 6 sind keine validen Werte - habe ich aber auch nur erraten; die GUI gibt auch kein Feedback dazu, es gibt nur einfach keinen Connect zu Rahmenbedingungen, zu denen es sonst einen gibt; keine Dokumentation über Suchmaschinen zu finden; wenn es krypted nicht gäbe, wäre ich komplett verloren).

Vielleicht setze ich den Router mal komplett zurück (das würde AVM auch fordern).

 

[Wuchtbrumme]

+VPN intern funktioniert
-VPN von außen nicht funktionierend, Connection attempt wird im ppp-Log nicht mal erwähnt
+Portforwardings korrekt, bis auf ESP nachgewiesen durch Filtern am internen Host
+Paketfilter auf dem Router korrekt, bis auf ESP nachgewiesen durch Filtern am internen Host
+scheinbar alle nötigen Pakete tauchen am Host auf, d.h. liegen an
-die ESP Pakete werden am Gast *nicht* gefiltert

das ist immer noch mein Stand, obwohl ich weiter getestet habe. Die neueste Laborsoftware für die 7490 hilft nicht und die MAC-Adressen scheinen zumindest da wo ich messen kann richtig gesetzt zu sein.

Ich bin auch mal in die Kommunikation eingestiegen; zunächst geht es an Port 500/udp mit dem Austausch der SPI, dann weiter mit Keyexchange, Port 4500, und dann sollten die ESP-Datagramme per IP-Protokoll 50 (ESP) kommen.

Intern funktioniert alles, also scheint die Bridiging-Funktionalität prinzipiell da zu sein.
Von außerhalb sehe ich weder die eingehenden ESP-Datagramme, noch ausgehende direkt am Server, d.h. hinter der Bridge und die Fritzbox ist definitiv im Weg.

Hat jemand noch Ideen?

 

[Insulaner]

Scheint, als wenn das Port-Forwarding nicht richtig funktioniert.
Frage:
Port-Forwarding: Hast Du UDP und TCP aktiviert?

Zudem ganz dumme Frage: Die IP-Einstellungen (Default Gateway) sind ok?
Ich hab mal selber ein "Problem" gehabt, was letzendlich ein Zahlendreher beim DG war.

 

[Wuchtbrumme]

Hallo,
danke für Deine Antwort!

Die Kommunikation läuft über udp, aber ich hatte probeweise auch tcp freigegeben, keine Verbesserung.

Das Default-GW ist leider auch schon richtig.

 

[ottomane]

ESP ist ein Problembär, da es direkt auf IP aufbaut und nicht TCP oder UDP nutzt. Vielleicht liegt da der Hund begraben.

 

[Wuchtbrumme]

das fürchte ich auch, jedenfalls ist das eine der Möglichkeiten. Für das VPN muss RFC 3947 funktionieren. Ich habe es noch nicht genauer angeguckt, aber ich meine, dass ich im Fall "VPN von außen" eine veränderte, niedrigere TTL und keine Checksums mehr gesehen habe - keine Ahnung, ob das relevant ist, soweit habe ich mir das noch nicht durchgelesen (es soll ja auch einfach funktionieren, dafür nimmt man ja gekaufte Lösungen, argh).
Eine weitere Überlegung war: Wo sitzt die Bridge eigentlich, wie kann ich erklären, dass ein Paket am Host zu sehen ist, am Gast aber nicht, jedenfalls wenn alles promiscous captured? 100% Bridging kann das ja wohl eher nicht sein.
Andererseits hatte ich Shimo auf dem Server installiert (der im Falle lokalen Verbindungsaufbaus aber auch keine Probleme verursacht).
Die Ports am Server "gehören" aber dem servermgr-vpn. Ich würde aber nicht erwarten, dass ein Serverdaemon am Ende der Kette noch vor dem Capturen von Wireshark Pakete abgreifen könnte.

Ich weiß einfach nicht, wie ich strukturiert weitersuchen soll. Ich überlege, einen Linuxrouter statt der Fritzbox hinstellen. Aber das ist auch nicht mal schnell gemacht. Und mit dem Altsystem gegentesten (einmal den Mac damit gebootet, dann in der VM) habe ich auch überlegt, aber wie valide ist das - da werden ja ständig Zertifikate generiert und/oder ausgetauscht und das letzte Downgrade erforderte gleich wieder ein Neuaufsetzen der iOS-Geräte.

Verflixt.

 

[Insulaner]

Ich erinnere mich, dass ich bei Cisco - falls VPN über eine NAT-Schnittstelle laufen musste -
GRE (generic routing encapsulation) nutzen musste. Das war genau der Grund für das, was
ottomane geschrieben hat. Ich bin aber aus der Technik schon einige Jahre raus.

 

[Wuchtbrumme]

kurzer, überraschender Zwischenstand - das VPN funktioniert, auch von außen. Nur halt nur aus anderen WLANs (als ich das zum Problemzeitpunkt testete, ging auch das nicht, aber das kam immer wieder mal vor, was ich auf die FB geschoben habe, weil nach Neustart FB es reproduzierbar ging).

Soweit ich das bis jetzt eruiert habe: Zusammenarbeit Apple und Telekom. Apple erfordert seit einiger Zeit ipv6 und Telekom hat auf ipv6 "umgestellt". Offenbar kann mein Router oder Anbieter das nicht, habe ich mal wieder ein Projekt gewonnnen.

Was las ich neulich? Sinngemäß: "Wenn alle Baustellen fertig sind, alle S-Bahnen fahren - was machen wir dann noch?".

 

[Wuchtbrumme]

Ich versuche es noch einmal mit der Frage nach meinem Problem und bitte, die obigen Postings zunächst nicht zu Rate zu ziehen, weil sie nicht strukturiert genug geschrieben sind und eher eine historische Abhandlung meiner Fragen und der Problemsuche sind.

Daher hier der aktuelle Stand:
Es gibt eine virtuelle Maschine auf einem Mac Mini. In dieser virtuellen Maschine eine 10.13.6-Installation mit macOS Server 5.7.1 und VPN Server. Wenn ich mich vom WLAN meiner Eltern einzuloggen versuche, funktioniert der VPN-Aufbau. Wenn ich es aus allen anderen bisher versuchten Netzen (T-Mobile Hotspots, T-Mobil-Netz, Firmengästenetz, andere WLANs) probiere, geht es nicht.

Aus der Tatsache, dass es von außen funktioniert, wenn ich es bei meinen Eltern mache, schließe ich, dass weder die Virtualisierung des bisher funktionierenden Servers, noch das Bridging, noch mein Internetanschluss, noch VMWare, noch mein Router mit dessen Software und Portforwarding ein Problem darstellt.

Jetzt suche ich den Unterschied zwischen den Ergebnissen geht aus dem WLAN meiner Eltern und geht nicht im Mobilfunknetz/Firmengästenetz sowie die Problemursache. (In *allen* diesen Netzen ging das VPN in derselben Konfiguration schon mal, nur halt nur *vor* der Virtualisierung).

Jemand eine Idee?

 

[Insulaner]

Wie ist denn das WLAN Deiner Eltern an das aktuelle Netz angebunden?
Du wirst das wissen, aber für den Leser erschliesst sich hier nix.
Ohne Netzplan wird das (so glaube ich) nix.

 

[Wuchtbrumme]

Hallo, das WLAN, wo es funktioniert, ist auch nur über public internet mit mir „verbunden“. Daher glaube ich nicht, dass ein detaillierter Netzwerkplan zusätzliche hilfreiche Informationen liefern könnte. Das einzige wären vielleicht die Provider. Im Gutfall ist das Vodafone, ansonsten steckt da Telekom drin.

 

[Insulaner]

Viel Glück dann!

 

[Wuchtbrumme]

Hallo,
ich habe jetzt wegen fehlender Lust und Zeit aufgegeben.

Nach meiner Meinung scheitert das Aushandeln der Verbindung über NAT-T.

Leider sind zuviele Dinge gleichzeitig (oder für mich nahezu zeitgleich) geändert worden - OS, Server-Version, mein Internet-Provider ist aufgekauft worden und hat intern irgendetwas umgestellt, ... kurzum, die Wahrscheinlichkeit, dass ich das in kurzer Zeit behebe, ist doch sehr minimal.

Der Erklärungsversuch erklärt, warum im Log /var/log/ppp/vpnd.log nichts zu finden ist, die Aufstellung der UDP-Netzwerkpakete und die Tatsache, dass es von manchen Netzen doch funktioniert; ein Test mit Parallels ergab dasselbe Verhalten.

Leider kann ich auch nicht ausschließen, dass die Fritzbox querschiesst, so schräg, wie die sich verhält (die Freigaben werden dort wohl über eine DB von Geräten verwaltet, die wiederum über die MAC-Adressen gespeist werden und dabei hat wohl irgendein d**licher Entwickler die Vereinfachung implementiert, dass Bridging nicht vorkommt, anders kann man sich das Verwürfeln von IP-Adressen in den Tabellen dort nicht erklären; aber es ist nicht das einzige, was auf dem Haufen von Bugs in der FB auffällt).

Meine wirklich pragmatische Lösung war jetzt (und es hat mich lediglich zwei Minuten gekostet): Server.app 5.6.3 übers Netzwerk auf den Host kopiert, installiert, den VPN-Dienst aktiviert und die Fritzbox-Freigaben umgebogen. Läuft.
Wie gesagt, zwei Minuten!