In this article, we will discuss the issue that arises when DMVPN and Easy VPN Server are enabled on the same Cisco router and we will also look at ways of resolving this issue.

For this article, we will use the following lab setup:

The ‘HUB’ router will act as both the DMVPN Hub and also the Easy VPN Server. The ‘SPOKE’ router is a DMVPN spoke while the ‘VPN Client’ is a computer with the Cisco VPN client software installed.

We will begin with the DMVPN configuration and then add the Easy VPN configuration later. The configuration on the HUB is as follows:

hostname HUB
!
interface FastEthernet 0/0
 ip address 192.0.2.1 255.255.255.0
!
interface Loopback 0
 ip address 10.1.1.1 255.255.255.0
!
crypto isakmp policy 10
 hash sha
 encryption aes
 authentication pre-share
!
crypto isakmp key dmvpn-cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set DMVPN_TSET esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN_IPSEC_PROF
 set transform-set DMVPN_TSET
!
interface Tunnel0
 ip address 172.16.1.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 12
 no ip split-horizon eigrp 12
 no ip next-hop-self eigrp 12
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IPSEC_PROF
!
router eigrp 12
 no auto-summary
 network 172.16.1.0 0.0.0.255
 network 10.1.1.0 0.0.0.255

The configuration on the SPOKE is as follows:

hostname SPOKE
!
interface FastEthernet 0/0
 ip address 192.0.2.2 255.255.255.0
!
interface Loopback 0
 ip address 10.2.2.2 255.255.255.0
!
crypto isakmp policy 10
 hash sha
 encryption aes
 authentication pre-share
!
crypto isakmp key dmvpn-cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set DMVPN_TSET esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN_IPSEC_PROF
 set transform-set DMVPN_TSET
!
interface Tunnel0
 ip address 172.16.1.2 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp map 172.16.1.1 192.0.2.1
 ip nhrp map multicast 192.0.2.1
 ip nhrp network-id 12
 ip nhrp nhs 172.16.1.1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IPSEC_PROF
!
router eigrp 12
 no auto
 network 172.16.1.0 0.0.0.255
 network 10.2.2.0 0.0.0.255

If our configuration is OK, the EIGRP adjacency should form between the HUB and SPOKE over their tunnel0 interfaces and the Loopback networks should be advertised. We can verify this on one of the routers:

HUB#show ip route eigrp
     10.0.0.0/24 is subnetted, 2 subnets
D       10.2.2.0 [90/297372416] via 172.16.1.2, 00:01:14, Tunnel0
HUB#
HUB#ping 10.2.2.2 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms
HUB#

Cool! Let’s now add on the Easy VPN Server configuration so that the VPN clients will be able to connect to the HUB router.

aaa new-model
aaa authentication login EZVPN local
aaa authorization network EZVPN local
!
username vpnuser password cisco
!
ip local pool EZVPN_POOL 10.1.1.10 10.1.1.20
ip access-list extended EZVPN_SPLIT_ACL
 permit ip 10.1.1.0 0.0.0.255 any
!
crypto isakmp policy 20
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp client configuration address-pool local EZVPN_POOL
!
crypto isakmp client configuration group EZVPN
 key ezvpn-cisco
 domain example.com
 pool EZVPN_POOL
 acl EZVPN_SPLIT_ACL
!
crypto ipsec transform-set EZVPN_TSET esp-aes esp-sha-hmac
!
crypto dynamic-map DYNMAP 1
 set transform-set EZVPN_TSET
 reverse-route
!
!
crypto map MYMAP client authentication list EZVPN
crypto map MYMAP isakmp authorization list EZVPN
crypto map MYMAP client configuration address respond
crypto map MYMAP 1 ipsec-isakmp dynamic DYNMAP
!
interface FastEthernet0/0
 crypto map MYMAP

Now let’s try to connect from the VPN client.

We can ping from this client to an IP address in the Split-tunnel list (10.1.1.0/24) to see if we have connectivity:

