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?
Server config
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 1.2.3.4"
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