skip to content

On a remote-access VPN client, why can classless static routes from the local DHCPv4 server pull traffic out of the tunnel, and what prevents it?

level: seniorimportance: should knowfreq 15%

answer

  1. the split lives on the client
  2. longest prefix beats who installed it
  3. option 121 routes MUST be installed
  4. the gateway never sees what stays out
  5. enforce below the route table

basics

~20 s

The split lives in the client's own route table, where the most specific route wins. Option 121 routes from the local DHCPv4 server, or a local administrator, can outrank the tunnel's routes; egress rules tied to the tunnel interface stop that.

solid answer

~50 s

A VPN client enforces its policy by installing routes: corporate prefixes for a split tunnel, or for a full tunnel a default route, often as the halves `0.0.0.0/1` and `128.0.0.0/1` so it beats the local `/0` without deleting it, an implementation technique. Lookup is longest-prefix, so any more specific route wins. RFC 3442's Classless Static Route option, code 121, lets the visited network's DHCPv4 server hand the client arbitrary prefixes via a local router, and a client that supports it MUST install them; a `/25` or `/32` pushed that way beats the tunnel's `/1` or `/8`, and that traffic leaves in clear. A local administrator can do the same by hand, and the gateway never sees what stays out of the tunnel. The controls are on the client: host firewall rules that allow egress only through the tunnel interface, refusing local routes that overlap tunnel policy, and no local admin rights.

go deeper

for a junior

Recall that the VPN works by adding routes on the client, and that the most specific route wins whoever installed it.

for a middle

Explain longest-prefix match against the tunnel's routes, the two-halves trick for a full tunnel, and what RFC 3442 option 121 lets a DHCP server install.

for a senior

Show why the gateway cannot see a bypass and which client controls actually hold: egress rules on the tunnel interface, refusing overlapping routes, no local admin rights.

for a principal

Treat the endpoint as the enforcement point of any VPN policy, and decide how much device control you need before split or full tunnel means anything.

## Where a split is actually enforced Whether a packet enters a VPN tunnel is decided on the **client**, by its route table, every time it sends. The gateway only ever sees packets that arrive through the tunnel. That makes the client's route table the real enforcement point for both split and full tunnels, and anything that can add routes to it can change the policy. A typical full-tunnel client at a hotel holds: | Prefix | Next hop | Installed by | |---|---|---| | `0.0.0.0/0` | hotel router `192.168.1.1` | DHCP Router option | | `0.0.0.0/1` | tunnel | VPN client | | `128.0.0.0/1` | tunnel | VPN client | | `203.0.113.10/32` | hotel router | VPN client, so packets to the gateway stay outside the tunnel | Splitting the default route into two `/1` halves is a common implementation technique: each half is longer than `/0`, so together they capture every destination without removing the local default route. It works only as long as nothing longer appears. ## Longest prefix decides, not the installer Forwarding picks the **longest matching prefix** (RFC 4632: forwarding "is done on a longest-match basis"). The route table does not care whether a route came from the VPN client, from DHCP or from a person. So: - a `/25` for `198.51.100.0` via the hotel router beats `128.0.0.0/1` for every address in that `/25`; - a `/24` for part of `10.0.0.0/8` beats a split tunnel's include route for that part; - a route with a lower metric does **not** beat a longer prefix; metrics only break ties between equal prefixes. ## Routes the visited network can push RFC 3442 defines the DHCPv4 **Classless Static Route option**, code 121, which carries any number of destination prefixes, each with a router address. Its client rules are strict: a client that supports it "MUST install the routes specified in the option", and if the server sends both option 121 and the Router option, the client MUST ignore the Router option. Its security considerations say the option "can be used to misdirect network traffic", the same exposure the Router option already has. For a VPN client this means a misconfigured or hostile DHCP server on the visited network can install prefixes longer than the tunnel's routes, pointing at a local router. Traffic to those prefixes then leaves the local interface unencrypted, while the VPN client still shows the tunnel as connected. IPv6 has a counterpart: RFC 4191's **Route Information Option** in Router Advertisements lets a router advertise more specific routes, which hosts that implement it install; RFC 4191 itself uses this for a correct split, with the corporate router advertising its site prefix through the tunnel. ## Local administrators A user with administrative rights on the device can add routes, delete the VPN's routes, or change the client's split policy. Whatever the organisation decided, the device does what its route table says. ## What the gateway can and cannot do | Gateway can | Gateway cannot | |---|---| | Drop tunnelled packets whose inner source is not the client's assigned address | See traffic that never entered the tunnel | | Limit which internal destinations tunnelled traffic may reach | Force the client to send anything into the tunnel | | Refuse clients whose posture report fails | Verify a posture report the client itself produced | The IPsec traffic selectors bound what each Child SA may carry, but they constrain the tunnel, not the client's decision to bypass it. ## Controls that hold 1. **Enforce below the route table.** Host firewall rules that permit egress only through the tunnel interface, except to the gateway's address and the local essentials such as DHCP, keep traffic in even when a longer route appears. This is how lockdown modes work, a subject of its own. 2. **Refuse overlapping local routes while connected.** Some clients ignore option 121, or drop local routes that overlap tunnel policy, while the tunnel is up; this is an implementation choice, not a protocol rule. 3. **Isolate routing.** Put the physical interface in a separate routing table or namespace so only the VPN process can use it. 4. **Remove local admin rights** on managed devices, and treat device posture as an input, not proof. A full tunnel is not immune by being full: built from routes alone, it loses to any longer prefix the visited network installs.

  • Does a full tunnel avoid route-override leaks?
    Not if it is built only from routes. Two `/1` halves beat the local `/0` but lose to any longer prefix covering the destination that the visited network installs through DHCP option 121 or an IPv6 Route Information Option. A full tunnel holds only when it is enforced below routing, with host firewall rules that drop egress outside the tunnel interface except to the gateway.
  • Why can the VPN gateway not detect that the client is bypassing the tunnel?
    The gateway's view is the tunnel: it sees and can filter what arrives there, such as packets with a wrong inner source address or a forbidden destination. Traffic routed out of the local interface never reaches it, and a posture report is produced by the client itself, so a modified client can report whatever it likes.

saying these in an interview costs you the question

  • Routes installed by the VPN client always take priority over routes learned locally.
  • A full tunnel cannot leak because its default route points into the tunnel.
  • The VPN gateway can enforce the split by inspecting the traffic it receives.
  • DHCP can only set a default gateway; it cannot install other routes.
  • A lower metric on the tunnel route beats a longer local prefix.