Is Full Tunneling Simpler Than a Long Split-Tunnel List?

A split-tunnel list starts with three applications and ends up covering most of the machine, and every new line is somebody's exception. At that point the list has quietly become a default with extra steps. Full tunneling inverts the arrangement: everything enters the tunnel unless a documented exclusion says otherwise. Whether that is simpler depends on the gateway and on the local services you would break.

Start by Counting the Rules You Maintain

Count the entries, then count how many have a named owner and a date on which they were last verified. The second number is the one that matters, because an exception nobody owns cannot be evaluated when the software it references is renamed or replaced. Rules keyed to an executable path fail silently after an update, and the failure looks like the VPN being flaky rather than a stale rule. Write the list down before you have an opinion about it.

Each entry should answer three questions: what breaks without it, who decided that, and how you would notice if the reason expired. Entries that cannot answer all three are candidates for deletion rather than migration, and deleting them first makes the later comparison honest.

If most entries route a large share of traffic, you are already running a full tunnel with a maintenance burden attached. The decision is then about where the default lives, not about whether to have one.

Check Whether the Gateway Can Carry the Default

Full tunneling moves every packet to one device, which changes that device's CPU load, conntrack table, address translation and upstream bandwidth requirement at the same time. A gateway that comfortably served a few internal subnets may not have been sized for all of a user's browsing. Look at the largest concurrent session count you expect rather than the average, because the peak is what breaks first.

ip -s link show dev tun0
conntrack -C
ss -s

Measure the same workload before and after the change instead of reasoning from specifications. A single afternoon of ordinary use on one machine will show whether the gateway is close to a limit, and it costs nothing compared with discovering it during a Monday morning.

Also check the path MTU end to end, because a full default exposes every application to the tunnel's maximum packet size. Applications that worked outside the tunnel may now depend on fragmentation behaviour you never had to consider.

Confirm Local Services and Private DNS Still Work

Enumerate what has to stay local by protocol rather than by application name: discovery protocols for printers and displays, a smart-home bridge, a router's management page, a local development server reached by a name that only resolves on the LAN. Those break when the default route starts pointing into a tunnel, and they break quietly because nothing logs an error at the client.

Private DNS is the other dependency. If internal names were resolved by the tunnel's resolver before, nothing changes; if they were resolved locally, a full default has to carry them to a resolver that knows the zones. Test one internal name and one public name after the change rather than assuming the resolver list survived.

Write the local exceptions into the profile that owns them. An exception kept only in someone's memory is the first thing the next migration loses.

Migrate One Profile and Verify the Boundaries

Change the profile through its owning configuration rather than layering a new default on top of manual routes left behind by earlier experiments. Those leftover routes are the usual cause of a migration that appears to work and behaves inconsistently a day later. Keep the old profile available so a rollback is a selection rather than a rebuild.

Then verify two boundaries separately: that public and private destinations both work, and that unwanted traffic does not leave outside the tunnel. A successful page load proves the first and says nothing about the second.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Repeat the check after a reconnect and after an outage, because a kill switch that blocks traffic during a drop is a different property from a route that restores correctly afterwards. The simpler design is the one whose real coverage you can still explain after an application or a network changes.