topic Re: Nat issue with Pix 515E in Network Security

Nat issue with Pix 515E

bradford66 — Mon, 11 Mar 2019 13:12:56 GMT

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.

Re: Nat issue with Pix 515E

andrew.prince — Mon, 14 Jul 2008 14:11:05 GMT

try adding:-

static (dmz,inside) 66.x.x.x 172.16.3.4 netmask 255.255.255.255

HTH.

Re: Nat issue with Pix 515E

dhananjoy chowdhury — Mon, 14 Jul 2008 15:57:17 GMT

did it work with the static statement ?

Re: Nat issue with Pix 515E

bradford66 — Mon, 14 Jul 2008 16:46:15 GMT

Nope,

telnet 88

Connecting To ...Could not open connection to the host,on port 88: Connect failed

The funny part is that when I did a sho conn | grep , where the ip was of the webserver and host machine on the inside interface, and nothing came back.

Here is what I added:

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

Re: Nat issue with Pix 515E

bradford66 — Tue, 15 Jul 2008 16:06:57 GMT

any takers? That last static statement didn't work.

Re: Nat issue with Pix 515E

andrew.prince — Tue, 15 Jul 2008 17:25:15 GMT

can you post your 515e sanitized config please?

Re: Nat issue with Pix 515E

bradford66 — Tue, 15 Jul 2008 18:39:05 GMT

Here is the sanitized 515E config. I have removed the pdm entries, and have removed the object-group definitions:

I have attached a .txt file since the lines of the config were greater than 4000.

Re: Nat issue with Pix 515E

andrew.prince — Tue, 15 Jul 2008 21:16:46 GMT

OK - seen.

So what Exactly is it you are trying to do, as currently you are very busy with your 515E right now?!

Re: Nat issue with Pix 515E

bradford66 — Tue, 15 Jul 2008 21:33:35 GMT

I'm trying to load a web page from a host on one pix interface (inside) from a webserver on another pix interface (dmz). This webserver has a static mapping to a public ip address, and a site on this webserver is mapped to this public ip address using a DNS a record. When I try to load the url that maps to the public ip address of the webserver, it times out. The http connection times out from any host located on the dmz interface or the inside interface. I can not load the page from the webserver itself when using the URL that maps to the public ip address. I want to know why this is happening and how to fix it. I think the connection is failing due to a missing entry in my nat/static config lines. Here is the output of the sho conn | grep (ip of webserver or host)after I tried to telnet to the listening port of the webserver:

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

The problem is that the web server ISN'T responding to ip address (208.x.x.x) that requested the http connection, but instead responding to the private IP address of the requesting host (172.16.4.8).

This all came about because a programmer brought it to my attention that one webserver couldn't open up a page on a different webserver if the URL used the DNS hostname A record.

PS: I described all of this in my initial posting. Is there something wrong with the initial posting?

Re: Nat issue with Pix 515E

bradford66 — Wed, 16 Jul 2008 22:31:59 GMT

You don't have anything for me to go on? I thought this would be an easy issue. Anybody?

Re: Nat issue with Pix 515E

cisco24x7 — Thu, 17 Jul 2008 02:12:39 GMT

do this and it will work:

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

alias (inside)

alias (dmz)

clear xlate

After that, hosts on the "inside" and "dmz"

will be able to access the http://www.example.com which resolved to

66.x.x.x but the Pix will intercept the dns-reply querry and doctor it back to 172.16.3.4.

This is based on the assumption that your ISP

is hosting your DNS server or that your DNS

server is somewhere outside of the firewall.

Easy right?

Re: Nat issue with Pix 515E

bradford66 — Thu, 17 Jul 2008 19:27:04 GMT

The alias entries returned back with this error:

Not enough arguments.

Usage: [no] alias [<(if_name)>] []

Should the syntax be?:

alias (inside) 172.16.3.4 63.x.x.x 255.255.255.255

alias (dmz) 172.16.3.4 63.x.x.x 255.255.255.255

I'm probably wrong on what means and what means. What is the right syntax?

Re: Nat issue with Pix 515E

bradford66 — Thu, 17 Jul 2008 21:52:02 GMT

Ok, the problem is now partially solved. After looking at the command reference for 6.3, I added these two entries to my pix config:

alias (dmz) 172.16.3.4 66.x.x.x 255.255.255.255

alias (inside) 172.16.3.4 66.x.x.x 255.255.255.255

For hosts on the dmz interface, I can now load www.myexample.com just fine, and the show conn output looks like this:

TCP out 172.16.3.4(66.x.x.x):80 in 172.16.3.30:2342 idle 0:01:04 Bytes 0 flags A

For hosts on the inside interface, www.myexample.com still times out and the show conn output looks like this:

TCP out 172.16.4.8:2524 in 172.16.3.4:80 idle 0:00:15 Bytes 0 flags aB

TCP out 172.16.3.4(66.x.x.x):80 in 172.16.4.8:2524 idle 0:00:15 Bytes 0 flags saA

I don't' get why this is failing now. 172.16.4.8 requests a http connection from www.myexample.com, and the dip is translated to 172.16.3.4. Then when www.myexample.com responds, the public ip address is swapped with the private one (e.g. TCP out 172.16.3.4(66.x.x.x):80). The source port for the requesting host is the same on both sides of the connection, so why is this failing?

Re: Nat issue with Pix 515E

cisco24x7 — Thu, 17 Jul 2008 22:50:01 GMT

This will work for you:

alias(inside) 66.x.x.x 172.16.3.4 255.255.255.255

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

alias (dmz) 172.16.3.4 66.x.x.x 255.255.255.255

Now both hosts on the DMZ and inside can access

http://www.example.com which is translated to

66.x.x.x

Re: Nat issue with Pix 515E

bradford66 — Fri, 18 Jul 2008 17:59:12 GMT

It still isn't working. The inside interface isn't intercepting the dns-reply for 66.x.x.x and transforming it to 172.16.3.4.

here's the sho conn for the inside host initiating the http connection.

TCP out 172.16.4.8:3956 in 66.x.x.x:80 idle 0:01:46 Bytes 0 flags SaAB

Here's my aliases:

alias (dmz) 172.16.3.4 66.x.x.x 255.255.255.255

alias (inside) 66.x.x.x 172.16.3.4 255.255.255.255

Static:

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

when I use nslookup on my inside host, it should swap the 66.x.x.x with 172.16.3.4. Here's the latest output for www.myexample.com')">http://www.myexample.com:

Default Server: vnsc-bak.sys.gtei.net

Address: 4.2.2.2

> set type=all

> http://www.myexample.com

Server: vnsc-bak.sys.gtei.net

Address: 4.2.2.2

Non-authoritative answer:

www.myexample.com internet address = 66.x.x.x

what gives?

Re: Nat issue with Pix 515E

bradford66 — Tue, 22 Jul 2008 17:33:03 GMT

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?

Re: Nat issue with Pix 515E

cisco24x7 — Thu, 24 Jul 2008 01:00:35 GMT

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