Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ICMP inbound

Status
Not open for further replies.

jwi71

MIS
May 27, 2003
42
0
0
US
This is driving me nuts. I have a clean 525 install and
I want to allow internal clients to ping outside hosts at will. I know the PIX allows ICMP outbound and drops the incoming reply by default. I have set the following ACL in our 525 (the only ACL configured for now):

access-list ping-out permit icmp any any

I then applied it to the outside interface (we only have two interfaces):

access-group ping-out in interface outside

No dice. I configured NAT with a small NAT pool and a failover PAT address. I also configured the interfaces. I can ping both interfaces from their respective networks (I can ping outside from the untrusted and the inside interface from the LAN). Again, expected and default behavior. Is the above access-list and access-group correct to allow ICMP replies inbound?

TIA
 
Where's your access-list to allow ICMP to pass from interface to interface? Something like...

access-list ping-inside-out permit icmp any any

then apply it to the inside interface...

access-group ping-inside-out in interface inside

If you don't do that, you won't be able to pass ICMP packets PAST the inside interface. Your inside hosts will be able to ping the inside interface all day. Until you tell the inside interface to let the ICMP packets past, it won't work.
 
Here's my acl to allow outgoing icmp:
access-list IN permit icmp any any echo-reply
access-list IN permit icmp any any source-quench
access-list IN permit icmp any any unreachable
access-list IN permit icmp any any time-exceeded

Apply that to the outside interface.
 
Still no dice. I modified my ACL to mimic "dix1" ACL and no go. I checked the cables and they're good. I think it is a NAT problem. Do I need a static NAT? The only Cisco doc I found on it has a static NAT. Otherwise, it looks like "dix1"'s ACL.

I verified I have cabled it right too. I will try a static NAT and see if that works.... Currently the pix is in a lab and connected via x-over cables to two servers, so no intervening routers/firewalls/ACLs. FTP works fine too, so no routing issues. Pulling my hair out.

Thanks for the help...I may have to post the entire config.
 
This one got me too. Try adding this to your config

icmp permit any outside
icmp permit w.x.y.z a.b.c.0 inside
 
are you using IDS
if so then disable these if they are on

ip audit signature 2000 disable
ip audit signature 2001 disable
ip audit signature 2004 disable
ip audit signature 2005 disable

if your policy is to drop or reset then even though the ACL is applied, ICMP still won't work

here's some stuff from my site
 
Just to clear up something that bwilliam13 said :

"Where's your access-list to allow ICMP to pass from interface to interface? Something like..."

Only true in the case that you already have an acl on the inside, if you don't you only need to permit the echo-reply back to the nat/pat address of the pix from the internet on your outside interface.

Jan

Network Systems Engineer
CCNA/CQS/CCSP
 
I figured it out.

This PIX is replacing an AIX firewall. To translate the AIX rulset into ACL I had whipped up a lab on the raised floor and printed the rules. For endsations, I was given two laptops.

The laptops had personal firewall software installed (corporate policy) and that was dropping ICMP.

And no, there was no taskbar icon indicating such. One of the Windows Admins informed me of the personal firewall.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top