Just few years ago if there was a requirement of connecting to destinations with same IP networks address or for a low-level network segregation – the solution was to get separate network devices. These days the same can be done on a single hardware platform using VRF (VRF-lite).
On server platform – it’s virtualization everywhere these days; why not VRF-lite on networking then! I have seen lots of routers they never use above 50% of its capacity! This saves us the following –
i. Buying new router hardware
ii. Less power consumption, less power outlet
iii. Less number of switch ports required
iv. Overall high gain total cost of ownership
That’s why I have started implementing VRF-lite on all my new implementations! Why “all” – because if there any new requirements comes into the picture I still can use the same device; no need to reconfigure the existing platform or buy new devices.
So far I experienced – Cisco IOS does support all IP features with VRF-lite; such as static routing, dynamic routing, BGP, site-to-site vpn, nat and packet filtering firewall. On HP Comware5 platform (A-Series, 5xxx) – VRF-lite doesn’t support Layer-3 packet filtering – other than this they support most of IP services.
Let’s talk about IPSec site-to-site VPN with VRF-lite. Following are the key configurable components of a site to site IPsec VPN –
- Remote peer with secret keys
- IKE Phase 1 security details
- IKE Phase 2 security details
- Crypto map
- NAT
- Access List
On a VRF environment – the whole VPN concept and commands remain same except the following only where we specify network addresses –
1. Remote peer & keys – remote peer is reachable via which VRF domain; instead of global “key” we need to configure “keyring” with specific vrf domain name here.
5. NAT – internal source address belongs to which VRF domain; we need to specify vrf domain name in the NAT rules.
6. Although “access-list” contain of IP addresses – no VRF name need to be specify here.
Following are the command syntaxes for remote peer with VRF details –
(config)#crypto keyring tunnelkey vrf my-vrf-A
(config-keyring)#pre-shared-key address 10.100.200.1 key 6 mysecretkey
(config)#crypto keyring tunnelkey vrf my-vrf-B
(config-keyring)#pre-shared-key address 20.100.200.1 key 6 mysecretkey
Without VRF the syntax is (this is called “global key”)-
(config)#crypto isakmp key mysecretkey address 10.100.200.1
Following are the command syntaxes for NAT rules with VRF domain name –
(config)#ip nat inside source static my_src_ip my_nat_inside_global_ip vrf my-vrf-A
(config)#ip nat inside source static 192.168.1.10 10.100.200.10 vrf my-vrf-A
Show configuration commands for the above are –
#show crypto isakmp key
#show ip nat translations vrf my-vrf-A
If the above are not specified correctly – you might receive the following error on the router log file;
No pre-shared key with 10.x.x.x!
Encryption algorithm offered does not match policy!
atts are not acceptable. Next payload is 3
phase 1 SA policy not acceptable!
deleting SA reason “Phase1 SA policy proposal not accepted” state (R) MM_NO_STATE (peer 10.x.x.x)
iCookServers-&-Networks 