Finally, the statistics on the VPN client show us that our traffic is going over the tunnel:

At this point, everything seems to be working perfectly – DMVPN and Easy VPN are coexisting. But what happens when the ISAKMP SA’s lifetime of the DMVPN tunnel between the HUB and the SPOKE expires and should be rebuilt? One way to test this is to clear the current ISAKMP SA and let the endpoints attempt to re-establish the tunnel.

What you will notice is that after clearing the ISAKMP SA between the HUB and the SPOKE, the tunnel will never be re-established. If you check the ISAKMP SAs on any of the routers, you will see the “MM_NO_STATE” as shown below:

On some newer IOS versions, you may also see the “CONF_XAUTH” SA state on the HUB as shown below:

Turning on ISAKMP debugging (debug crypto isakmp) on the HUB will reveal what the problem is as shown in the debug snippet below:

...
*Mar  1 00:52:45.163: ISAKMP:(1019):Need XAUTH
*Mar  1 00:52:45.163: ISAKMP: set new node -1419244008 to CONF_XAUTH
*Mar  1 00:52:45.167: ISAKMP/xauth: request attribute XAUTH_USER_NAME_V2
*Mar  1 00:52:45.167: ISAKMP/xauth: request attribute XAUTH_USER_PASSWORD_V2
...

The problem is that the HUB router is requesting that the DMVPN spoke complete the XAUTH phase. This is because when crypto maps are used for Easy VPN configuration, by default, XAUTH is globally enabled on the router for ALL IPsec sessions. Since Easy VPN clients normally respond to XAUTH requests, the Easy VPN side will not be affected.

Note: This issue doesn’t occur when Easy VPN is configured to use dVTIs rather than crypto maps.

Solutions

We will consider two solutions to this issue. The first issue is to bypass XAUTH per-peer. For example, we can bypass XAUTH for the DMVPN spoke. The configuration is as shown below:

crypto isakmp key 0 dmvpn-cisco address 192.0.2.2 no-xauth

With this configuration, after a while, the DMVPN tunnel between the HUB and SPOKE will come up and begin passing traffic again. However, this configuration is a bit too “manual.” I don’t want to have to make a configuration change or addition on my DMVPN hub every time a new spoke is added. This brings us to the second solution.

We can disable the default turning on of XAUTH by using ISAKMP profiles to separate the different VPN configurations. The configuration to achieve this on the HUB is as follows:

!--For DMVPN --!
crypto keyring DMVPN_KEYRING
 pre-shared-key address 0.0.0.0 0.0.0.0 key dmvpn-cisco
!
crypto isakmp profile DMVPN_ISAKMP_PROF
 keyring DMVPN_KEYRING
 match identity address 0.0.0.0
!
crypto ipsec profile DMVPN_IPSEC_PROF
 set isakmp-profile DMVPN_ISAKMP_PROF
!
!--Remove unnecessary configuration --!
no crypto isakmp key dmvpn-cisco address 0.0.0.0 0.0.0.0
!
!--For Easy VPN --!
crypto isakmp profile EZVPN_ISAKMP_PROF
  match identity group EZVPN
  client authentication list EZVPN
  isakmp authorization list EZVPN
  client configuration address respond
!
crypto dynamic-map DYNMAP 1
 set isakmp-profile EZVPN_ISAKMP_PROF
!
!--Remove unnecessary config --!
no crypto map MYMAP client authentication list EZVPN
no crypto map MYMAP isakmp authorization list EZVPN
no crypto map MYMAP client configuration address respond

With this configuration, both DMVPN and Easy VPN can coexist without any issues. To show you that this is true, I will clear the ISAKMP SAs and then try to connect to the Easy VPN server again from the VPN client (the DMVPN tunnel will be automatically established).

Summary

In this article, we have looked at how to configure DMVPN and Easy VPN server to coexist on the same Cisco router by either bypassing XAUTH for some IP addresses or by using ISAKMP profiles (which is a better method).

I hope you have found this article insightful.

References and Further reading