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

IP SLA - PIX 525

Greetings

I am a bit new so forgive any Cisco speak I don't speak. So I am adding a second ISP to my existing PIX firewall. I have read, and think I understand how to set it up but I am having an issue confirming ping to my primary ISP gateway. I am about to setup IP SLA to monitor the outside next hop but I wanted to confirm ping. From telnet I cannot ping the router IP(ISP gateway), if I apply an access rule to the outside interface to allow ping, no good however I can ping from a machine on the inside network(have access rule for this as well). If I disable the outside rule ping is blocked. I am confused on how I can check that the firewall can ping the gateway or am I missing a configuration. I assumed that I would simply exit the outside interface when sending a ping from a telnet session. PIX8.02 on a 525. Any guidance is appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Blue

Re: IP SLA - PIX 525

Bob

Access-lists only control ping going through the firewall and not to the firewall itself.

To allow ping to an interface on the pix you need to use the "icmp permit .." command -

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/i1.html#wp1685750

Jon

11 REPLIES
Hall of Fame Super Blue

Re: IP SLA - PIX 525

Bob

Access-lists only control ping going through the firewall and not to the firewall itself.

To allow ping to an interface on the pix you need to use the "icmp permit .." command -

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/i1.html#wp1685750

Jon

Community Member

Re: IP SLA - PIX 525

Ah, that makes sense, that's what I was looking for and worked.

Thanks !!

Hall of Fame Super Blue

Re: IP SLA - PIX 525

No problem, glad to have helped.

Jon

Silver

Re: IP SLA - PIX 525

jon,

I am not sure I agree with this statement:

"Access-lists only control ping going through the firewall and not to the firewall itself."

let me give you an example:

Pix outside IP address is 4.2.2.1

Pix inside IP address is 192.168.1.1

there is a server with an ip address of 192.168.1.2. This server is static NAT to 4.2.2.2

The objective is to block icmp going to the server and also to the Pix outside Ip address. Will the ACL below accomplish this:

static (inside,outside) 4.2.2.2 192.168.1.2 netmask 255.255.255.255

access-list External deny icmp any any log

access-list External permit ip any any log

access-group External in interface outside

Will that accomplish blocking ping going through and to the Pix firewall?

Hall of Fame Super Blue

Re: IP SLA - PIX 525

David

Why do i get the feeling this is a trick question :-)

It would block ping going to through to the 192.168.1.2 server but i don't believe it will block ping to the outside interface.

Unfortunately i don't have a pix handy to test with. Have you tried it and found it does block it ?

Jon

Hall of Fame Super Blue

Re: IP SLA - PIX 525

David

Just a quick follow up on this.

The default is not to allow icmp to the outside interface. So with just the above config then yes it would block both but it wouldn't be blocking icmp to the outside interface because of the acl.

So to do a proper test you need to add "icmp permit any outside" and then try.

Jon

Silver

Re: IP SLA - PIX 525

Jon,

"The default is not to allow icmp to the outside interface."

Are you sure about this? I thought the pix, by default, will allow ping on the interface.

"So with just the above config then yes it would block both"

That's how I understand it.

"So with just the above config then yes it would block both but it wouldn't be blocking icmp to the outside interface because of the acl."

Not sure what you mean by this.

Hall of Fame Super Blue

Re: IP SLA - PIX 525

David

You've really got me thinking now and i wish i had a pix to test on :-)

Firstly you are totally correct in that the default is to allow ICMP to all interfaces, my mistake.

From the command reference -

"The icmp command controls ICMP traffic that terminates on any security appliance interface. If no ICMP control list is configured, then the security appliance accepts all ICMP traffic that terminates at any interface, including the outside interface. However, by default, the security appliance does not respond to ICMP echo requests directed to a broadcast address.

The icmp deny command disables pinging to an interface, and the icmp permit command enables pinging to an interface. With pinging disabled, the security appliance cannot be detected on the network. This is also referred to as configurable proxy pinging.

Use the access-list extended or access-group commands for ICMP traffic that is routed through the security appliance for destinations on a protected interface."

Which is now confusing me. I always assumed that the default was to block ping to the outside interface.

I have answered a number of threads here where people have had a "permit icmp any any" or had a "permit ip any any" in the acl configured on their outside interface and still they cannot ping the firewall outside interface - see this thread for an example.

And from my own personal experience to allow a firewall to respond to an ICMP request on it's outside interface i have used "icmp permit any any" in the config regardless of what is in the acl attached to outside interface.

But because the default is to allow all you have got me wondering if there is more to it than that.

Perhaps by applying an acl that doesn't specifically permit icmp it then blocks it but it can be overriden by using the "icmp ..." statement. But then why if you use a "permit ip any any" in the acl do people still have trouble pinging the outside interface.

My memory isn't what it used to be :-). If you have access to a pix or you can confirm for sure could you possibly run a few tests.

Or perhaps i'm overlooking something really obvious, if so please put me out of my misery !!

Jon

Silver

Re: IP SLA - PIX 525

Jon,

After going back and looking at my CCIE security note, I found the followings:

access-list External deny icmp any any log

access-list External permit ip any any log

access-group External in interface outside

This will NOT stop ping from the Pix outside interface. In other words, one can still ping the Pix outside interface and get a reply.

Therefore, your statement "Access-lists only control ping going through the firewall and not to the firewall itself." is a correct one.

David

Hall of Fame Super Blue

Re: IP SLA - PIX 525

David

Thanks for this but it still leaves the outstanding question ie.

if the above acl does not control ICMP to the firewall interface and the default is to allow all ICMP requests to firewall interfaces why do you still have to explicitly use "icmp permit any any" to allow ICMP.

If the default was to deny all pings to interfaces then it would make sense but as you pointed out this is not the default.

Therefore one of 2 things is happening as far as i can see -

1) When i have added an "icmp permit any outside" to my config to temporarily allow ICMP to the outside interface it is because i have previously had an "icmp deny any outside" in the config.

Maybe so but i am sure i have also answered questions on NetPro where people have not had any "icmp deny ..." statements and still they could not ping.

2) There is some weird interaction between an acl applied to the outside interface and the "icmp " statement.

I don't have the answer but when i next get access to a pix i'll be sure to test.

Many thanks for the discussion.

Jon

Cisco Employee

Re: IP SLA - PIX 525

Jon,

You were right in your first posting.

ACL applied to the interface has nothing to do with "TO" the box traffic. ACL is only for "THROUGH" the box traffic.

With that said. By default PIX/ASA platform do allow pings to the interface whereas the FWSM does not.

sh run icmp

should help to see if they are specifically denied for some reason.

311
Views
0
Helpful
11
Replies
CreatePlease to create content