08-01-2009 02:38 AM - edited 03-06-2019 07:02 AM
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.
08-03-2009 10:25 AM
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
08-04-2009 10:52 PM
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.
08-23-2009 03:57 AM
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
08-23-2009 06:45 PM
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?
08-23-2009 11:18 PM
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.
08-24-2009 01:24 AM
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?
08-24-2009 04:07 AM
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.
09-07-2009 12:46 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide