A VPN profile has one decision that affects performance, security, and support load more than any other: does the default route go through the tunnel?

Full tunneling sends everything. Split tunneling sends only the internal prefixes and lets the rest use the local internet. Both are correct under different requirements, and most districts run one by accident.

The two models

Model Route Effect
Full tunnel 0.0.0.0/0 via VPN All traffic inspected and logged; slower; heavier load
Split tunnel Internal prefixes only Local browsing; faster; filtering depends on endpoint

Full tunneling is the right answer when the requirement is "all staff traffic must be filtered and logged," which is common in K-12 for staff devices. Split tunneling is right when the requirement is "reach the file share and print server," and the rest is ordinary web traffic.

The failure is a full tunnel deployed for policy reasons, then disabled on request for one user who complained about speed — without changing the policy.

Split tunneling moves the filter to the endpoint

If a laptop browses directly, the district resolver and proxy never see the traffic. That is fine if the device has its own filtering agent and you accept the gap. It is not fine if you believed the network was filtering it.

DNS is where split tunnels leak

Three configurations, three behaviors:

Configuration Query path Leak risk
DNS pushed via tunnel Resolver sees every query Low
Local DNS for all queries Internal names fail or leak to ISP High
Split DNS Internal names via tunnel, rest local Medium, needs correct suffix list

A split tunnel without split DNS produces the classic ticket: "the VPN is connected but the intranet doesn't load." The name resolved through the home router, which has never heard of marionisd.net.

Test it explicitly: with the tunnel up, resolve an internal name and an external name, and check which server answered.

The return path

A packet that enters the tunnel must return through it. Two ways this breaks:

  1. Asymmetric routing at the far end. The server replies via its local default gateway instead of the tunnel, and the client drops the reply because it expects the tunnel address.
  2. NAT applied on one side only. The server sees a translated address and replies to it, but the translation does not exist on the return path.

The symptom is identical in both cases: the connection is established, the request arrives, and nothing comes back. A sourced ping from the far end is the fastest discriminator.

Full tunnel, split tunnel, and the return path that has to match.

MTU and MSS

Tunnels shrink the MTU. If the client believes it can send 1500-byte packets and the path allows 1420, the first large packet is dropped, ICMP "fragmentation needed" is often filtered, and the connection stalls.

Fixes, in order of preference:

  1. Set the tunnel MTU to the measured path MTU.
  2. Clamp MSS at the tunnel endpoint.
  3. Lower the client's MTU as a last resort.

Test with ping -M do -s 1400 and adjust until it passes. If ping passes at 1400 and fails at 1472, you have found the number.

Worked example: the teacher whose printing broke

A staff laptop uses split tunneling. Local browsing works, the file share works, printing does not.

  1. The print server is 10.0.0.30; the split tunnel includes 10.0.0.0/8. So the route exists.
  2. ping 10.0.0.30 from the laptop succeeds.
  3. Printing fails. The printer is discovered by mDNS, which does not cross the tunnel.
  4. The fix is either a print server queue reachable by IP, or multicast relay — not "add more routes."

The route was never the problem, which is why "it's a VPN issue" was only half right.

What breaks in production

  • Split tunnel without split DNS, so internal names fail.
  • Full tunnel without capacity, so the VPN concentrator becomes the bottleneck at 08:00.
  • Asymmetric return, so connections hang after the handshake.
  • MTU left at defaults, so large transfers stall while ping works.
  • Policy drift, where the tunnel mode differs per user with no record of why.
  • No logging of the split path, so the traffic you cannot see is the traffic you cannot defend.

Checklist

  1. The tunnel mode is a documented policy decision, not a default.
  2. DNS behavior is tested for internal and external names with the tunnel up.
  3. The return path is verified with a sourced ping from the far end.
  4. MTU is measured and MSS clamped where needed.
  5. Split-tunnel traffic has an endpoint filtering story, or an accepted risk.
  6. Per-user exceptions are recorded, not applied ad hoc.

Next

Tunnels assume a perimeter. The last article asks what happens when you stop assuming one: When Zero Trust Replaces VPN.

  • VPN
  • Split Tunnel
  • DNS
  • MTU
  • Routing