I want to monitor ICMP traffic only going out of a high sec zone to a low sec zone. I am trying to figure out why my pix is blocking ICMP traffic and other various protocols outgoing. I thought by default from a High to low sec everything is open.
How can I monitor this? The debug packet command doesnt tell me why stuff is getting blocked.
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 > 126.96.36.199
27: Inbound ICMP echo reply ( len 32 id 2 seq 22784) 188.8.131.52 >
Public_IP > 172.16.6.8
Any how on that particular thing I tried to ping 184.108.40.206 from the client 172.16.6.8.
While on the pix I can ping 220.127.116.11 with a normal ping command. if I try "ping inside 18.104.22.168" 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?
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).
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.
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.
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.
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 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.