Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

pix code 7.2 experiencing multiple icmp built and tear downs

I am experiencing successive icmp built and teardowns with source and destination port(0) to the management interface. This might be a dumb question, but is this an attack? and I have ACL's on all interfaces to deny ICMP any ideas?

4 REPLIES
Bronze

Re: pix code 7.2 experiencing multiple icmp built and tear downs

well, it looks like some sort of ping sweep?

HTH, please rate it.

Gold

Re: pix code 7.2 experiencing multiple icmp built and tear downs

ping sweeps on the Internet are a dime a dozen. However, if you're getting ping sweeps on your management interface, that sounds like an internal issue and should be addressed. Do you know where the icmp's are coming from?

(you do have your management interface on the inside of your network - and not at all reachable from the I'net?)

Bronze

Re: pix code 7.2 experiencing multiple icmp built and tear downs

hello,

i agree with you, but he didn't mentioned about internet and he only mentioned about the management interface side of his firewall with icmp build and teardown.

if you can provide some more information it would be better to understand your problem

Community Member

Re: pix code 7.2 experiencing multiple icmp built and tear downs

Thank you all for responding to this. It turns out that a logging statement on an internal firewall was firing to an old Syslog server and IP address.

The address of that old Syslog server was of a subnet on the inside. Since this system was not responding being it has been decommisioned, then the logging was being directed out the gateway to a perimeter firewall which in the PIX logs was the Source and the Inside interface of the Inside interface was the destination. Unfortunetly the PIX logs from ASDM were not descriptive, and it wasn't until an Ethereal capture that it was found out.

Lessons learned, keep logging statements up to date. Second, can't rely on the PIX ASDM logs for detail errors on the network. It did indicate there were problems.

Regards,

Carlos

146
Views
0
Helpful
4
Replies
CreatePlease to create content