windows openvpn / unexpected default route

windows openvpn / unexpected default route

  • Written by
    Walter Doekes
  • Published on

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 >
  51928+ A? (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 as DNS to the users (to solve a different issue) using the following rules:

push "dhcp-option DNS"
push "dhcp-option DNS"
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 and 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 >
  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  <- default  <- vpn     On-link  <- vpn     On-link  <- vpn     On-link  <- vpn     On-link     On-link     On-link     On-link     On-link     On-link  <- vpn-server     On-link     On-link     On-link  <- vpn     On-link     On-link     On-link  <- vpn

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

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

push "route vpn_gateway"
push "route vpn_gateway"

Lo and behold! Things started working properly. Traffic to (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.

Back to overview Newer post: CephFS EINVAL specified for ceph.dir.subvolume Older post: Kubernetes CRL support with the front-proxy-client and Haproxy