Include-Only or Exclude-Only Split Tunneling: Which Default?
Choose the default before you build the list: tunnel only what you name, or tunnel everything and carve out exceptions. Then test the app nobody listed.
Open the routing section of your VPN client and you are looking at two differently shaped controls that often wear the same label. One asks you to list the destinations that belong in the tunnel, and everything else keeps using the local network. The other assumes everything is tunneled and asks what should be carved back out. Both give you a working tunnel on the first test, and both are maintained by adding lines to a list, which is why the difference stays invisible until somebody installs something new.
The choice is a default, not a feature. Settle it before the list has twenty entries in it.
Read the default off the client, not the brochure
WireGuard makes the decision unusually visible, because AllowedIPs is an include list and nothing else. A peer with 0.0.0.0/0, ::/0 tunnels everything; a peer with 10.20.0.0/16 tunnels only that. There is no exclusion syntax, so if you want one subnet left out you either enumerate every other prefix or add policy routing outside the interface.
OpenVPN reaches the same place from the other direction, with redirect-gateway def1 installing a full tunnel and explicit route directives adding or overriding specific prefixes. Commercial clients usually hide both behind a checkbox and a destination table, so read which one the table actually edits before you trust the label.
The question to ask is not what the checkbox is called. It is what happens to a packet whose destination appears in neither list. Answer that in writing and the rest of the configuration follows from it. Skip the question and the first unexplained failure will be decided by whoever is closest to the client that day.
Follow an application nobody listed
In an include-only design that application goes direct, on the local network, with the local DNS. In an exclude-only design it goes through the tunnel, subject to whatever the server allows, which is often the difference between a new SaaS tool working on day one and a ticket that says the VPN broke it.
Neither default is more secure on its own. Include-only narrows what the tunnel carries and makes the local network the path of least resistance; exclude-only assumes the tunnel is the normal path and treats exceptions as exceptions, which is closer to what most corporate policies actually intend.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Notice which kind of object the platform lists
Android's VpnService.Builder exposes an allowed-application list and a disallowed-application list as two separate models, and per-app rules choose by package rather than by destination. A browser placed in such a list carries every destination it opens, which is a different granularity from a route table and cannot fix one broken site inside a working app.
Desktop clients usually mix both kinds in one interface, so check whether the row you are adding is a package, a hostname or a prefix. They fail in different ways and they are resolved in different places. A hostname row usually becomes a route plus a name, while a package row becomes a policy decision inside the client. Write down which one you added, because the person debugging it later will assume the other.
Test the failure state, not only the happy path
An application excluded from the tunnel does not automatically get clean direct access. If the client also enforces a block-without-VPN rule, the excluded traffic may be dropped entirely, which looks like a broken app rather than a routing decision. Test that case deliberately instead of discovering it from a user report.
Then check DNS and IPv6 as separate items. A tunnel that carries only IPv4 leaves a v6-capable application a path around it, and split DNS decides whether internal names resolve for traffic that is not tunneled at all. Run a listed app, an unlisted app, a name lookup and one reconnect, and keep the results with the configuration.
Write the default down where the next person will find it
Record the chosen default, the exceptions and who owns them in the same place as the client profile, because the next administrator will add an entry without reading this reasoning. Note the date and the reason for each exception, so a stale carve-out for a site that has since been fixed can be removed with confidence. A list with no reasons grows forever.
When somebody reports one broken destination, change the exception rather than the baseline. Flipping the default to fix a single site silently moves every unlisted application to the other side of the tunnel.