Users frustrated that everything is grinding to a halt on the VPN? Split tunnelling has become a go-to fix for IT teams under pressure to improve performance, and vendors like Microsoft and Salesforce have actively recommended it.
But when the switch gets flipped, do you know exactly where that data is going? Who is seeing it? Is your security team even monitoring it?
Without the right guardrails in place, the convenience can quietly create security gaps that your team may not know exist.
What is split tunnelling?
Split tunnelling is a VPN feature that routes traffic through multiple, often two, paths simultaneously: one encrypted VPN tunnel and one standard, unencrypted direct internet path.
Rather than sending everything through one corporate gateway, split tunnelling allows organizations to define which traffic gets tunneled and which goes direct.
Common implementations include:
-
Include-only: specific traffic goes through the VPN
-
Exclude-only: everything goes through the VPN except specified traffic
-
App-based: each application can have its own routing rules
The convenience of split tunnelling
VPNs were originally built to provide secure remote access to internal resources, not to proxy an entire workforce's internet traffic through a single gateway. When large numbers of employees work remotely, that gateway becomes a bottleneck. All that traffic gets encrypted and decrypted by a single device at significant processing cost.
Consider the journey of a network packet from a remote worker using Microsoft 365:
User's laptop → VPN tunnel → Corporate gateway → Internet → Microsoft 365
Whereas if split tunnelling is enabled with Microsoft 365 traffic being split, that journey becomes:
User's laptop → Internet → Microsoft 365
The unnecessary steps disappear entirely.
Because Microsoft 365 is a SaaS product rather than an internal service, routing it through a corporate VPN reflects an outdated design philosophy. Sending all internet activity through a single encrypted tunnel is rarely the right outcome for modern organizations.
Removing the tunnel for SaaS traffic will likely improve latency and, since traffic to Microsoft 365 and most reputable SaaS applications is encrypted via TLS, you still retain a meaningful baseline of security compared to a plain HTTP connection.
Microsoft officially acknowledged this in March 2020, when it recommended VPN split tunnelling for Teams and Office 365 for exactly this reason.
There's also a clear business case. Organizations that try to scale VPN infrastructure to handle all remote internet traffic face unnecessary hardware costs and frustrated users who find their own workarounds, including disabling the VPN entirely, which creates even bigger problems down the road.
The risks of split tunnelling
Traffic that bypasses the VPN also bypasses your next-generation firewall (NGFW), web proxy, and data loss prevention (DLP) controls. For security teams, that means blind spots.
Those blind spots can allow employees to reach malicious websites from work devices, exfiltrate documents to external file stores, or enable threat actors to operate on compromised endpoints without leaving any network trace.
There's also a less obvious risk: if you enable split tunnelling without fully understanding the scope of what you're allowing to bypass the VPN, you could inadvertently give an infected endpoint a clear path to "phone home" over standard internet routes while still connected to the corporate network.
Man-in-the-middle (MitM) attacks
Remote workers connecting from coffee shops, hotels, or public Wi-Fi are already operating in higher-risk environments. When non-tunneled traffic travels unencrypted across those networks, it becomes a target for interception.
DNS leaks
Depending on the implementation, split tunnelling can expose DNS query destinations, creating both a monitoring blind spot and a potential channel for malware.
In a worst-case scenario, a user clicks a phishing link, downloads malware, and that malware establishes its own DNS tunnel, routing requests to an external resolver entirely outside corporate visibility.
From there, it can communicate freely without ever alerting your security team.
Lateral movement
A device with split tunnelling enabled sits with one foot in the corporate network and one foot on the open internet.
A threat actor controlling that device could use C2 infrastructure to quietly gather intelligence from the corporate network through the tunnel.
A sophisticated attacker working slowly could fly under the radar entirely and, by the time the activity is detected, the trail from the compromised device may already be cold.
Real-world scenarios
Scenario A: John receives a phishing email and clicks the link. Because his organization uses app-based split tunnelling and his browser routes over the direct internet path, the payload downloads and beacons home without ever hitting the corporate proxy. His security team has no visibility into the activity.
Scenario B: Jane connects to an airport hotspot while travelling for business. Her organization allows their CRM application to use a direct internet connection. A threat actor intercepts that traffic and harvests her credentials. The security team is left reacting to anomalous SaaS access after the fact, with an unknown dwell time and potential data exposure already in play.
Mitigation strategies
Closing the visibility gap created by split tunnelling doesn't have to mean abandoning it. It means looking beyond the network layer and finding other ways to monitor what matters.
Endpoint detection and response
One of these mitigations is adopting a cybersecurity solution that includes endpoint detection and response.
When traffic bypasses the network perimeter, the endpoint becomes your primary visibility point. Having strong visibility into and the ability to detect and respond to threats at the device level is essential, catching threats that network controls would otherwise have flagged.
DNS security
Forcing DNS queries through a secure resolver, even for direct internet traffic, closes one of the most commonly overlooked gaps in split tunnel configurations.
Field Effect MDR includes a DNS firewall, ensuring that even when devices connect directly to the internet, their DNS activity remains visible, filtered, and protected.
Approved application and IP allowlists
Policy-based rules that restrict direct internet access to specific approved applications and documented IP ranges help ensure split tunnelling is scoped deliberately rather than broadly.
Device compliance enforcement
For organizations that use device management tooling, split tunnelling access can be conditioned on compliance posture.
Devices that fall out of compliance (missed patches, disabled security controls, etc.) could automatically revert to full VPN tunnelling, be placed in a quarantine environment with restricted access, or be blocked from connecting altogether.
Regular configuration audits
Scheduled audits should review the rules currently in place, confirm they work as expected, and assess whether they're still needed.
As with all IT policy, what was appropriate previously may not be appropriate now.
Zero trust for the long term
For organizations looking beyond VPN architecture entirely, a zero trust approach removes the implicit trust VPNs extend to any connected device.
Access is granted at the application layer, conditioned on verified identity and device health, eliminating the need to manage which traffic should or shouldn't be tunneled.
Split tunnelling: Is the risk worth it?
The question isn't simply whether you should enable split tunnelling. It's whether your environment is prepared to do it securely.
The checklist below can help you assess your readiness:
-
Do you have endpoint protections deployed on all devices?
-
Do you have DNS security outside of your tunnel?
-
Do you have appropriate device compliance controls in place?
-
Is the scope of inclusions and exclusions appropriate and documented?
-
Is there a process for periodic configuration reviews?
Answering no to any of these isn't a reason to abandon split tunnelling outright, look at it as a prompt to address the gap first.
Before you flip the switch
Cybersecurity is full of trade-offs between convenience and risk, and split tunnelling is no exception.
Implemented thoughtfully, it can meaningfully improve network performance and reduce infrastructure overhead. Implemented carelessly, it creates bigger problems than the slow VPN complaints it was meant to solve.
If you're considering split tunnelling, don't just flip the switch. Put the guardrails in place first, monitor the implementation, and keep asking whether it's still working the way you intended.
Frequently asked questions
What is split tunnelling and why do organizations use it?
Split tunnelling is a VPN configuration that routes some traffic through an encrypted corporate tunnel and sends the rest directly over the internet. Organizations use it primarily to reduce latency, ease the load on VPN infrastructure, and improve performance for cloud-based applications like Microsoft 365.
Is split tunnelling inherently insecure?
Not inherently, but it does introduce risks that need to be actively managed. Traffic that bypasses the VPN also bypasses your network security controls, so without compensating measures that give you strong visibility into and the ability to detect and respond to threats at the endpoint level (alongside DNS security) it can create significant blind spots.
What types of traffic are safe to exclude from the VPN tunnel?
Well-established SaaS applications that enforce TLS encryption, like Microsoft 365 or Salesforce, are commonly considered reasonable candidates for direct internet routing. That said, any exclusions should be deliberate, documented, and regularly reviewed rather than broadly applied.
What is a DNS leak and why does it matter for split tunnelling?
A DNS leak occurs when DNS queries travel outside the encrypted tunnel and become visible to third parties. In a split tunnel configuration, this can expose where users are connecting and, in malware scenarios, give attackers a covert channel to communicate outside of corporate visibility entirely.
How does split tunnelling relate to zero trust?
Split tunnelling is a workaround within traditional VPN architecture. Zero trust takes a fundamentally different approach, granting access at the application layer based on verified identity and device health, rather than managing which traffic should or shouldn't be tunneled. For organizations looking to move beyond VPN, zero trust is the longer-term alternative.
What should we have in place before enabling split tunnelling?
At a minimum: strong visibility into and the ability to detect and respond to threats across all devices, DNS security that operates outside the tunnel, documented and scoped inclusion/exclusion rules, device compliance enforcement, and a process for regular configuration audits. If any of these are missing, address them before enabling split tunnelling.
Can split tunnelling be reversed if something goes wrong?
Yes — it's a configuration change, not a permanent architectural decision. However, by the time a security incident is attributed to a split tunnel blind spot, damage may already have occurred. Getting the controls right before enabling it is far preferable to reacting after the fact.
