DMVPN and IPSEC with Front Door VRF
In this post I want to show how to configure DMVPN with IPSEC, with tunnel source/destination IPs located in a separate VRF. Idea here is to have underlay network running in a VRF, often called FVRF or Front Door VRF.
By using Front Door VRF we are isolating transport network, usually Internet facing, and this allows us to configure default route that won't interfere with routing in our global table. There are other benefits of this design and it's quite commonly used in the SP/Enterprise world.
We will be working with the following topology:
-
R1 is a DMVPN hub
-
R2 and R3 are DMVPN spokes
-
Underlay network: 10.1.123.X/24
-
Overlay network: 172.16.0.X/24
-
Loopbacks: 10.0.0.X/32
First, we will configure VRFs and DMVPN before moving to IPSEC:
!!R1 (HUB) ip vrf FVRF rd 1:1 interface Loopback0 ip address 10.0.0.1 255.255.255.255 interface Ethernet0/0 ip vrf forwarding FVRF ip address 10.1.123.1 255.255.255.0 interface Tunnel123 ip address 172.16.0.1 255.255.255.0 tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel key 123 tunnel vrf FVRF ip nhrp authentication DMVPN ip nhrp map multicast dynamic ip nhrp network-id 123 ip mtu 1400 ip tcp adjust-mss 1360
Spoke configurations:
!!R2 ip vrf FVRF rd 1:1 interface Loopback0 ip address 10.0.0.2 255.255.255.255 interface Ethernet0/0 ip vrf forwarding FVRF ip address 10.1.123.2 255.255.255.0 interface Tunnel123 ip address 172.16.0.2 255.255.255.0 tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel key 123 tunnel vrf FVRF ip nhrp authentication DMVPN ip nhrp map 172.16.0.1 10.1.123.1 ip nhrp map multicast 10.1.123.1 ip nhrp network-id 123 ip nhrp nhs 172.16.0.1 ip mtu 1400 ip tcp adjust-mss 1360
!!R3 ip vrf FVRF rd 1:1 interface Loopback0 ip address 10.0.0.3 255.255.255.255 interface Ethernet0/0 ip vrf forwarding FVRF ip address 10.1.123.2 255.255.255.0 interface Tunnel123 ip address 172.16.0.2 255.255.255.0 tunnel source Ethernet0/0 tunnel mode gre multipoint tunnel key 123 tunnel vrf FVRF ip nhrp authentication DMVPN ip nhrp map 172.16.0.1 10.1.123.1 ip nhrp map multicast 10.1.123.1 ip nhrp network-id 123 ip nhrp nhs 172.16.0.1 ip mtu 1400 ip tcp adjust-mss 1360
This is a pretty standard configuration for DMVPN Phase 1. The only thing that is non-standard is use of a separate VRF for the underlay and having to specify this in the configuration of our tunnels.
Command tunnel vrf FVRF tells IOS that tunnel source and destination will be located in VRF FVRF. This also means that overlay IPs will be located in the default/global VRF as tunnels themselves are not part of this VRF.
Let's check if everything is up and running as it should:
R1#sh dmvpn | b Inter
Interface: Tunnel123, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.1.123.2 172.16.0.2 UP 00:00:29 D
1 10.1.123.3 172.16.0.3 UP 00:00:27 D
R1#ping 172.16.0.2 r 2
Sending 2, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
R1#ping 172.16.0.3 r 2
Sending 2, 100-byte ICMP Echos to 172.16.0.3, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
R2#ping 172.16.0.1 r 2
Sending 2, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
R2#ping 172.16.0.3 r 2
Sending 2, 100-byte ICMP Echos to 172.16.0.3, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
R2#sh dmvpn | b Inter
Interface: Tunnel123, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.1.123.1 172.16.0.1 UP 00:04:47 S
1 10.1.123.3 172.16.0.3 UP 00:00:37 D
R3#ping 172.16.0.1 r 2
Type escape sequence to abort.
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
R3#ping 172.16.0.2 r 2
Type escape sequence to abort.
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
R3#sh dmvpn | b Inter
Interface: Tunnel123, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.1.123.1 172.16.0.1 UP 00:06:20 S
1 10.1.123.2 172.16.0.2 UP 00:02:12 D
All is looking good, spokes registered with the hub and all three routers can ping each other.
Now we need to configure IPSEC and apply it to DVMPN tunnels. All of our routers will use the same config.
First we will configure isakmp policy and transform-set, nothing special is happening here, just standard IPSEC config:
crypto isakmp policy 10 encr 3des hash md5 authentication pre-share crypto ipsec transform-set TS esp-3des esp-md5-hmac mode transport
Next we need to define keyring in which we will specify our pre-shared key. In the keyring definition we also include VRF which will be used to establish IPSEC sessions.
crypto keyring KEYRING vrf FVRF pre-shared-key address 10.1.123.0 255.255.255.0 key CISCO
Once keyring is defined, we need to configure isakmp profile. In the profile we use the keyring we just created. We also need to specify identity of our peers and set VRF used to reach them.
crypto isakmp profile ISAKMP_PROF keyring KEYRING match identity address 10.1.123.0 255.255.255.0 FVRF
With isakmp profile configured we can now proceed to the definition of ipsec profile, which we then apply to our DVMPN tunnels. We will also enable OSPF on tunnels and loopback interfaces. This is just to show that routing will be established in the global VRF and it will allow us to ping between loopbacks.
!!R1-R3 crypto ipsec profile IPSEC_PROF set transform-set TS set isakmp-profile ISAKMP_PROF
!!R1 interface Loopback0 ip address 10.0.0.1 255.255.255.255 ip ospf 1 area 1 interface Tunnel123 ip ospf network broadcast ip ospf 1 area 0 tunnel protection ipsec profile IPSEC_PROF
!!R2 interface Loopback0 ip ospf 1 area 2 interface Tunnel123 ip ospf network broadcast ip ospf priority 0 ip ospf 1 area 0 tunnel protection ipsec profile IPSEC_PROF
!!R3 interface Loopback0 ip ospf 1 area 3 interface Tunnel123 ip ospf network broadcast ip ospf priority 0 ip ospf 1 area 0 tunnel protection ipsec profile IPSEC_PROF
Now that all of the config is in place we'll check if the tunnels are IPSEC protected:
R1#sh crypto session
Interface: Tunnel123
Profile: ISAKMP_PROF
Session status: UP-ACTIVE
Peer: 10.1.123.3 port 500
Session ID: 0
IKEv1 SA: local 10.1.123.1/500 remote 10.1.123.3/500 Active
IPSEC FLOW: permit 47 host 10.1.123.1 host 10.1.123.3
Active SAs: 2, origin: crypto map
Interface: Tunnel123
Profile: ISAKMP_PROF
Session status: UP-ACTIVE
Peer: 10.1.123.2 port 500
Session ID: 0
IKEv1 SA: local 10.1.123.1/500 remote 10.1.123.2/500 Active
IPSEC FLOW: permit 47 host 10.1.123.1 host 10.1.123.2
Active SAs: 2, origin: crypto map
R2#sh crypto session
Interface: Tunnel123
Profile: ISAKMP_PROF
Session status: UP-ACTIVE
Peer: 10.1.123.1 port 500
Session ID: 0
IKEv1 SA: local 10.1.123.2/500 remote 10.1.123.1/500 Active
IPSEC FLOW: permit 47 host 10.1.123.2 host 10.1.123.1
Active SAs: 2, origin: crypto map
R3
R3#sh crypto session
Interface: Tunnel123
Profile: ISAKMP_PROF
Session status: UP-ACTIVE
Peer: 10.1.123.1 port 500
Session ID: 0
IKEv1 SA: local 10.1.123.3/500 remote 10.1.123.1/500 Active
IPSEC FLOW: permit 47 host 10.1.123.3 host 10.1.123.1
Active SAs: 2, origin: crypto map
Then we check the status of OSPF and routing table.
R1#sh ip ospf ne
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 0 FULL/DROTHER 00:00:32 172.16.0.2 Tunnel123
10.0.0.3 0 FULL/DROTHER 00:00:35 172.16.0.3 Tunnel123
R1#sh ip route | b Gate
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 3 subnets
C 10.0.0.1 is directly connected, Loopback0
O IA 10.0.0.2 [110/1001] via 172.16.0.2, 00:01:36, Tunnel123
O IA 10.0.0.3 [110/1001] via 172.16.0.3, 00:01:31, Tunnel123
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.0/24 is directly connected, Tunnel123
L 172.16.0.1/32 is directly connected, Tunnel123
R2#sh ip ospf ne
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 1 FULL/DR 00:00:37 172.16.0.1 Tunnel123
R2#sh ip route | b Gate
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 3 subnets
O IA 10.0.0.1 [110/1001] via 172.16.0.1, 00:01:58, Tunnel123
C 10.0.0.2 is directly connected, Loopback0
O IA 10.0.0.3 [110/1001] via 172.16.0.3, 00:01:53, Tunnel123
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.0/24 is directly connected, Tunnel123
L 172.16.0.2/32 is directly connected, Tunnel123
R3#sh ip ospf ne
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 1 FULL/DR 00:00:34 172.16.0.1 Tunnel123
R3#sh ip route | b Gate
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 3 subnets
O IA 10.0.0.1 [110/1001] via 172.16.0.1, 00:01:59, Tunnel123
O IA 10.0.0.2 [110/1001] via 172.16.0.2, 00:01:59, Tunnel123
C 10.0.0.3 is directly connected, Loopback0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.0/24 is directly connected, Tunnel123
L 172.16.0.3/32 is directly connected, Tunnel123
Finally we will carry out ping between loopbacks of all of our devices.
R1#ping 10.0.0.2 sour l0 r 2 Sending 2, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: Packet sent with a source address of 10.0.0.1 !! Success rate is 100 percent (2/2), round-trip min/avg/max = 5/5/6 ms R1#ping 10.0.0.3 sour l0 r 2 Sending 2, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with a source address of 10.0.0.1 !! Success rate is 100 percent (2/2), round-trip min/avg/max = 5/5/6 ms
R2#ping 10.0.0.1 sour l0 r 2 Sending 2, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: Packet sent with a source address of 10.0.0.2 !! Success rate is 100 percent (2/2), round-trip min/avg/max = 2/3/5 ms R2#ping 10.0.0.3 sour l0 r 2 Sending 2, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds: Packet sent with a source address of 10.0.0.2 !! Success rate is 100 percent (2/2), round-trip min/avg/max = 5/5/6 ms
R3#ping 10.0.0.1 sour l0 r 2 Sending 2, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: Packet sent with a source address of 10.0.0.3 !! Success rate is 100 percent (2/2), round-trip min/avg/max = 5/5/5 ms R3#ping 10.0.0.2 sour l0 r 2 Sending 2, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: Packet sent with a source address of 10.0.0.3 !! Success rate is 100 percent (2/2), round-trip min/avg/max = 5/5/6 ms
Following ping tests, R2 and R3 established spoke to spoke tunnels, which further confirms that our configuration is correct:
R2#sh crypto session remote 10.1.123.3
Interface: Tunnel123
Profile: ISAKMP_PROF
Session status: UP-ACTIVE
Peer: 10.1.123.3 port 500
Session ID: 0
IKEv1 SA: local 10.1.123.2/500 remote 10.1.123.3/500 Active
Session ID: 0
IKEv1 SA: local 10.1.123.2/500 remote 10.1.123.3/500 Active
IPSEC FLOW: permit 47 host 10.1.123.2 host 10.1.123.3
Active SAs: 4, origin: crypto map
R2#sh ip nhrp | b 172.16.0.3
172.16.0.3/32 via 172.16.0.3
Tunnel123 created 00:01:53, expire 01:58:06
Type: dynamic, Flags: router used nhop
NBMA address: 10.1.123.3
R3#sh crypto session remote 10.1.123.2
Interface: Tunnel123
Profile: ISAKMP_PROF
Session status: UP-ACTIVE
Peer: 10.1.123.2 port 500
Session ID: 0
IKEv1 SA: local 10.1.123.3/500 remote 10.1.123.2/500 Active
Session ID: 0
IKEv1 SA: local 10.1.123.3/500 remote 10.1.123.2/500 Active
IPSEC FLOW: permit 47 host 10.1.123.3 host 10.1.123.2
Active SAs: 4, origin: crypto map
R3#sh ip nhrp | b 172.16.0.2
172.16.0.2/32 via 172.16.0.2
Tunnel123 created 00:02:10, expire 01:57:49
Type: dynamic, Flags: router used nhop
NBMA address: 10.1.123.2
All done. We have achieved our goal. There is a full reachability between all of the devices over the IPSEC protected DMVPN tunnels with underlay network located in a separate VRF.
Overall the configuration of the IPSEC protected DMVPN with Front End VRF is similar to the standard DMVPN with IPSEC scenario. It differs only in a few places, where we need to tell IOS which VRF it needs to use for IPSEC negotiation.