You would need to do some analysis on the AIP-SSM to determine why the SSM would be requesting to drop the ICMP packet.
The IPS does not generally drop normal ICMP packets. So something specific must be going on.
Some possibilities:
1) Sig 2000 or 2004 may have been enabled (these match ICMP packets, but are normally disabled). And had their configuration changed to deny the packets.
2) The ICMP packet may not be normal (maybe extremely large, or weirdly formed) and is matching a signature looking for an ICMP attack.
3) If running IPS version 7.0 the source of the ICMP packet may be from an address known to have very bad reputation in which case all packets from the address may be denied.
4) The source address may have triggered a completely separate signature, and the action for that other signature was to deny all packets from that source address.
The list above is just examples of what might have happened. There are other possibilities as well.
Some things you might try:
a) Try pinging through with other addresses. If the other addresses work, then the SSM may be specifically denying this address.
If pings using other addresses do not work either then check the SSM configuration, something may have been misconfigured on the SSM (especially check sigs 2000 and 2004).
b) You might also consider tuning "ByPass On" for the SSM. This will stop the SSM from doing analysis. Try the ping again. If the ping is now allowed through, then the SSM analysis for some reason is denying the ping. If the ping is still not allowed through, then it isn't the SSM analysis that is denying the traffic.
Remember to tune ByPass back to the default "auto" in order to turn the analysis back on.
You might also check the IPS feature within the ASA itself. The ASA has IPS software in the SSM, but it also has a small subset of IPS signatures that the ASA itself is capable of monitoring. Check the ASA itself to ensure that the IPS functionality within the ASA is not denying the traffic.
