Some flows not up on crypto map

Jonathan Ridgway · ‎06-22-2015

Hi,

I have a crypto map on a WAN interface behind NAT and when I look at the crypto session I only see 3 flows as up out of 4:

Interface: *WAN-INTERFACE*
Session status: UP-ACTIVE
Peer: *CISCO-ASA-IP* port 4500
IKEv1 SA: local 10.10.1.1/4500 remote *CISCO-ASA-IP*/4500 Active
IKEv1 SA: local 10.10.1.1/4500 remote *CISCO-ASA-IP*/4500 Inactive
IKEv1 SA: local 10.10.1.1/4500 remote *CISCO-ASA-IP*/4500 Inactive
IPSEC FLOW: permit ip 10.10.0.0/255.255.0.0 host 192.168.2.1
        Active SAs: 0, origin: crypto map
IPSEC FLOW: permit ip 10.10.0.0/255.255.0.0 192.168.1.0/255.255.255.0
        Active SAs: 2, origin: crypto map
IPSEC FLOW: permit ip 10.10.0.0/255.255.0.0 192.168.3.0/255.255.255.0
        Active SAs: 2, origin: crypto map

The fourth one should be:

IPSEC FLOW: permit ip 10.10.0.0/255.255.0.0 172.16.0.0/255.255.0.0

Here is my ACL for the crypto map:

Extended IP access list VPN_ACL
    10 permit ip 10.10.0.0 0.0.255.255 172.16.0.0 0.0.255.255 (2468616 matches)
    20 permit ip 10.10.0.0 0.0.255.255 192.168.1.0 0.0.0.255 (667921 matches)
    30 permit ip 10.10.0.0 0.0.255.255 192.168.3.0 0.0.0.255 (674012 matches)
    40 permit ip 10.10.0.0 0.0.255.255 host 192.168.2.1 (15 matches)

And my Crypto map looks like the following:

crypto map VPN 1 ipsec-isakmp
set peer *CISCO-ASA-IP*
set transform-set aes_sha
set pfs group2
match address VPN_ACL
qos pre-classify

Normally this happens when there is no traffic that matches the access list entry, however when I do "ping 172.16.1.1 source LAN-INTERFACE" it still does not come up and you can see the matches on the ACL.

I have other remote sites with the same configuration and these are working fine. In the logs I have the following message appear over and over:

Jun 22 13:26:17.481: %CRYPTO-4-IKMP_NO_SA: IKE message from *CISCO-ASA-IP* has no SA and is not an initialization offer

Any suggestions?

Jonathan

rizwanr74 · ‎06-22-2015

Hi Jonathan,

Please make sure you have a nat-exemption for source and remote-subnet is configured.

Secondly check for static-route for remote-subnet is in placed, that is you have a static route to push the traffic towards to default-gateway address of the router, so that router's crytop-engine will catch traffic in question for encryption.

Thanks

Rizwan Rafeek.

Jonathan Ridgway · ‎06-23-2015

Hi,

Thanks for the response. Indeed, I have a NAT access-list with a deny statement for the LAN->Remote-Subnet.

10 deny ip 10.10.0.0 0.0.0.255 172.16.0.0 0.0.0.255

In the end I got this working. There are two WAN interfaces where the crypto map is applied and I have an EEM script to clear crypto sessions and security associations when one of the interfaces changes state.

For some reason, even though the default route was pointing at WAN-A, the three working IPsec flows were going through WAN-B (both WAN connections are up and running but the default route is pointing to WAN-A).

I had already tried manually clearing crypto sessions, security associations and nat translations, and I even removed the crypto map on WAN-B but the IPsec flows were still present and they worked! To force these over WAN-A I had to manually shutdown the WAN-B interface.

With regards to the fourth IPsec flow, this was probably not up from before due to no matched traffic and then failing to connect due to some sort of asymmetric routing, after shutting down the WAN-B interface, all 4 flows came up and worked. This seems to work both ways, I had to switch off the WAN-A interface for all four IPsec flows to move over to WAN-B, regardless of which way the static route is pointing, regardless of clearing crypto sessions, security associations and nat translations and regardless of whether the crypto map is even on the interface anymore. Personally I prefer tunnel interfaces but crypto maps is the configuration I have to work with here due to an ASA at the other end.

I am running IOS 15.2(4)M4 - is this a known issue with crypto maps getting stuck to an interface?