Symptom:

You’re using a private subnet. Your servers are on that same private subnet. Outside users can find your servers by name, but inside users can’t, or vice versa.

Problem:

Simple NAT service (the part of your firewall that connects your private subnet to the Internet) has a problem with connections that go from the inside network, through the firewall, and back to the inside network again.

If someone on the outside connects to your public IP address on port 80 (for example), the connection is forwarded to your web server. The web server sees a connection request from some public IP address, and sends the response. The response goes through the router, which changes the source to your public address, so that the browser sees a response from the same address to which it sent the request.

If someone on the inside connects to your public IP address on port 80, the connection is again forwarded to your web server. The web server sees a connection request from an internal address, so it sends the response directly to that address. The client machine receives the response, but not from the address to which it sent the request. The connection fails.

The problem is, your public DNS records can only usefully hold the public address. If you enter the private address there, then people on the outside won’t be able to reach your server.

Solution

There are several solutions available. They are presented here from best to worst, in our opinion.

Two-way NAT Service

The best solution has a variety of names, including “local NAT”, “two-way NAT”, and “source NAT and destination NAT”. With this solution, when the request is forwarded to your web server, the source address is changed to that of your firewall. The web server’s response goes to the firewall, which changes both source and destination addresses, and forwards it to the web browser. The connection works.

Not all NAT servers support this - in fact, most don’t. You may need to consult your documentation or ask your vendor to find out. If it does not, then things get difficult. Some NAT servers that support this:

• at least some Netopia routers
• at least some XSense routers
• some newer Cisco routers
• most software routers

Using a DMZ

If your firewall has a DMZ port, put all your servers on the DMZ subnet. This way, the server’s not on the same subnet as the internal client machines, and the NAT service works normally. Note that this causes problems if your servers need to contact each other using the same (public) addresses.

Cisco DNS Translation

Use a Cisco firewall with a DNS translation function. This way, you put the private address in the DNS record, and the Cisco router translates that address to the appropriate public address as the DNS response packet goes out to the outside world. This approach has a few disadvantages, the biggest of which is that you can’t use an off-site slave (secondary) server, since this feature doesn’t work on zone transfers.

Split Namespace

This is the most common approach when two-way NAT is not available.

Split your DNS into public and private versions. This generally requires two separate DNS servers, though it can be done (with some effort) with just one server. BIND 9’s “views” feature is designed to make this easier.