Learn OpenVPN - Network Policy & Split Tunneling

#Introduction

Episode 6 introduced routing, episode 15 connected office networks. Now the question is more strategic: which traffic should go through the tunnel, and which may go straight to the internet? The answer is network policy, and its main tool is split tunneling.

Episode 16 covers two sides of network policy. The first side is routing: choosing routes with push "route ...", sending all traffic with redirect-gateway, and selective routing with allow-pull-fqdn. The second side is DNS: distributing resolvers with dhcp-option, and preventing DNS queries from leaking out of the tunnel.

Why does this matter? A wrong policy not only slows connections, but can also leak sensitive information. Incorrect DNS configuration is a common gap that lets site addresses that should stay safe inside the tunnel leak out to the internet.

#Split Tunneling and Selective Routes

#Returning to the push Concept

Split tunneling gives each client route choices controlled from the server. The server determines which routes are pushed to the client via push "route ...". The client only passes through the tunnel for pushed subnets:

push "route 10.10.0.0 255.255.255.0"
push "route 10.20.0.0 255.255.255.0"

With this configuration, traffic to 10.10.0.0/24 and 10.20.0.0/24 enters the tunnel, while internet access stays on the local path. The consequence: the server doesn't see the client's internet traffic, and server bandwidth isn't drained by browsing.

#Split Pros and Cons

• Pros: server bandwidth is saved, internet access stays fast, and isolation between networks is cleaner.
• Cons: client internet traffic isn't protected, and corporate security policy is hard to enforce outside the tunnel.
• Compromise: selective split tunneling for internal subnets plus internet control at another level.

#allow-pull-fqdn for Selective Routing

By default, the route directive on the client side only accepts IP addresses. When you want to define a route by hostname — for example the FQDN of an internal service — the client needs to allow FQDN pulls:

allow-pull-fqdn

allow-pull-fqdn makes the client willing to accept a route carrying a host name, not just an address. The FQDN is resolved to an IP when the route is installed. This is useful when an internal service's IP changes but its hostname stays stable.

#Full Tunneling with redirect-gateway

#Sending All Traffic Through the Tunnel

The opposite of split tunneling is full tunneling: all client traffic — including the internet — enters the tunnel. The server enables it with push "redirect-gateway def1":

push "redirect-gateway def1"

push "redirect-gateway def1" adds two default routes to the client's table pointing at the tunnel. The def1 route uses the addresses 0.0.0.0/1 and 128.0.0.0/1 to mimic a default route without overriding existing local routes.

#Full Tunneling Consequences

With full tunneling, the server sees all client traffic — suitable for corporate security policy and for hiding client activity from the local ISP. The cost: all client bandwidth flows through the server, and latency to public sites increases because of the extra hop.

#Verifying the Default Route

To make sure all traffic really goes through the tunnel, inspect the client routing table:

ip route show
ip route show table 0 | grep default

ip route show displays the main routes. A default route with gateway 10.8.0.1 indicates traffic exits through the tunnel. If a default route to the local router still exists, traffic keeps leaking to the internet.

#DNS Configuration

#Distributing DNS with dhcp-option

A tunnel doesn't just need routes; it also needs the right DNS resolvers. The server distributes resolvers via push "dhcp-option DNS":

push "dhcp-option DNS 10.10.0.10"
push "dhcp-option DOMAIN corp.example"

push "dhcp-option DNS 10.10.0.10" tells the client to use 10.10.0.10 as its resolver, which can only be reached through the tunnel. dhcp-option DOMAIN adds a search suffix so internal hostnames resolve with the domain automatically.

#Preventing DNS Leaks on Linux

Once the default route enters the tunnel, DNS queries usually follow. But on some systems, a manually configured resolver can send queries directly to the internet. The most reliable way: make sure the only active resolvers are the ones pushed by the server, and inspect with a tool like resolvectl:

resolvectl status

resolvectl status shows the currently active DNS server per interface. Make sure the tun0 interface uses the server's resolver and no rules send DNS queries out of the tunnel.

#block-outside-dns for Windows

Windows has a particular problem: browsers can bypass the VPN and send DNS queries to an old resolver. OpenVPN provides a dedicated directive to close this gap:

block-outside-dns

block-outside-dns installs a filter on Windows that blocks DNS queries not going through the tunnel interface. This directive is safe to add in client.ovpn because it's ignored with a warning on Linux and macOS.

#Choosing the Right Policy

#Common Patterns

• Individual remote worker: split tunneling — only office subnets enter the tunnel.
• Strict compliance policy: full tunneling — all traffic audited by the server.
• Site-to-site: no default redirect; only partner subnets are routed.

#Testing the Policy

Every policy change should be tested in both directions: make sure internal services are reachable, and make sure what should go out still goes out. Combine ip route show for routing and resolvectl status for DNS, then record the results as a baseline.

#Conclusion

Key takeaways:

• push "route ..." creates selective split tunneling from the server side.
• allow-pull-fqdn allows hostname-based routes on the client.
• redirect-gateway def1 sends all traffic through the tunnel.
• dhcp-option DNS and DOMAIN distribute resolvers and suffixes.
• DNS leaks are prevented by ensuring resolvers only come from the tunnel.
• block-outside-dns closes the DNS query gap on Windows.

In the next episode, episode 17, we will discuss multi-server and cluster — running multiple OpenVPN instances for segmentation and scale, learn-address scripting for address synchronization, and high availability with keepalived and HAProxy in front of many servers. After this episode, your VPN infrastructure is ready to serve many regions.