Cisco PIX-515E NAT translation Issue

Unanswered Question
Aug 1st, 2009

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 (192.168.0.0/24) from the DMZ (192.168.1.0/24), the connection to the internet is established with a 2611XM, this should be unrelated though.

The Firewall has one interface in the DMZ (192.168.1.4) and one in the internal network (192.168.0.1). 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:192.168.0.30 to outside:192.168.1.1 ID=76

8 seq=58369 len=32

ICMP echo request translating inside:192.168.0.30 to outside:192.168.1.30

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

len=32

ICMP echo reply untranslating outside:192.168.1.30 to inside:192.168.0.22

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

no global (outside) 1 192.168.1.30-192.168.1.199

global (outside) 1 192.168.1.30-192.168.1.199

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

Further information:

gateway# show running-config global

global (outside) 1 192.168.1.30-192.168.1.199

gateway# show nat

NAT policies on Interface inside:

match ip inside any outside any

dynamic translation to pool 1 (192.168.1.30 - 192.168.1.199)

translate_hits = 55489, untranslate_hits = 397

I will post the entire configuration upon request.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
John Blakley Mon, 08/03/2009 - 10:25

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 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0

nat (inside) 0 access-list nonat

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

HTH,

John

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

Sorry, I might be missing something here, but as long as I am going with the subnetmask 255.255.255.0, the hosts in the 192.168.0.0 and 192.168.1.0 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

John,

please feel free to review the configuration:

PIX Version 8.0(3)

!

hostname gateway

enable password foobar encrypted

names

!

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 192.168.1.4 255.255.255.0

!

interface Redundant2

member-interface Ethernet2

nameif inside

security-level 100

ip address 192.168.0.1 255.255.255.0

!

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

name-server 192.168.1.10

name-server 192.168.1.13

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 192.168.1.30-192.168.1.199

nat (inside) 1 0.0.0.0 0.0.0.0

access-group 100 in interface inside

route outside 0.0.0.0 0.0.0.0 192.168.1.1 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 192.168.0.0 255.255.255.0 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 192.53.103.103

ntp server 192.53.103.108

ntp server 192.53.103.104

username webadmin password foobar encrypted privilege 15

!

!

prompt hostname context

Cryptochecksum:barfoobarfoo

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

Well! - 192.168.0.22 is a APC UPS, so is 192.168.0.21, 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

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

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.

Actions

This Discussion