cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2065
Views
0
Helpful
8
Replies

Cisco PIX-515E NAT translation Issue

lbrinias8546
Level 1
Level 1

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.

8 Replies 8

John Blakley
VIP Alumni
VIP Alumni

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

HTH, John *** Please rate all useful posts ***

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.

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

Who own's the ip address 192.168.0.22?

Interestingly in binary format, the number 22 and 30 are only off by 1 bit.

11110 = .30

10110 = .22

What happens when you try to ping from a different ip address or when you use interace PAT instead of a nat pool?

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,

Is this behavior only occuring for ICMP pings? What about other traffic like HTTP, SMTP, etc? How is NAT handling that traffic since its TCP based?

Is that working?

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: