DMVPN ISR Routers behind ASA 9.1 - Hub ASA NAT Stuck?

[laserted007]

Greetings - I'm in need of some assistance to help debug what I think is a NAT problem on a router->ASA->internet<-ASA<-router DMVPN problem. I attempted to garner more knowledge from a couple posts including base source for attempts:
https://community.cisco.com/t5/vpn-and-anyconnect/dmvpn-router-behind-asa-need-help-please/td-p/2773156  however the setup from that discussion did not function on real hardware.

I have a working DMVPN setup using the following layout:

That is, a HUB router with no ASA directly connected to the internet with a static IP on gi0/0, and an ASA with DHCP WAN port and the spoke ISR behind it. That setup I have functional both in the lab and the field currently. DMVPN is limited to PHASE 1 only, which I am fine with as some of my internet services are heavily natted by the vendors.

Those configs are in "ISR-SPOKE01", "ASA-SPOKE" and "ISR-HUB-ALONE". They have been stripped and simplified, but all the relevant working parts are there. This is based upon IOS 15.1 and ASA 9.1. Any routes for the tunnels are static since there aren't many of them (simplified to not use any routing protocols at the moment).

I would like to hit the target of:

In which an ASA is placed between the HUB router and the Internet. 

Here is the why:

• I have a limited quantity of static IP addresses and more demands on outside-in requests
• I have a growing VOIP demand and ISR's are not good at port-forwarding ranges of ports (eg SIP/RTSP). The ASA could offload the VOIP range to another subnet and skip my gateway router entirely.
• I have been recently requested to provide more "Absolute" SFTP outside access inward. This is a biggie, since I manage the routers with SSH, and forwarding port 22 from outside to inside doesn't work when SSH management is enabled. 
• I have a couple more ASA's sitting around so the assets are still valuable to implement.

So to attempt to hit the target, I modified ISR-HUB-ALONE to be ISR-HUB-BEHIND, and placed it behind the newly added ASA-HUB (configs also attached).

However, as configured, my DMVPN tunnel will not come up. All other functions, such as pinging etc (NAT to outside, static routes) are functional. DMVPN is stuck in IKE at the spoke:

DMVPN Tunnel Status on ISR-SPOKE
==================================
Interface: Tunnel21, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 10.0.0.10 192.168.221.254 IKE 00:15:11 S

IPv4 Crypto ISAKMP SA
==========================
dst src state conn-id status
10.0.0.10 192.168.240.34 QM_IDLE 1007 ACTIVE

I have also attached a snippet from debug crypto isakmp - it appears to transit port 4500 requests, but I don't see it getting past that.

Any thoughts?

Kindest regards,

Ted.

[Rob Ingram · Accepted solution]

Hi,

Please try changing your IPSec Transform Set to transport mode on both routers. Reference here and here.

crypto ipsec transform-set tun21tset esp-3des esp-md5-hmac

 mode transport

Reset the tunnel on both ends to ensure the IKE negotiation process is cleared and started again.

HTH

[laserted007]

@Rob Ingram - Success, thank you very much! This indeed allowed the tunnel to up/up. That particular mode I have not seen used before (my DMVPN experience is only in the range of 5-6 years now) - however in reading the first link it all makes sense.

The second link you sent (the discussion below that article in particular) one of the commentors noted tunnel mode added a "useless additional 20 bytes to the header" - and that particular statement I've head similar but the opposite; the tunnel encryption added necessary header, which start the discussion of the necessary calculations to limit MTU to prevent fragging. I've only gone through those two docs a couple times, however are you aware of any pitfalls in using the transport-only mode? All my tunnels are persistent, and in the past I typically leave my lifetimes pretty short (an hours or so) due to some past flapping, which may incidentally, have been caused by the use of tunnel mode. My read on this is the "unencrypted" section is only at the initial negotiation (or renegotiation). Any chance I can extend my SA lifetimes and thus keep the tunnels in a more likely secure state? Regardless, thanks for the fix on this. 

TH.

[Rob Ingram]

Hi,

Glad to hear it's working.

I am not aware of any pitfalls using transport mode. Transport mode is recommended by Cisco as Best Practice for DMVPN, reference here. You should look to also configure "ip mtu 1400" and "ip tcp adjust-mss 1360" on the tunnel interfaces.

In regard to lifetimes, 24 hours on ISAKMP SA and 8 hours on IPSec SA should be good. If you increase your lifetimes you should definately look at using stronger encryption, hashing and diffe helleman algorithms for both ISAKMP and IPSec as your current ISAKMP and IPSec algorithms (3des and md5) are considered weak. Some further information regarding algorithms here.

HTH