There are two methods of site-to-site VPN tunnels: route-based and policy-based. While some of you may already be familiar with this, some may have never heard of it. Some firewalls only implement one of these types, so you probably don’t have a chance to configure the other one anyway. Too bad since route-based VPNs have many advantages over policy-based ones which I will highlight here.
I had many situations in which network admins did not know the differences between those two methods and simply configured “some kind of” VPN tunnel regardless of any methodology. In this blogpost I am explaining the structural differences between them along with screenshots of common firewalls. I am explaining all advantages of route-based VPNs and listing a table comparing some firewalls regarding their VPN features.
Note that this article focuses on site-to-site VPNs and not on remote access VPNs such as clientless/web-based TLS or client-based IPsec VPNs. I am only talking about site-to-site VPNs between two firewalls/routers which secure IP communications between different IP subnets.
Along with the basic IPsec settings for the tunnel termination such as IKE/IPsec crypto profiles and WAN IP addresses a route-based VPN consists of the following components:
- a virtual tunnel-interface that sends/receives the tunneled traffic,
- a routing statement that routes certain IP destinations into the tunnel with the tunnel-interface as exit interface, and
- a security policy statement based on the zones or addresses which are used by the tunnel-interface.
A route-based VPN does NOT need specific phase 2 selectors/proxy-IDs. They can be ignored since every firewall sets them to ::/0 respectively 0.0.0.0/0 if not specified otherwise. This single VPN tunnel will have only one phase 1 (IKE) tunnel / security association and again only one single phase 2 (IPsec) tunnel / SA.
Here is an example of a route-based VPN configured on a Palo Alto Networks firewall. The following screenshots show (1) the tunnel-interface which belongs to a virtual router and a security zone, (2) a routing entry to route the IPv4 network 192.168.9.0/24 into tunnel.9, and (3) some security policies that decide whether to allow or block traffic coming from/to the tunnel interface based on the zone called “vpn-s2s”:
Here is another example of a route-based VPN on a Fortinet FortiGate firewall. The virtual tunnel-interface is created automatically by the firewall after adding a VPN tunnel (1). You must still configure the route (2) and of course some security policies (3):
Beside the basic VPN settings (which are the same for both types, i.e., crypto settings, WAN IP addresses, etc.) policy-based VPNs need proxy-ID statements that declare the source and destination of the tunneled networks. Synonyms for proxy-IDs are phase 2 selectors or quick mode selectors. Those selectors can either be complete IP subnets or single IP addresses both with either “any” service or just single TCP/UDP ports. In any case, every pair of selectors creates a phase 2 (IPsec) tunnel / security association! That is: if you have X network statements on the local side and Y network statements on the remote side, you’ll have up to X*Y phase 2 tunnels. Ridiculous.
Note that on some firewalls you need an extra security policy section (ACLs/ACEs) in order to control the traffic. For example, on a Palo Alto firewall every traffic is controlled via security policies. Now if a policy-based VPN is terminated here, you have two (!) segments where you must control the traffic: via the phase 2 selectors (to have the VPN come up) and in the security policy (to allow/deny the traffic).
A well-known firewall that only supports policy-based VPNs is the Cisco ASA firewall. Here you’re using so-called crypto maps that specify the tunneled networks. Commonly complete IP subnets are used for both ends (source and destination) while the service is mostly set to “any”. (If you want to allow/deny certain connections you can either add many different traffic selections here, which generates lots of phase 2 SAs, or you must use an additional ACL for that.)
Another firewall that is able to configure policy-based VPNs is the FortiGate from Fortinet (if enabled explicitly). Here you don’t have a separate policy but a third option within the security policy: Beside “ACCEPT” and “DENY” you can now “IPsec” the traffic. Note that every single policy entry generates its own phase 2 tunnel according to its source-destination-service objects. You’ll have many IPsec tunnel afterwards. And of course you must match the tunnel statements on the remote VPN peer firewall exactly to become active.
Advantages of Route-Based VPNs
Route-based VPNs have the following advantages over policy-based ones:
- Routing table entry:
- This gives an unambiguous state of packet traversal. Easy to understand. No hidden policy-based forwarding rules.
- Troubleshooting with traceroute
- Unicast reverse path forwarding (uRPF)
- Load-balancing over more than one tunnel
- Possibility to run routing protocols:
- Not only the common ones such as OSPF but also
- Multicast routing, e.g., PIM
- Redundant VPNs with two or more tunnels over different interfaces/ISPs
- The tunnel-interface can be placed in another virtual router than the WAN interface on which the IPsec tunnel terminates. This give you the possibility to place a default route into the VPN tunnel which is not possible if you’re using proxy-IDs for your tunnel decision. E.g., a 0.0.0.0/0 proxy-ID is problematic with policy-based VPNs.
- Separation of routing (layer 3) and security policies (layer 4-7) which is a good network design. Again, easy to understand. Complexity kills.
- Structured “from-to” access list entries in one single policy set. You have all allowed/blocked entries in one single policy. For example, on a Cisco ASA you must use additional ACLs for each VPN. Really bad.
- Security policies only have the two options “allow” or “block” and not a third action of “ipsec/tunnel”. This makes them easier to understand.
- You can ignore the Proxy IDs. Simply set them to ::/0 (for IPv6) respectively 0.0.0.0/0 (legacy IP) and you’re done.
- Many tunneled IP subnets (routes) still result in one single phase 2 SA tunnels since you’re using the default proxy-ID which tunnels everything. With policy-based VPNs you would have tons of phase 2 SAs since every new policy entry negotiates its own additional tunnel.
Advantages of Policy-Based VPNs
Really, I’m not kidding. To my mind there is no single advantage which makes a policy-based tunnel preferable over a route-based one. In almost all situations it’s a burden because you have to configure many different phase 2 proxy-IDs AND the appropriate security policies.
Hence the question is: Why do so many admins use policy-based VPNs? –> Because Cisco ASA is not capable of route-based VPNs and only implements this annoying policy-based type. Same is true for some other firewall vendors. (Note that at least Cisco routers are able to route VPN traffic to tunnel-interfaces and must not be used merely with policies.) And since the Cisco ASA firewall is quite common in budget-focused security implementations, many admins think it is the best way to do it. It isn’t!
Go for Route-Based!
It should be clear that you should always implement route-based VPNs. No exception.
If you’re running a firewall that only supports policy-based VPNs: Consider buying a better one. ;) Especially when it’s an old Cisco ASA.
One Example out of my Daily Business
Some time ago I migrated a firewall cluster for a customer from an old Juniper ScreenOS firewall to a Fortinet FortiGate one. Since the VPNs were developed over a long period, all cases of different configurations existed: route-based, policy-based with configured proxy-IDs, as well as policy-based through the security policy (type IPsec). Now the customer wanted to tighten it to only have the first two types of VPNs. While it was quite easy to migrate the route-based VPNs and the generic proxy-ID configured VPNs, the policy-based ones were quite a mess! There were not only host objects within the security policies, but also (nested) groups of objects. Furthermore, through static NATs (called MIP within ScreenOS), the proxy-IDs for these policies were NOT the private IPv4 addresses at some points, but the public (NATted) ones. The only way to find out which proxy-IDs were really used was to do a hard job on the CLI to merge the negotiated IDs to the address objects. At the end it was a nightmare to understand all the phase 2 IPsec tunnels. If the customer would have used only route-based VPNs, the complete network setup would be much easier!
The following table shows some firewall/router vendors and their capabilities of VPNs. “Policy-Based” refers to the possibility to configure outgoing VPN tunnels (either in a separate policy or with “tunnel” statements in the security policy) while “Policy-Based Termination” means that the firewall can accept policy-based VPNs from another peer that uses only policy-based statements (proxy-IDs) but cannot have “tunnel” settings in the security policy.
It’s quite obvious that the Cisco ASA firewall sticks out by not having the possibility to configure route-based VPNs. (The Fritzbox is just a “good router” with basic VPN functionality anyway.) The fact that Palo Alto does not implement policy-based VPNs is due to their overall network design principles in which policy-based VPNs do not exist, which is perfect.
(Update: I just came across a link talking about virtual tunnel interfaces (VTI) on Cisco ASA devices beginning with version 9.7. Well, that can probably change my mind after all those years…)