Policy-Based vs Route-Based VPNs: Part 1
By Zeeshan | Sunday, December 28, 2014 at 11:05 p.m.
This is the first part of a two-part post that will compare and contrast policy-based VPNs and route-based VPNs. Policy-based VPNs encrypt and encapsulate a subset of traffic flowing through an interface according to a defined policy (an access list). The policy may dictate that only some or all of the traffic being evaluated is placed into the VPN. This type of VPN is often referred to as LAN-to-LAN when implemented on Cisco ASAs, and I have covered the ASA implementation before. This article examines the configuration of a policy-based VPN on Cisco IOS.
In contrast to a policy-based VPN, a route-based VPN employs routed tunnel interfaces as the endpoints of the virtual network. All traffic passing through a tunnel interface is placed into the VPN. Rather than relying on an explicit policy to dictate which traffic enters the VPN, static and/or dynamic IP routes are formed to direct the desired traffic through the VPN tunnel interface. IPsec quick and dirty provides a decent primer if you're not familiar with route-based VPNs on IOS.
The lab topology employed in this article is easily replicated using Dynamips or the community lab, and I encourage readers to play along in a lab of their own while reading. If you do, be sure to bookmark this VPN troubleshooting guide from Cisco before you begin. It can be a real time-saver should you run into a wall.
Topology
Our goal is to form two VPNs across the "public" network represented by the 172.16.0.0/15 space. (And before anyone brings up my New Year's pledge, I am planning to replicate both VPNs configurations using IPv6 in the future. I just wanted to keep the IP architecture as simple as possible for now since we're already dealing with two fairly complex topics.)
The first part of this article covers setting up a policy-based VPN between R1 and R3. The second part will cover the configuration of a route-based VPN tunnel between R1 and R5, and discuss some pros and cons to both approaches.
Step 1: Define an access list to match interesting traffic
This is the policy part of policy-based VPNs. We need to define an access list to match all the traffic we want to send through the VPN between the two routers. Every line in the access list will result in a bidirectional pair of IPsec security associations (SAs) between the VPN endpoints, so it's beneficial to be as succinct as possible when creating a policy.
For our purposes, we only need to match traffic between the two LANs attached to R1 and R3. Specifically, we need to match traffic from 10.0.1.0/24 to 10.0.3.0/24 on R1, and from 10.0.3.0/24 to 10.0.1.0/24 on R3. This results in two ACLs which mirror each other, one on either router.
R1
ip access-list extended R1_to_R3 permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255
R3
ip access-list extended R3_to_R1 permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255
Note that these ACLs must mirror each other exactly in order for the IPsec SAs to form correctly. This is easy when we only have one permit statement, but can become burdensome when dealing with numerous policy entries.
Step 2: Create a pre-shared key
To keep things simple, we'll configure the routers to authenticate one another (via ISAKMP) using a pre-shared key. In the real world, public key authentication provides much better security.
We'll create a keyring to hold our pre-shared keys, which are mapped by peer (public) IP address. R1 maps the key string MySecretKey to R3, and vice versa.
R1
crypto keyring VPN pre-shared-key address 172.16.0.3 key MySecretKey
R3
crypto keyring VPN pre-shared-key address 172.16.0.1 key MySecretKey
Step 3: Create an ISAKMP policy
Next we'll create an ISAKMP policy. This sets the parameters which will be used by the routers during IKE phase one, when the initial asymmetrically-encrypted ISAKMP SA is negotiated. The policy below employs 256-bit AES using pre-shared key authentication (from step two) and Diffie-Hellman group five.
This policy is applied identically to both routers.
R1 and R3:
crypto isakmp policy 10 encr aes 256 authentication pre-share group 5
Step 4: Create an ISAKMP profile
An ISAKMP profile is used to establish parameters for a particular ISAKMP peer by matching its outside IP address. We specify the keyring to be used for this peer so that the router knows how to locate the correct pre-shared key.
R1
crypto isakmp profile R1_to_R3 keyring VPN match identity address 172.16.0.3 255.255.255.255
R3
crypto isakmp profile R3_to_R1 keyring VPN match identity address 172.16.0.1 255.255.255.255
Step 5: Define an IPsec transform-set
Now that ISAKMP is out of the way, we move on to IPsec configuration, which is much less involved: We simply need to define an IPsec transform-set. A transform-set tells the router what protocol, encryption, and hashing algorithms to use when forming the IPsec SAs, as well as in which mode to operate (tunnel or transport) and a few other details. The line below defines a transform-set employing ESP with 256-bit AES and SHA-1 hashing (similar to our ISAKMP policy) in tunnel mode. Create the same transform-set on both routers.
R1 and R3
crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac
Step 6: Create and apply the crypto map
Finally, we tie together all of these pieces by creating a crypto map, which does a few things. In order of the config snippets presented below, these are:
- Matches "interesting" traffic based on the access list we created in step one
- Sets the remote peer to the outside IP address of the remote router
- Sets the transform-set we defined in step five
- Sets the ISAKMP profile we defined in step four
- Enables static reverse-route injection, which creates static routes for the remote networks specified by the matched access list
- Sets the administrative distance of the injected static routes to ten (optional)
After creating the crypto map, apply it to the appropriate interface on each router.
R1
crypto map Policy_VPN 10 ipsec-isakmp match address R1_to_R3 set peer 172.16.0.3 set transform-set ESP-AES256-SHA1 set isakmp-profile R1_to_R3 reverse-route static set reverse-route distance 10 ! interface FastEthernet0/0 crypto map Policy_VPN
R3
crypto map Policy_VPN 10 ipsec-isakmp match address R3_to_R1 set peer 172.16.0.1 set transform-set ESP-AES256-SHA1 set isakmp-profile R3_to_R1 reverse-route static set reverse-route distance 10 ! interface FastEthernet0/0 crypto map Policy_VPN
Our policy VPN configuration is complete! We can verify that the crypto map has injected a static route on R1 for the 10.0.3.0/24 network on R3. (Note that the
static parameter of the reverse-route command causes the route to be injected even when the VPN tunnel is not established.)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
Testing
Policy VPNs by nature are created on-demand when traffic which matches the associated policy (access list) is detected egressing an interface to which the crypto map is applied. Currently, there are no existing ISAKMP SAs:
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
IPv6 Crypto ISAKMP SA
We can generate some traffic to trigger the creation of the VPN by performing a simple ping whose source anddestination addresses are matched by the VPN policy:
R1# ping 10.0.3.1 source 10.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms
Notice that the first packet was dropped while the VPN was established. The next four pings succeeded, and we can verify that an ISAKMP SA was established. We can also verify the creation of IPsec SAs with the command
show crypto ipsec sa.R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
172.16.0.3 172.16.0.1 QM_IDLE 4003 ACTIVE
IPv6 Crypto ISAKMP SA
Successive pings will all succeed so long as the VPN tunnel doesn't time-out.
R1# ping 10.0.3.1 source 10.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.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
That about wraps it up for simple policy-based VPNs. In part two, we'll look at the configuration of a comparable route-based VPN and examine the pros and cons of each approach.
Policy-Based vs Route-Based VPNs: Part 2
By Zeeshan | Sunday, December 28, 2014 at 11:05 p.m.
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.)
R1
crypto keyring VPN pre-shared-key address 172.16.0.3 key MySecretKey pre-shared-key address 172.17.0.5 key AnotherSecretKey
R5
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.)
R1
crypto isakmp profile R1_to_R5 keyring VPN match identity address 172.17.0.5 255.255.255.255
R5
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.
R1
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
R5
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
Testing
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!
No comments:
Post a Comment
Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.