NAT issue in PIX

Hi All,

The PIX firewall have configured with following.

access-list out_in line 1 permit tcp <src IP> 255.255.0.0 host x.x.x.x

static (inside,outside) 1.1.1.1 <Native IP> netmask 255.255.255.255 0 0

but I couldn't ping the outside IP 1.1.1.1 (fake IP) seems the NAT is not working properly.

The server is reachable from PIX with its local IP.

Can some one help me on this to fix it ASAP.

Thanks in ADV

I believe on the PIX, by design, you can't ping an outside interface from inside. I think this is hairpinning.

See www.firewall.cx/ftopict-4572-hairpinning.html

no I'm not pining from inside...I tried it from outside...its not reachable.

Sorry, I must have read it wrong.

Does your ACL allow for echo replies to be sent out?

Have you applied your ACL to an interface?

Dove, can i see the NAT and Global Settings. Also is this access-list as you have put it ?

I have noticed that with ICMP (your access-list is allowing TCP BTW and not ICMP) you need to allow it in both interfaces (if you have access lists on both interfaces. Well, i say that but this is just what i have observed with our core firewall which does pure routing, it doesn't seem to maintain the connection information (states) for ICMP traffic).

For example,

If on the outside you have a rule that says;

access-list outside-int extended icmp any host 1.1.1.1 eq echo

you will also need to add;

access-list inside-int extended icmp host <Native IP> any eq echo-reply

I have found that with the Pix, ICMP isn't stateful and as such it doesn't keep a record of the ICMP traffic thats just gone through and therefore allow the return traffic back.

Remember, that on the external, you set the access-list to the outside ip address and not the internal address that its natting to.

Hope it helps

I've had numerous problems passing ICMP packets through PIX firewalls in the past and came to a few conclusions for each scenario:

1) In the case of a simple NAT (PAT or Overload), you’ll need to created ICMP access-lists on both inside and outside interfaces, otherwise 'pings' tend to fail :

Assuming 10.0.0.0 is the internal network, 192.168.0.166 is the external PIX interface IP Address.

access-list inside_access_in permit icmp 10.0.0.0 255.255.255.0 any [Allow any internal host to send a ‘ping’]
access-list outside_access_in permit icmp any host 192.168.0.166 [Allow any ICMP to hit and pass through the external interface]

access-group outside_access_in in interface outside [Apply ACL to outside interface]
access-group inside_access_in in interface inside [Apply ACL to inside interface]

global (outside) 5 interface [Define PAT/NAT Overload]
nat (inside) 5 10.0.0.0 255.255.255.0 0 0 [Map above NAT to this ‘inside’ network]

2) In the case you’ve got a static NAT configuration (an Internal host maps to a external IP address), the same rule applies:

Assuming 10.0.0.2 is the internal workstation mapped to the static public IP 192.168.0.170

access-list inside_access_in permit icmp 10.0.0.0 255.255.255.0 any [Allow any internal host to send a ‘ping’]
access-list outside_access_in permit icmp any host 192.168.0.170 [Allow any ICMP to hit and pass through the static IP configured]


static (inside,outside) 192.168.0.170 10.0.0.2 netmask 255.255.255.255 [Static NAT, internal host 10.0.0.2 to public IP 192.168.0.170]

access-group outside_access_in in interface outside [Apply ACL to outside interface]
access-group inside_access_in in interface inside [Apply ACL to inside interface]

3) The last scenario I can think of is one where the PIX firewall is simply acting as a ‘router’ without NAT translation of any kind. In this configuration, the public can see all internal IP address as they are not masked by the PIX firewall’s external IP address.

Assuming 10.0.0.2 is the internal workstation and 192.168.0.0 is the public network on the PIX outside interface.

access-list inside_access_in permit icmp 10.0.0.0 255.255.255.0 any [Allow any internal host to send a ‘ping’]
access-list outside_access_in permit icmp any host 10.0.0.2 [Allow any ICMP to internal host 10.0.0.2]


static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.255.255.0 [Do not NAT any packets from inside network to the outside network, simply route them]

access-group outside_access_in in interface outside [Apply ACL to outside interface]
access-group inside_access_in in interface inside [Apply ACL to inside interface]

In all above scenarios, the access-lists are required on both sides of the PIX firewall in order for the internal host to receive icmp replies.
So Smuf’s note that ICMP packets are stateless, is correct.

Cheers,