[Gelöst] One-Way Traffic mit Windows IKEv2

[Barbarossa]

Hallo zusammen,

ich habe mich jetzt die letzten zwei Wochen hier im Forum und über Google rauf und runter gesucht und leider keine Lösung für mein Problem gefunden.

Was möchte ich tun:
Ich haben einen ISG-4000 (auch getestet mit 1900EF und 1781EF+) auf dem ich eine ganze Reihe IKEv2 Verbindungen in Betrieb habe, bisher mit dem kostenpflichtigen Lancom VPN Client.
Aufgrund verschiedener Umstellungen möchten wir prüfen, ob die Clients sich auch mit dem Microsoft eigenen VPN-Client verbinden können. Dies soll mit Zertifikaten aus unserer eigenen CA passieren.

Was habe ich getan:
Abgesehen davon, dass man sich die Informationen dazu zusammensammeln muss (an dieser Stelle noch mal vielen Dank an verschiedene Forumsmitglieder, die fundiert und strukturiert entsprechende Informationen hier zusammengetragen haben), hat das im Grundsatz auch geklappt, Windows meldet erfolgreichen Verbindungsaufbau und auch das Trace auf dem Lancom sieht sauber aus und die Verbindung ist stabil.
Auch ein Ping aus dem internen Netz auf den Client-Rechner kommt dort, mit wireshark geloggt, sauber an.

Und jetzt das Problem:
Traffic vom Client zum internen Netz versackt irgendwo im Nirvana. Keins, aber auch gar kein einziges der Pakete, die ich auf dem Client auf dem Tunnelinterface mit Wireshark rausgehen sehen kann, kommt beim Lancom an. Die NAT-Keepalives laufen sauber, der Tunnel steht über Stunden. Nur ist er eine Einbahnstraße. Nicht mal die ICMP Replies kommen durch. Kein DNS, kein HTTP/S, kein garnichts.
Und ich finde partout keine Lösungsansätze dafür.

Ich habe das ganze jetzt schon mit Windows 10 und 11 getestet, bei beiden das selbe Problem.
Hacke ich die entsprechenden Daten in ein iPhone, funktioniert es wunderbar. Ja, ich weiß, das deutet recht klar auf ein Microsoft Problem hin, aber am Ende des Tages habe ich trotzdem die Hoffnung, dass mir hier jemand helfen kann.

Vielen Dank!

[GrandDixence]

Entsprechende Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
"durchgeackert"? Routingtabelle auf dem Windows-Rechner mit "route -4 print" kontrolliert?
https://de.wikipedia.org/wiki/Routingtabelle

Namensauflösung auf dem Windows-Rechner mit "nslookup" kontrolliert?

[Barbarossa]

Anleitungen mehrfach durchgeackert, ja.
Routentabelle ist korrekt. Mit Redirect Gateway wird ja die default Route entsprechend gesetzt, zusätzlich wurden die Remote Netze per Powershell auf die Verbindung hinzugefügt.

nslookup hilft mir leider nicht, da die Pakete zum DNS genau wie alles andere irgendwo im Tunnel versacken.

[GrandDixence]

Fehlersuche gemäss:
fragen-zum-thema-vpn-f14/verwirrendes-v ... ml#p109163
durchführen. ICMP-Datenpaket (Ping + Pong) mit dem entsprechenden Trace "einfangen".

[Barbarossa]

Guten morgen!

wir haben das Problem gefunden. Zu meiner Schande muss ich zugeben, dass es an der Firewall von F-Secure lag.
Das habe ich bei dem Fehlerbild nicht auf der Rechnung gehabt. Blöderweise hat das Ding nicht mal irgendeine Rückmeldung gegeben und der VPN-Aufbau lief ja auch problemlos. Nur kam halt nix durch.

In dem Zusammenhang die Erinnerung für andere, die vielleicht vor einem ähnlichen Problem stehen: Wireshark arbeitet vor der Windows Firewall bzw. vor Software Firewalls im allgemeinen. Nur weil eingehende Pakete in Wireshark sichtbar sind, bedeutet das nicht, dass die Firewall da nichts wegblockt.