Policy-Based Routing for VPNs Explained

Normal routing is simple. A packet carries a destination address, the system looks the address up in a routing table, picks the best matching route and sends the packet out of that interface. The decision depends only on where the packet is going. Policy-based routing changes that: the system looks at other facts about the packet first, such as which device sent it, which port it uses or what label it carries, and picks a routing table based on those rules.

For VPN users this matters because it is how a router or a Linux machine decides "this laptop uses the VPN, that smart TV does not" or "this kind of traffic goes through the tunnel, everything else goes out directly". This article explains the idea behind policy-based routing for VPNs, the pieces it is made of, practical examples, how it can go wrong, and how to test it. It stays on the routing layer. For the general idea of excluding apps, see what split tunneling is, and for router-specific rules see split tunneling on a router.

The problem normal routing cannot solve

A device with a VPN has two ways out: the physical network and the tunnel interface. The default route decides which one is preferred. Usually the VPN adds a route that makes the tunnel the default, so everything goes through it.

Now imagine a household router with one VPN connection and several devices.

• A work laptop should use the VPN.
• A smart TV app should use the normal connection because it fails on VPN addresses.
• A phone should use the VPN only when its owner asks.
• A home server must stay reachable from the local network.

Destination-based routing cannot express this, because all four devices may be going to the same destination. What differs is the source, the device, or the purpose of the traffic. That is the gap policy-based routing fills.

How policy-based routing works

The idea has three parts that work together.

1. Match. A rule describes which packets it applies to. Common criteria include:

• The source IP address or range, which usually identifies a device or a group of devices.
• The destination address or range.
• The protocol and port, for example TCP 443 or UDP 123.
• The incoming interface, such as a particular Wi-Fi network or VLAN.
• A firewall mark, which is a small tag added earlier by the firewall.

2. Select a table. When a rule matches, the system uses a specific routing table instead of the main one. One table might route everything to the VPN interface, another to the normal gateway.

3. Route. The packet follows the selected table, so the matching traffic goes into the VPN while the rest follows the default path.

A typical Linux version of this looks like the following, shown only to illustrate the shape of it.

# Table 100 sends traffic into the VPN interface
ip route add default dev vpn0 table 100

# Rule: traffic from the work laptop uses table 100
ip rule add from 192.168.1.20 lookup 100 priority 1000

Router firmware wraps the same idea in a screen: pick a device, pick "use VPN" or "bypass VPN", and the system writes the equivalent rules. The private address ranges in these examples come from the reserved set explained in RFC 1918.

Rule order and priority

Rules are checked in order. The first matching rule wins, which makes priority the single most important concept in policy routing.

A short example for a home network:

1. Priority 100: traffic to the local network (192.168.1.0/24) uses the main table, so printers and the home server stay reachable.
2. Priority 200: traffic from the work laptop uses the VPN table.
3. Priority 300: traffic from the VPN-by-request phone uses the VPN table only if it carries a specific mark.
4. Priority 32766: everything else uses the main table, which means the normal connection.

If rule 2 is placed above rule 1, the work laptop can no longer reach the home printer, because its local traffic is sent into the tunnel and goes nowhere. If rule 4 is accidentally above the others, none of the VPN rules ever match. Most "the policy does nothing" or "my printer vanished" reports come down to order.

Match types compared

Match type	What it identifies	Good for	Watch for
Source address	A device or group	Per-device VPN on or off	Addresses must be fixed, so use reservations
Destination address	A server or range	Sending only work or office destinations into the tunnel	Services behind several addresses change over time
Port and protocol	A type of traffic	Sending one service through the VPN	Many apps use common ports, so the rule catches too much
Interface or VLAN	A whole network segment	A guest or "VPN" Wi-Fi network	Needs router support for separate segments
Firewall mark	A tag set by the firewall	Complex mixes of conditions	Harder to read, easier to misconfigure

Source-based rules are the most understandable. Devices on the "VPN Wi-Fi" use the tunnel, devices on the normal Wi-Fi do not. Many households choose this because it needs no per-app thinking.

Policy routing versus its neighbours

People ask how this differs from similar ideas.

