source NAT bi-directional configuration confirmation needed

jkrawczyk · ‎10-14-2009

Hi,

I have a need to build a NAT policy to handle bidirectional communications between a host behind my DMZ and an internal host. Once an hour, the host behind my DMZ (207.91.23.64) initializes a connction to an inside device. Likelise, whenever there is activity on my inside device (inside local:172.31.45.20 / DMZ Global 192.168.10.160) this will provoke a communication to the native IP of the host behind the DMZ (207.91.23.64). ALl is working fine now but I have a need to source translate the source)

There is an .INI file on the inside device containing the native IP of the host behind my DMZ, and I need to change this value to 172.31.48.51. However, I can 't accmplish this in one day so I'm trying to figure out a way to facilitate both native and NAT on the source DMZ host. (note: I have static routes for the Native IP back to my DMZ. The NAT IP of 172.31.48.51 is in my routing table)

I've come up with this configuration and from the looks of it, testing with sniffer and packet-tracer this sees to be working. However, I'm being told that data is not arriving into DMZ host 207.91.23.64. Please check the below and tell me if this makes sense.

(Addresses have been changed to protect the innocent)

Regards

jeff

To handle source translation at PIX-DMZ going to inside interface when session is initiated from the lower level interface.

global (inside) 101 172.31.48.64 netmask 255.255.255.255

nat (DMZ) 101 access-list NAT_DMZ_TO_INSIDE outside

access-list NAT_DMZ_TO_INSIDE extended permit ip 207.91.23.0 255.255.255.0 any

To handle source translation at the PIX-inside going to DMZ interface when session is initiated from the higher level interface.

static (inside,DMZ) 172.31.48.51 207.91.23.64 netmask 255.255.255.255

static (inside,DMZ) 172.31.45.0 172.31.45.0 netmask 255.255.255.0

static (inside,DMZ) 192.168.10.160 172.31.45.20 netmask 255.255.255.255

Jon Marshall · ‎10-14-2009

Jeff

Think you may need to explain this a little better.

You have multiple NAT statements here and i can't really tell which is designed to do what ie.

static (inside,DMZ) 192.168.10.160 172.31.45.20 netmask 255.255.255.255

this will translate 172.31.45.20 to 192.168.10.160 as the packet goes from inside to DMZ

static (inside,DMZ) 172.31.45.0 172.31.45.0 netmask 255.255.255.0

this will leave untranslated the source address of all packets on the inside with an address of 172.31.45.x as they travel to the dmz

static (inside,DMZ) 172.31.48.51 207.91.23.64 netmask 255.255.255.255

this translates the source IP of packets coming from 207.91.23.64 on the inside to a new IP of 172.31.48.51. But 207.91.23.64 isn't on the inside ??

Please could you list out exactly what you want to happen ie.

packet direction, original IP and Natted IP whether that is source or destination IP.

Jon

jkrawczyk · ‎10-14-2009

Hi Jon,

first off

static (inside,DMZ) 172.31.48.51 207.91.23.64 netmask 255.255.255.255

This s/b (DMZ,inside) since this public IP is behind the DMZ interface.

Let me try to explain my case in verbiage. Our contracted payroll service is behind our DMZ. In this example their payrill time clock poller IP is 207.91.23.64. They hit my DMZ interface and I destination NAT 192.168.10.160 into my inside local IP of 172.31.48.51. The poll interval is every 60 minutes. The poll just checks to see if the time clock is there and online.

From the inside:

When employees punch, the time clock initiates a tcp connection to native IP 207.91.23.64 IP. Each time clock has a .INI file that contains the poller server IP of 207.91.23.64. I have static routes from this inside remote office bringing the src: 172.31.45.20 dst: 207.91.23.64 back to my PIX.

Currently this works fine.

Now I want to masquerade 207.91.23.64 into 172.31.48.51 when the poller initiates form the DMZ, but being that I have a ton of time clocks on the inside, when I ask the payroll service vendor to push a new .INI to the time clocks, the old and new configurations will work so that I can systematically change the .INI files over the course of a few days.

whew, and confusing..!

Jeff