Problem mit VPN bei VMWare mit gebridgtem VPN-Server

Dieses Thema im Forum "Netzwerk" wurde erstellt von Wuchtbrumme, 16.07.18.

  1. Wuchtbrumme

    Wuchtbrumme Gravensteiner

    Dabei seit:
    03.05.10
    Beiträge:
    10.123
    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.
     
    #1 Wuchtbrumme, 16.07.18
    Zuletzt bearbeitet: 16.07.18
  2. Wuchtbrumme

    Wuchtbrumme Gravensteiner

    Dabei seit:
    03.05.10
    Beiträge:
    10.123
    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).
     
  3. Wuchtbrumme

    Wuchtbrumme Gravensteiner

    Dabei seit:
    03.05.10
    Beiträge:
    10.123
    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?
     
  4. Insulaner

    Insulaner Zabergäurenette

    Dabei seit:
    06.01.12
    Beiträge:
    607
    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.
     
    #4 Insulaner, 19.07.18
    Zuletzt bearbeitet: 19.07.18
  5. Wuchtbrumme

    Wuchtbrumme Gravensteiner

    Dabei seit:
    03.05.10
    Beiträge:
    10.123
    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.
     
  6. ottomane

    ottomane Geflammter Kardinal

    Dabei seit:
    24.08.12
    Beiträge:
    9.178
    ESP ist ein Problembär, da es direkt auf IP aufbaut und nicht TCP oder UDP nutzt. Vielleicht liegt da der Hund begraben.
     
  7. Wuchtbrumme

    Wuchtbrumme Gravensteiner

    Dabei seit:
    03.05.10
    Beiträge:
    10.123
    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.
     
  8. Insulaner

    Insulaner Zabergäurenette

    Dabei seit:
    06.01.12
    Beiträge:
    607
    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.
     
    trexx und ottomane gefällt das.
  9. Wuchtbrumme

    Wuchtbrumme Gravensteiner

    Dabei seit:
    03.05.10
    Beiträge:
    10.123
    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?".