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 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 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. (Update: Since version 9.7, ASA supports route-based VPNs!) 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 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 (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 Check Point and Cisco ASA (up to version 9.6) are not capable of route-based VPNs and only implement this annoying policy-based type. Same is true for some other firewall vendors. (Note that Cisco routers are able to route VPN traffic to tunnel-interfaces and must not be used merely with policies.) And since Check Point and Cisco ASA firewalls are quite common, 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.

AVM FRITZ!Box-yesyes
Cisco Routeryesyesyes
Cisco ASA-yesyes
Cisco ASA since 9.7yesyesyes
Fortinet FortiGateyesyesyes
Juniper ScreenOSyesyesyes
Palo Alto Networksyes-yes

It’s quite obvious that the Cisco ASA (pre 9.6) 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…

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

17 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 :)


  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. ;)

    2. The only thing that comes to my mind (feel free to destroy that point) is IP-bridging.
      With policy IPSec VPNs, at least on FortiGate, you can have the same subnet on both ends of the Client-to-Site tunnel and other hosts on the network won’t even notice that you are connected through a VPN.
      Some previous guy had this set up and we migrated away from it ASAP, but it worked without Mode-config on FortiOS 4.x.
      And yes, this is bad and please don’t do this if you don’t absolutely have to.

  4. Good stuff. But at the moment Cisco Asa can routed based VPN, that I use by myself

  5. 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…

  6. The advantage to Policy based VPNs are simply ease. Often, they expedite the configuration and minimize the hassle of getting a simple “dial-up” VPN running.

    Once more than basic connectivity is required, route based is the winner.

  7. Just some remarks on the AVM FritzBox – The implementation is policy based, yet only one (1) SA seems to be used at any time.

    My setup models hub and spokes: Central there is an (old) bintec RS123, the branches have different FB models. In order to reach branchA from branchB I added the other networks to the “access lists” in their FB vpn.cfg and made the central firewall pass packets. The bintec router started to create separate SAs for each network, even when in routing VPN mode. The FB would only use the latest SA, at least, that’s what it looks like. This was broken.

    Solution to this: make the bintec hub use a policy for the VPN (“Zusätzlicher Filter des Datenverkehrs”) with a local part, that is a superset of all the connected networks. Curiously that works out good.

  8. ASAs can do VTI (route based VPN) as of about 2018 or so, this article is out of date and needs to be updated.

  9. Palo Alto certainly can handle a policy-based VPN. It allows you to setup IPsec phase2 traffic selectors just like everything else.

    You just generally want to avoid doing it, because route-based is so much more elegant. ;)

  10. Informative article. Thank you for writing it. I have a circumstance where I believe a policy-based tunnel will be easier and more appropriate. But I welcome a correction so that I can use route-based instead.

    I have about 400 random hosts across 20 random subnets that need to reach out to a vendor across a tunnel using an ASA/FTD. With route-based tunnel, the vendor can put whatever they want as the routing entries on their side, and all of those will “knock on the door” of my firewall, requiring an ACL to block requests to hosts I do not want them to reach. In fact, they will actually be doing this because they will prefer to enter broad subnets rather than individual /32 routes. Now my firewall needs to process these, and I need to write a separate outside>inside ACL.

    With a policy-based tunnel, our phase 2 entries have to match, and I need to write only one ACL which handles traffic both ways (the hosts can already egress on the needed port inside>out ACL because it’s 443). So my interesting traffic ACL has to match theirs, and it handles all of the traffic, and they can’t attempt entry on any IP they want as they could with a route-based.

    I do generally prefer route-based tunnels, so I would like to use it. But in this case I can’t see an advantage, and a possible disadvantage.

    1. Hey aane!. Thanks for your comment.

      I’ve one question to understand your setup correctly: If you have “400 random hosts across 20 random subnets”, you need all those 400 /32 hosts within your Proxy-IDs (= phase 2 selector), so does your partner on the other side, don’t you? Or do you have larger IP address blocks within your phase 2?

      However, you SHOULD use a dedicated policy/ACL anyway. I don’t expect an enterprise to run a VPN without any ACL for incoming traffic, even coming from their partners.

      Concerning ““knock on the door” of my firewall” –> Yes, you don’t want this situation. But the only chance to overcome this situation is to get your partner to block those unnecessary connections on HIS side anyway. If HE sends junk into the VPN tunnel, it will reach your side anyway, won’t it?

      “With a policy-based tunnel, our phase 2 entries have to match, and I need to write only one ACL which handles traffic both ways (the hosts can already egress on the needed port inside>out ACL because it’s 443).” –> How big is your “phase 2 entries”? If you have to specify your 400 hosts in the phase 2 entries (so must your partner!), you could also specify those 400 hosts in a single security policy (in case of a route-based VPN with one single big route but without any phase 2 entries).

      But maybe I’m wrong. So let’s dig into it. (Sorry for the late reply, by the way.)


Leave a Reply

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