Windows 10, Redirect-gatway, and recursive routing

This forum is for admins who are looking to build or expand their OpenVPN setup.
Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See https://forums.openvpn.net/viewtopic.php?f=30&t=21589 for an example.
ewiley
OpenVpn Newbie
Posts: 4
Joined: Thu Jan 05, 2012 5:21 pm

Windows 10, Redirect-gatway, and recursive routing

Postby ewiley » Mon Jul 17, 2017 2:22 pm

For the last month or so I've been fighting with intermittent issues in Windows 10 (1511) and OpenVPN as an always-on service to connect whenever the user is online. We also have a requirement to disable split-tunneling so we use redirect-gateway to force all traffic over the tunnel. This occurs in 2.4.3 as recently as today.

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 :evil:! 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"


client config

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

Return to “Server Administration”

Who is online

Users browsing this forum: No registered users and 2 guests