Securepoint Support Forum

Hallo zusammen,

folgendes Problem ist gerade aufgefallen:

Stelle ich mit dem neuen VPN-Client eine OpenVPN-Verbindung zu einer UTM her, wird zusätzlich zu den gewünschten Routen ins remote-Netzwerk eine Host-Route zum Remote-Host (also dem VPN-Gateway) eingetragen.
Diese hat zwar als Gateway meine lokale LAN-Gateway-IP eingetragen, aber als Schnittstelle die VPN-Schnittstelle, z.B. so:
    a.b.c.d 255.255.255.255    192.168.192.1  192.168.50.100    97

a.b.c.d ist dabei das Remote-Gateway, 192.168.192.1 mein lokales Gateway im LAN, und 192.168.50.100 meine Client-IP im VPN.

Im Ergebnis kann ich damit bei aktiver VPN-Verbindung nicht mehr auf die IP der Gegenstelle zugreifen, z.B. auf Dienste die dort per Reverse-Proxy / Port-Forwarding auf der WAN-Schnittstelle zugänglich sind.

Viele Grüße,
Christian

Das hat nichts mit dem Beta VPN zu tun.
Ich beobachte diesen Fehler seit dem April - Update von Windows.

Lösungen:
In der .ovpn die Option "route-delay 5" setzen

oder

Die Verbindung statt mit UDP mit TCP aufbauen lassen

Hm, ich kann das hier auf zwei verschiedenen Maschinen sehr reproduzierbar nachstellen (jeweils > 15 Mal getestet): mit dem alten Client passiert das nie, mit dem neuen immer.
Kann aber natürlich auch ein Zufall oder eher anderes Timing zwischen den Client sein.

Andersrum habe ich das Problem weder selbst noch von irgendeinem Kunden berichtet mit dem alten Client gehabt. Aufgrund des Setups bei einem größeren Kunden hätte ich das vermutlich gehört, da dann die Zeiterfassung bei den meisten im Homeoffice nicht mehr funktionieren würde...

Setze ich die route-delay-Option im neuen Client über die Bearbeiten-Funktion der Verbindung, wird diese in der Config immer in ein "#UNSUPPORTED:route-delay 5" umgewandelt. Zweimal ist mit der Client beim Speichern auch ohne Meldung abgestürzt bzw. einfach beendet wurden.

TCP kann ich gerade nicht testen (alle UTMs sind für OpenVPN nur mit UDP konfiguriert), muss ich später mal irgendwo nachbauen.