skip to content

In IPsec site-to-site VPNs, what is the difference between a policy-based tunnel and a route-based tunnel built on a virtual tunnel interface?

level: middleimportance: must knowfreq 34%

answer

  1. who decides a packet enters the tunnel
  2. SPD selectors versus the routing table
  3. narrow selectors versus any-to-any
  4. inbound selector check as a free filter

basics

~20 s

In a policy-based IPsec VPN, Security Policy Database selectors decide which packets are encrypted, typically one selector pair per protected subnet pair. In a route-based VPN, a virtual tunnel interface carries wide selectors and the routing table decides what enters it.

solid answer

~40 s

Both designs rest on the RFC 4301 Security Policy Database (SPD), an ordered list of entries whose selectors (address ranges, protocol, ports) say PROTECT, BYPASS or DISCARD. In a **policy-based** tunnel the selectors *are* the tunnel: each local/remote subnet pair is an SPD entry, IKE negotiates traffic selectors to match, and adding a subnet means editing both peers. In a **route-based** tunnel the implementation binds the SAs to a virtual tunnel interface (VTI, an implementation term with no RFC), usually with any-to-any selectors, so a route pointing at that interface decides what is encrypted and BGP or OSPF can run over it. The price of route-based is that the inbound selector check no longer filters inner addresses, so the operator adds that filter on the interface. Neither label appears in an RFC.

go deeper

for a junior

Recall the one-line split: in a policy-based IPsec VPN, selectors decide what is encrypted; in a route-based one, a route pointing at a tunnel interface decides.

for a middle

Explain the SPD as an ordered list of selectors with PROTECT, BYPASS and DISCARD, how IKE copies selectors into TSi and TSr, and why a route-based tunnel negotiates one any-to-any pair.

for a senior

Show the operating consequences: selector edits on both peers for every new subnet, routing-driven failover over a tunnel interface, and the inner-source filtering you must add once wide selectors switch off the inbound selector check.

for a principal

Frame it as where policy lives: in IPsec selectors, which interoperate everywhere but sprawl, or in routing and interface filters, which scale and fail over but turn every routing mistake into a security one.

## The decision both designs make Every IPsec gateway has to decide, for each outbound packet, whether to protect it and with which **Security Association (SA)**. RFC 4301 puts that decision in the **Security Policy Database (SPD)**: an *ordered* list of entries, each holding **selectors** (local and remote address ranges, next-layer protocol, local and remote ports) and an action — `PROTECT`, `BYPASS` or `DISCARD`. RFC 4301 compares the SPD to an access-control list: entries overlap, so order matters, and every SPD SHOULD end with a catch-all entry that discards. The two deployment styles differ in what feeds that decision, not in the cryptography. One point to make early in an interview: **"policy-based" and "route-based" are implementation vocabulary**, and so is **VTI** (virtual tunnel interface). No RFC defines a tunnel interface. The closest hook in the architecture is that RFC 4301 lets an implementation keep several SPDs and choose one with an SPD selection function whose inputs may include local metadata such as the interface a packet arrived on. ## Policy-based: the selectors are the tunnel - Each protected pair — say branch `10.1.1.0/24` to cloud `10.20.0.0/16` — is an SPD `PROTECT` entry naming the remote gateway. - The packet is routed as usual toward the internet-facing interface; on the way out it matches the SPD entry and is encrypted. - IKE copies those selectors into the **traffic selector** payloads (`TSi`, `TSr`) when it creates the Child SA, so the peer must hold the mirror image. - Adding a subnet means editing the selectors on **both** peers and negotiating more Child SA state. - Routing protocols cannot steer traffic into the tunnel: a learned route changes the next hop, but whether a packet is encrypted, and for which peer, is still decided by the SPD match. ## Route-based: the routing table is the tunnel - The implementation creates an interface and binds an IKE SA and a Child SA pair to it, normally with **any-to-any selectors**: address range `0.0.0.0`–`255.255.255.255`, all protocols, ports `0`–`65535`. - A route that points a prefix at the interface is what puts traffic into the tunnel; everything sent to the interface is encrypted with that SA. - The interface has its own address, counters and MTU, so a dynamic routing protocol can peer across it and fail over by withdrawing routes. - Adding a subnet is a route change, static or learned, with no change to IPsec state. ## Side by side | | Policy-based | Route-based | |---|---|---| | What selects traffic | SPD selectors | A route pointing at the tunnel interface | | Selectors negotiated | One pair per protected subnet pair (or a list) | Usually one any-to-any pair | | Adding a subnet | Edit selectors on both peers | Add or learn a route | | Failover | Implementation-specific peer lists | Routing: withdraw the route, use the other tunnel | | Inner-address filtering | The IPsec inbound selector check | Must be added on the interface | | Interoperability | Any IKE peer with matching selectors | Both ends must accept wide selectors | ## What route-based gives up RFC 4301 requires a receiver, after decrypting a packet, to check its inner header against the selectors of the SA it arrived on and to **discard** a mismatch (an auditable event; it MAY also send the IKE notification `INVALID_SELECTORS`). With narrow selectors that check is a free anti-spoofing filter: a branch can only send from the subnets it negotiated. With any-to-any selectors every inner source passes, so a route-based design must add: 1. a filter or reverse-path check on the tunnel interface limiting which inner sources the peer may use; 2. route filtering on any routing protocol run over the tunnel, because a bad advertisement now pulls traffic into it; 3. an MTU set on the interface that accounts for the tunnel-mode and ESP overhead. Policy-based keeps its own costs: selector sprawl, many Child SAs, and partial outages where one subnet pair is down while the others pass. ## Choosing Pick **policy-based** for a handful of static subnets, or when the peer only offers it. Pick **route-based** when the estate grows, prefixes change, or you need two tunnels with routing-driven failover. In an interview, say who decides (SPD versus route lookup), what that does to change cost and failover, and what route-based gives up in filtering — not which product has which button.

  • Can a policy-based IPsec tunnel carry a routing protocol between the two gateways?
    Yes, if the selectors include the gateways' peering addresses, the BGP session itself is protected. But the routes it learns change nothing: what gets encrypted is still decided by the SPD entries, so a learned prefix cannot pull traffic into the tunnel or move it to another. That is why dynamic failover goes with route-based designs.
  • A route-based IPsec peer proposes any-to-any selectors and the other side is configured policy-based with one subnet pair; what happens?
    In IKEv2 the policy-based responder can narrow the proposal to its own subnet pair, or reply `TS_UNACCEPTABLE` if no part is acceptable. A narrowed result leaves the route-based side with an SA that covers only one pair, so traffic it routes into the tunnel for other prefixes is dropped. Matching the selectors on both ends avoids it.

saying these in an interview costs you the question

  • Route-based and policy-based are modes defined in the IPsec RFCs.
  • A route-based tunnel still needs one selector pair per subnet.
  • Any-to-any selectors need no extra filtering on the tunnel interface.
  • Learning a route via BGP moves traffic into a policy-based tunnel.
  • Policy-based means transport mode and route-based means tunnel mode.