PIX 515E 6.3 NAT Question

[paulstone80]

Hi,

I'm having some issues trying to get connectivity from the inside to the DMZ on a PIX515 (6.3).

Here's the scenario (diagram attached).

Inside interface IP: 10.44.181.235/23

DMZ interface IP: 172.31.255.254/24

There is a server in the DMZ with an IP of 172.31.255.250.

The DMZ network routes are not to be published. To access the server, clients on the inside network must target an IP on the local subnet, which has been provided as 10.44.181.236, so a static NAT is required.

The internal networks must remain hidden from the server in the DMZ.

I think i'm approaching the NAT all wrong, but not sure what's the correct way to configure it.

Config below:

PIX Version 6.3(5)

interface ethernet0 auto shutdown

interface ethernet1 auto

interface ethernet2 auto

interface ethernet3 auto shutdown

interface ethernet4 auto shutdown

interface ethernet5 auto shutdown

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security50

nameif ethernet3 intf3 security6

nameif ethernet4 intf4 security8

nameif ethernet5 intf5 security10

hostname PIX01

names

access-list acl_dmz_in permit ip any any

access-list acl_dmz_in permit icmp any any

access-list acl_inside_in permit icmp any any

access-list acl_inside_in permit ip any any

pager lines 24

mtu outside 1500

mtu inside 1500

mtu dmz 1500

mtu intf3 1500

mtu intf4 1500

mtu intf5 1500

no ip address outside

ip address inside 10.44.181.235 255.255.254.0

ip address dmz 172.31.255.254 255.255.255.0

no ip address intf3

no ip address intf4

no ip address intf5

ip audit info action alarm

ip audit attack action alarm

no failover

failover timeout 0:00:00

failover poll 15

no failover ip address outside

no failover ip address inside

no failover ip address dmz

no failover ip address intf3

no failover ip address intf4

no failover ip address intf5

pdm history enable

arp timeout 14400

static (dmz,inside) 10.44.181.236 172.31.255.250 netmask 255.255.255.255 0 0

access-group acl_inside_in in interface inside

access-group acl_dmz_in in interface dmz

route inside 0.0.0.0 0.0.0.0 10.44.180.250 1

Thanks,

Paul

[Jouni Forss]

Hi,

The attachements arent currently working on the forums for some reason. I wonder if you can just simply copy a screencapture of the picture and copy/paste it directly to the post/reply.

I guess if you are looking for an option to the above NAT you could consider Policy NAT

access-list DMZ-SERVER-POLICYNAT permit ip host 172.31.255.250 10.44.180.0 255.255.254.0

or

access-list DMZ-SERVER-POLICYNAT permit ip host 172.31.255.250 any

static (dmz,inside) 10.44.181.236 access-list DMZ-SERVER-POLICYNAT

I'm not 100% sure if it will work. Dont remember if the old softwares had their own limitations. Use them very rarely nowadays.

- Jouni

[paulstone80]

Hi Jouni,

Thanks for your feedback, the diagram was really just to illustrate what I wrote in the post.

I got the nat working from inside to dmz, by using:

global (dmz) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (dmz,inside) 10.44.181.236 172.31.255.250 netmask 255.255.255.255 0 0

I can ping 172.31.255.250 and it replies with 10.44.181.236, and I can also ping 10.44.181.236.

I haven't managed to get traffic that's initiated from the dmz to the inside to work yet.

Thanks,

Paul

[Jouni Forss]

Hi,

The configuration above that you bolded will only create a PAT translation for traffic entering from "inside" to "dmz". Traffic to the "dmz" server will be using the "dmz" interface IP address as the PAT address.

To my understanding the Policy NAT configuration I pasted above should work for both directions.

What it should do is:

• When "dmz" host initiates connections to the network 10.44.180.0/23 it will translate to the specified IP address of 10.44.181.236
• In the same way if a host on "inside" network 10.44.180.0/23 initiates connections towards the host address 10.44.181.236 it should forward the traffic to the "dmz" host.
• So it should make it possible to initiate connections from either side. The ACL version (destination addres/network(s) used) will specify for what traffic the Policy NAT applies

Atleast that is how it should work to my understanding. If you happen to try the Policy NAT I would suggest removing the existing NAT.

If it doesnt work possibly check "show xlate" to see if there is some old Xlate still in use that needs to be cleared.

- Jouni

[paulstone80]

Hi Jouni,

I removed all the nat configuration and replaced with the following Policy NAT:

access-list dmz-svr-policynat permit ip host 172.31.255.250 10.44.180.0 255.255.254.0

static (dmz,inside) 10.44.181.236 access-list dmz-svr-policynat 0 0

There is now no connectivity to/from the server in the DMZ (172.31.255.250).

I issued a clear xlate after the commands were added, and show xlate shows 0 translations in use.

