Policy-Based vs Route-Based VPNs: Part 2
By stretch | Wednesday, August 17, 2011 at 1:19 a.m. UTC
This article is a continuation of our discussion regarding policy-based versus route-based VPNs. Make sure to read through part one before continuing if you haven't already. In this second part, we'll look at configuring a route-based VPN on IOS and then examine some important differences between the two approaches.
Step 1: Create a pre-shared key
Route-based VPNs don't rely on an explicit policy (access list) to match traffic, so we can skip that step and start by creating a pre-shared key. On R1, we can re-use the keyring we defined in part one and simply add a new key for R5. On R5, create a new keyring and key for R1. (Use the same key on both routers.)
crypto keyring VPN pre-shared-key address 172.16.0.3 key MySecretKey pre-shared-key address 172.17.0.5 key AnotherSecretKey
crypto keyring VPN pre-shared-key address 172.17.0.1 key AnotherSecretKey
Step 2: Create an ISAKMP policy
We can also re-use the ISAKMP policy we created on R1 in part one; just remember to apply it to R5.
R1 and R5
crypto isakmp policy 10 encr aes 256 authentication pre-share group 5
Step 3: Create an ISAKMP profile
This step should also look familiar. Create a new ISAKMP profile on both R1 and R5 to match the peer IP address to the pre-shared key keyring. (R1 will now have two ISAKMP profiles, R1_to_R3 and R1_to_R5.)
crypto isakmp profile R1_to_R5 keyring VPN match identity address 172.17.0.5 255.255.255.255
crypto isakmp profile R5_to_R1 keyring VPN match identity address 172.17.0.1 255.255.255.255
Step 4: Define an IPsec transform-set
We can also re-use the IPsec transform-set defined on R1. Be sure to define it on R5 as well.
R1 and R5
crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac
Step 5: Create an IPsec profile
At this point we start doing things a bit differently. We need to create an IPsec profile, which serves as a wrapper around one or more transform-sets and other parameters to be used in the construction of IPsec SAs. (For our purposes, we only need to reference a single transform-set, so it probably appears redundant.) Create the IPsec profile on both R1 and R5.
R1 and R5
crypto ipsec profile Routed_VPN set transform-set ESP-AES256-SHA1
Step 6: Create a VPN tunnel interface
Now we get into the meat of the VPN configuration. We need to create a routed tunnel interface on both routers to act as the logical VPN edge. Tunnel interfaces serve to encapsulate/encrypt egressing traffic and decapsulate/decrypt ingressing traffic. (Here's a way to visualize this concept if it's a bit fuzzy.)
We'll use the 192.168.0.0/30 network for our VPN tunnel. The tunnel source and destination addresses are defined as the local and remote outside router IP addresses, respectively. The last two lines of the configs below apply IPsec to the tunnel interface using the IPsec profile we defined in the previous step.
interface Tunnel0 ip address 192.168.0.1 255.255.255.252 tunnel source 172.17.0.1 tunnel destination 172.17.0.5 tunnel mode ipsec ipv4 tunnel protection ipsec profile Routed_VPN
interface Tunnel0 ip address 192.168.0.2 255.255.255.252 tunnel source 172.17.0.5 tunnel destination 172.17.0.1 tunnel mode ipsec ipv4 tunnel protection ipsec profile Routed_VPN
Notice that, unlike our policy VPN configuration, the peer LAN (10.0.5.0/24) is not automatically injected by the VPN because there is no policy to tell the router what exists on the other side of the tunnel:
R1# show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.17.0.0/24 is subnetted, 1 subnets C 172.17.0.0 is directly connected, FastEthernet0/1 172.16.0.0/24 is subnetted, 1 subnets C 172.16.0.0 is directly connected, FastEthernet0/0 10.0.0.0/24 is subnetted, 2 subnets S 10.0.3.0 [10/0] via 172.16.0.3 C 10.0.1.0 is directly connected, Loopback1 192.168.0.0/30 is subnetted, 1 subnets C 192.168.0.0 is directly connected, Tunnel0
Also unlike policy-based VPNs, the SAs for a route-based VPN are constructed automatically and maintained indefinitely whether or not traffic is passing across the VPN.
R1# show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 172.17.0.5 172.17.0.1 QM_IDLE 4004 ACTIVE 172.16.0.3 172.16.0.1 QM_IDLE 4003 ACTIVE
Step 7: Enable dynamic routing
As just mentioned, route-based VPNs have no mechanism to automatically discover the remote networks which are reachable over the VPN. So how do we communicate this information among peers? With a routing protocol, of course! Just about any routing protocol will do; we'll use single-area OSPF for this lab.
OSPF must be enabled for both the internal LAN interface (which in this case is actually just a loopback pretending to be a /24 network) and the tunnel interface. An OSPF adjacency should form between R1 and R5 over the 192.168.0.0/30 network, inside the VPN. There is no need to enable OSPF on the outside network (172.17.0.0/16), which we're pretending is publicly routed space outside of the VPN (e.g. the Internet).
R1 and R5
router ospf 1 ! interface Loopback1 ip ospf 1 area 0 ! interface Tunnel0 ip ospf 1 area 0
R1 and R5 should learn of each other's LAN prefixes via OSPF, and both networks should be immediately reachable via through the VPN tunnel:
R1# show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.17.0.0/24 is subnetted, 1 subnets C 172.17.0.0 is directly connected, FastEthernet0/1 172.16.0.0/24 is subnetted, 1 subnets C 172.16.0.0 is directly connected, FastEthernet0/0 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks S 10.0.3.0/24 [10/0] via 172.16.0.3 C 10.0.1.0/24 is directly connected, Loopback1 O 10.0.5.1/32 [110/1001] via 192.168.0.2, 00:01:29, Tunnel0 192.168.0.0/30 is subnetted, 1 subnets C 192.168.0.0 is directly connected, Tunnel0 R1# ping 10.0.5.1 source 10.0.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.5.1, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Pros and Cons
If you've been paying close attention throughout these last two articles, you'll have noticed a number of subtle but important differences between policy-based and route-based VPNs.
Policy-based VPNs require administrative policy maintenance
This is probably the biggest drawback of using policy-based VPNs as configured in part one. If we wanted to add a second internal network to R3, for example, we would have to manually update the policy ACL on both R1 and R3 to match traffic for the new network. This isn't a big deal if you're only ever going to manage a handful of networks, but the burden can quickly grow tiring when managing several dozen VPN sites.
Policy-based VPNs result in excessive IPsec SA creation
On the heels of the first observation, we realize that every ACL entry in a VPN policy results in a distinct pair of IPsec SAs (which we can examine in detail with the command
show crypto ipsec sa). This isn't a problem if you can efficiently summarize routes, but results in substantial overhead if you have to define a number of distinct routes at either end of the VPN.
Some devices only support policy-based VPNs
I'm looking at you, ASAs. Some devices simply don't support tunnel interfaces or route-based VPNs, making the choice to adopt policy-based VPNs rather easy.
Route-based VPNs require a routed subnet
While route-based VPNs require only a single pair of IPsec SAs, they accomplish this because the VPN tunnel is constructed as an independently routed link (192.168.0.0/30 in our example). Rather than having to match all possible source and destination addresses in the private networks, a pair of IPSec SAs is built only to match traffic between the tunnel source and destination outside IPs. The trade-off, of course, is that we need to assign additional IP address space to the tunnel links.
Route-based VPNs are always on
The SAs for a route-based VPN are always maintained, so long as the corresponding tunnel interface is up. This is in contrast to a policy-based VPN, which forms SAs in response to detecting traffic which matches the policy (and will eventually tear down the SAs in the absence of such traffic). This can be seen as a benefit of policy-based VPNs if your VPN experiences infrequent traffic load, but personally I prefer to have my crypto tunnels up all the time to avoid IKE negotiation delay.
Route-based VPNs require a routing protocol
We saw in part one that reverse route injection can be used in a policy-based VPN to automatically inject static routes for destinations reachable via the VPN tunnel. Route-based VPNs require the introduction of a separate dynamic routing protocol (or static routes) to distribute VPN routing information among peers.
Overall, I think it's fair to say that route-based VPNs offer a much more robust and versatile VPN solution than the policy-based VPN configuration we examined in part one. (And that's not even taking into consideration more scalable route-based VPN solutions like DMVPN.) But I'm curious to hear what readers prefer: policy-based or route-based? Leave a comment and let everyone know!
The configuration files from all three routers used in both parts of this article are available here.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Security
August 17, 2011 at 5:37 a.m. UTC
Well done. Thank for work.
In big corporate network ( > 10 branches) with star (or distrubuted star) topology route-based VPN is more preffered, I think so. Very simple managment and deployment procedure.
August 17, 2011 at 5:47 a.m. UTC
Very nice article!
I would definitely prefer route based VPN if it was available on all platforms and if it was implemented the same way by all the vendors. For example, Juniper's route based VPN still require the definition of an encryption domain and it has to match the packets going into the tunnel rather than the tunnel's outer IP...
So my position is to go for route based VPN if you manage both ends of the VPN tunnel (and with a single vendor solution) or to go for policy based VPN if you only manage one side of the VPN tunnel.
August 17, 2011 at 6:01 a.m. UTC
Of course, you could also use unnumbered interfaces with the route based VPN's saving you a /30. But in that case static routing is out of the window too.
August 17, 2011 at 9:38 a.m. UTC
I prefer route based IPSec VPN cause it's more flexible and simple to manage. Also, in a Lan-to-Lan deployment, it's more convenient and implies less overhead to have the SA's always on.
August 17, 2011 at 12:26 p.m. UTC
Great article! I'd definitely go for route-based VPN.
On the similar note as Krik. Does anybody have an idea whether Huawei supports route-based VPN? I've tried to find something about this but no success....
August 17, 2011 at 3:06 p.m. UTC
I know it wasn't discussed in this article but wouldn't the hybrid approach where routers are used to generate the GRE tunnel and then the ASA is used to encrypt the tunnel. I would think it has the benefits of both: route based with a single SA established on each ASA and able to use dynamic routing protocols.
August 18, 2011 at 12:11 a.m. UTC
Good post, but one of the most useful reasons for implementing VTI with tunnel protection (or route-based VPN) was not mentioned - multicast.
Traditional crypto based VPNs (policy-based VPNs) cannot protect multicast traffic and therefore present a boundary for the multicast domain. Using VTI provides the flexibility to extend and support a multicast architecture.
August 18, 2011 at 12:18 a.m. UTC
@jgiacobbe - The "hybrid" approach you mention is very often used to provide GRE tunnel transport peering within a protected or isolated environment, with an edge or boundary device packaging the clear GRE tunnels inside a crypto IPSEC tunnel, before transmission over an untrusted or unsecure infrastucture (internet). This design scales well and reduces the overall SA sessions supported and maintained.
One of the most powerful and flexible implementations of this design is found in DMVPN, which I believe Stretch covers in a separate article.
August 18, 2011 at 9:39 a.m. UTC
I definitely use route-based VPN in Cisco routers environment, but sometimes it's necessary to use policy-based VPN, ie. Cisco Router to Cisco ASA or different vendor gear.
For more than 5+ branches, I'd recommend DMVPN solution which is very easy to maintain a scale. But it always depends on design - full mesh or star.
August 19, 2011 at 7:39 a.m. UTC
Great job Jeremy .
I'll add few points :
- VTI is supported officially by Cisco indeed between IOS routers only . Unofficially it may work or may not with other gear as well - IOS and Checkpoint firewalls, IOS and ASA (see here https://learningnetwork.cisco.com/thread/4093 ) . But in the end of the day you wouldn't play with production traffic like that.
- The main advantage , as was already mentioned, of VTI is that it can encapsulate multicast, therefore enabling routing protocols to run over VTI interface. You could actually achieve the same functionality with crypto maps by matching crypto ACL on GRE traffic only , then creating non-encrypted GRE tunnel between routers and then transparently for the GRE tunnels encrypting already GRE encapsulated traffic (including routing protocols) using crypto maps. But such setup adds unnecessary header encapsulation lowering effective mtu.
- Being the interface by any other name VTI tunnel adds a lot of functionality, unavailable or not readily available to crypto map configuration:
- You can set VTI as ip nat inside/outside and do NAT translation . In crypto maps case you could this only using PBR and routing traffic via some loopback just for the NAT (and it makes it less supportable and more painful).
- QOS is fully available . In crypto maps you could use "qos pre-classify" in crypto map but at least it is less elegant and less clear how it works . Be aware though that once you enable QOS on VTI the traffic on it becomes process-switched .
- You can set access-lists as you would do on usual interface and do it dynamically without tearing down the tunnel . You can have it in crypto maps also - set access-group under crypto map, but usually you will have to shut down VPN and bring it back for ACL to take effect.
- You can do IP SLA stuff on it (so having to allocate IP address to the tunnel I see as an advantage rather than disadvantage, after all you can pick any RFC 1918 IPs for the tunnel not wasting any legal IPs)
- You can allocate VTI interface to the VRF instance. It is also available with crypto maps (search VRF-aware VPN on cisco.com) but it is no fun doing it this way.While on VTI you just do ip vrf ... under interface and you are done.
Worth knowing that Dynamic VTI is also available to replace the dynamic crypto maps setup for Remote Access VPNs. And there you get even more benefits.
Shameless plug i couldn't help but add - how to configure DVTI on IOS https://supportforums.cisco.com/videos/2542
- Important point to remember - when creating VTIs make sure that destination IP address of the tunnel is NOT resolvable to the very same tunnel interface it is set under . This would cause route resolving loop and interface would be shut down. For this reason it is best practice NOT to run the same routing protocol process on VTI interface and physical interfaces on the same router, or if still doing this at least filter out routes carefully (but most probably it will fail anyway ; so just use different routing processes)
- IN my opinion the main benefit of VTI is that it was a predecessor of the DMVPN, and DMVPN is completely different story (it is amazing to see how you can securely connect 300 branch routers to the DMVPN cloud in no time) .
PS My personal biased view - crypto key rings were designed to ease administrative burden , not adding actually any functionality, but in my experience and having seen few hundred production routers - it only confuses people and is rarely ever used in the end.
I guess I'll stop here as I can talk about VPNs for hours... :)
Best Regards ,
August 23, 2011 at 5:58 p.m. UTC
Good Job, You made me be your Fan
August 31, 2011 at 12:44 p.m. UTC
Step 7... we can use Static Routing... no? I created a VPN between CkeckPoint and Netscreen, and used Static Routing...
I have a topology like MPLS, and once I happened to create a VPN so that more network could have access to a specific network through the Star of the topology ... in this case I had to adopt a policy-based VPN, because a route-based VPN is usable only in case of "one-LAN-to-one-LAN".
So, Route-based VPNs are more robust, but Policy-based VPNs give you more configuration opportunities.
September 18, 2011 at 6:16 p.m. UTC
Another benefit to the VTI VPN tunnel is NAT simplicity. In real life the VPN router may also be acting as the Internet firewall for the branch. In that case the egress interface where the crypto-map is applied is a 'nat outside' interface and policy-based VPN requires NAT route-maps and additional ACLs to perform NAT exemption. This is due to the router's order of operations in which NAT is performed before crypto.
With the VTI VPN, traffic for the remote LAN goes into the tunnel, is encapsulated with the appropriate ESP/IP headers, and is switched to the Internet egress interface. At this point NAT is a non-issue as the ESP packet is just going out from the router's interface and the internally addressed IP packet is safely encapsulated inside.
Maybe not a HUGE benefit but one more small reason route-based VPN is much cleaner than policy-based. If only the ASA would get on board...
September 29, 2011 at 8:09 p.m. UTC
MAN! YOU SIMPLY SAVED MY LIFE! THANK YOU THANK YOU THANK YOU!
December 7, 2011 at 1:12 a.m. UTC
We recently moved away from policy-based in favor of route-based VPN's. The primary reason for this was using a virtual tunnel interface allows multicast to be encrypted across the link (where as IPSEC does not natively support encryption of multicast traffic). Also, you can use unnumbered tunnel interfaces to mitigate the con that "Route-based VPNs require a routed subnet". Hope that helps.
December 15, 2011 at 12:47 p.m. UTC
Thanks for writing this. I'm a technical writer documenting a product that can implement both policy-based and route-based VPNs. My networking background is pretty minimal, but your articles helped me understand the concepts well enough to ask the developers the right questions to be able document the feature.
March 4, 2012 at 4:27 a.m. UTC
I stumbled upon your excellent posts looking into Amazon's VPC with VPN to our data center. Amazon requires route-based VPN and BGP routing. Just another use-case for route-based VPNs.
March 15, 2013 at 2:37 p.m. UTC
@Francesco - Not sure how you had it configured but accessing remote VPN sites via a central hub site is perfectly feasible using route based VPNs. Essentially they behave in the same was as point to point serial links in labs we have all done.
You cannot terminate lots of VPNs on a single tunnel interface, but if each tunnel has a dedicated interface this works fine. Remember tunnel interfaces are virtual like loopbacks, so you can create as many as required.
E.g Site A connects to site C via site B. (for this example Site X refers to both the router and all networks local to it for which is serves as gateway)
Tunnel0 on site A peers with Tunnel0 on site B, 10.0.0.0/30
Tunnel0 on site C peers with Tunnel1 on site B, 10.0.0.4/30
Site A needs a route to both sites B and C via network 10.0.0.0/30
Site B needs a route to Site A via 10.0.0.0/30 and Site C via 10.0.0.4/30
Site C mirrors A by having routes to both A and C via 10.0.0.4/30
Packet generated at A destination C.
A looks up the route to the destination network at C, which points it at tunnel0 on B as the next hop. the packet is encapsulated and forwarded via Tunnel0
The packet is received by B on tunnel0 un-encapsulated and the inner IP headers processed. It then looks up the destination network in it's routing table, which points to tunnel0 on C as the next hop via the attached network on it's own Tunnel1 interface. It encapsulates the packet and forwards it out of tunnel1. It's then received by C on tunnel0, un-encapsulated and forwarded to the local network according to it's own routing table.
I hope that's clear. I currently use Palo Alto firewalls which use route based VPNs. I currently have 12 tunnel interfaces on the ones acting as the hubs. Another advantage of route based is if the router supports firewall features, having separate tunnel interfaces for each VPN allows each tunnel to be in a different firewall zone, or tunnels with properties in common grouped together into the same zone where a single ACL can be applied. - Makes access control a lot simpler to manage in some cases :)
July 7, 2014 at 11:18 p.m. UTC
@krik IME, Juniper has the most flexible IPsec tunnel configurations. You're incorrect that there is a requirement for an encryption domain for Juniper IPsec tunnels. That only exists for policy (not route) based IPsec (in both ScreenOS and Junos).
I realize your comment is 3 years old. Just making things clear for googlers. :)
July 21, 2015 at 5:52 p.m. UTC
Thanks for the post -- hopefully it will prove useful!
Just wanted to let you know that I downloaded the configuration files from your link (http://media.packetlife.net/media/blog/attachments/631/VPN_configs.zip) -- it appears that R3's configuration doesn't include the route-based VPN parameters.
June 8, 2016 at 4:55 p.m. UTC
Thanks for this series of articles. I had not kept up on my VPN technologies as I have been an ASA guy. With my current employer using Palo Alto and looking at Juniper, this was a great quick overview for me to understanding the route-based VPNs and contrasting them to the ASA's policy-based VPNs.