skip to content

In a split-tunnel VPN, how does an include-only route list differ from an exclude list, and where does an unlisted destination go?

level: middleimportance: should knowfreq 35%

answer

  1. two descriptions of one split
  2. which route stays the default
  3. longest prefix decides
  4. INTERNAL_IP4_SUBNET carries the include side

basics

~20 s

An include list sends only the named prefixes through the tunnel and everything else direct; an exclude list sends everything through the tunnel except the named prefixes. So an unlisted destination goes direct under include and into the tunnel under exclude.

solid answer

~40 s

With an **include-only** list the default route stays on the local interface and the client adds tunnel routes for the corporate prefixes, say `10.0.0.0/8` and `172.16.0.0/12`. With an **exclude** list the default route goes into the tunnel and the client adds more specific local routes for a few destinations, such as a SaaS range or its own subnet. The two fail differently: a new internal subnet missing from an include list is sent direct and fails, while a new SaaS range missing from an exclude list just costs head-end capacity. Both rest on longest-prefix match, so overlaps matter: a home LAN on `10.1.2.0/24` beats a tunnel route for `10.0.0.0/8`. In IKEv2 the gateway announces the include side with `INTERNAL_IP4_SUBNET` and `INTERNAL_IP6_SUBNET`; RFC 7296 defines no exclude-list attribute, so exclusions are client configuration.

go deeper

for a junior

Remember the direction: include names what goes into the tunnel, exclude names what stays out of it. The default route sits on the opposite side in each case.

for a middle

Walk through a route table for each model and explain longest-prefix match, including why a home LAN in RFC 1918 space can shadow a corporate prefix.

for a senior

Argue how each list fails when it goes stale, and check IPv6 and the gateway's host route before trusting either model in production.

for a principal

Choose the model by failure mode: an include list risks reachability gaps and clear-text strays, an exclude list risks head-end load. Pick the one whose failure you can afford.

## Two ways to describe the same split A split-tunnel VPN client sends some destinations into the tunnel and the rest out of the local interface. There are two ways to write that policy down, and they are not mirror images in how they fail. - An **include-only** list (often called split-include) names the prefixes that go **into** the tunnel. Everything not named follows the local default route. - An **exclude** list (often called split-exclude) names the prefixes that go **around** the tunnel. Everything not named follows a default route that points into the tunnel. The names vary between clients; the mechanism does not. Both are just entries in the client's route table, and the route table chooses by **longest-prefix match**: of all routes that cover a destination, the one with the longest prefix wins (RFC 4632 states that forwarding "is done on a longest-match basis"). ## Include-only A typical include-only table on a laptop at a hotel looks like this: | Prefix | Next hop | Why it is there | |---|---|---| | `0.0.0.0/0` | hotel router | the local default route, untouched | | `10.0.0.0/8` | tunnel | corporate prefix from the include list | | `172.16.0.0/12` | tunnel | corporate prefix from the include list | | `203.0.113.10/32` | hotel router | the gateway itself, so encrypted packets do not loop into the tunnel | The gateway carries only what the list names. That is the point of split tunnelling, and also its weakness: the list must be complete. When the organisation adds `192.168.50.0/24` for a new data centre and forgets the list, clients send those packets to the hotel router, where they fail or, worse, reach whatever answers on that address locally. ## Exclude An exclude table turns it around: a default route into the tunnel (often implemented as the two halves `0.0.0.0/1` and `128.0.0.0/1`, an implementation technique that outranks the local `/0` without deleting it), plus local routes for the exempted destinations, for example `198.51.100.0/24` for a heavy SaaS service and the client's own LAN prefix. Anything not named goes to the gateway. A stale exclude list fails toward the tunnel: a SaaS provider that adds a new range simply sees that traffic arrive through the head-end, which costs capacity but loses no control. ## What an unlisted destination does | Situation | Include-only | Exclude | |---|---|---| | New internal subnet not in the list | Goes direct and fails | Goes through the tunnel and works | | New SaaS range not in the list | Goes direct, as intended | Goes through the tunnel, costing capacity | | Default when the list is empty | Nothing is tunnelled | Everything is tunnelled | | Typical failure | Reachability gap, packets in clear on the local network | Capacity, latency | So an exclude list fails safer for control, an include list for head-end load. ## Overlaps: the local network can win Longest-prefix match does not care who installed a route. Corporate networks and home routers both draw from RFC 1918 space (`10/8`, `172.16/12`, `192.168/16`), so collisions are common: 1. The client sits on a home LAN `10.1.2.0/24`, which installs a connected route for that `/24`. 2. The VPN adds `10.0.0.0/8` into the tunnel. 3. A packet for the corporate server `10.1.2.40` matches both; the `/24` is longer, so it goes to the home LAN and the server is unreachable. A host route for that one server fixes it but then shadows any home device at that address; the durable fix is corporate addressing that rarely collides. ## How the list reaches the client In IKEv2, the gateway can describe the include side in its configuration payload. RFC 7296 section 3.15.2 says `INTERNAL_IP4_SUBNET` and `INTERNAL_IP6_SUBNET` "may also express the gateway's policy about what traffic should be sent through the gateway", and that the client "can choose whether other traffic" is sent through the gateway or directly. The IPsec traffic selectors then decide what each Child SA actually carries, a subject of its own. RFC 7296 defines no attribute that lists exclusions, so an exclude list is something the client's own configuration supplies. Whatever list is used, it has to cover IPv6 as well: a policy written only for IPv4 leaves every IPv6 destination on the local path.

  • Why does an IPv4-only split policy leak on a dual-stack network?
    The visited network gives the client IPv6 through Router Advertisements, so it has a local IPv6 default route. If the tunnel policy only covers IPv4, every destination reachable over IPv6, SaaS and internet alike, leaves directly whatever the include or exclude list says. The policy has to carry IPv6 prefixes too (in IKEv2, `INTERNAL_IP6_SUBNET`), or the client must block IPv6 egress outside the tunnel.
  • Why does the client add a host route for the VPN gateway's own address via the local router?
    Once a default route or a broad prefix points into the tunnel, the gateway's public address would match it too, and the encrypted packets would be sent into the tunnel they are meant to carry. A `/32` host route via the local router is longer than any tunnel route covering that address, so the outer packets always take the local path.

saying these in an interview costs you the question

  • Include and exclude lists are two names for the same configuration.
  • With an exclude list, destinations not in the list go straight to the internet.
  • A VPN route for 10.0.0.0/8 always wins over the local LAN's own routes.
  • An IPv4 include list also decides where the client's IPv6 traffic goes.
  • RFC 7296 defines an exclude-list attribute alongside INTERNAL_IP4_SUBNET.