Pix Debug Commands

If you have an access-group applied to the inside interface, then that default no longer holds. The default also only applies if there is a network translation available for the outgoing traffic (static or nat/global).

debug icmp trace

might help, as would pushing your logging level up to 6 and monitoring the 'deny' messages carefully.

Another item to check is that PIX 6 will block all ICMP messages of more than 1000 bytes.

Thanks Walter. Debug ICMP trace shows that the outbound echo requests are send and a reply is received but on the client end it says "request timed out" as if no connectivity exists. However those clients browse the internet just fine.

So far as I can tell, I have scoured this config for some time now and I cannot find any ACLs being applied to the inside interface

debug icmp trace shows this when a client tries to ping

Pix# 26: Outbound ICMP echo request ( len 32 id 2 seq 22784)

172.16.6.8 > Public_IP > 72.14.207.99 27: Inbound ICMP echo reply ( len 32 id 2 seq 22784) 72.14.207.99 >

Public_IP > 172.16.6.8

Any how on that particular thing I tried to ping 4.2.2.1 from the client 172.16.6.8.

While on the pix I can ping 4.2.2.1 with a normal ping command. if I try "ping inside 4.2.2.1" I get no response.

I am confused by this "might help, as would pushing your logging level up to 6 and monitoring the 'deny' messages carefully. "

I want to see these deny requests. How can I do this?

Thanks soo much for the help Walter!

,

Sorry about the reply from another account. That was me on another account.

Which PIX version? PIX 6 up right through PIX 6.3(5) has only weak automatic remapping of ICMP replies back through to the original host (ICMP packets have no sequence numbers or port numbers so they are harder to match.) The cure for this on PIX 6 is to explicitly permit "safe" icmp in to all of your systems. The safe icmp are icmp 3 (remote system inaccessible) and icmp 8 (echo reply).

logging on logging buffered 6 logging trap 6 logging host IPADDRESS

The 'logging buffered' number controls which messages show up when you 'show buffer'; the buffer is not very big, and it will wrap around fairly quickly if you use a high logging level. But it's a fast way of seeing information if you are right at the PIX. You would normally want to turn that level down after you finish your debug session.

The 'logging trap' number controls which messages get sent to your syslog server. 'logging host IPADDRESS' tells it the IP of your syslog server. I used to leave my syslog level permanently at 6 to my syslog server, so that I would be able to trace everything afterwards, but a lot of people only log to level 4 to the syslog server except when they are looking for something specific, because the logs can really add up in size... and then what are you going to do with them? If you don't have a unix syslog facility handy (and recall that on linux systems you have to configure the syslog server to listen to your pix sending messages!) then a good PC based syslog program is Kiwi Syslog.

Not only that but v7 and 8 and their respective revs of ASDM have a visual packet trace tool that shows you the rule(s) responsible for allowing/denying access.

-Gary

Thanks Gary, this guy is slightly older. We were about to upgrade to an ASA5505 but saw that by default you could allow 10 users to pass through the device which was not only rediculous after the price of the device but unacceptable when we had a perfectly fine working Pix

506 that had no license limitations.

Unfortunately I looked for an SDM on this machine but nothing is loaded in the flash, and it is an older version 6.

I just need to go and download a syslog service for our windows server, I think that this logging technique might show me what I want to see. It still would be nice to see exactly what is blocking the pings if anything.

Its not just pings, its VPNing out, RDPing out. Tons of services being blocked and I don't know why because its all traffic going from a HIGH Sec zone to a LOW. And other random services do appear to work.

*shrug*.

Thanks for the help gentlemen.

That could happen if you have a static() that mentions the interface outside IP by IP number instead of by the keyword 'interface'. Also, the access-lists have to use 'interface outside' instead of the actual interface outside IP address.

Walter, or anyone else of course - how did you find out all these fine things about the Pix?

I find the Pix almost unusable due to all of the weird and wonderful implicit behaviours that it has that are not, as far as I can see, documented.

Maybe there are some good books? If not maybe you should make one?

Partly trial and error; partly by reading and answering a lot of questions here.

The last PIX (515E) has been EOS'd now, and I only know PIX 5 and PIX 6; what little I know about PIX 7 is by reading a few of the messages here. With the time it would take to research and write book, the result would have a diminished market by the time it was ready.

I used to be a network and security admin, but about 2 1/4 years ago, I shifted over to biomedical programming (which had always been part of my job here.) My answers these days are from memory, and the details are fading.

Ok Walter I got some very interesting information for us to analyze.

I ran a syslog of my pix and here is my discovery.

Here is me trying ping google from internal host 172.16.6.2. I replaced my public IP with 10.0.0.1 so you could get an idea of the translations.

Apr 15 12:43:45 172.16.6.1 %PIX-6-305011: Built dynamic ICMP translation from inside:172.16.6.2/512 to outside:10.0.0.1/10

Apr 15 12:43:45 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

72.14.207.99 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL- IN"

Apr 15 12:43:46 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

72.14.207.99 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL- IN"

Apr 15 12:43:48 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

72.14.207.99 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL- IN"

Apr 15 12:43:49 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

72.14.207.99 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL- IN"

Here is me trying to ping public DNS 4.2.2.1 from the same host. Apr 15 13:11:30 172.16.6.1 %PIX-6-305011: Built dynamic ICMP translation from inside:172.16.6.2/512 to outside:10.0.0.1/12

Apr 15 13:11:30 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

4.2.2.1 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL-IN"

Apr 15 13:11:31 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

4.2.2.1 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL-IN"

Apr 15 13:11:33 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

4.2.2.1 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL-IN"

Apr 15 13:11:34 172.16.6.1 %PIX-4-106023: Deny icmp src outside:

4.2.2.1 dst inside:10.0.0.1 (type 0, code 0) by access-group "ACL-IN"

Now here is me accessing the google webpage from the same host. Apr 15 13:13:22 172.16.6.1 %PIX-6-305011: Built dynamic TCP translation from inside:172.16.6.2/14007 to outside:10.0.0.1/33799

Apr 15 13:13:22 172.16.6.1 %PIX-6-302013: Built outbound TCP connection 247829 for outside:64.233.167.99/80 (64.233.167.99/80) to inside:172.16.6.2/14007 (10.0.0.1/33799)

Apr 15 13:13:22 172.16.6.1 %PIX-5-304001: 172.16.6.2 Accessed URL

64.233.167.99:/

Ok I get it. My ACL_IN is blocking ICMP. But this conflicts with my fundamental understanding of what NAT SHOULD be doing. Nat should allow a connection outgoing to be established. Meaning that the response to that outgoing connection should be allowed to be replied to.

In my ACL_IN there is nothing permitting ICMP. Port 80 IS permitted but at a different ip (10.0.0.2). A logical IP used for other connections.

I dont ever recall having to explicitly open ports on my firewall for a service thats OUTBOUND to work. Obviously if im hosting something inside and an outside client needs to initiate the connection thats different. So its odd that ICMP is blocked and HTTP is permitted. I have no outbound ACL, only inbound.

I double checked all my static statements and they are all "static (inside,outside) etc..."

Is this a bug in my PIX? I'm afraid its EOS and we have no service contract with cisco so updating the IOS would be difficult.

Any other ideas?