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
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.
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).
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
- Troubleshooting DMVPNs – BRKSEC-3052: http://www.alcatron.net/Cisco%20Live%202013%20Melbourne/Cisco%20Live%20Content/Security/BRKSEC-3052%20%20Troubleshooting%20DMVPNs.pdf
- DMVPN and Easy VPN Server with ISAKMP Profiles Configuration Example: http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/47541-dmvpn-ezvpn-isakmp.html