IPSec-Spoofing issue on VPNs in v 8.4

[jimmyc_2]

After hours of trial and error, and searching user groups, I have found that on occasion, ASA v8.4 will stop pings with the IPsec-Spoofing logic.  Interestingly, the packet-trace will say everything is allowed.

The fix (at least in my case, and one other) is to narrow the crypto-map to specific hosts, not subnets.

Any one else see this, or can shed some light?  I have to assume this is a bug, but don't know for sure.

jc

[Jouni Forss · Accepted solution]

Hi,

Are you saying that you are expiriencing this on an L2L VPN connection?

We do have a device that is mostly hosting L2L VPN connections on 8.4(x) software but havent heard of any similiar problems.

The latest situation where I have recently wondered about a growing IPsec spoof counter was with a IPsec Hardware VPN client (ASA5505) though to my understanding in that case the IPsec spoof counter increasing is caused by the fact that the ASA is expecting traffic coming even towards its "outside" interface public IP address to be encrypted and naturally there is scanning/etc going on constantly will hit the firewalls public IP address.

Though I kinda wonder why there would be IPsec spoof on the ASA. Wouldnt this mean that there would be a unencrypted packet coming to the ASA that is matching a local VPN configuration? If we are talking about private IP addresses in both ends wouldnt this mean that unencrypted packets would never reach the local ASA at all.

Though I am not sure what the case would be if you were actually using public IP addresses on a L2L VPN connection. Would the traffic sending ASA drop that traffic if the L2L VPN wasnt coming up OR would it send this traffic with public source and destination IP to the remote ASA which would then drop it as IPsec spoof?

It does sound like some bug but to be honest I am not 100% sure about your setup and the messages/output the ASA gives that you are referring to.

Just thought I would "rant" a bit

- Jouni

[jimmyc_2]

Everything is set up in a lab, and I do use private IP addresses for most of my connections.  I don't keep interface names "inside" and "outside", and I manually change the security settings so they are not 0 or 100.  Perhaps if I had used public IP addresses in my isolated lab, I would not have gotten the errors??   Even so, I would still consider that a bug, as there is not any mention that you can not use private IP address on all the interfaces, right?