In a remote-access VPN, what is the difference between a full tunnel and a split tunnel, and what does each cost?
answer
- where the default route points
- only corporate prefixes enter
- head-end capacity versus inspection
- resolver choice must follow the split
basics
~20 sA full tunnel sends all the client's traffic through the VPN gateway; a split tunnel sends only corporate destinations there and lets the rest go direct. Split saves gateway capacity and latency; full keeps central visibility and control.
solid answer
~40 sThe difference is where the client's default route points. In a **full tunnel** every destination, internet included, goes into the tunnel, so SaaS, web and video traffic reach the internet through the corporate gateway: one egress, central inspection and logging, one DNS policy, but each internet-bound byte crosses the head-end's internet link twice and remote users pay the longer path. In a **split tunnel** only the corporate prefixes, usually RFC 1918 ranges, enter the tunnel and everything else leaves through the local network: far less head-end load and shorter paths to SaaS, but the organisation no longer sees or filters that direct traffic. The split also has to reach name resolution, or lookups for internal names go to the local resolver. It is a capacity-and-latency versus control trade-off, argued per traffic class.
go deeper
Recall the one-line difference: full tunnel sends everything to the VPN gateway, split tunnel sends only corporate destinations there. Then name one gain and one loss of each.
Explain it as a route-table decision: where the default route points, which prefixes go into the tunnel, and why internet traffic in a full tunnel crosses the head-end twice.
Show that DNS has to follow the split, and that the local-subnet exemption leaks names even in a full tunnel. Argue which traffic classes deserve inspection and which can go direct.
Frame it as a capacity and latency budget against central visibility, and say where control moves when traffic goes direct: to the endpoint, or nowhere.
## What the choice is about A **remote-access VPN** connects one device (a laptop or phone) to an organisation's network across networks nobody in the organisation controls: a home router, a hotel, a mobile carrier. Once the tunnel is up, the client has two ways out: the **tunnel interface**, which carries packets encrypted to the **VPN gateway** (the head-end), and the **local interface**, which reaches the internet directly. Every packet is sent one way or the other by the client's route table. Full and split tunnelling are the two answers to one question: *which destinations go into the tunnel?* ## Full tunnel In a **full tunnel** the default route points into the tunnel, so every destination, corporate or not, is sent to the gateway. Internet-bound traffic is decrypted there and leaves through the organisation's own internet edge. - **What it buys:** one egress point, so the same web filtering, data-loss controls, logging and DNS policy apply to a remote user as to someone in the office; the visited network sees only encrypted packets to the gateway. - **What it costs:** every internet-bound byte crosses the head-end's internet link twice, once in through the tunnel and once out to the destination, and the replies do the same in reverse. Video calls and SaaS traffic take a detour via the gateway, adding latency, and gateway capacity has to be sized for all remote traffic, not just corporate traffic. ## Split tunnel In a **split tunnel** only the organisation's own prefixes go into the tunnel and the default route stays on the local interface. RFC 8598 describes it plainly: split-tunnel configurations "only send packets with a specific destination IP range, usually chosen from [RFC1918], via the VPN", which lets an enterprise offer remote access "without needing to accept and forward all the non-enterprise-related network traffic" of its users. - **What it buys:** the gateway carries only corporate traffic, and SaaS and internet traffic take the shortest path. - **What it costs:** traffic that goes direct is outside every central control. The organisation cannot inspect, filter or log it, and the visited network sees its destinations. ## Side by side | Aspect | Full tunnel | Split tunnel | |---|---|---| | Default route | Into the tunnel | Local interface | | Internet and SaaS traffic | Via the gateway | Direct | | Head-end load | All remote traffic, internet traffic twice over the internet link | Corporate traffic only | | Latency to SaaS | Extra path via the gateway | Shortest path | | Central inspection and logging | Everything | Tunnelled traffic only | | What the visited network sees | Encrypted packets to the gateway | Destinations of direct traffic, and names if DNS stays local | | DNS | Gateway-supplied resolvers for every name | Must be split per domain, or internal names leak | ## The split has to include name resolution A route table splits packets by **destination address**, but a DNS query's destination is the resolver, not the name inside it. A split-tunnel client that keeps the local network's resolver for everything will ask it for internal names too. **Split DNS** fixes this by sending queries for internal domains to internal resolvers through the tunnel and the rest to the local resolver; RFC 8598 standardises how an IKEv2 gateway tells the client which domains are internal. The full tunnel is not automatically clean either: RFC 8598 notes that the local network "is often explicitly exempted from IPsec encryption", so a full-tunnel client that keeps using a resolver on that local subnet still sends every name in clear. ## How the decision is usually argued The choice is rarely all-or-nothing. Common positions are: 1. **Full tunnel with a local-subnet exception**, so the client can still reach devices on its own link while everything else is controlled centrally. 2. **Split tunnel with corporate prefixes in**, internet out, and split DNS, when inspection happens on the endpoint instead of the network. 3. **Full tunnel with a few heavy, trusted destinations sent direct**, when head-end capacity is the constraint. What an interviewer wants is the trade-off argued for a traffic class: what the organisation loses sight of, what it saves, and whether name resolution follows the same split.
- Who sees a split-tunnel user's direct internet traffic, and who no longer does?The visited network and its ISP see the destinations of direct traffic, and the names too if lookups go to their resolver. The organisation sees none of it, since it never reaches the gateway. With a full tunnel the visited network sees only encrypted packets to the gateway and the organisation sees the browsing. RFC 8598 counts this as a privacy gain of split DNS: the enterprise "remains unaware of all non-enterprise (DNS) activity of the user".
- Does a full tunnel mean no packet ever uses the local network?No. The tunnel's own encrypted packets travel to the gateway over the local network, address assignment and link-layer resolution stay local, and many deployments exempt the local subnet so the user can reach local devices. That exemption is why RFC 8598 tells full-tunnel deployments to use the gateway-supplied DNS servers for all queries, so lookups do not leak onto the exempted local network.
saying these in an interview costs you the question
- Split tunnelling means the tunnel encrypts only part of each packet.
- A split tunnel sends internet traffic into the tunnel and corporate traffic direct.
- A full tunnel is always faster because the corporate internet link is bigger.
- Splitting the routes is enough; DNS follows the split automatically.
- A full tunnel guarantees that nothing ever touches the local network.