ASA 5505 <-EZVPN-> 5512-X weirdness

[mikedeyoung]

So my customer has asked me to configure a 5505 for a home user to connect to corporate 5510-X head-end using EZVPN. 

My issue is this... the 5505 is not receiving encrypted traffic from 5512-X (no decaps). But if I "show cry ipsec sa peer <ip>" I can see encaps but they never show up at 5505.

Appreciate any help! thx.

5512-X: show vpnsession-db ra-ikev1-ipsec

Session Type: IKEv1 IPsec

Username : ASA1 Index : 1072
Assigned IP : 192.168.6.0 Public IP : x.x.x.x
Protocol : IKEv1 IPsecOverNatT
License : Other VPN
Encryption : IKEv1: (1)3DES IPsecOverNatT: (3)3DES
Hashing : IKEv1: (1)MD5 IPsecOverNatT: (3)MD5
Bytes Tx : 240 Bytes Rx : 240
Group Policy : GP_MOBILE_STAFF Tunnel Group : TG_MOBILE_STAFF
Login Time : 13:42:43 EST Thu Jan 5 2017
Duration : 0h:25m:56s
Inactivity : 0h:00m:00s
VLAN Mapping : N/A VLAN : none
Audt Sess ID : c0a8000100430000586e93a3
Security Grp : none

5505: show vpnsession-db ra-ikev1-ipsec

Session Type: IKEv1 IPsec

Index : 2
Assigned IP : 192.168.6.0 Peer IP : x.x.x.x
Protocol : IKEv1 IPsecOverNatT
License : Other VPN
Encryption : IKEv1: (1)3DES IPsecOverNatT: (3)3DES
Hashing : IKEv1: (1)MD5 IPsecOverNatT: (3)MD5
Bytes Tx : 240 Bytes Rx : 0
Login Time : 13:42:43 EST Thu Jan 5 2017
Duration : 0h:25m:51s
Inactivity : 0h:00m:00s
Audt Sess ID : c0a8060100002000586e93a3
Security Grp : none

[Rahul Govindan]

I would apply a capture for encrypted traffic on both the ASA WAN interfaces for UDP 4500. This will confirm the packets transmitted from the 5512 is making it to the ASA5505.

Sometimes ISP's do not allow IKE and IPsec protocols by default, so might be blocked in the path. But it is very strange to see UDP 4500 being blocked after tunnel is established as tunnel negotiation also moves into udp 4500 midway through the process.

Can you also get a "show crypto ipsec sa detailed" from both sides?

[mikedeyoung]

Hi Rahul,

I setup the capture, cleared IPSEC sa counters, and originated a ping from the 5505 LAN side to the 5512 LAN side.

See attached two files.

Could this be somehow related to NAT-T?

Thx for help.

-Mike

[mikedeyoung]

Rahul,

The root cause if this problem was that I inadvertently forgot that I had previously added a static route to reach the 5505 via an alternate ISP path... so return traffic was being sourced from an unexpected IP when it showed up at the 5505.

Why the tunnel came up but not subsequent data payload I do not understand.

Thx for you time!

-Mike

[Rahul Govindan]

I was just looking at the outputs and could not see a response back from the 5515 in the capture. I was going to ask you to check the routing table, looks like you figured it out :)

It could be with the way the ASA routes for the control plane vs Dataplane traffic that caused the ASA to established tunnel in the first place. I think the "show ASP table routing" output should be reflected with the correct route.