02 Policy-based vs Route-based VPN

The difference between these two models decides how a tunnel is configured, how far it scales and which vendors work well together. It is where most multi-vendor VPNs fail (for example Palo Alto ↔ Meraki).

Contenido complementario

Not covered in my courses. Verified against Palo Alto and Meraki documentation (see Sources).

Policy-based

A policy decides which traffic goes into the tunnel: an ACL (classic Cisco crypto map), Proxy IDs (Palo Alto when the peer is policy-based) or Private subnets (Meraki). Each subnet pair is an SA.

  • Pro: easy to understand; works with older devices.
  • Cons: changing subnets means touching both ends; SAs grow with the combinations; no dynamic routing inside the tunnel.

With IKEv1, m local subnets and n remote subnets give T = 2 × m × n SAs (formula from the Meraki documentation). With IKEv2, Meraki sends one aggregated selector and needs only 2.

Route-based

The tunnel is a virtual interface (Tunnel Interface on Palo Alto, VTI on Cisco/Meraki). Traffic enters the tunnel because the routing table points it at that interface. The selectors are 0.0.0.0/0 ↔ 0.0.0.0/0 and don’t restrict anything: routes decide.

  • Pros: adding a subnet means adding a route (or letting BGP advertise it); supports dynamic routing; fewer SAs.
  • Cons: both ends must support it; you have to watch for routing loops.
graph LR
    subgraph "Policy-based"
    P1["ACL / Proxy IDs / Private subnets<br/>decide what gets encrypted"]
    end
    subgraph "Route-based"
    R1["Routing table → tunnel interface<br/>decides what gets encrypted"]
    end

Comparison

Policy-basedRoute-based
What selects the trafficSelectorsRoutes
Changing subnetsBoth endsRoutes (or BGP)
Dynamic routingNoYes (BGP/OSPF)
SAsOne per pair (IKEv1)Usually one
Virtual interfaceNoYes
Palo AltoOnly to interoperate (Proxy IDs)Native
Meraki MXIKEv1 and IKEv2 (IKEv2 policy-based being phased out from MX 26.2)IKEv2: dynamic (BGP) ≥ 19.1.4, static ≥ 26.2

How Palo Alto handles it (documented)

  • With no Proxy ID configured, PAN-OS uses 0.0.0.0/0 ↔ 0.0.0.0/0 with application any: it is route-based by default. A policy-based peer cannot match that with IKEv1.
  • With IKEv1 it accepts only an exact Proxy ID match; with IKEv2 it supports narrowing.
  • Each Proxy ID counts as a tunnel against the firewall’s IPsec capacity.
  • If the traffic is NATed, the Proxy IDs must use the post-NAT addresses.

When to choose each

Self-check

Q1 — What decides which traffic enters a route-based tunnel?

A) A crypto map ACL
B) The Proxy IDs
C) The routing table
D) The phase 2 lifetime

Q2 — With IKEv1, an MX with 3 subnets and a peer with 4 subnets. How many SAs in total (T = 2 × m × n)?

A) 7
B) 12
C) 24
D) 2

Q3 — Why can't an Auto VPN spoke reach the Palo Alto through the hub when the hub–PA tunnel is policy-based?

A) Because IPsec doesn’t support spokes
B) Because traffic arriving over an Auto VPN tunnel cannot be routed into a policy-based IPsec tunnel
C) Because the PA doesn’t accept IKEv2
D) Because the PSK is different

Q4 — What do 0.0.0.0/0 selectors mean in a route-based tunnel?

A) All the site’s traffic is sent through the tunnel
B) The tunnel goes down
C) They don’t restrict anything; routes decide what enters
D) Only ICMP traffic passes

Sources