DEV Community

Hugo | DevOps | Cybersecurity
Hugo | DevOps | Cybersecurity

Posted on • Originally published at valtersit.com

Split Tunneling: Performance vs Security in the Remote Work Era

I recently sat in a boardroom where a non-technical CISO was pounding the table, demanding that every single byte of data from 500 remote employees be forced through the corporate VPN. "Full Tunneling is the only way to ensure security!" he shouted.

Meanwhile, back in the server room, the network engineers were watching the office's primary 1Gbps fiber uplink choke to death. Why? Because half the staff was working from home with Netflix running in the background, or downloading 50GB Call of Duty updates, and all that irrelevant, non-business traffic was being hauled across the country into our datacenter, decrypted, inspected by a firewall that was never sized for that much throughput, and then shoved back out to the internet.

Congratulations. You’ve successfully "secured" your network by making it completely unusable for everyone.

If your "Security Policy" involves turning your office into a bottlenecked proxy for the entire internet's entertainment traffic, you aren't an architect; you're a glutton for punishment. It’s 2026. We have the tools to be surgical. It’s time to talk about Split Tunneling—the right way.

The Mechanics: Full Tunneling (The "Hammer" Approach)

In a Full Tunnel configuration, the VPN client modifies the operating system's routing table to set the "Default Gateway" to the virtual VPN interface. In networking terms, we are pushing a 0.0.0.0/0 route into the tunnel.

1. The Bottleneck Problem

When a remote worker is on a Full Tunnel, their computer says: "I don't care if I'm looking for a spreadsheet on the internal file server or a cat video on YouTube—send it all to the VPN."

This creates a massive "tromboning" effect. A packet goes from the user's home in New York, to the office in Chicago, gets inspected, and then goes back out to a server in Virginia. This adds massive latency (RTT) and consumes twice the bandwidth on your corporate circuit—once for the "ingress" from the user, and once for the "egress" to the destination.

2. The False Sense of Security

Admins love Full Tunneling because it allows them to use their expensive "Next-Gen" Firewalls to perform Deep Packet Inspection (DPI) on all user traffic. They think they are catching malware. In reality, most malware today is delivered over encrypted HTTPS (TLS 1.3) with Certificate Pinning. Unless you are performing invasive SSL decryption (which breaks half the modern web and opens its own can of privacy worms), your firewall is just watching encrypted blobs fly by. You are killing your performance for a security benefit that is largely theoretical for most remote workloads.

The Mechanics: Split Tunneling (The "Scalpel" Approach)

Split Tunneling is the practice of only sending specific, corporate-owned IP ranges through the VPN tunnel. Your internet traffic (Google, YouTube, Office 365) goes out through your local home ISP, while your internal traffic (Jira, GitLab, Database) goes through the VPN.

1. The Routing Logic

Instead of 0.0.0.0/0, the VPN client only adds specific routes—like 10.0.0.0/8 or 192.168.50.0/24—to the tunnel interface. The OS sees that a request for 10.0.5.20 matches the specific VPN route, but a request for 8.8.8.8 falls back to the default local gateway.


⚠️ DECLASSIFIED / TRUNCATED VERSION
You are reading a truncated version of this technical guide.
To read the full, unedited deep-dive (including all configuration files, architecture diagrams, and high-res images), visit the original post on Valters IT Docs.

Top comments (0)