windows openvpn / unexpected default route

The other day, I was looking into a VPN client issue. The user could connect, they would get their routes pushed, but they would then proceed to use the VPN for all traffic instead of just the routes we provided them.

We did not push a default route, because this VPN server exposed a small internal network only. Any regular internet surfing should be done directly. So, when I looked at a tcpdump I was baffled when I saw that DNS lookups were attempted through the OpenVPN tunnel:

12:50:45.992684 IP 10.8.8.11.51953 > 8.8.8.8.53:
  51928+ A? kv601.prod.do.dsp.mp.microsoft.com. (52)

The server in question runs OpenVPN 2.4.

The client that exhibited this behaviour was OpenVPN Connect v3 for Windows, with the following peer info, according to the server logs:

peer info: IV_VER=3.git::d3f8b18b
peer info: IV_PLAT=win
peer info: IV_NCP=2
peer info: IV_TCPNL=1
peer info: IV_PROTO=30
peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
peer info: IV_AUTO_SESS=1
peer info: IV_GUI_VER=OCWindows_3.3.6-2752
peer info: IV_SSO=webauth,openurl,crtext

The users with Linux OpenVPN clients had no issues with this VPN. Was there an extra setting in the Windows OpenVPN Connect that we could change? A “Send all traffic over this tunnel” option to uncheck, perhaps? There seemed to be very few settings.

One thing we had changed recently was the DNS. We had begun pushing 8.8.8.8 as DNS to the users (to solve a different issue) using the following rules:

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "dhcp-option DOMAIN-ROUTE one-specific-domain.tld"

This rule was supposed to force lookups for *.one-specific-domain.tld to go through the aforementioned Google DNS servers. Maybe the VPN client secretly added a route for this under the assumption that if you want a specific DNS server for VPN, it should be routed through the VPN as well.

This was easy enough to test. I allowed traffic to 8.8.8.8 and 8.8.4.4 to go through the VPN.

Did that fix the problem? Well, no. DNS resolving worked for the user, and now actual (non-DNS) traffic would be attempted through the VPN as well:

13:02:14.618777 IP 10.8.8.11.52040 > 23.2.214.66.443:
  Flags [S], seq 932856193, win 64240,
  options [mss 1289,nop,wscale 8,nop,nop,sackOK], length 0

What is up with this? A route print on the Windows side showed nothing out of the ordinary:

============================================================
Active Routes:
Network Destination      Netmask      Gateway      Interface
        0.0.0.0          0.0.0.0  192.168.1.1  192.168.1.100  <- default
    10.55.55.55  255.255.255.255     10.8.8.1      10.8.8.11  <- vpn
       10.8.8.0    255.255.255.0     On-link       10.8.8.11  <- vpn
      10.8.8.11  255.255.255.255     On-link       10.8.8.11  <- vpn
     10.8.8.255  255.255.255.255     On-link       10.8.8.11  <- vpn
      127.0.0.0        255.0.0.0     On-link       127.0.0.1
      127.0.0.1  255.255.255.255     On-link       127.0.0.1
127.255.255.255  255.255.255.255     On-link       127.0.0.1
    192.168.1.0    255.255.255.0     On-link   192.168.1.100
  192.168.1.100  255.255.255.255     On-link   192.168.1.100
  192.168.1.255  255.255.255.255     On-link   192.168.1.100
123.123.123.123  255.255.255.255  192.168.1.1  192.168.1.100  <- vpn-server
      224.0.0.0        240.0.0.0     On-link       127.0.0.1
      224.0.0.0        240.0.0.0     On-link   192.168.1.100
      224.0.0.0        240.0.0.0     On-link       10.8.8.11  <- vpn
255.255.255.255  255.255.255.255     On-link       127.0.0.1
255.255.255.255  255.255.255.255     On-link   192.168.1.100
255.255.255.255  255.255.255.255     On-link       10.8.8.11  <- vpn
============================================================

Ignoring broadcast and multicast addresses, only 10.55.55.55 and 10.8.8.* should go through the VPN interface. The default route 0.0.0.0 is clearly marked to go through the regular internet via the 192.168.1.1 gateway. This does not explain at all why traffic to 8.8.8.8 or 23.2.214.66 goes to the VPN.

In a last ditch attempt to fix things, I tried what happens if we did push 8.8.8.8 and 8.8.4.4 as routes that should go through the VPN:

push "route 8.8.8.8 255.255.255.255 vpn_gateway"
push "route 8.8.4.4 255.255.255.255 vpn_gateway"

Lo and behold! Things started working properly. Traffic to 10.55.55.55 (and to the nameservers) now goes through the tunnel, but traffic to the rest of the internet properly takes the default route.

I cannot explain why OpenVPN Connect on Windows would not use the routes it prints. Maybe there is a “Use default gateway on remote network” setting somewhere that got enabled when it received a DNS server IP that was not pushed over the same tunnel. One would think that this would be visible on the routing table though. If anyone reading this can explain this phenomenon, please drop us a line.