Nat issue with Pix 515E

[bradford66]

PIX-515E: Version 6.3(5)

I'm trying to open a connection to a webserver on the dmz interface from a host on the inside interface and it fails. In this instance the webserver is listening on port 88. I think the problem it is something obvious that I'm missing in my config.

I have mapped a public ip to the webserver in the DMZ using the static command:

static (dmz,outside) 66.x.x.x 172.16.3.4 netmask 255.255.255.255 0 0

The inside interface host is just using interface PAT:

nat (inside) 1 172.16.4.0 255.255.255.0 0 0

global (outside) 1 interface

ip address outside 208.x.x.x 255.255.x.x

So when I try to telnet (from 172.16.4.8 in this case) to the hostname mapped to 66.x.x.x, it just times out.

This is what the sho conn filtered for the ip's in question looks like:

TCP out 208.x.x.x:19025 in 172.16.3.4:88 idle 0:00:24 Bytes 0 flags aB

TCP out 66.x.x.x:88 in 172.16.4.8:3364 idle 0:00:14 Bytes 0 flags saA

So when the packets leave 172.16.4.8 out the outside interface destined to the public ip 66.x.x.x, the ip pat'd to 208.x.x.x. Then the packet comes in from the outside interface and opens a connection to port 88 on 172.16.3.4 (the pix must have translated the public ip from 66.x.x.x to the private one 172.16.3.4 once the packet was “processed” on the outside int.)

The webserver (172.16.3.4) then responds, leaves over the outside interface, and is translated to 66.x.x.x, then re-enters the outside interface, but instead of responding to the PAT'd ip address and port (208.x.x.x:19025) of the host, it tries to open a connection to the private ip and different port of the host instead (172.16.4.8:3364). That is why I think this is failing. The webserver isn't responding to the ip address that requested a connection (208.x.x.x), it's instead responding to the private ip addresses before PAT translation (172.16.3.4). What on earth should be in the config to allow connections between hosts on different interfaces where one host has a static mapping to a public ip address?

I can telnet directly to the dmz webserver's private ip and listening port from the host on the inside interface, but that circumvents the static and PAT entries. I have nat0 acls between both interfaces, so I'm confused why the static entries would supersede the nat0 acls. Shouldn't the pix not translate a packet coming from one interface destined to a public ip address on a different interface, if the nat 0 acl is triggered? In this case, when 172.16.4.8 tries to make a connection to 66.x.x.x, why won't the pix realize that 66.x.x.x is really 172.16.3.4, and thus there would be no translation because the 172.16.4.0 subnet won't nat when reaching the 172.16.3.0 subnet because of this acl:

access-list inside_outbound_nat0_acl permit ip any 172.16.3.0 255.255.255.0\

Here are the relevant lines in the running config:

access-list acl_out permit tcp any host 66.x.x.x eq 88

access-list inside_outbound_nat0_acl permit ip any 172.16.3.0 255.255.255.0

access-list dmz_outbound_nat0_acl permit ip any 172.16.4.0 255.255.255.0

static (dmz,outside) 66.x.x.x 172.16.3.4 netmask 255.255.255.255 0 0

ip address dmz 172.16.3.1 255.255.255.0

ip address inside 172.16.4.1 255.255.255.0

ip address outside 208.x.x.x 255.255.x.x

nat (dmz) 0 access-list dmz_outbound_nat0_acl

nat (dmz) 1 172.16.3.0 255.255.255.0 0 0

nat (inside) 0 access-list inside_outbound_nat0_acl

nat (inside) 1 172.16.4.0 255.255.255.0 0 0

global (outside) 1 interface

access-group acl_out in interface outside

I've been stumped by this one for a while now.

[bradford66]

The above config changes still fail for the inside interface hosts. Does anybody have an idea why? The (inside) alias line isn't re-writing the dns replies from 66.x.x.x to 172.16.3.4. Why is it not doing this? Anybody?

[cisco24x7 · Accepted solution]

Now that I have time to look at your configuration a bit carefully,

the configuration will work, Why? Because I tested it myself.

- Pix outside interface is 129.174.1.129/24,

- Pix inside interface is 192.168.2.1/28,

- Pix dmz interface is 192.168.192.1/24,

- DNS server is on the outside interface with IP address of 192.168.15.10,

- There is a Linux client on the inside interface with IP address of 192.168.2.3/28,

- There is a Linux WEB Server in the DMZ interface with IP address of 192.168.192.10/24,

- The linux WEB server is static NAT to the outside with 129.174.1.26. The

Fully Qualified Domain Name (FQDN) is test.cciesecurity.com,

- The linux client has the dns server of 192.168.15.10 in the /etc/resolv.conf file,

- The linux WEB server has the dns server of 192.168.15.10 in the /etc/resolv.conf file,

- Now from the Linux client behind the inside interface, I do this:

Gen2Linux ~ # nslookup

> server 192.168.15.10

Default server: 192.168.15.10

Address: 192.168.15.10#53

> test.cciesecurity.com

Server: 192.168.15.10

Address: 192.168.15.10#53

Name: test.cciesecurity.com

Address: 192.168.192.10

>

tcpdump on the DNS server:

02:48:33.630437 129.174.1.129.1028 > 192.168.15.10.53: 19766+ A? test.cciesecurity.com. (35) (DF)

02:48:33.631392 192.168.15.10.53 > 129.174.1.129.1028: 19766* 1/1/0 A 129.174.1.26 (69) (DF)

- Now from a Linux host behind the DMZ interface, I do this:

[root@bwi40-LinuxES root]# nslookup

Note: nslookup is deprecated and may be removed from future releases.

Consider using the `dig' or `host' programs instead. Run nslookup with

the `-sil[ent]' option to prevent this message from appearing.

> server 192.168.15.10

Default server: 192.168.15.10

Address: 192.168.15.10#53

> test.cciesecurity.com

Server: 192.168.15.10

Address: 192.168.15.10#53

Name: test.cciesecurity.com

Address: 192.168.192.10

>

tcpdump on the DNS server:

[root@dca2-LinuxES named]# tcpdump -i eth0 -nnn port 53 and host 129.174.1.26

tcpdump: listening on eth0

02:51:03.873646 129.174.1.26.32870 > 192.168.15.10.53: 40843+ A? test.cciesecurity.com. (35) (DF)

02:51:03.875087 192.168.15.10.53 > 129.174.1.26.32870: 40843* 1/1/0 A 129.174.1.26 (69) (DF)

- Finally, on the DNS server itself, I do this:

[root@dca2-LinuxES named]# nslookup

Note: nslookup is deprecated and may be removed from future releases.

Consider using the `dig' or `host' programs instead. Run nslookup with

the `-sil[ent]' option to prevent this message from appearing.

> server 192.168.15.10

Default server: 192.168.15.10

Address: 192.168.15.10#53

> test.cciesecurity.com

Server: 192.168.15.10

Address: 192.168.15.10#53

Name: test.cciesecurity.com

Address: 129.174.1.26

>

As you can see, anything outside of the Pix firewall will learn test.cciesecurity.com

as 129.174.1.26 while everything behind the Pix firewall will learn test.cciesecurity.com

as 192.168.192.10. Why? Because the Pix intercepts the DNS reply and modified

the content of the DNS.

Here is the config:

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0

alias (dmz) 192.168.192.10 129.174.1.26 255.255.255.255

static (dmz,outside) 129.174.1.26 192.168.192.10 netmask 255.255.255.255 dns

Easy right?

CCIE Security