NATed IP issue

i faced this issue more than one time during my career and i'd like to have an explanation about it now.

It's about NATing, we have local network that connected to a Firewall which also has DMZ and internet connected to.

assume local network ip range is 192.168.2.0/24, DMZ is 192.168.3.0/24 .

a server in DMZ zone is NATed to x.x.x.x
The problem is, a client in local network, cannot ping/telnet/ftp (all sorts of communication) x.x.x.x while it can communicate 192.168.3.0/24 network.
I mean there is no connectivity with NATed IP while the local ip is fine! Your help is appreciated.

It sounds like you also need a NAT translation rule on the inside part of the network that translates the request destined for the public IP back to the internal IP address of the server on the DMZ.

Alans,

I've got a few questions regarding the setup.

You mentioned that the server in the DMZ is natted to xxx.xxx.xxx.xxx. This should only happen for the public , where as you as an internal client should hit the server using the 192.168.3.x IP address - correct ?

Assuming my assumption is correct, then it surely does seem like nat issue on the firewall's side. Is this a Cisco ASA or PIX Firewall ?

Generally, you won't want NAT for the communication between the 192.168.2.x (LAN) and 192.168.3.x (DMZ) network, but a series of access lists to restrict the necessary traffic between them.

Here's a sample configuration to achieve this:

Disable NAT for DMZ-->Inside Network
static (dmz,inside) 192.168.3.0 192.168.3.0 netmask 255.255.255.0

Access lists for DMZ Network--> LAN
access-list dmz-in remark ==[ACL for MAIL SRV]==
access-list dmz-in extended permit ip host 192.168.3.5 192.168.2.0 255.255.255.0

The above rule allows all communication from the dmz host 192.168.3.5 to the LAN network - its not restrictive at all, and only serves as an example.

Access lists for Inside Network
access-list inside-in remark ==[ACL for DMZ-SRV-DATA]==
access-list inside-in extended permit tcp 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0 object-group inside-to-dmz-data-tcp (using object groups here - not shown)



Each access list is applied to the relevant interface.


Another action you can take to help you figure out where the problem is, is to enable logging on to your PC, run a syslog service and enter the following commands to your ASA/PIX Firewall:


logging enable
logging console debugging
logging monitor debugging
logging buffered debugging
logging trap debugging
logging host inside 192.168.2.x (Your PC)


This will provide a clear insight of what's happening and where and why packets are being dropped.

Let us know how it went!

Good luck.

You mentioned that the server in the DMZ is natted to xxx.xxx.xxx.xxx. This should only happen for the public , where as you as an internal client should hit the server using the 192.168.3.x IP address - correct ?

Actually we want to be able to hit the servers public IP xx.xx.xx.xx

We already can hit them using their DMZ IP but we can't hit them using their NATed public IP.

Thanks Chris.

is there anyway to NAT destination IP?
So when someone in local network tries to connect to xx.xx.xx.xx
this xx.xx.xx.xx will be changed to DMZ local IP and then we can communicate with servers.

is there anyway to NAT destination IP?
So when someone in local network tries to connect to xx.xx.xx.xx
this xx.xx.xx.xx will be changed to DMZ local IP and then we can communicate with servers.

Yes there is, Assuming here your using either ASA or Pix as Chris mentioned, not a none Cisco firewall. You can do it like this:

[code:1]static (dmz,inside) x.x.x.x 192.168.3.x netmask 255.255.255.255 [/code:1]

Replace 192.168.3.x with your server's private IP. Assuming also here that all ACLs (if any) are configured correctly.

If this doesn't work, Then can outside hosts (internet) hit the x.x.x.x IP ? If NOT, then it would help us if you post your config.