IPSec for DMVPN with Front Door VRFs

January 10, 2019

When you look at the blueprint for the CCIE lab exam you’ll notice a lot of separate items. These often appear as disparate things. When you study them you think you understand them and are able to apply them during a test. However, they don’t test your ability to configure separate technologies in isolated environments. They will test whether you understand the technologies and are able to combine them to make a solution work.

When you study using the INE Advanced Technologies Course you might run into this ‘issue’ at some point. You might even get the feeling like the image below.

Classwork Meme

One of these calculate the sun kind of assignments hidden in one of the workbook full scale labs are front-door VRFs. If you just read the blueprint you might never expect this assignment, and I can understand you to be dumbfounded by it.

First of, what are front door VRFs? Well, that’s a whole blogpost in itself. One that has been done several times before and probably better than I’ll ever be able to do. I particularly like the explanation of Denise Fishburne: Tunnels and the Use of Front Door VRFs. I would highly recommend you to read that post if you don’t have a grasp of Front Door VRFs (FVRFs) yet.

Just to summarize what FVRFs are:

A FVRF is a VRF that is used to separate the routing table connected to external networks (for example: the internet) from the global routing table. This is useful for security and creates a separation between the underlay and overlay networks that help maintain stability in your network

One of the things that is missing in the blogpost made by Denise Fishburne is the IPsec part. Many times when you create a DMVPN you will also use IPsec to protect the VPN. When using IPsec on a regular DMVPN this is fairly simple.

Regular DMVPN with IPsec

In regular DMVPN with IPsec you create the tunnel interface and some crypto policies. For this to work you need five things:

An ISAKMP policy (not an ISAKMP profile!)
An ISAKMP key for your peers (I’m using a wildcard in my configurations)
An IPsec transform-set
An IPsec profile
To apply the IPsec profile to the tunnel interface.

This is fairly straight forward. Below is an example of the configuration for a regular DMVPN spoke with IPsec.

crypto isakmp key Cisco address 0.0.0.0
!
crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 5
!
crypto ipsec transform-set dmvpn esp-aes esp-sha-hmac 
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set dmvpn 
!
interface Tunnel0
 ip address 155.1.0.2 255.255.255.0
 no ip redirects
 ip mtu 1500
 ip nhrp authentication DMVPN
 ip nhrp network-id 2
 ip nhrp nhs 155.1.0.5 nbma 169.254.100.5 multicast
 ip nhrp shortcut
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1.100
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

You probably have done this several times already if you’re studying for CCIE. The best part about this is that this complete configuration can be found on the Cisco webpage in the documentation, so if you want you can actually copy/paste it from there. (I know many people state that if you need the documentation for basics you’re bound to fail. However, in this case using the documentation could save you some time depending on how fast you can create this configuration)

FVRF DMVPN

To make the original DMVPN configuration into a FVRF DMVPN (without IPsec) there are actually only three things you need to do:

Define the VRF
Add the DMVPN source interface to the VRF
Change the tunnel configuration so it uses the VRF

Of course configuring a VRF might have some more steps like configuring routing for the VRF etc. but for now I’ll just ignore that. In fact all routers I’m using are directly connected to a broadcast network, so no routing protocol is required.

The configuration would change like this:

vrf definition DMVPN
 rd 100:100
 !
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet0/1.100
 encapsulation dot1Q 100
 vrf forwarding DMVPN
 ip address 169.254.100.2 255.255.255.0
!
interface Tunnel0
 ip address 155.1.0.2 255.255.255.0
 no ip redirects
 ip mtu 1500
 ip nhrp authentication DMVPN
 ip nhrp network-id 2
 ip nhrp nhs 155.1.0.5 nbma 169.254.100.5 multicast
 ip nhrp shortcut
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/1.100
 tunnel mode gre multipoint
 tunnel key 100
 tunnel vrf DMVPN
end

This is sufficient to bring up the DMVPN over the VRF. However, now we want to reapply the IPsec configuration. This is a lot more complicated than it used to be. The fact that the documentation doesn’t mention this configuration anywhere doesn’t make it any easier. (If you have found the location where this is documented, please let me know). The documentation that most closely resembles the configuration you have to create is the VRF aware IPsec configuration. This can be found as follows: Cisco IOS 15.3M&T –> Secure Connectivity Configuration Guide Library –> Internet Key Exchange for IPsec VPNs Configuration Guide –> VRF-Aware IPsec

The following needs to be done to apply IPsec for FVRF DMVPN

An ISAKMP policy needs to be defined
A crypto keyring must be created
An ISAKMP profile must be made that references the keyring and the identities of the remote parties
A regular IPsec transform set needs to be created
A crypro IPsec profile must be created that references the transform set and the ISAKMP profile
The IPsec profile must be applied to the tunnel interface

So let’s look at the configuration for this:

crypto keyring dmvpn vrf DMVPN 
  pre-shared-key address 0.0.0.0 0.0.0.0 key Cisco
!
crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 5
!
crypto isakmp profile dmvpn
   keyring dmvpn
   match identity address 169.254.100.0 255.255.255.0 DMVPN
!
crypto ipsec transform-set dmvpn esp-aes esp-sha-hmac 
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set dmvpn 
 set isakmp-profile dmvpn
!
interface tunnel0
 tunnel protection ipsec profile DMVPN