• Split tunneling on an app: an app on your phone or computer decides, often by process name. Policy routing decides in the network layer, so it works for devices that cannot run a VPN app, such as a TV or game console.
• A static route: a fixed route to a destination. It can send a range into the tunnel but cannot choose based on the sending device.
• A VPN router versus a VPN app: policy routing is part of what makes a router setup flexible. See VPN router vs VPN app for the wider comparison.
• Zero trust or per-application access: these work at the identity and application level and are a different approach entirely.

A worked example

Take a family with a router that supports policy rules and a VPN connection configured on it.

• Dad's work laptop: 192.168.1.20.
• Mum's phone: 192.168.1.30.
• Smart TV: 192.168.1.40.
• NAS storage: 192.168.1.50.

The goals are that the laptop is always inside the tunnel, the phone is in the tunnel only when it joins the "Private" Wi-Fi, the TV never uses the tunnel, and every device can reach the NAS.

The family sets up four rules in order. First, anything going to 192.168.1.0/24 uses the main table. Second, anything from 192.168.1.20 uses the VPN table. Third, anything arriving on the Private Wi-Fi uses the VPN table. Fourth, anything else uses the main table. They add a fifth item: a firewall rule that drops traffic from 192.168.1.20 and the Private Wi-Fi if the VPN interface is down, which acts as a kill switch.

Result: the laptop is always protected, the phone chooses by Wi-Fi, the TV works as before, and the NAS stays reachable. The family tests it by visiting an IP-check page on each device and confirming the address shown matches what they expect.

Where policy routing fails

Most failures are quiet. The network still works, but not as intended.

• Leaks when the tunnel drops. If the VPN interface goes down, the VPN table loses its default route. The system may fall back to the main table, and traffic leaves in the clear. Add a rule that blocks that traffic instead of falling back.
• DNS goes the wrong way. A device sends its name lookups to the router, which may use the normal connection. Ensure the DNS used by VPN-routed devices also goes through the tunnel. See what a DNS leak is.
• IPv6 is ignored. Rules written for IPv4 do not apply to IPv6. If the network hands out IPv6 addresses, devices can bypass the policy. Either route IPv6 too or turn it off for those devices.
• Changing addresses. If a device gets a different local address after a reboot, the source rule no longer matches. Use DHCP reservations.
• MTU problems. Tunnels shrink the usable packet size. Traffic through the VPN table may hang on some sites if the maximum packet size is not adjusted.
• Overlapping address ranges. If the network you visit uses the same private range as your home, local routes win and some traffic goes to the wrong place.
• Stale marks or connection tracking. Existing connections can keep their old route after you change a rule, which makes testing confusing. Restart the connection or clear its tracked state.

How to test a policy

1. Check the rule list. Read the active rules and routing tables in order and confirm they match your intention.
2. Test each device separately. Visit an IP-check page on each one and compare with what is expected.
3. Test DNS. Use a DNS leak test on devices that should be in the tunnel.
4. Test IPv6. Use a site that reports IPv6 and confirm there is no unexpected address.
5. Take the tunnel down. Disconnect the VPN on purpose and confirm the protected devices lose internet instead of using the normal connection.
6. Test local access. Print, open the NAS and cast to the TV with the policy active.
7. Reboot the router. Confirm the rules and the tunnel come back in the right order.

Limits and good habits

Policy routing is powerful and it is also easy to over-engineer. Keep to a few principles.

• Prefer source-based rules, since they are the easiest to read and audit.
• Use as few rules as will do the job, and write a one-line comment beside each.
• Back up the configuration before changing it, so you can restore a working state.
• Do not treat a router rule as a security boundary against a determined user on the same network. A device owner can usually change their own network settings.
• Remember that policy routing does not make a VPN more private. It only decides which traffic enters the tunnel.
• For step-by-step setup on a router, use the vendor's own instructions and the router setup guide.

Summary

Policy-based routing lets a router or computer choose the route of a packet by rules about its source, port, interface or mark, rather than only its destination. For VPNs it is the machinery behind sending some devices or traffic into the tunnel while others use the normal connection. The key points are rule order, a fail-safe for when the tunnel drops, matching DNS and IPv6 behaviour, and testing each device. Keep rules few and readable, and verify them rather than trusting that they work.

If a prepaid VPN pass would help you test a setup like this, the pricing page shows what is on offer.