Route- vs. Policy-Based VPN Tunnels

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.

This is one of many VPN articles on my blog. –> Have a look at this full list. <–

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.

Route-Based VPN

As the name implies a route-based VPN is a connection in which a routing table entry decides whether to route specific IP connections (based on its destination address) into a VPN tunnel or not. This routing statement is placed in the routing table of the firewall/router such as any other static/dynamic/connected routes.

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:

  1. a virtual tunnel-interface that sends/receives the tunneled traffic,
  2. a routing statement that routes certain IP destinations into the tunnel with the tunnel-interface as exit interface, and
  3. 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):

Policy-Based VPN

A policy-based VPN does NOT use the routing table but a special additional policy to decide whether IP traffic is sent through a VPN tunnel or not. This policy is similar to policy-based routing which takes precedence over the normal routing table. Hence there are NO routing statements about the remote networks within the routing table.

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

None!

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

Coming into Boston via Cambridge” by Rusty Clark is licensed under CC BY 2.0

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!

Firewall Specific

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.

 Route-
Based
Policy-
Based
Policy-
Based
Termination
AVM FRITZ!Box-yesyes
Cisco Routeryesyesyes
Cisco ASA-yesyes
Fortinet FortiGateyesyesyes
Juniper ScreenOSyesyesyes
Palo Altoyes-yes

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.

Links

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…

Featured image: “The Tunnel” by Frank Dürr is licensed under CC BY-NC-ND 2.0.

7 thoughts on “Route- vs. Policy-Based VPN Tunnels

  1. Check Point firewalls are also supporting only policy-based VPNs which is a disaster if you want to have redundancy, etc…

  2. Hello Johannes,

    Really enjoyed reading that! In our case we mostly implemented what customer asked but in the future we will recommend route based over policy based.

    Have a great rest of the week :)

    Mohamed

  3. Is there really no point in policy based VPN tunnels?
    I’m no expert, but shouldn’t policies allow more control about what traffic to send over the tunnel and what not? A route is for any IP based traffic, a policy can match on specific protocols, sources or other stuff?

    1. Hey Peter,

      thanks a lot for your good question. I have added a couple of sentences in the article to make it better understandable.

      To answer your question: No! Because on route-based VPNs you ALWAYS need a security policy in the firewall to explicitly allow or deny traffic. Just as any other traffic that flows through the firewall. That is: Yes, looking at the route, everything is allowed. But since we are talking about firewalls, we have explicit security policies (ACLs/ACEs).

      So if you have policy-based VPNs terminated on a firewall that uses security policies to control the traffic (as every firewall should do!), you need all traffic statements TWO times, which is ridiculous! One at the VPN section (to have the VPN come up since the policy-based section needs it) and another at the security policies.

      That is: Yes, with policy-based VPNs you can control which traffic is allowed and denied, too. But 1) you don’t have all your security policies at one place (since some of them are in the VPN section while the others are in the firewall section), and 2) you have lots of phase 2 SAs.

      Conclusion: Still no single point for policy-based VPNs. ;)

  4. Hi

    I guess routing based VPN is a lot cheaper to implement. In my opinion that’s the reason for it’s widely spreaded availability on many platforms. In most of the cases it’s suffering the needs but not all.

    In the context of IPSec VPN as intended policy based is the more ‘real’ implementation. For every pair of communicating endpoints there has to be a pair of unidirectional SAs and that’s what pb VPNs guarantee.

    Especially in a situation where routing comes to an end you HAVE to use pb VPN!

    Thinking about this helps a lot…

Leave a Reply

Your email address will not be published. Required fields are marked *