NAT Issue on PIX

[daniel.bowen]

Hi Everyone,

I have three devices, 2 on the Inside network and 1 on the DMZ that need to talk to each other for server replication. I tried creating a NAT pool and a static translation for bi-directional traffic but I could not get it working.

My config was as follows;

global (dmz) 1 10.1.0.190-10.1.0.200 netmask 255.255.255.0

global (dmz) 1 10.1.0.201 netmask 255.255.255.0

nat (inside) 1 10.0.0.0 255.255.255.0 0 0

nat (dmz) 1 10.1.0.0 255.255.255.0 0 0

static (inside,dmz) 10.1.0.27 10.0.0.209 netmask 255.255.255.255 0 0

10.1.0.27 was the address of the server on the DMZ

10.0.0.209 was the free address on the Inside that I wanted the DMZ server translated to

10.0.0.52 was the address of the server on the Inside.

It did work however, when I used the following command.

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.255.255.0

Any help would be great in troubleshooting this problem.

Many thanks,

Dan

PS - ACLs wernt the issue as I put in a permit any any on both interfaces to rule it out.

[a.kiprawih]

The "static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.255.255.0" line was correct. That's why it allows DMZ to access Inside successfully.

Basically, you mapped and allow the two segments to access each other freely using respective original IPs.

You can use this method, but apply access-list (ACL) on both inside and DMZ interfaces to restrict access from unwanted devices on each side from flowing across. Allow only specific IP/host via specific tcp/udp port(s).

Add/create new ACL and bind them to Inside and DMZ interfaces. Example here is to allow TCP/FTP services. Change according to your desired tcp/udp port:

1. For inside interface/segment:

access-list inside-access-out permit icmp any any --> for testing purposes only. Use this to test inside-DMZ server communication. Remove after used.

access-list inside-access-out permit tcp host 10.0.0.52 host 10.1.0.27 eq 21 --> permit only 10.0.0.52 to access DMZ's 10.1.0.27

access-list inside-access-out deny ip any 10.1.0.0 255.255.255.0 --> deny other inside's hosts to access DMZ network/segment

access-list inside-access-out permit ip any any --> permit all inside hosts to access internet/other segment (if any)

access-group inside-access-out in interface inside --> bind acl to inside interface

2. For DMZ interface/segment:

access-list DMZ-access-out permit icmp any any --> for testing purposes only. Use this to test DMZ-inside server communication. Remove after used.

access-list DMZ-access-out permit tcp host 10.1.0.27 host 10.0.0.52 eq 21 --> permit DMZ's 10.1.0.27 to access inside's 10.0.0.52

access-list DMZ-access-out deny ip any 10.0.0.0 255.255.255.0 --> deny other DMZ's hosts to access inside network/segment

access-list DMZ-access-out permit ip any any --> permit all DMZ hosts to access internet/other segment (if any)

access-group DMZ-access-out in interface inside --> bind acl to DMZ interface

Otherwise, use the previous config line with condition you change the IP of 10.1.0.27 to another unused/free IP. It was not working mainly because the IP that you used here has already been assigned to your server, and you are supposed (must) to use any unassigned IP to make it work. The rule is, used any free IP for the static mapping. Exammple:

Original config line: static (inside,dmz) 10.1.0.27 10.0.0.209 netmask 255.255.255.255 0 0

New: static (inside,dmz) 10.1.0.100 10.0.0.209 netmask 255.255.255.255 0 0 ----> assuming 10.1.0.100 is free/unused IP

This will allow your 10.1.0.27 to access inside server running on 10.0.0.209 using virtual IP of 10.1.0.100. Logically, both 10.1.0.27 and 10.1.0.100 will looks like sitting in the same segment.

HTH

AK

[daniel.bowen]

Thanks for your post.

Can I just comfirm that in your example, both addresses in the static command should be free addresses? For example,

static (inside,dmz) (free DMZ address) (free inside address) netmask 255.255.255.255 0 0

Cheers,

Dan

[daniel.bowen]

Would the following configuration work (bi-directional NAT)?

