IPsec VPN Configuration On Cisco IOS XE - Part 2 - VRF-Aware Policy Based VPN

This is the second article in series about configuring VPN tunnels in IOS XE. [ Link to Part 1 ]

In the previous part, I configured simple policy-based VPN tunnels. In this article, I will show how to build a VRF-aware policy-based VPN tunnel.

Network administrators need this solution in following special cases.

1) Spoke site networks using same IP subnet.

If you check the network diagram given above, you will notice that both locations site-a and site-b have same LAN subnet, i.e. 192.168.10.0/24. If we use simple VPN tunnels setup (like Part 1) then it causes trouble for traffic paths towards spoke sites. Router dc-gw1 cannot differentiate between traffic to site-a with traffic to site-b.

The solution for this situation is to enable VRF-aware VPN tunnels, one VRF for each tunnel and with NAT for spoke side LAN subnet (192.168.10.0/24). This is also applicable if any spoke sites have matching network subnet as hub (DC) site.

2) Network security requirements of the organization require separating traffic passing through different tunnels.

If a network administrator wants to keep traffic passing through two tunnels separate. In this scenario, separation is done by using VRF.

This is an imaginary setup of a company which has Data Centre (DC) with Application and Storage servers. And two sites (a and b) connect to DC via IPSEC VPN tunnels with the Internet as an underlay. Details of IP addresses and device connections are shown in the diagram.

Goals of this scenario are -
1) Create Policy based IPSec VPN tunnel between "dc-gw1" in DC to "site-a-gw1" in site A.
2) Create Policy based IPSec VPN tunnel between "dc-gw1" in DC to "site-b-gw1" in site B.
3) Traffic between "app1" server to "user" in site A will be NATed. We have to configure "inside" and "outside" NAT.
4) Keep traffic between DC to sites in different VRF.

Router IOS version used for this setup are -
dc-gw1 = Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(2)S, RELEASE SOFTWARE (fc2)
site-a-gw1 and site-b-gw1 = Cisco IOS Software, 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(24)T, RELEASE SOFTWARE (fc1)

I had configured Interface IP's on DC router and site routers and implemented default route towards Internet router. This simulates underlay Internet links for DC and sites.

Interface And Route Configuration On DC Router = "dc-gw1"

Interface And Route Configuration On site A Router = "site-a-gw1"

Interface And Route Configuration On site B Router = "site-b-gw1"

Above in both routers "site-a-gw1" and "site-b-gw1" have LAN interface with same IP subnet - 192.168.10.0/24 

Next is  Policy-based IPsec VPN configuration for DC router and site routers

IPsec VPN Configuration On DC Router = "dc-gw1"

Here ISAKMP profiles are assigned to their VRF using commands "vrf site-a" and "vrf site-b"

IPsec VPN Configuration On site A Router = "site-a-gw1"

IPsec VPN Configuration On site B Router = "site-b-gw1"

This completes our goals 1, 2 and 4, and we have VPN tunnels between DC and sites. The next part is about implementing NAT on a DC router.

This NAT will change App server IP from 100.0.10.10 to 172.16.10.10

I did not use the "ip nat outside" command for this NAT, because I want to keep traffic between Storage server to site-A user without NAT.

And this NAT configuration will change site user IP from 172.17.10.10 to 192.168.10.10.

In all configuration given above one thing to notice is, NAT configuration will have an effect on VPN access lists.

- access list rule between storage server to site users = Source Network and Destination Network are same (original IP)
- access list rule between app server to site users = Source Network 100.0.10.0/24 will change to 172.16.10.0/24 (NAT IP) and Destination Network are same (original IP)

And here are the ping commands to generate traffic.

This traffic created NAT translation table entries as below.

These ping results and NAT translation entries show connections between app server in DC and user computer in site sites.

Please note that:

1) When a packet generated by app server it does have a source IP  100.0.10.10, when this packet reaches DC router, it gets changed into 172.16.10.10.

2) The same packet generated by app server it does have destination IP  172.17.10.10, when this packet reaches DC router, it gets changed into 192.168.10.10. And route map "traffic-to-vrf" check packet destination IP is "172.17.10.10" and matches to ACL "traffic-to-site-a". Then as per command "set vrf site-a" it passes this packet to VRF "site-a".

3) If similar packet generated by app server with destination IP  172.17.20.10. When this packet reaches DC router, it gets changed into 192.168.10.10. And route map "traffic-to-vrf" check packet destination IP is "172.17.20.10" and matches to ACL "traffic-to-site-b". Then as per command "set vrf site-b" it passes this packet to VRF "site-b".

4) After both inside (source IP) and outside (destination IP) this packet enters VPN tunnel.

This is the end of Part 2 of this series, we have seen basic VRF-aware policy-based VPN setup and its sample configuration. Anyone who is working on VPN setup using Cisco routers with IOS XE may use this configuration.

Link to the next article in this series = Part 3 - Route Based VPN

I hope you find this helpful.