The Morning Our Proxy Logs Went Quiet
Our split-tunnel VPN users were bypassing our DNS filtering and web proxy for all non-corporate traffic, including risky personal browsing on corporate devices. I saw it during a Monday review after a FortiGate running FortiOS 7.4.3 showed clean proxy logs for users who had clearly been active all weekend. The endpoint EDR had browser telemetry. The firewall did not. That gap bothered me more than the alerts.
We run a manufacturing environment, so remote access is not just email and file shares. My team supports engineers reaching CAD repositories, maintenance vendors accessing jump hosts, and supervisors checking production dashboards from home. The VPN profile had been tuned for speed because video calls and large file syncs were hurting the gateway. Split tunneling looked like the practical fix at the time.
I was wrong about the blast radius.
The mistake was basic and painful: split tunneling was configured for performance reasons, but the security team was never informed, and DNS leak protection was not configured. We assumed corporate devices would still use our DNS filtering and web proxy. They did not. Anything outside the routed corporate subnets went straight out through home networks, hotel Wi-Fi, and mobile hotspots with no proxy log, no DNS sinkhole, and no consistent policy enforcement.
How Split Tunneling Routes Traffic and What It Exposes
In our FortiClient setup, split tunneling meant only specific internal networks were sent through the VPN tunnel. Routes for ERP, file servers, domain controllers, and several OT systems were injected into the client route table. Everything else, including personal web browsing, public SaaS, search engines, and uncategorized sites, used the local internet connection.
That routing decision changed what we could see. Traffic to our internal ranges crossed the FortiGate and hit our IPS, web filtering, application control, and logging pipeline. Traffic to public destinations skipped those controls entirely unless the endpoint agent caught it locally. We still had Microsoft Defender for Endpoint, but our layered controls became uneven because network inspection disappeared for a large part of the browsing session.
Visibility is a control.
What I did not expect was how normal the bypass looked to users. Nobody was trying to evade security. They opened Chrome, clicked a personal webmail link, searched for a driver download, or watched a training video, and the traffic followed the default route. The VPN icon stayed connected, so users believed they were protected by our normal stack. That false confidence is what makes split tunneling dangerous in corporate environments.
Where DNS Leaks Started Hurting Us
The first hard evidence came from DNS. I compared FortiAnalyzer logs, endpoint DNS telemetry, and a small Python 3.11 script on Ubuntu 22.04 that parsed exported resolver events. Several laptops were resolving gambling domains, newly registered domains, and file-sharing hosts through consumer ISP resolvers while connected to VPN. Our internal DNS servers never saw those lookups.
config vpn ssl web portal
edit "remote-users"
set tunnel-mode enable
set split-tunneling enable
set dns-server1 10.20.10.10
set dns-server2 10.20.10.11
set ipv6-split-tunneling disable
next
end
config vpn ssl settings
set dns-suffix "corp.example.local"
set source-interface "wan1"
set source-address "all"
set default-portal "remote-users"
endThe configuration handed out corporate DNS servers, but it did not force all DNS to use them. On some home networks, the local adapter kept its resolver preference. On others, browsers using secure DNS made the problem harder to spot because lookups moved to HTTPS. If I cannot see the query, I cannot block the domain before the connection starts.
DNS leaks are not cosmetic.
We treated DNS as a policy boundary after that. I do not care whether the packet eventually goes direct or through the tunnel if the device can still ask an untrusted resolver where to go next. For corporate-owned devices, resolver control is part of the security baseline, not a convenience setting.
Choosing When Split Tunnel Is Acceptable
We stopped arguing about split tunneling as if it were always good or always reckless. The better question was which users, devices, and traffic patterns could tolerate reduced network visibility. In a plant environment, that distinction matters because a controls engineer downloading vendor firmware from a hotel network is a different risk than a sales user joining a public webinar.
- We allow split tunnel for managed devices with enforced DNS, current EDR, disk encryption, and certificate-based VPN authentication.
- We do not allow split tunnel for privileged admin accounts, domain admin workflows, or access into OT management segments.
- We require full tunnel for unmanaged contractor devices, even when access is limited to a published application.
- We block local LAN access during VPN sessions unless a business exception is documented.
- We review SaaS and public cloud destinations separately instead of pretending every internet path has equal risk.
Switching 200 remote users to full-tunnel VPN increased bandwidth on the VPN gateway by 40%, but it eliminated all DNS leak and web filter bypass incidents. That was not free. We had to add capacity, tune inspection profiles, and adjust help desk scripts for home printer complaints. I still prefer paying for bandwidth over explaining why a corporate laptop reached a known-malicious domain with no network log.
Performance is not a security exception.
You may also find this useful: Check out our guide on Python Network Config Backup: Automating Multi-Vendor Device Snapshots for more practical tips.
My opinion is simple: split tunneling is acceptable only when the security team owns the policy, the device is managed, DNS is enforced, and bypass traffic is measured. If the network team quietly enables it to reduce load, the organization has made a security decision without security review.
Implementing DNS Enforcement as the Middle Ground
We did not keep every user on full tunnel forever. After the incident review, we built a middle ground that kept split tunneling for selected groups while forcing DNS and high-risk web categories back through controlled paths. FortiOS 7.4.3 gave us the VPN and policy tools, but the real work was operational: endpoint profiles, change records, exception tracking, and log validation.
Our target state was plain. Corporate DNS had to be used during VPN sessions. Browser secure DNS had to be disabled by policy. Known risky categories had to traverse our proxy or secure web gateway. Local network access had to be blocked for users handling sensitive systems. We also added a scheduled check that compared VPN sessions against DNS events, because configuration screenshots are not evidence.
Trust the logs, not the diagram.
For testing, I used a Windows 11 23H2 laptop, FortiClient 7.2.4, and a lab Ubuntu 22.04 box running Python 3.11 to generate DNS and HTTP probes before and after VPN connection. The test was intentionally boring: resolve controlled domains, browse allowed and blocked categories, verify route tables, then confirm FortiAnalyzer received the expected DNS and web events. Boring tests catch expensive assumptions.
I also learned to write the exception process in plain language. If a department wanted split tunnel for performance, they had to identify what traffic would bypass inspection, what endpoint controls replaced the missing network controls, and who accepted the residual risk. That made the conversation less emotional. It also stopped split tunneling from being treated as a hidden performance knob.
Measure What Remote Users Are Bypassing
I now treat every VPN design review as a visibility review. I ask what the user can reach, what the gateway can inspect, what DNS path the device uses, and what logs my team would have after a malware download. If the answer depends on hope, the design is not ready.
The cleanest control is still full tunnel for high-risk users and high-value systems. Split tunnel can work, but only with enforced DNS, endpoint policy, browser controls, route validation, and logging that proves bypass traffic is not turning into unmanaged traffic. In my environment, the performance win was real, but the visibility loss was real too, and only one of those showed up in a security incident review.
My opinion after cleaning this up is blunt: split tunneling should be an approved security architecture, not a quiet bandwidth workaround.