Router VPN Policy Routing and Split Tunneling

A router with a VPN client usually starts with a blunt setting: everything at home goes through the tunnel. That is simple, and it is also awkward. The smart TV that works better on the plain connection, the work laptop that already has its own company VPN, the printer that must stay reachable on the local network and the games console that dislikes tunnels all get dragged along. The answer is vpn router split tunneling, which on a router is done with policy routing: rules that decide, device by device or destination by destination, which traffic enters the tunnel and which does not.

This guide covers how policy routing works, the four ways routers choose traffic, how to set up a two-lane home network, how DNS fits in, and the mistakes that cause the most confusion. It assumes a VPN client is already running on your router; if not, start with the router setup guide. For the general idea behind splitting traffic, read what split tunneling is first.

Policy routing in one paragraph

A normal router chooses the next hop by the destination address alone, using one routing table with one default route. Policy routing adds a question before that lookup: does this packet match a rule? A rule might say "packets from 192.168.1.50 use table VPN" or "packets going to this address range use the normal table". The packet then follows whichever table the rule selected. Private home addresses of this kind are defined in RFC 1918, and they are what most home rules match on, because the router sees each device only by its local address.

That last point is the key difference from a phone or computer. A VPN app on a laptop knows which program is sending data. A router sees only packets: a source address, a destination address, a port. It cannot tell whether a browser or a game made the request. Everything you can do on a router has to be expressed in those terms.

Four ways to choose what goes through the tunnel

1. By device (source address)

The most common method. You list the local addresses of the devices that should use the tunnel, or the ones that should skip it. Because the router knows devices by address, you need each device to keep the same address, which is covered below.

2. By network segment

Instead of listing devices, you create two networks (for example a main LAN and a second SSID or VLAN) and apply the tunnel rule to one segment. Anything that joins that Wi-Fi name is in the tunnel; anything on the other is not. This is easier to live with than a list of addresses.

3. By destination (address list)

You send traffic for chosen destination address ranges through the tunnel and everything else directly, or the reverse. This is popular for reaching a workplace network, or for keeping a particular service on the plain connection. It works well for stable, well-defined ranges and poorly for big public websites.

4. By port or service

Rules can match a destination port, such as sending only mail traffic or only a certain service port through the tunnel. This is narrow and precise, but modern traffic mostly shares ports (web traffic is almost all on the same one), so it is rarely a useful way to separate things people actually care about.

Method	Good for	Weak point
By device	Keeping a TV or console outside the tunnel	Needs fixed addresses
By network segment	Households and small offices	Needs a second SSID or VLAN
By destination	Reaching one workplace or a stable service	Large sites change addresses
By port	Specific services	Most traffic shares a few ports

Setting up the lanes

Step 1: give devices stable addresses

Every device rule depends on the device keeping its address. Routers hand out addresses by DHCP, and unless told otherwise the lease can change. Before you write rules:

1. Open the router's list of connected devices and note each device's name and hardware (MAC) address.
2. Create a DHCP reservation for every device you will name in a rule, so the router always gives it the same address.
3. Reboot or renew the device's connection and confirm the address matches what you reserved.
4. Write the table down: device, address, which lane.

Some phones use a randomised hardware address per Wi-Fi network. If a phone keeps getting a new address, switch off address randomisation for your home network on that phone, or the reservation will never match.

Step 2: decide your lanes

Most homes need only two. Write them down before you touch the router.

• Tunnel lane: laptops, phones and tablets that handle email, shopping or work from the home network, and any device you want your internet provider not to read.
• Direct lane: devices that misbehave in a tunnel, devices that need to be reachable from outside, local-only gadgets and anything where speed is more valuable than hiding the address.

A third lane, "work lane", is useful when an employer's laptop already uses a company VPN. Running a second VPN over the tunnel is possible, but it can slow things down and sometimes fails. Putting that laptop in the direct lane, or in its own segment, is often the cleaner choice.

Step 3: build the rules in the right order

Menu names differ, so here is the logic. Check your firmware documentation for the real labels.

1. Create or confirm the tunnel route. The VPN client should expose a separate routing table or an interface the router can select.
2. Turn off "route all traffic through the VPN" as the default. Many firmwares have a single switch for this. For policy routing you replace it with rules.
3. Add rules for the tunnel lane. For each device or segment: source address, destination "any", route via the VPN interface.
4. Leave the direct lane on the default route. Do nothing special for devices that are meant to stay outside.
5. Put specific rules above general ones. A rule for one address should be read before a catch-all. If a general rule sits first, the specific one never triggers.
6. Add an exception for the local network. Traffic between your own devices, such as a phone casting to a TV, should stay on the local network and not enter the tunnel. Most firmware does this by default, but confirm it.
7. Save and test each lane. The test is in the next section.

Testing each lane

