Showing results for 
Search instead for 
Did you mean: 

Some flows not up on crypto map

Jonathan Ridgway



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 remote *CISCO-ASA-IP*/4500 Active
  IKEv1 SA: local remote *CISCO-ASA-IP*/4500 Inactive
  IKEv1 SA: local remote *CISCO-ASA-IP*/4500 Inactive
  IPSEC FLOW: permit ip host
        Active SAs: 0, origin: crypto map
  IPSEC FLOW: permit ip
        Active SAs: 2, origin: crypto map
  IPSEC FLOW: permit ip
        Active SAs: 2, origin: crypto map


The fourth one should be:

  IPSEC FLOW: permit ip


Here is my ACL for the crypto map:

Extended IP access list VPN_ACL
    10 permit ip (2468616 matches)
    20 permit ip (667921 matches)
    30 permit ip (674012 matches)
    40 permit ip host (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 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?


2 Replies 2

Rising star
Rising star

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.



Rizwan Rafeek.




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

10 deny ip


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?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers