Problems with IPSec tunnel, phase 2 active but no forwarding

[uabrisqueta]

Hi all,

We have a setup with a production IPSEC tunnel against a third party and we needed to modify the ACL that defines the IPSEC phase 2. We have included the new communication flow but although the phase 2 seems to be up, there is no traffic reaching our next hop, routing is okay and the destination is reachable from other 3rd party tunnels.

The decryption counters are the following ones:

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 295, #pkts decrypt: 295, #pkts verify: 295
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

The only strange thing we have set up is that due to a misconfiguration in the other side, the mask was set up incorrectly so we have two entries in our cisco router ACL, a /25 and a /24 that both covers the traffic that is not working. Could this be generating any issue? Do you know which is the impact of changing the ACL of a crypto map? does this bring down the whole ipsec phase2 of that tunnel?

Thanks in advance

[MHM Cisco World]

The misconfig mask in Acl can cause issue sure. 

Try romove old acl and add new one with only correct mask

MHM

[MHM Cisco World]

let explain issue here 

one side use proxy of ACL /24 
other side use proxy of ACL /25
this not match and hence you see decrypt no encrypt 

MHM

[Aref Alsouqi]

Although I would highly recommend having mirrored ACLs, that would not be the case because. For instance say we have subnet A which is 192.168.0.0/25 and subnet B which is 192.168.1.0/25. The IP ranges of the usable hosts for these two subnets would be from .1 - .126. If we assume that we have the encryption domains configured in site A as 192.168.0.0/24 and in site B as 192.168.0.0/25, when the traffic is sent from site A to B it will still match the encryption domain 192.168.0.0/24 because the IP will still be an IP within the /25 that is defined in site B. Same concept would apply when we send the traffic from site B to site A. As I said I saw this working just fine and if I'm not mistaking it works on the ASAs but not on the IOS devices.

The decaps and encaps are the traffic hits over the VPN tunnel, if for whatever reason we don't see encaps it means that we are not sending the interested traffic over the tunnel. That could be related to routing if we use route-based VPN, NAT exemption that is not covering the interested traffic, or if we are sending traffic from or to IP addresses that are not part of the encryption domains ACLs.

[Aref Alsouqi]

Having inconsistent encryption domains access lists could be an issue, however, I saw IPsec tunnels working just fine as long as the longest match ACL is included in the shortest match. However, please ensure both ends have exactly mirrored ACLs.

Also, the shared output shows that you have decaps but zero encaps. This means that although you are receiving traffic over the VPN tunnel, but you are not sending anything inside the tunnel. This could be caused by a wrong NAT statement or the interested traffic is not included in the encryption domain ACL.