<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

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

Published on
3,733 Points
733 Views
Last Modified:
This article is about building a VRF-Aware site to site VPN tunnels in Cisco CSR1000V router with IOS XE.
There are two VRF-Aware Policy Based IPsec VPN tunnels configured on CSR1000V router one with NAT and another without NAT.

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"


ip vrf site-a
rd 1:10

ip vrf site-b
rd 1:20

interface GigabitEthernet1
platform ring rx 256
ip address 10.0.0.2 255.255.255.252
ip nat outside
negotiation auto
crypto map site-vpn

interface GigabitEthernet2
platform ring rx 256
ip address 100.0.20.1 255.255.255.0 secondary
ip address 100.0.10.1 255.255.255.0
ip nat inside
ip policy route-map traffic-to-vrf
negotiation auto

ip route 0.0.0.0 0.0.0.0 10.0.0.1
ip route vrf site-a 0.0.0.0 0.0.0.0 10.0.0.1 global
ip route vrf site-a 100.0.10.0 255.255.255.0 100.0.10.10 global
ip route vrf site-a 100.0.20.0 255.255.255.0 100.0.20.10 global
ip route vrf site-b 0.0.0.0 0.0.0.0 10.0.0.1 global
ip route vrf site-b 100.0.10.0 255.255.255.0 100.0.10.10 global
ip route vrf site-b 100.0.20.0 255.255.255.0 100.0.20.10 global

ip access-list extended traffic-to-site-a
permit ip 100.0.10.0 0.0.0.255 172.17.10.0 0.0.0.255 log
permit ip 100.0.20.0 0.0.0.255 172.17.10.0 0.0.0.255 log

route-map traffic-to-vrf permit 10
match ip address traffic-to-site-a
set vrf site-a

ip access-list extended traffic-to-site-b
permit ip 100.0.10.0 0.0.0.255 172.17.20.0 0.0.0.255 log
permit ip 100.0.20.0 0.0.0.255 172.17.20.0 0.0.0.255 log

route-map traffic-to-vrf permit 20
match ip address traffic-to-site-b
set vrf site-b


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


interface GigabitEthernet0/0
ip address 20.0.0.2 255.255.255.252
duplex full
speed 1000
media-type gbic
negotiation auto
crypto map app-dc

interface GigabitEthernet1/0
ip address 192.168.10.1 255.255.255.0
negotiation auto

ip route 0.0.0.0 0.0.0.0 20.0.0.1


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


interface GigabitEthernet0/0
ip address 30.0.0.2 255.255.255.252
duplex full
speed 1000
media-type gbic
negotiation auto
crypto map vpn-to-dc

interface GigabitEthernet1/0
ip address 192.168.10.1 255.255.255.0
negotiation auto

ip route 0.0.0.0 0.0.0.0 30.0.0.1


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"


crypto keyring site-a
pre-shared-key address 20.0.0.2 key acme

crypto keyring site-b
pre-shared-key address 30.0.0.2 key acme

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 14

crypto isakmp profile site-a
vrf site-a
keyring site-a
match identity address 20.0.0.2 255.255.255.255

crypto isakmp profile site-b
vrf site-b
keyring site-b
match identity address 30.0.0.2 255.255.255.255

crypto ipsec transform-set AES-256-SHA esp-aes 256 esp-sha-hmac
mode tunnel

crypto map site-vpn 10 ipsec-isakmp
set peer 20.0.0.2
set transform-set AES-256-SHA
set pfs group14
set isakmp-profile site-a
match address vpn-to-site-a

crypto map site-vpn 11 ipsec-isakmp
set peer 30.0.0.2
set transform-set AES-256-SHA
set pfs group14
set isakmp-profile site-b
match address vpn-to-site-b

ip access-list extended vpn-to-site-a
permit ip 100.0.20.0 0.0.0.255 192.168.10.0 0.0.0.255 log
permit ip 172.16.10.0 0.0.0.255 192.168.10.0 0.0.0.255 log

ip access-list extended vpn-to-site-b
permit ip 100.0.20.0 0.0.0.255 192.168.10.0 0.0.0.255 log
permit ip 172.16.10.0 0.0.0.255 192.168.10.0 0.0.0.255 log


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


crypto isakmp policy 10
encr aes 256
authentication pre-share
group 14

crypto isakmp key acme address 10.0.0.2

crypto ipsec transform-set AES-256-SHA esp-aes 256 esp-sha-hmac

crypto map app-dc 10 ipsec-isakmp
set peer 10.0.0.2
set transform-set AES-256-SHA
set pfs group14
match address cry-acl-app-dc

ip access-list extended cry-acl-app-dc
permit ip 192.168.10.0 0.0.0.255 100.0.20.0 0.0.0.255
permit ip 192.168.10.0 0.0.0.255 172.16.10.0 0.0.0.255


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


crypto isakmp policy 10
encr aes 256
authentication pre-share
group 14

crypto isakmp key acme address 10.0.0.2

crypto ipsec transform-set AES-256-SHA esp-aes 256 esp-sha-hmac

crypto map vpn-to-dc 10 ipsec-isakmp
set peer 10.0.0.2
set transform-set AES-256-SHA
set pfs group14
match address vpn-to-dc

ip access-list extended vpn-to-dc
permit ip 192.168.10.0 0.0.0.255 172.16.10.0 0.0.0.255
permit ip 192.168.10.0 0.0.0.255 100.0.20.0 0.0.0.255


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.


ip nat pool source-nat-pool 172.16.10.10 172.16.10.10 prefix-length 30

ip access-list extended source-nat-acl
permit ip host 100.0.10.10 host 172.17.10.10 log
permit ip host 100.0.10.10 host 172.17.20.10 log

route-map source-nat-routemap permit 10
match ip address source-nat-acl

ip nat inside source route-map source-nat-routemap pool source-nat-pool vrf site-a overload
ip nat inside source route-map source-nat-routemap pool source-nat-pool vrf site-b overload


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


ip nat outside source static 192.168.10.10 172.17.10.10 vrf site-a
ip nat outside source static 192.168.10.10 172.17.20.10 vrf site-b


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)

ip access-list extended traffic-to-site-a
permit ip 100.0.10.0 0.0.0.255 172.17.10.0 0.0.0.255 log
permit ip 100.0.20.0 0.0.0.255 172.17.10.0 0.0.0.255 log

ip access-list extended traffic-to-site-b
permit ip 100.0.10.0 0.0.0.255 172.17.20.0 0.0.0.255 log
permit ip 100.0.20.0 0.0.0.255 172.17.20.0 0.0.0.255 log


And here are the ping commands to generate traffic.


app1> ping 172.17.10.10
84 bytes from 172.17.10.10 icmp_seq=1 ttl=62 time=91.018 ms
84 bytes from 172.17.10.10 icmp_seq=2 ttl=62 time=46.509 ms
84 bytes from 172.17.10.10 icmp_seq=3 ttl=62 time=70.014 ms
84 bytes from 172.17.10.10 icmp_seq=4 ttl=62 time=57.511 ms
84 bytes from 172.17.10.10 icmp_seq=5 ttl=62 time=60.512 ms

app1> ping 172.17.20.10
84 bytes from 172.17.20.10 icmp_seq=1 ttl=62 time=117.024 ms
84 bytes from 172.17.20.10 icmp_seq=2 ttl=62 time=117.523 ms
84 bytes from 172.17.20.10 icmp_seq=3 ttl=62 time=105.021 ms
84 bytes from 172.17.20.10 icmp_seq=4 ttl=62 time=61.012 ms
84 bytes from 172.17.20.10 icmp_seq=5 ttl=62 time=65.013 ms


This traffic created NAT translation table entries as below.


dc-gw1#sh ip nat translations vrf site-a
Pro  Inside global         Inside local          Outside local         Outside global
---  ---                   ---                   172.17.10.10          192.168.10.10
icmp 172.16.10.10:3        100.0.10.10:26769     172.17.10.10:26769    192.168.10.10:3
icmp 172.16.10.10:1        100.0.10.10:26257     172.17.10.10:26257    192.168.10.10:1
icmp 172.16.10.10:5        100.0.10.10:27281     172.17.10.10:27281    192.168.10.10:5
icmp 172.16.10.10:4        100.0.10.10:27025     172.17.10.10:27025    192.168.10.10:4
icmp 172.16.10.10:2        100.0.10.10:26513     172.17.10.10:26513    192.168.10.10:2
Total number of translations: 6

dc-gw1#sh ip nat translations vrf site-b
Pro  Inside global         Inside local          Outside local         Outside global
---  ---                   ---                   172.17.20.10          192.168.10.10
icmp 172.16.10.10:1        100.0.10.10:61073     172.17.20.10:61073    192.168.10.10:1
icmp 172.16.10.10:4        100.0.10.10:61841     172.17.20.10:61841    192.168.10.10:4
icmp 172.16.10.10:5        100.0.10.10:62353     172.17.20.10:62353    192.168.10.10:5
icmp 172.16.10.10:2        100.0.10.10:61329     172.17.20.10:61329    192.168.10.10:2
icmp 172.16.10.10:3        100.0.10.10:61585     172.17.20.10:61585    192.168.10.10:3
Total number of translations: 6


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.

0
0 Comments

Featured Post

HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month