The laptop could connect successfully, but then 2 minutes in (in some cases) the log would fill up with recursive-routing drops and all traffic would essentially stop functioning. The user would have to disconnect the tunnel to start getting Internet access again. This didn't happen consistently and I had a hard time reproducing it.
The issue seems to be Windows 10 attempting to 'prefer' the Ethernet-looking tunnel network when the wifi signal is very weak. This behavior *seems* to be documented here:
https://docs.microsoft.com/en-us/window ... on-manager
And there's a hint about the behavior here: https://support.microsoft.com/en-us/hel ... ion-is-est but the fix doesn't seem to work when dealing with a weak wifi signal
However, the only control you have in Windows is to disable the 'minimize the number of Internet connections' feature, which doesn't affect the automatic "soft disconnect" of the wifi adapter when it encounters weak signal. This probably isn't evident on user-initiated openvpn connections because there's a note in the documentation about 'manually initiated user connections' not being subject to this weird behavior, but if you configure the service to run your connections automatically and have a weak wifi signal, this seems to manifest.
What's more frustrating is the routing table does not change ! The /32 route for my VPN gateway remains, and all appears to be correct, unless you use the powershell command 'Find-NetRoute' which actually tells you what route Windows will use for a particular destination. This seems to be some kind of hidden Windows network preference that you don't have direct control over.
Using the allow-recursive-routing directive does nothing to help with this (it just removes the recursive routing warnings from the log)
TL;DR: OpenVPN redirect-gatway creates a /32 route for the VPN server to use the old default gateway. If you have a weak wifi signal, Windows overrides this silently and sends all your traffic through the Tunnel interface, causing recursive packets to be dropped. Route table is unchanged but find-netroute shows the tunnel as the next hop for the VPN server
First, can anyone reproduce this behavior? Second, does anyone know how to disable it in Windows 10?
Code: Select all
dev ovpns1 verb 4 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.0.1 tls-server server 10.0.0.0 255.255.255.128 client-config-dir /var/etc/openvpn-csc/server1 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'ovpn-server' 2" lport 1194 management /var/etc/openvpn/server1.sock unix push "dhcp-option DOMAIN domain.com" push "dhcp-option DNS 184.108.40.206" push "block-outside-dns" push "register-dns" push "redirect-gateway def1" ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server1.tls-auth 0 topology subnet push "ping-restart 30"
Code: Select all
dev tun persist-tun persist-key cipher AES-128-CBC auth SHA256 tls-client client resolv-retry 15 <connection> remote test.domain.net 1194 udp explicit-exit-notify </connection> cryptoapicert "SUBJ:domain.com" management 127.0.0.1 199 remap-usr1 SIGHUP remote-cert-tls server #in-line keys removed