Static (inside,dmz) 10.1.0.100 10.0.0.27 ? (10.1.0.100 must be free or replaced with a free address on DMZ LAN range)

Static (dmz,inside) 10.0.0.100 10.1.0.52 ? (10.0.0.100 must be free or replaced with a free address on inside LAN range)

Many thanks,

Dan

[shomar]

Hi Dan,

let me see if I get you right, you have a server on the inside (lets assume its ip address 10.10.1.1) and a server on the DMZ (10.10.2.1) and these two servers need to talk to each other, is that correct?

if so you can do it using a static command only and access list on the DMZ and the inside interfaces

static (inside,dmz) 10.10.2.2 10.10.1.1

**10.10.2.2 is a free ip address on the DMZ

access-list dmz-inside permit ip 10.10.2.1 10.10.2.2

access-group dmz-inside in interface dmz

and if you have an access-list on the inside interface you need to open a rule to permit traffic (do nothing if you don't have an access-list applied to the inside interface)

access-list inside-dmz permit ip 10.10.1.1 10.10.2.2

i hope that this helps :)

regards,

Shadi`

[daniel.bowen]

Thanks very much for your answer.

Can I just confirm that for traffic initiated from the inside server, do I need to configure a NAT and Global command so that the Inside server can NAT to "an address" on the DMZ?

From my understanding, the command you entered was only for the DMZ server translating to an Inside address and not the other way around?

Am I right in what I am saying?

Cheers again,

Dan

[a.kiprawih]

Q: Would the following configuration work (bi-directional NAT)?

Static (inside,dmz) 10.1.0.100 10.0.0.27 ? (10.1.0.100 must be free or replaced with a free address on DMZ LAN range)

Static (dmz,inside) 10.0.0.100 10.1.0.52 ? (10.0.0.100 must be free or replaced with a free address on inside LAN range)

A: No, the 2nd static config line is sufficient. Ignore the 1st line.

The "static (inside,dmz) netmask 255.255.255.0" means you are allowing inside segment to access DMZ via original IP, as well as permitting the whole DMZ segment to access inside via their original IP.

You only need both your static commands if you assigned them with same security level, and wanted to allow bi-directional traffic. The condition is you need to configure access between same security level interface.

same-security-traffic permit inter-interface

http://www.cisco.com/en/US/products/ps6120/products_command_reference_chapter09186a00805fb9eb.html#wp1250643

HTH

AK

[Fernando_Meza]

Hi .. the most common way of configuring this type of access is by a static NAT and appropriate entries on the access control lists. You don't need anything else .. so if you want the inside host to appear as is on the DMZ side then you need

static (inside,dmz) 10.0.0.52 10.0.0.52 netmask 255.255.255.255

access-list DMZ_Inside extended permit ip host 10.1.0.27 host 10.0.0.52

access-group DMZ_Inside in interface dmz

If you need the inside host to appear as 10.1.0.X on the dmz segment the you need

static (inside,dmz) 10.1.0.X 10.0.0.52 netmask 255.255.255.255 where X is an available address on the dmz segment

access-list DMZ_Inside extended permit ip host 10.1.0.27 host 10.1.0.X

access-group DMZ_Inside in interface dmz

I hope it helps .. please rate if it it does !!!

[daniel.bowen]

Thanks very much.

I still dont understand how I get the DMZ to talk back to the Inside host though?

From what you have put, I think that takes care of the Inside to DMZ translation, but I need both devices to be able to initiate comms so need the translation to go both ways.

it seems that the two examples above both work for the Inside appearing on the DMZ, but not the DMZ address translating to an Inside address.

many thanks,

Dan

[Fernando_Meza]

Hi .. in tat case you need to use another static as below.

static (dmz,inside) x.x.x.x y.y.y.y netmask 255.255.255.255

where x.x.x.x is the IP address which will be seen on the inside network

and y.y.y.y is the real IP address of the server on the DMZ.

The access-list applied to the inside interface needs to allow that access as

permit tcp any host x.x.x.x eq

also access list applied to the DMZ interface need to allow the access to the inside hosts ( real IP addresses or NATed if you are using it )

I hope it helps .. please rate it if it does !!!