Policy and Route-based IPsec VPNs compared
In MX19.1.4 firmware, MX Appliances and Z-series Teleworker gateways gained the ability to deploy route-based IPsec VPN tunnels in addition to the older, policy-based model. As of MX26.2 firmware and onward, Meraki devices will be phasing out the use of the latter in IKEv2 unless the the peer explicitly requests a tunnel be built following that model.
This article will describe how policy-based VPNs in IKEv1 and IKEv2 are built on Meraki devices, how the route-based model works in IKEv2, and why the latter is now the preferred method of creating them.
Firmware Support Matrix
This table indicates which firmware releases support the use of policy and route-based VPNs for each version of IKE
| Policy-based VPNs | Dynamic Route-based VPNs | Static Routed-based VPNs | |
| IKEv1 | All existing firmware releases as of MX26.2 | N/A | N/A |
| IKEv2 | MX15 through MX26.1 |
MX19.1.4 onward (eBGP and policy-based routing with a health-check) |
MX26.2.x onward |
Policy-based VPNs
Policy-based VPNs are a legacy model of deploying IPsec VPNs, and rely on what are effectively access control lists to dictate how a tunnel is built. Configuring one requires a list of matching local and remote policies known as Traffic Selectors (aka Proxy IDs) that indicate what traffic is allowed to pass over a given VPN tunnel, and each peer in the tunnel must be in agreement over what is permitted.
Downsides
Policy-based VPNs are a legacy technology that come with a number of significant disadvantages:
- Adding or removing permitted traffic across a policy-based VPN requires reconfiguring each end of the tunnel.
- If new traffic needs to pass over a VPN tunnel that is not covered by a previously established security association (SA)*, a new one must be keyed and maintained, causing additional CPU load and overhead on each peer.
- Depending on the way traffic selectors are structured in a policy-based VPN, situations may arise where new traffic that needs to pass over a VPN tunnel cannot because it would cause a conflict with the traffic selectors covered by an existing SA
- Because of the way traffic selectors are defined on Meraki appliances, it is not possible to route traffic that originated from behind an AutoVPN tunnel over IPsec VPN tunnels when a policy-based VPN is in use
*Note: A security association (SA) describes a means of securely sending traffic from a given source or set of sources to a given destination or set of destinations when IPsec is in use.
A single SA can effectively be considered half of a working IPsec tunnel, since it can send traffic from A to B, but not from B to A (i.e. it's a simplex medium)
IKEv1 Policy-based VPNs
By the nature of how the protocol was originally designed, a given IPsec tunnel keyed by IKEv1 can only contain a pair of traffic selectors that define a single source and destination subnet in each direction. This introduces significant overhead and scale concerns, as each tunnel requires its own cryptographic keying material to be derived and periodically refreshed, to the point that some vendors and cloud service providers restrict how many concurrent SAs may be in place at once.
The formula to calculate the maximum number of SAs that will be keyed between an MX and an IPsec peer when IKEv1 is in use is T=2*m*n where m is the number of subnets on the Meraki device, and n is the number of subnets on the 3rd-party device.
IKEv1 example
The following example visualizes how the security associations would logically appear between an MX appliance and a peer that each have two subnets participating in a VPN with IKEv1:
Following our formula above, in this example, m=2, and n=2. As a result, the equation is T=2*2*2 or T=8 for the total of SAs that must be keyed for full connectivity in each direction.
Note however, that since SAs are keyed on demand (i.e. only when traffic from a given source needs to reach a IPsec VPN peer for which an SA doesn't already exist), the maximum number needed may not always be active at a given point in time.
IKEv2 Policy-based VPNs
One of many differences between IKEv1 and IKEv2 is that the latter removed the restriction on how many subnets can be defined as part of a single traffic selector. When implementing a policy-based peering for IKEv2 on Meraki devices, a single pair of aggregated traffic selectors is created using all of the local and remote subnets configured on Dashboard, and these are used when keying a tunnel to minimize how many are needed for full connectivity.
Compared to the IKEv1 example above that requires 8 SAs, the same IKEv2 policy only requires two:
Theoretically, IKEv2 can allow us to scale up significantly higher than IKEv1 as a result, since there's no need to keep keying additional SAs as more subnets are added, but this has a tendency to run into conflicts in practice.
Unfortunately, there are known compatibility issues this presents to certain vendors - strongSwan is the process Meraki devices utilize to build tunnels to IPsec VPN devices and for L2TP/IPsec Client VPN - as some that continue to enforce the IKEv1 restriction of a single set of src/dst subnets per SA in their IKEv2 implementations (e.g. Cisco ASAs)
Such implementations generally respond to requests to key an IPsec SA by only using a single pair of subnets. If this happens, a tunnel is keyed up only between the subnet that contains the initiating traffic and the destination it's trying to reach, and all further traffic is dropped because it's not in scope.
These conflicts don't arise from anything that is explicitly, technically incorrect, just differences in implementations that standards allow for, but are complex to resolve, which is why Meraki has started to move away from policy-based VPNs starting with MX26.2 firmware.
NOTE: A formal definition on how this process operates can be found under RFC 7296 Section 2.9
The above scenarios are also only a subset of what can fail, because IKEv2 handles SAs very differently depending on whether a device is initiating or responding to a request to build an IPsec tunnel, and a comprehensive list of fail cases is not possible to document.
Route-based VPNs
Rather than using a strict ACL-like policy to determine what traffic should be sent over a VPN tunnel, route-based VPNs rely on the same general routing information learned statically or dynamically as any other traffic would. Internally, these routes can be defined statically or originated and learned via dynamic routing protocols, and use what are frequently referred to as virtual tunnel interfaces (VTIs) as their next hops.
Internally, these interfaces map to a configured VPN tunnel, and upon receiving traffic, devices encrypt and forward it accordingly.,
Compared to policy-based VPNs, route-based VPNs generally require far less overhead, both in complexity of deployment, and in device overhead. They have mostly supplanted policy-based VPNs across the industry as a result, which is why the latter are being phased out on Meraki devices.
The biggest advantage they offer, since they do not rely upon strict policies to build tunnels, is the ability to freely route traffic over them regardless of its source (i.e. they do not suffer from the AutoVPN to IPsec VPN restrictions that Policy-based VPNs do)
How a route-based VPN should be built
The way route-based VPNs should ideally be built can look confusing if you're used to how policy-based VPNs have historically functioned:
Contrary to what the 0.0.0.0/0 in each direction may suggest, the above tunnel doesn't indicate that all traffic will be sent from the MX to its peer or vice-versa: if it did, this would represent a routing loop! Compared to policy-based VPNs, where traffic selectors are the determining factor that dictates what traffic is allowed in, and sent via a VPN tunnel, route-based VPNs do not rely on traffic selectors at all for this determination.
Instead, as their name suggests, they rely entirely on routing information to determine if traffic should be sent to a given VPN peer, as illustrated below
Static route-based VPN example with Virtual Tunnel Interfaces
This example depicts an MX with two VPN peers, each one configured with static routes* to 10.0.0.0/16 and 10.1.0.0/16 as their remote subnets. Such a configuration creates two VTIs within the MX that map to a tunnel for each peer, and static routes that direct it to forward traffic destined to their corresponding subnets. It's these static routes that dictate whether traffic is sent over a given VPN tunnel, not the traffic selectors used to build the tunnel.
Note: the above is an approximation of the internal structure on Meraki devices. The virtual interfaces depicted here are not visible on the Meraki Dashboard
*For more information on how to use BGP to dynamically signal routes over IPsec tunnels, refer to this article. The depicted model is largely still the same, but it requires users to configure a /30 subnet so that the VTIs on each end of the tunnel have distinct IP addresses they can use to form the BGP peering.
Problems if the peer is using a policy-based model
If a remote peer is still using a policy-based model to build a VPN tunnel, IKEv2 has built-in concessions* that will allow it to establish using more strict traffic selectors, but it will likely cause health checks to fail and mark the corresponding routes bad if they are in use, and the tunnel may still experience the same sort of conflicts that are called out in the policy-based IKEv2 section.
If policy-based restrictions are unavoidable on the peer, steps must be taken to ensure the traffic selectors on it are broad enough to cover all of the traffic that is expected to pass over the tunnel in each direction.
*Again, refer to RFC 7296 Section 2.9 as documented earlier.