Thanks,

Paul

[Jouni Forss]

Hi,

Can you share the complete current configuration of the PIX.

Too bad because of the old software we cant use the "packet-tracer" command to confirm the operation of the NAT.

- Jouni

[paulstone80]

Hi Journi,

I'll post the config when I'm back in the office later.

I'm only configuring this as a proof of concept for something and don't have anything newer lying around. Did the PIX support packet tracer? I might b able to update the ios if needed.

Thanks,

Paul

Sent from Cisco Technical Support Android App

[Jouni Forss]

Hi,

You would have to have the PIX at software level 7.2(1) at minimum to get support for this command

Link to command reference:

http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/p_72.html#wp1724426

Between 6.x and 7.x software there were changes to the configurations formats. Though I think they were a big advantage as it moved the configurations of PIX more towards the Cisco IOS devices.

I guess the only real obstacle with software update might be either the Flash memory or RAM memory amount. But since you dont have any big configurations I dont think the RAM is going to be an issue.

To be honest the software and PIX firewall are so old already that I have forgotten some of their limitations.

- Jouni

[paulstone80]

Hi Journi,

I'll explore the upgrade paths and see if we can update the IOS to 7.2 onwards. I'm not sure we would be able to get hold of the IOS anymore as I think we no longer have support on this PIX, it was just EOL and kept for testing.

Config below:

PIX Version 6.3(5)

interface ethernet0 auto shutdown

interface ethernet1 auto

interface ethernet2 auto

interface ethernet3 auto shutdown

interface ethernet4 auto shutdown

interface ethernet5 auto shutdown

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security50

nameif ethernet3 intf3 security6

nameif ethernet4 intf4 security8

nameif ethernet5 intf5 security10

enable password encrypted

passwd encrypted

hostname PIX01

domain-name test.com

fixup protocol dns maximum-length 512

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol tftp 69

names

access-list acl_dmz_in permit ip any any

access-list acl_dmz_in permit icmp any any

access-list acl_dmz_in permit icmp any any echo-reply

access-list acl_inside_in permit icmp any any

access-list acl_inside_in permit ip any any

access-list dmz-svr-policynat permit ip host 172.31.255.250 10.44.180.0 255.255.254.0

pager lines 24

mtu outside 1500

mtu inside 1500

mtu dmz 1500

mtu intf3 1500

mtu intf4 1500

mtu intf5 1500

no ip address outside

ip address inside 10.44.181.235 255.255.254.0

ip address dmz 172.31.255.254 255.255.255.0

no ip address intf3

no ip address intf4

no ip address intf5

ip audit info action alarm

ip audit attack action alarm

no failover

failover timeout 0:00:00

failover poll 15

no failover ip address outside

no failover ip address inside

no failover ip address dmz

no failover ip address intf3

no failover ip address intf4

no failover ip address intf5

pdm history enable

arp timeout 14400

static (dmz,inside) 10.44.181.236 access-list dmz-svr-policynat 0 0

access-group acl_inside_in in interface inside

access-group acl_dmz_in in interface dmz

route inside 0.0.0.0 0.0.0.0 10.44.180.250 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout sip-disconnect 0:02:00 sip-invite 0:03:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server TACACS+ max-failed-attempts 3

aaa-server TACACS+ deadtime 10

aaa-server RADIUS protocol radius

aaa-server RADIUS max-failed-attempts 3

aaa-server RADIUS deadtime 10

aaa-server LOCAL protocol local

http server enable

http 10.44.180.48 255.255.255.255 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

telnet 10.44.180.48 255.255.255.255 inside

telnet 10.44.180.0 255.255.254.0 inside

telnet timeout 5

ssh timeout 5

console timeout 0

username password encrypted privilege 15

terminal width 80

Cryptochecksum:4d93f63cd27e8a45ab1ab29e9b388791

: end

Thanks,

Paul   

[paulstone80]

Hi Journi,

I figured this out now

The reason it was not working with just the policy-nat statement was because there was no translation from dmz back to inside. It worked with the inside PAT configured because traffic initiated from the inside was seen with a source of 172.31.255.254 (dmz interface), but with the PAT removed there was no 172.31.255.xxx address for the return traffic to target.

I have setup some static translations for servers on the inside that I need to target from the dmz, and it's all working ok now.

static (dmz,inside) 10.44.181.236 172.31.255.250 netmask 255.255.255.255 0 0

static (inside,dmz) 172.31.255.150 10.44.180.48 netmask 255.255.255.255 0 0

static (inside,dmz) 172.31.255.160 10.44.180.54 netmask 255.255.255.255 0 0

static (inside,dmz) 172.31.255.100 10.44.132.1 netmask 255.255.255.255 0 0

Thanks for your help with this.

Paul