ASA IPS inline module broke IPSEC tunnel due to anti-replay

[aaron.storey]

I have a customer in which we were deploying their AIP-SSM modules in their ASA's.  They have 3 sites with a VPN tunnel mesh between them.  All was working well until we attempted to upgrade their signatures to the latest version (524).  Units were running 518/519 prior.  All policies were configured to only listen and not to block anything.

Once upgrading, one of the sites experienced a VPN tunnel outage until I was able to log in and remove the IPS from being inline to traffic.  The ASA was reporting anti-replay errors, which I suspected was due to the AIP-SSM trying to manipulate the traffic in some way.  Once I removed the ips inline command, and cleared the crypto SA, the tunnel came back up.

I have since set all IPS modules to promiscuous mode, to reduce the risk of this happening again.  Search doesn't really return much hits on this problem, nor does bug tool seem to have any info.  Has anyone run into this before?  I suspect I may be able to set the interesting traffic to deny forwarding IPSEC traffic to the IPS, while allowing anything else, but I'm not sure if denies are possible.

ASA version = 8.2(2)

IPS version = 7.0(4)E4

Thanks.

[fadlouni]

Hi.

anti-replay window checks, usually mean that a certain ipsec packet came outside the replay window size (similar to tcp window). this is a security measure in case a hacker replays vpn packets thus causing the traffic to appear twice after decryption on the network.

it could be that the AIP-SSM is inspecting the tunnel itself and somehow causing so much packet re-ordering that some packets arriving first are sent much later than packets arriving later, thus causing this to fail.

you can:

1- try increasing the anti-replay window on the asa: crypto ipsec security-association replay

2- bypass crypto traffic from going to the ssm. to answer your question, yes you can put denies in MPF access-lists.

3- you can troubleshoot ssm to see why is it doing that (maybe it's loaded and it's interface buffers are getting filled causing this).

however since vpn traffic is already encrypted and ssm can't do much about the content, it's safe to bypass inspection for that. so option 2 above is the logical thing to do. you can however configure traffic after decryption to be inspected by the ssm module by matching the decrypted traffic address in your MPF and excluding the tunnel endpoints.

Regards,

Fadi.

[aaron.storey]

Thank you for the reply, Fadi.  It was very helpful.