The most common NAT problem

AKA "why can't I reach my server on its external IP from an internal IP?"

As a Networking ZA/PE, I see a rather significant number of NAT-related (network address translation) questions whose problems can all be attributed to a single issue.  

Typically the scenario involves an internal network that is connected to the internet via some sort of NAT device. The internal network contains a server. The server hosts some arbitrary number of services. No internal client can connect to these services via an external IP that has been forwarded (via some sort of DNAT) to the server. This issue can even affect client processes on the server itself if those processes attempt to connect to the server via its externally forwarded IP.

To resolve this problem, an understanding of the underlying cause is helpful.

A NAT device exists with an external IP of 1.2.3.4. It connects an internal network with the range 10.1.2.x to the internet via SNAT with an internal IP of 10.1.2.1. A server exists on the internal network at IP 10.1.2.10. All appropriate inbound connections to 1.2.3.4 are forwarded (via DNAT) to 10.1.2.10. A client with IP 10.1.2.150 attempts to access a service on the server via the externally forwarded IP address of 1.2.3.4 (typically, the client obtains the external IP through its name resolution/resolver engine which often includes configured DNS servers and a local hosts file). Here is the communication breakdown:

The client (10.1.2.150) sends a packet to the server via the externally forwarded IP (1.2.3.4)

The NAT device translates the destination IP from 1.2.3.4 to 10.1.2.10 and forwards the packet. The source address of the client (10.1.2.150) remains the same.

The server (10.1.2.10) receives the packet with a source of the client (10.1.2.150).

The server (10.1.2.10) sends a response packet directly to the client (10.1.2.150).

The client, having sent a request to the server at 1.2.3.4, does not expect a response from the server at 10.1.2.10, and the replies are discarded.

Given an understanding of the above, there are two obvious methods to resolve this problem.

Reconfigure the resolver:

The clients will not experience this problem if they can be configured to access the server directly on its internal IP. Split-DNS is a possible solution. Using split-DNS, the DNS servers responsible for address (A) records that correspond to the server reply with the external IP (1.2.3.4) when contacted by external clients, and reply with the internal IP (10.1.2.10) when contacted by internal clients. This is typically the preferred solution, if it can be implemented.

Another solution (which is not generally scalable) using the resolver is to add/push entries for the local IP of the server to the local hosts files on all local machines (probably \windows\system32\drivers\etc\hosts in windows,  /etc/hosts in unix/linux/os x)

Reconfigure the NAT device:

Be forewarned, this may not be possible for all NAT devices (particularly appliances). Since the original client connection travels through the NAT device (remember, the client is accessing the server through the external IP on the NAT device), the NAT device should be reconfigured to source-NAT (SNAT) the packets from the client so that they appear to originate from the NAT device (packets flowing through the NAT device from 10.1.2.x are re-written so as to appear to originate from 10.1.2.1).

Of course, this requires a stateful NAT device which will keep track of SNATted connections so that the replies from the server are handled correctly, but generally any modern NAT device that supports SNAT should satisfy this requirement.  Implementing an SNAT solution does have the unfortunate side-effect of preventing meaningful client address information from appearing in the server logs, although client connection information can be collected on the NAT device (if supported), and later unified with the server logs.

Relevant questions:

Nat U-Turn - Netscreen N50 - A reminder about false positives (a service on the NAT device may pollute test results when testing on the port associated with such a service)

Connection forwarding with iptables - An interesting instance in which the situation occurs on the public internet.