Do this with one device from each lane, not just one.

1. On a tunnel-lane device, open an IP-checking page. The address shown should be the tunnel's address, not the one your internet provider gave you. If you are unsure which is which, see what a public IP address is.
2. On a direct-lane device, check the same page. You should see your normal address.
3. Run a DNS leak test on a tunnel-lane device and confirm the resolver is not your internet provider's.
4. Cast or print between a tunnel-lane device and a local device and confirm the local network still works.
5. Restart the router and repeat steps 1 and 2, since some rules fail to load at startup.

For the wider checklist, checking that your VPN is working explains what each result means.

DNS: the part that silently goes wrong

Policy routing decides where packets go, but a DNS request is also a packet. If a tunnel-lane device asks a DNS server that sits outside the tunnel, the names of the sites it visits are visible to that server even though the page traffic is hidden. Two common situations cause this:

• The router gives all devices the same DNS server, and that server is reached over the normal connection.
• A device uses its own configured DNS, such as one set in its network settings, which ignores the router's choice.

The tidy approach is to make sure that the DNS server given to tunnel-lane devices is reachable through the tunnel, and that direct-lane devices use ordinary DNS. A related guide on split DNS explains why a mismatch between routes and name servers causes sites to behave oddly, for example loading a regional version you did not expect. For direct-lane devices there is nothing to protect, so ordinary DNS is fine.

Three scenarios

A household with a TV, a console and four phones. The family wants phones and laptops protected, but the TV app complains whenever the tunnel is on, and the console has long delays. The parent reserves addresses for the TV and the console, puts the phones and laptops on the main Wi-Fi in the tunnel lane, and creates a second Wi-Fi name for the TV and console in the direct lane. Nothing needs to be listed by hand after that, because the segment decides the lane. Pointing the TV at the plain connection also avoids a smart TV VPN problem at its source.

A home office with a company laptop. Lena works for a firm that issues a laptop with its own company VPN. She wants her personal phone and tablet protected, but she does not want the company laptop to run two tunnels at once. She reserves the laptop's address and adds a rule that keeps it on the direct route. The company VPN does its job on top of the plain connection, and personal devices use the router tunnel.

A shared flat with one router. Four flatmates share one connection. One of them wants privacy from the internet provider; the others do not care and one streams a lot. They agree to create a separate SSID that follows the tunnel rule. Only the person who wants it joins that network. The others keep the default network and speeds are unaffected for them.

Limits and honest trade-offs

• Excluded means exposed. Any device in the direct lane uses your normal public address, and your internet provider can see its destinations. Do not move something to the direct lane just because it is annoying; ask whether the risk is acceptable.
• A fail-open default. When the tunnel drops, a device in the tunnel lane may fall back to the normal route unless you have also built a block rule. Splitting does not remove the need for that.
• Domain-based rules are fragile. Large sites use many addresses that change, and a list built today may be wrong next month. Treat domain lists as best effort.
• Throughput is shared. All tunnel-lane devices share one tunnel and the router's processing power. A lower-end router can slow down when several devices stream through it. See why internet speed changes with a VPN.
• Apps on a device are not split. You cannot send one app on a phone through the tunnel and another not through the router. For that you need the app-level setting on the phone.
• Firmware varies. Some consumer firmware offers only an all-or-nothing switch. If your router lacks policy routing, you may need a different firmware or a second device.

Troubleshooting

A device I excluded still shows the tunnel address. Look for a general rule above the specific one, a changed device address, or a second network that follows the default. Re-check the reservation.

A device I included shows my normal address. The rule did not load, the address changed, or the tunnel was down when the rule was evaluated. Restart the VPN client, then the router.

Local printing or casting stopped working. The local-network exception is missing. Add a rule that keeps traffic between private ranges off the tunnel.

Sites in the tunnel lane behave oddly. Compare DNS settings. A mismatch between where packets go and which resolver answers is the usual cause.

Everything is slow. The tunnel lane may be overloaded. Move heavy streaming devices to the direct lane, or see why a VPN is slow.

Common mistakes

• Writing rules by address without reserving the addresses.
• Leaving the "all traffic through the VPN" switch on while also adding rules.
• Placing a catch-all rule above the specific ones.
• Forgetting DNS, so that tunnelled devices still ask the provider's resolver.
• Excluding a sensitive device because it was easier than fixing the problem.
• Assuming a router can split by application.

Summary

Split tunneling on a router is done with policy routing: rules that choose the path by device, network segment, destination or port. Give devices fixed addresses, decide a tunnel lane and a direct lane, order the rules from specific to general, keep local traffic local, and match DNS to the route. Test each lane after setup and after restarts, and remember that anything outside the tunnel is not protected by it.

If you want to try a router setup with a prepaid pass, the pricing page shows the options, and your My Pass page lists the connection methods you can use.