Split tunneling sends only corporate traffic through the VPN tunnel and everything else out over the user's own connection. Full tunneling sends all of it through the office. The split buys bandwidth and speed, and costs the inspection and logging that used to cover every packet.
- Inclusion splits route a named list of internal subnets, nothing else
- Exclusion splits protect by default and let named services out
- Microsoft recommends bypassing the VPN for its optimize endpoints
- Direct traffic is not inspected by anything the company runs
- The DNS half has to be split too, or internal names break
On this page
- The two shapes of a VPN split, and the third one nobody mentions
- Why full tunneling stopped being the obvious answer
- What split tunneling actually costs
- Making a split tunnel VPN safe
- Where the setting lives on each VPN platform
- The DNS half of a split tunnel VPN, which is where it usually breaks
- Where people go wrong
- Comparison
- FAQ
The shapesThe two shapes of a VPN split, and the third one nobody mentions
Every remote access VPN has to answer one question for every packet a device sends: does this data go through the VPN tunnel or not. There are three ways to answer it.
Full tunneling. All traffic goes through the VPN tunnel. The VPN client's default route points into the VPN, so a request for a public website travels to the office, out over the office internet connection, back to the office, and back down the VPN tunnel to the user. Simple, complete, and expensive in speed, bandwidth and everything except security.
Split tunneling by inclusion. The VPN tunnel carries traffic destined for a specific list of internal networks and nothing else. The VPN client keeps its own default route, so any data not on that list goes out over the local internet connection directly.
This is the common enterprise split tunneling configuration, and the list is usually the internal subnets users need access to.
Split tunneling by exclusion. The default route still points into the VPN tunnel, but a named list of destinations is excluded from it. All traffic goes through the VPN except the services you have deliberately let out, which is usually a handful of high bandwidth apps.
Vendors call this inverse split tunneling, and it is the more secure of the two because the default is encryption rather than direct access.
| Shape | Default route | A destination nobody listed | Auditable |
|---|---|---|---|
| Full tunneling | Into the VPN | Goes through the VPN | Completely |
| Split by inclusion | Stays local | Goes out direct, uninspected | Yes, the list is subnets |
| Split by exclusion | Into the VPN | Goes through the VPN | Yes, the list is services |
| Split by app | Either | Follows whichever default applies | Harder, the list is processes |
The third column is the one to read. Under an inclusion split, anything forgotten is exposed; under an exclusion split, anything forgotten is protected. That is the difference between a mistake that costs performance and a mistake that costs visibility.
App based split tunneling is a variation on either, deciding by which app opened the connection rather than by what the data is trying to access. It is common on consumer VPN clients and less so on enterprise ones, because a rule about an app is harder to audit than a rule about a network.
What changedWhy full tunneling stopped being the obvious answer
For a long time full tunneling was the default remote access design, and the security argument was easy: everything the user does is inspected, logged and filtered exactly as it would be in the office.
Two things changed. The first was that the apps users need access to moved out of the building. When the mail server, the file server and the line of business system were all in the building, sending everything through the VPN tunnel sent it to where it was going anyway.
Now the mail is in a cloud tenant, the data is in a cloud platform, and the video calls go to a service with points of presence closer to the user than the office is.
Full tunneling routes that traffic to the office and back out over the internet, costing speed on a path it never needed to take.
The second was volume. Forty users on video calls through one office internet connection is a different problem from forty users fetching email. The office internet link becomes the bottleneck for work that has nothing to do with the office, and the firewall doing the VPN encryption becomes the second bottleneck.
Microsoft's own guidance is the clearest illustration. Its optimize category endpoints, the ones carrying the bulk of the data and the ones where users notice the speed most, are recommended to bypass the VPN entirely. The vendor of the software is telling you not to route its traffic through your VPN.
The costsWhat split tunneling actually costs
The speed benefits are easy to measure and the security costs are not, which is why split tunneling often gets decided on the benefits alone.
Direct traffic is not inspected. Any data bypassing the VPN tunnel does not pass the company firewall, its web filter, its content inspection or its logging. If a user reaches a malicious site over the direct internet path, none of the security tools the company operates sees it happen.
The device bridges two networks. A machine with an active VPN tunnel to the corporate network and an active path to the internet is a route between them for the duration of the session.
That is the structural security objection to split tunneling and it is a real one, though it applies to full tunneling as well whenever the device is on a hostile local network.
Logs become incomplete. An investigation that relies on VPN or firewall logs to reconstruct what a user did will find only the fraction of the data that went through the VPN tunnel. This matters more than most people expect during a security incident.
The local network is now in scope. Users on a hotel or home network reach the internet through equipment you do not control, with local DNS you do not control, alongside devices you have never seen.
None of these are arguments against split tunneling. They are arguments for putting the security controls on the device rather than on the network path, which is the shift that makes the configuration workable.
Doing it safelyMaking a split tunnel VPN safe
A split tunnel VPN is defensible when the security that used to live in the tunnel lives on the device instead.
Put secure access filtering on the device. A DNS filtering agent or a secure web gateway client on the machine inspects the direct internet path, which is the path split tunneling no longer sends through the VPN. This is the single change that turns split tunneling from a security gap into a design.
Be specific about what is excluded. Exclusion lists should name apps and services, not categories. A rule that sends one video conferencing service and one cloud productivity suite directly is auditable. A rule that sends all other data directly is a much larger statement than it looks.
Get the DNS right, and test it. This is where most VPN implementations break, and it is subtle enough to deserve its own section below.
Keep the device managed. Split tunneling assumes the device users have access to is patched, carries working endpoint security and is not shared. On an unmanaged device, full tunneling is not much better, and neither VPN design is the answer.
Log what you can from the device. If the network no longer sees the traffic, the security agent on the machine has to, or the investigation after an incident will have nothing to work with.
By platformWhere the setting lives on each VPN platform
Every VPN platform expresses split tunneling differently, and the vocabulary is different enough that the same decision looks like four unrelated settings.
| VPN platform | Where split tunneling is configured |
|---|---|
| WireGuard | AllowedIPs on the peer. A list of internal subnets splits; 0.0.0.0/0 is a full tunnel |
| OpenVPN | Omit redirect-gateway and push routes for the internal networks instead |
| Cisco Secure Client | The group policy split tunnel setting, with a network list naming what is included or excluded |
| FortiClient | The split tunneling option in the VPN portal or tunnel settings on the firewall |
| Windows built in VPN | The default gateway checkbox in the adapter properties, or Set-VpnConnection -SplitTunneling |
Two details are worth knowing whatever the VPN platform is.
The settings are enforced on the server, not requested by the client. On any managed remote access VPN the routes are pushed down at connection time, which means the split is a policy decision rather than a user preference. That is the property that makes it auditable.
WireGuard is the clearest implementation and the easiest to misread. The allowed IPs list does two jobs at once: it decides what the client sends into the tunnel and what it will accept out of it.
An address missing from that list is not simply unrouted, it is rejected, which is why a WireGuard split tunnel that looks correct sometimes drops return traffic from a subnet nobody listed.
The DNS halfThe DNS half of a split tunnel VPN, which is where it usually breaks
A split tunnel VPN makes two routing decisions, and almost everyone gets the second one wrong.
Consider a user connected over the VPN with split tunneling who wants access to the internal application server. The name has to resolve first. If the VPN client is using the internal DNS server, the answer is a private address, that address matches the VPN route list, and access works.
Now consider the same user opening a public website. If the VPN client is still using the internal DNS server, that query travels through the VPN tunnel to the office, and the answer comes back the same way, even though the connection that follows will go out over the local internet directly.
Every name lookup takes a round trip to the office, which is exactly the speed penalty split tunneling was meant to remove.
The opposite failure is worse. If the VPN client uses the local DNS server for everything, internal names do not resolve at all, or they resolve to the public address of a service that also exists internally, and the user gets outside access to a system they are supposed to reach from the inside.
The configuration that works sends internal domain queries through the VPN tunnel to the internal resolver and every other query to the local one. Most VPN clients call this split DNS or domain based DNS, and split tunneling does not configure it for you. The split horizon DNS problem is the same question seen from the server side.
Test it from a connected VPN client by resolving one internal name and one public name and checking which server answered each. That test takes a minute and catches the mistake that produces half the tickets on a new remote access deployment.
PitfallsWhere people go wrong
Splitting the VPN routes and forgetting the DNS. The most common split tunneling failure by a wide margin, and the symptom is intermittent: some internal names work, some resolve to public addresses, and users get different answers depending on caching.
Excluding by category instead of by destination. "All web traffic" is not an exclusion list, it is the absence of one.
Assuming the device is protected because the VPN is up. The tunnel protects the data that goes through it. With split tunneling the majority of traffic does not.
Leaving the internal subnet list stale. A new internal network that never gets added to the include list has no access over the VPN at all, and the fault looks like a VPN problem rather than a routing list problem.
Overlapping address ranges. Users whose home network uses the same private range as the office have a route conflict, and the usual outcome is no access to the internal resource at all. This is the reason to avoid the default consumer router ranges inside a company.
Treating split tunneling as a setting rather than a decision. It changes where the security controls have to live. Turning it on without moving them is the actual risk, rather than the split itself.
Splitting on an unmanaged device. If the machine is not managed, no security agent on it can be relied on to inspect the direct path, and the VPN configuration has no compensating control at all.
ComparisonThe two designs, row by row, and where each one pays
| Criterion | Split tunneling | Full tunneling |
|---|---|---|
| Traffic through the VPN tunnel | Corporate only | Everything |
| Load on the office internet link | Low | High |
| Latency to cloud services | Low | High |
| All traffic inspected and logged | No | Yes |
| Endpoint bridges two networks | Yes | Less so |
| DNS configuration difficulty | Harder | Simpler |
| Suitable for unmanaged devices | No | Better |
| Vendor recommended for cloud suites | Yes | No |
The fourth and sixth rows are the whole VPN decision. Full tunneling buys complete inspection and pays for it in bandwidth and speed; a split tunnel VPN reverses every one of those and moves the cost to the endpoint.
FAQFrequently asked questions
What is split tunneling?
A VPN configuration where only some traffic goes through the encrypted tunnel. Corporate destinations are routed through the VPN and everything else goes directly over the user's own internet connection, at whatever speed that connection offers.
What is the difference between split tunneling and full tunneling?
Full tunneling routes all traffic through the VPN, including traffic destined for the public internet. A split tunnel VPN routes only what needs to reach the corporate network and leaves the rest to the local connection.
Is split tunneling secure?
It is as secure as whatever protects the device. Data that bypasses the VPN is not inspected by anything the company runs, so the filtering and logging have to move onto the endpoint.
Why do VPN vendors recommend split tunneling for cloud services?
Because routing that traffic through an office and back out adds latency to a path that never needed to include the office. Microsoft recommends bypassing the VPN for its optimize category endpoints specifically.
What is inverse split tunneling?
The opposite default: everything goes through the VPN except a named list of destinations you exclude. It is the safer configuration because anything you forget to list stays protected.
Does a split tunnel VPN leak my DNS?
It can, in both directions. Internal queries sent to a public resolver fail or return the wrong address, and public queries sent through the VPN add a round trip to the office. Split DNS on the VPN client is the fix.
Does split tunneling improve speed?
It improves speed for every connection not going through the VPN, which is usually most of what users do. The encrypted tunnel itself is unchanged.
Can I use split tunneling with WireGuard?
Yes. In WireGuard the split is expressed directly as the allowed IPs list on the peer, which is one of the clearer implementations of split tunneling anywhere.
Should a small business use split tunneling?
Usually yes, if the devices are managed and there is DNS filtering or a web gateway agent on them. If neither is true, the direct internet path has no security at all.
Does split tunneling affect compliance?
It can, because a requirement to log or inspect sensitive user traffic is harder to satisfy when most of it never touches the VPN or any other company infrastructure. Endpoint logging is the usual answer, and it has to be in place before the split, not after.
What happens if my home network uses the same subnet as the office?
The routes conflict and the internal resource is usually unreachable. It is the reason companies avoid the address ranges that consumer routers ship with.
Can I split by app instead of by destination?
Some VPN clients allow it. It is common on consumer VPN products and less common on enterprise ones, because a rule tied to an app is harder to audit than a rule tied to a network.
Is split tunneling on by default?
It depends entirely on the VPN platform. Assume nothing and check, because the default determines whether an unlisted destination is reached over an encrypted tunnel or over direct internet access.
Keep readingRelated concepts
Read next · Remote access What Is an IPsec VPN? The traditional remote access tunnel, and the place the full tunnel default came from. Open this next11 min- Remote access · 14 min WireGuard Explained The allowed IPs list is a split tunnel written as one line, and it decides what the client will accept as well as what it sends.
- DNS · 14 min DNS Not Resolving A split tunnel with unsplit DNS is one of the specific ways a name stops resolving to the right address.