Cisco PIX-515E NAT translation Issue

Unanswered Question
Aug 1st, 2009
User Badges:

First off, I've started this conversation in the Network Infrastructure forum because I don't believe it is security related, but NAT related. If anyone else thinks differently, feel free to move it over to Security. Thank you.

Now to the actual problem. I have recently set up a Cisco PIX-515E Firewall to separate the internal network ( from the DMZ (, the connection to the internet is established with a 2611XM, this should be unrelated though.

The Firewall has one interface in the DMZ ( and one in the internal network ( I have configured an ACL to allow ICMP traffic between both networks.

However, I am unable to ping or traceroute between the two. The reason for this is obvious:

ICMP echo request from inside: to outside: ID=76

8 seq=58369 len=32

ICMP echo request translating inside: to outside:

ICMP echo reply from outside: to inside: ID=768 seq=58369


ICMP echo reply untranslating outside: to inside:

As you can see, the firewall untranslates to the wrong IP address. I have tried this:

no global (outside) 1

global (outside) 1

This was suggested in another thread and helped once, but not anymore.

Further information:

gateway# show running-config global

global (outside) 1

gateway# show nat

NAT policies on Interface inside:

match ip inside any outside any

dynamic translation to pool 1 ( -

translate_hits = 55489, untranslate_hits = 397

I will post the entire configuration upon request.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
John Blakley Mon, 08/03/2009 - 10:25
User Badges:
  • Purple, 4500 points or more

I may need to see the config, but here's a couple of things to look for. You can use nat exemption to allow the hosts on the internal network to talk to the DMZ without translation. Is there a reason that you would WANT translation into the DMZ?

Anyway, you can do it like this:

access-list nonat permit ip

nat (inside) 0 access-list nonat

Any source machine in the subnet wouldn't be translated going to the dmz, and this works the other direction as well.



lbrinias8546 Tue, 08/04/2009 - 22:52
User Badges:

Sorry, I might be missing something here, but as long as I am going with the subnetmask, the hosts in the and would be in two separate subnets, thus being out of reach for one another, since the PIX is not a router.

In that case, I'd have to go with either a different subnetmask, or merge the subnets into one. In the latter case, it would be preferable to go with a transparent firewall. However, I wanted to have two different subnets.

Anyways, I noticed that the untranslation is not random. The addresses are always untranslated to an address from which an ICMP packet has been received previously.

Regarding the configuration: I don't have access to the system right now, I will publish it later today.

lukas.brinias Sun, 08/23/2009 - 03:57
User Badges:


please feel free to review the configuration:

PIX Version 8.0(3)


hostname gateway

enable password foobar encrypted



interface Ethernet0

speed 100

duplex full

no nameif

no security-level

no ip address


interface Ethernet1

speed 100

duplex full

no nameif

no security-level

no ip address


interface Ethernet2

speed 100

duplex full

no nameif

no security-level

no ip address


interface Redundant1

member-interface Ethernet0

member-interface Ethernet1

nameif outside

security-level 0

ip address


interface Redundant2

member-interface Ethernet2

nameif inside

security-level 100

ip address


passwd barfoo encrypted

boot system flash:/pix803.bin

ftp mode passive

clock timezone CET 1

clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00

dns domain-lookup outside

dns domain-lookup inside

dns server-group DefaultDNS



access-list 100 extended permit icmp any any

access-list 100 extended permit ip any any

pager lines 24

mtu outside 1500

mtu inside 1500

icmp unreachable rate-limit 1 burst-size 1

asdm history enable

arp timeout 14400

global (outside) 1

nat (inside) 1

access-group 100 in interface inside

route outside 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout uauth 0:05:00 absolute

dynamic-access-policy-record DfltAccessPolicy

http server enable

http inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

telnet timeout 5

ssh timeout 5

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

ntp server

ntp server

ntp server

username webadmin password foobar encrypted privilege 15



prompt hostname context


lukas.brinias Sun, 08/23/2009 - 23:18
User Badges:

Well! - is a APC UPS, so is, both send pings every minute to whatever address they know as the gateway. I suppose this is to verify whether or not they have connectivity. With that in mind I would guess that the PIX is just messing up its internal table. Interesting observation on the binary format too.

Same applies to pinging anything in the DMZ from a different host behind the firewall. I'm going to try this again with only one host in the LAN. I haven't tried (and considered) using PAT instead of NAT yet, I'll give it a shot tonight.

lukas.brinias Mon, 08/24/2009 - 04:07
User Badges:

Again, I can't test it right now, our cute little STM-0 went down this morning, looks like the fiber was cut by an excavator...

Anyways, TCP traffic works 'fine' latency however, is MUCH higher than in the DMZ. I'm not referring to ICMP echo latency, but the time to load a page, or similar is much higher. Doesn't look like a duplex-mismatch issue, both the switch port and the ethernet port are fixed to full-duplex operation. I can't think of any UDP traffic that's going through the firewall, so there is a chance that the only reason TCP traffic is working because of the retransmission and I actually have massive packetloss at the firewall.

Sorry, I'm mostly guessing here. I will run some debugging tonight to see what's going on.

lukas.brinias Mon, 09/07/2009 - 12:46
User Badges:

Well, I was actually planning on debugging this yesterday. However I ran into a problem:

How do I debug NAT?

I haven't found anything that specifically deals with NAT, only certain protocols, I haven't even found an option for debug all.


This Discussion