Cisco PIX 515E DMZ NAT Question, Please help

Hello,

I hope someone can help me.

We recently acquired a new business partner that is connected by a
frame-relay to our DMZ. Here is my problem. The router (frame-relay)
in the DMZ NATS from their public address to our private address in
the DMZ to 172.16.10.90 I want to take the source address if
172.16.10.90 and NAT it back to our inside network to a ftp server. I
do not have a physical device in the DMZ for this address
(172.16.10.90) and I haven't been able pass the traffic back from the
DMZ. I have access list allowing traffic from the DMZ 172.16.10.90 to
inside 10.10.2.90 via ftp. We currently have our Web server and a mail
gateway in the DMZ, I would like to accomplish this without changing
the global or jeopardize any of the DMZ rules that are currently in
place.

Thank you for you help

 

:We recently acquired a new business partner that is connected by a
:frame-relay to our DMZ. Here is my problem. The router (frame-relay)
:in the DMZ NATS from their public address to our private address in
:the DMZ to 172.16.10.90 I want to take the source address if
:172.16.10.90 and NAT it back to our inside network to a ftp server. I
:do not have a physical device in the DMZ for this address
172.16.10.90) and I haven't been able pass the traffic back from the
MZ. I have access list allowing traffic from the DMZ 172.16.10.90 to
:inside 10.10.2.90 via ftp. We currently have our Web server and a mail
:gateway in the DMZ, I would like to accomplish this without changing
:the global or jeopardize any of the DMZ rules that are currently in
lace.

Sorry, I'm confused by your question. Let me see if I have this
straight:

You have a PIX with inside network 10.10.2/24.

You have a DMZ with network 172.16.10/24 or (my suspicion) 172.16/24.

You have a web server and smtp gateway on the DMZ.

You have a FR router on the DMZ that is passing you traffic with
a source IP of 172.16.10.90. Question: are the devices on the other
side of the FR able to access the web server and smtp gateway without
difficulty now?

You want the traffic from the FR to be able to do something additional
that involves the inside interface and the IP 10.10.2.90, but I'm
having trouble making out what exactly it is ?? I -think- what
you are wanting the FR traffic to be able to access an inside FTP
server that has IP address 10.10.2.90, but you have confused me
with your wording about source addresses and "NAT it back".


If I have understood correctly what you want to do, then the
normal way of accomplishing it would not involve a 'global' statement
but rather a 'static' statement. You could use either of

static (inside, dmz) 10.10.2.90 10.10.2.90 netmask 255.255.255.255

or

static (inside, dmz) 172.16.10.X 10.10.2.90 netmask 255.255.255.255 dns

where X is an otherwise unused IP in the 172.16.10 range.

The difference between the two is only in what IP address the FR
traffic uses to address the ftp server. You could use pretty much any
IP address in the first location, as long as the router at the
remote partner knows to route along the FR to that IP. The 'dns'
modifier will cause DNS queries that pass from the dmz interface
to the inside interface to automatically be examined and have
the IP address 10.10.2.90 modified in the reply packet to whatever
IP you have on the left in the static statement.


Modern PIX software provides other ways of handling the situation,
including:

access-list noNatFR permit ip 10.10.2.90 172.16.10.90
nat (inside) 0 access-list noNatFR

This tells the PIX to leave IP address 10.10.2.90 alone when outgoing
packets from 10.10.2.90 are addressed to 172.16.10.90, and
conversely to leave the destination IP 10.10.2.90 alone when
inbound traffic with a source IP of 172.16.10.90 is going to 10.10.2.90.
This particular form also has the important side effect of not
requiring that there be a 'static' command to allow traffic from
172.16.10.90 to go to the higher security address 10.10.2.90.


If there is some particular reason why 10.10.2.90 must show up
with a different IP to the other hosts on the DMZ than it shows up to
for 172.16.10.90, then with newer PIX releases you can use policy
static, but I don't have time at the moment to figure out the
exact syntax. See

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/s.htm#wp1026694

for more information.