Question about encaps and decaps on a site-to-site VPN

[martino-cisco]

Hi All,

I recently experienced an issue with a site-to-site VPN. The issue has now been resolved but i noticed a behaviour that I thought was strange during the troubleshooting which I felt may have reduced the troubleshooting time if it was otherwise and wanted to at least try and get some clarification. Here it goes:

I set up a S2S VPN from a different vendor device (call this Site1) to a Cisco ASA at a remote site (say Site 2). Phase 1 was complete and fine. Phase 2 was also mostly fine. The only issue was I noticed 'encaps' counters going up at both ends, but no 'decaps'. Now, looking at the logs on the ASA, i could see traffic from site 1 coming in to the ASA at site 2 with a lot of the traffic being SYN timeouts. With SYN timeouts, i thought the traffic was getting to site 2 and the return traffic was probably going out a different way (which ended up being the case - and was then resolved).

Now, my confusion is, if the ASA at site 2 was receiving this traffic and correctly identifying SYN and SYN timeouts, should that not mean it has successfully decrypted the traffic to identify the nature of the traffic (in this case, SYN and SYN timeouts)? Why then would the decaps remain 0?

Any thoughts please?

[Flavio Miranda]

Hello @martino-cisco

Most of time I have found this problem it was due incorrect configuration NAT statements and ACL mismatching. 

-If I helped you somehow, please, rate it as useful.-

[martino-cisco]

Thanks Silvio. As mentioned, it was eventually due to a routing issue on a downstream device. I'm really just trying to understand why the ASA was seeing the traffic but was still not incrementing decaps

[Rahul Govindan]

Any possibility that the traffic was received by the ASA unencrypted? If it was routed through a different path on the remote ASA, it could have made it across the internet (provided NAT etc was done) or another internal path. This would still show up on the ASA and not match the inbound crypto map rules (since NAT would have changed its source ip address), hence no decaps. This is just a theory but might explain how you are seeing this behavior.

[martino-cisco]

Hmmm...You raise a good point. However, i noted that it was seeing the traffic source as the Outside interface, which is what you would expect over the VPN. On whether it may have been routed out to the internet and back...I don't know for sure but would consider it unlikely as the source of the traffic in the logs was the same private IP I was expecting, and not a public IP. Plus, in that scenario, i would anticipate seeing logs that could indicate something along asymmetric routing rather than SYN timeouts.

I understand it may be difficult to correctly analyse especially as the issue is no longer there. Was just wondering if this is an expected behaviour. Perhaps, decaps counters only increase after a fully established session and traffic flow between both ends??