The difficulty here isn’t so much the amount of configuration, but knowing where to apply the VRF statements. So let’s break up the configuration and look at it line for line. Since the ISAKMP policy and the ipsec transform-set are exactly the same as in regular IPsec DMVPN I won’t focus on those.

Defining the pre-shared key

crypto keyring dmvpn vrf DMVPN 
  pre-shared-key address 0.0.0.0 0.0.0.0 key Cisco

When you are using a front door VRF you can’t define the key using the ‘old’ crypto isakmp key command. The key must be defined in a keyring. The crypto isakmp key command doesn’t support VRFs. If you don’t use a keyring you won’t be able to apply the key to the ISAKMP profile, so the IPsec configuration won’t have access to a ISAKMP pre-shared key and the tunnel won’t come up due to ISAKMP failing. Debug crypto isakmp shows this failure:

ISAKMP-ERROR: (0):Profile has no keyring, aborting key search
ISAKMP-ERROR: (0):Profile has no keyring, aborting host key search
ISAKMP-ERROR: (0):No Cert or pre-shared address key. 
ISAKMP-ERROR: (0):construct_initial_message: Can not start Main mode
ISAKMP-ERROR: (0):Error while processing SA request: Failed to initialize SA
ISAKMP-ERROR: (0):Error while processing KMI message 0, error 2.

It literally tells you that the profile has no keyring and can’t start main mode. This is a dead giveaway that you need the keyring.

So let’s define a keyring. But now we ‘forget’ to define the vrf in the keyring. So the keyring now looks as follows:

crypto keyring dmvpn 
  pre-shared-key address 0.0.0.0 0.0.0.0 key Cisco

This will also fail. The message will be a bit different, but it will still tell you that it can’t find a key. The only difference with the previous messages is that the errors no longer state that there isn’t a keyring defined. This time there is, but it is incorrect.

The following messages will tell you about this:

ISAKMP-ERROR: (0):No Cert or pre-shared address key. 
ISAKMP-ERROR: (0):construct_initial_message: Can not start Main mode
ISAKMP-ERROR: (0):Error while processing SA request: Failed to initialize SA
ISAKMP-ERROR: (0):Error while processing KMI message 0, error 2.

The errors are almost identical to the keyring missing, except for the two messages stating that there is no keyring. So according to my configuration there is a keyring and it has a key defined. The errors don’t state there is an issue with a VRF, so you have to figure this out yourself. After changing the keyring to a keyring with VRF this configuration works.

R2(config-if)#do sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
169.254.100.5   169.254.100.2   QM_IDLE           1004 ACTIVE dmvpn

Creating the ISAKMP profile

The ISAKMP profile is used to combine the keyring to the destinations. The configuration itself is fairly simple. You only need two lines:

One defining the ISAKMP keyring
One defining the destinations

In fact, when defining an ISAKMP profile it will tell you that if you forget to define the target it won’t be considered complete. So you don’t really have to think about that one, it will tell you to configure it:

% A profile is deemed incomplete until it has match identity statements

So the configuration itself is easy:

crypto isakmp profile dmvpn
   keyring dmvpn
   match identity address 169.254.100.0 255.255.255.0 DMVPN

Of course if you forget the keyring command you will get the same debug messages as when you didn’t define the keyring at all since you can’t specify a non existing keyring here. This is also a reminder that you need a keyring:

R2(conf-isa-prof)#keyring test
% No such keyring test

The other line defines the identity of the remote peers. In my example I used a fairly specific range, but you could make it even more specific, or if you wanted as generic as a 0.0.0.0. So aht happens here if we forget to configure the VRF?

Well… actually it works:

R2(config-if)#do sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
169.254.100.5   169.254.100.2   QM_IDLE           1006 ACTIVE dmvpn
!
R2(config-if)#do ping 155.1.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/9 ms

This, however is only the case when the HUB has the VRF still defined. When both the spoke and the hub do not have the DMVPN defined the isakmp SA will come up, but the IPsec will stay down. You can see this on the spoke side using show crypto ipsec sa. This will state 0 packets both for encap and decap:

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 169.254.100.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (169.254.100.2/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (169.254.100.5/255.255.255.255/47/0)
   current_peer 169.254.100.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 7, #recv errors 0

This is important to note. You could ‘forget’ to configure the VRF in the isakmp profile for the spokes. This would mean that all traffic will traverse the hub (since the spokes can’t establish spoke to spoke tunnels), but to be honest you should configure the VRF on both sides at all times.

IPsec profile

The IPsec profile is just slightly different from normal. In normal IPsec DMVPN you have to configure the IPsec profile to refer to the transform-set. Now you also have to refer to the ISAKMP profile.

crypto ipsec profile DMVPN
 set transform-set dmvpn 
 set isakmp-profile dmvpn

This is just to bind them together.

So now you know how to configure IPsec over FVRF DMVPNs.

Update

As Artem in the comment section remarked. It’s possible to do this just by creating the keyring with the VRF. The ISAKMP profile isn’t necessary. Configuration in that case looks as follows:

crypto keyring dmvpn vrf DMVPN 
  pre-shared-key address 0.0.0.0 0.0.0.0 key Cisco
!
crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 5
!
crypto ipsec transform-set dmvpn esp-aes esp-sha-hmac 
 mode transport
!
crypto ipsec profile DMVPN
 set transform-set dmvpn