A Monday 9:00 a.m. bandwidth graph that looks like a SYN flood is usually just thousands of remote employees pulling operating system updates and joining video calls. The VPN concentrator CPU pegs at 99 percent. An employee opening an internal finance application sees the same delay as someone joining a call, though the call has no reason to traverse the data center.

The network team blames the appliance. The security team blames the inspection policies. In reality, the appliance passes 10 Gbps with a clean pipe and 2 Gbps with full SSL decryption and IPS enabled. The bottleneck is the inspection stack. The VPN just gets blamed for the queue.

Routing all remote traffic through a corporate data center made sense when the applications lived there. Now users are at home and applications are in the cloud. Full tunneling forces internet-bound traffic to hairpin through the data center. You pay for the bandwidth twice. Split tunneling sends that traffic straight to the internet. It fixes the bandwidth graph. It also removes the corporate egress as the observation and enforcement point.

Split tunneling is a trust decision disguised as a routing decision. The routing table is the easy part. The hard part is admitting what you are no longer inspecting at the network layer. If your security posture depends on seeing every packet at the corporate firewall, you do not have a security posture. You have a network architecture.

When to keep the full tunnel

Full tunneling remains the right choice when the organization cannot accept the loss of network-level visibility, or when the physical constraints do not yet demand a change.

Keep the full tunnel when:

  • Strict regulatory or data handling requirements mandate network-level logging at a corporate egress, and no working replacement exists. Auditors do not care about your bandwidth constraints.
  • Endpoint controls are weak, inconsistent, or deployed on unmanaged devices.
  • Internal resources are entirely in the data center and users require low-latency access to them.
  • The remote population is small enough that the concentrator and internet egress are not bottlenecks.

When to split named services

Most organizations start with a selective split. You exclude specific high-volume or latency-sensitive services, like video media streams or trusted OS updates, while keeping everything else in the tunnel.

Split named services when:

  • Specific traffic is high-volume or latency-sensitive.
  • The destinations can be maintained with confidence.
  • Security has identified replacement controls and logs for the excluded traffic.

The operational trap here is managing a list of cloud provider IP addresses. SaaS providers use massive, rotating content delivery networks. If you use static IP lists for a selective split, legitimate traffic will eventually get blackholed or routed back through the tunnel. Use application-based routing if your client supports it, or accept that the exception will degrade over time and require constant maintenance.

When to split general internet traffic

A broad split opens the default route to the local ISP and only tunnels traffic destined for corporate subnets. This is the reality of modern traffic, where internal-bound traffic is almost always a minority of total tunneled traffic.

Split general internet traffic when:

  • Internal-bound traffic is a small fraction of total tunneled traffic. Verify this with NetFlow before changing the configuration; the number is usually lower than the security team assumes and higher than the network team hopes.
  • Managed endpoints have dependable local protection.
  • The organization accepts that the corporate egress is no longer its general web control point.

The prerequisite for a broad split is endpoint inspection. EDR, DLP, and CASB agents inspect traffic before it leaves the device. This is what makes broad split tunneling defensible. If you split the tunnel and do not have endpoint or cloud inspection, you are trusting the endpoint entirely. That may be acceptable, but it must be a documented decision, not an accident.

The mechanics of breaking things

Before changing the default route, you have to check the failure modes. A successful pilot does not make the routing policy self-maintaining.

  • DNS resolution: Split tunneling creates a split-brain problem. Internal names need internal resolvers; external names need public resolvers. If you force all DNS down the tunnel, you break geolocation routing for public CDNs. If you do not, internal hostnames fail to resolve. Configure the Name Resolution Policy Table (NRPT) on Windows or split DNS on macOS and Linux before touching the routing table.
  • IPv6 leaks: If you tunnel IPv4 but leave IPv6 on the local connection, IPv6 traffic goes direct and uninspected. If your security policy assumes all traffic is inspected, this is a blind spot. Know whether your client drops, tunnels, or ignores IPv6.
  • Subnet overlap: Home router manufacturers default to the 192.168.1.x and 10.0.0.x address spaces. If your corporate network uses the same ranges, split tunneling will cause routing conflicts on the endpoint. The traffic never enters the tunnel.
  • Endpoint health: Check what happens when the endpoint protection agent is unhealthy, uninstalled, or cannot reach its management service. A faster connection is not evidence that the logging requirement went away.

The cloud security shift

SASE vendors will tell you their platform replaces the VPN. It replaces the tunnel. It does not replace the decision about what gets inspected.

When you move to a cloud security service, traffic goes from the endpoint to a nearby cloud point-of-presence for inspection, rather than backhauling to a data center. Zero Trust Network Access (ZTNA) removes the tunnel entirely, connecting the user directly to the application via a broker.

The architecture changes, but the policy questions remain. You still choose what gets inspected. You still have to map controls to traffic classes. You still have to decide what happens when the agent is off. Moving to a cloud-native gateway eliminates the hardware bottleneck, but it requires the same rigorous mapping of traffic to enforcement points.

Write down which control and log source applies to each traffic class before and after the change. “Still protected” is too vague for an incident investigation. When the security operations center pulls the logs for a compromised laptop, they need to know exactly where the traffic went and who was watching it.