Hot Downloads

Welcome, Guest
Username: Password: Remember me

TOPIC: NAT issue in PIX

NAT issue in PIX 9 years 1 month ago #23539

  • Dove
  • Dove's Avatar
  • Offline
  • Distinguished Member
  • Posts: 198
  • Thank you received: 1
  • Karma: 2
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

Dove
The administrator has disabled public write access.

Re: NAT issue in PIX 9 years 1 month ago #23545

  • skepticals
  • skepticals's Avatar
  • Offline
  • Expert Member
  • Posts: 783
  • Karma: 0
I believe on the PIX, by design, you can't ping an outside interface from inside. I think this is hairpinning.

See http://www.firewall.cx/ftopict-4572-hairpinning.html
The administrator has disabled public write access.

Re: NAT issue in PIX 9 years 1 month ago #23551

  • Dove
  • Dove's Avatar
  • Offline
  • Distinguished Member
  • Posts: 198
  • Thank you received: 1
  • Karma: 2
no I'm not pining from inside...I tried it from outside...its not reachable.

Dove
The administrator has disabled public write access.

Re: NAT issue in PIX 9 years 1 month ago #23559

  • skepticals
  • skepticals's Avatar
  • Offline
  • Expert Member
  • Posts: 783
  • Karma: 0
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?
The administrator has disabled public write access.

Re: NAT issue in PIX 9 years 1 month ago #23560

  • Smurf
  • Smurf's Avatar
  • Offline
  • Moderator
  • Posts: 1390
  • Karma: 1
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
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx

Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
The administrator has disabled public write access.

Re: NAT issue in PIX 9 years 1 month ago #23590

  • Chris
  • Chris's Avatar
  • Offline
  • Administrator
  • Posts: 1446
  • Thank you received: 13
  • Karma: 8
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 [/color] [/quote] 2) In the case you’ve got a [b]static NAT configuration[/b] (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 [quote]access-list inside_access_in permit icmp 10.0.0.0 255.255.255.0 any [color=violet][Allow any internal host to send a ‘ping’][/color] access-list outside_access_in permit icmp any host 192.168.0.170 [color=violet][Allow any ICMP to hit and pass through the static IP configured][/color] static (inside,outside) 192.168.0.170 10.0.0.2 netmask 255.255.255.255 [color=violet][Static NAT, internal host 10.0.0.2 to public IP 192.168.0.170][/color] access-group outside_access_in in interface outside [color=violet][Apply ACL to outside interface][/color] access-group inside_access_in in interface inside [color=violet][Apply ACL to inside interface][/color] [/quote] 3) The last scenario I can think of is one where the PIX firewall is simply acting as a [b]‘router’ without NAT translation[/b] 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. [quote]access-list inside_access_in permit icmp 10.0.0.0 255.255.255.0 any [color=violet][Allow any internal host to send a ‘ping’][/color] access-list outside_access_in permit icmp any host 10.0.0.2 [color=violet][Allow any ICMP to internal host 10.0.0.2][/color] static (inside,outside) 10.0.0.0 10.0.0.0 netmask 255.255.255.0 [color=violet][Do not NAT any packets from inside network to the outside network, simply route them][/color] access-group outside_access_in in interface outside [color=violet][Apply ACL to outside interface][/color] access-group inside_access_in in interface inside [color=violet][Apply ACL to inside interface][/color] [/quote] 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,[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,
Chris Partsenidis.
Founder & Editor-in-Chief
www.Firewall.cx
The administrator has disabled public write access.
Time to create page: 0.087 seconds

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup