Public Servers NATing?

My question in short: "Which is better? To assign private IP addresses to public servers and do NATing, or to assign public IP addresses to them without the need for NATing"?

The NATing can be useful for users to allow many users to access the Internet using a small pool of public IP addresses (can be just one IP). This is called PATing also.

I am discussing NATing the IP addresses of public servers such as: DNS, Web servers, Email servers, etc. NATing of public servers should be done using static NAT. So, someone can think of eliminating the NATing process and assigning the public IPs on the servers. Here is a comparison of the two scenarios.

With NATing:

+ The public IP addresses are managed and used on the gateway as desrired.

+ The public IPs are preserved and can be used as efficiently as possible.

- A little overhead will be added on the gateway router / firewall.

- The private IP addresses may be exposed to the outside (for example, in emails headers, or in a misconfiguration).

- We need to create two views for the DNS servers (private for internal users and public for external users).

Without NATing:

- Assigning more than one IP address for a server should be done on the server itself. The application/service should be aware to use all the IPs for the outgoing traffic.

- The public IP addresses are assigned to the servers directly. So, some IPs may be wasted (not used) such as the case of cluster and VIP.

+ The routing/forwarding will be a bit faster as we are not doing NATing (less overhead).

+ All communications will be done using the public IPs.

+ One DNS view will be enough as we are using the same IPs from internal and external.

Any other ideas/suggestions??

Solution 1:

I'm strongly in favor of the NAT approach. As you say conserves public IP address more effectively, and additionally, you don't expose any services to the outside world until you are intentionally ready to do so — you can make assigning a public address linked with your process for approving a firewall ruleset for a given server.

With the Cisco router we're using, at least, the overhead of NAT is negligible compared to the overhead of using the firewall module at all, and since we're already using that, the performance issue isn't a big deal. It also has an optional automatic rewrite rule so that accesses to the external addresses from internal nets are rewritten to the internal address by "magic", thus avoiding the need for split DNS. (We use a .int subdomain for the internal 10.x addresses).

Solution 2:

OK, this was asked a couple of days ago, and there is already an accepted answer.

Keep It Simple Sir. Generally speaking, one public Internet server should have one public IP address.

With NATing: The public IPs are preserved and can be used as efficiently as possible.

IMHO a bit of a red heering. OK, it's true, but v4 IP's are not that scarce, and besides, it's not your sole responsibility to fix the Internet "address shortage".

Without NATing: Assigning more than one IP address for a server should be done on the server itself. The application/service should be aware to use all the IPs for the outgoing traffic.

Why assign multiple IP addresses? If you have multiple services, use DNS CNAMES and IP port ranges to split things up. If you need to conserve IPs when doing floating IPs (VIPs) you can often use private IPs for the machine-specific IP, and just use public IPs for the actual VIP that you publicize Internet applications on.

As I see it, it mainly boils down to:

• With NAT, you gain a little bit of security through obscurity. This holds little value.

• Without NAT, you follow the design intentions of the Internet. Common troubleshooting tools like Ping etc work as expected. Sysadmins on other sites & upstream ISPs can better work together with you to fix problems.

My clear preference is one public IP per server, unless there is some local constraint that forces me to do otherwise.

Solution 3:

@mattdm : Using NAT without a firewall alongside is not very smart (aka "security" through obscurity).

When using NAT, you do not need an internal view for DNS if you use NAT reflexion (or hairpin NAT).

As for your question, I'd say it's a matter of preference.

• Do you have plans for the IP addresses you'd save?

• Do you have multiple machines that provide the same services which need to be accessible from the outside using the standard ports?

• How important do you want your router to be as a gateway?

I would assume answering these questions will help you determine which path to follow. Just remember that either way will not matter that much and will not keep you from using the other strategy later on.

Solution 4:

I've had issues with the "Without Natting" scenario.

Your internal clients may end up trying to connect to internal servers with their public IPs. This can cause traffic to be routed from the internal network to the router and then back into the network - or may fail entirely depending on how your routing is configured.

You need to be careful that internal clients always get the internal IP, otherwise you lose the "routing/forwarding will be a bit faster" benefit.

EDIT I may have explained the above poorly. The internal lan had private IP's. When deciding to make some servers public facing, they were assigned both private and public IP's and the router/firewall set to allow traffic for these public IPs through.

The issues occured with internal clients on private IPs trying to access the internal servers via public IPs. It was several years ago and I think the DNS and/or routing was misconfigured - so for this network, internal clients starting off accessing one server on an internal IP.

When the first server tried to direct the user to another server, there was some confusion over internal/external names and IPs. Often, the server would point the internal client to a public IP and the client assumed that this was out through the router. Routing from the private IP's to the public IP's was not properly set up and doing so proved awkward.

Alternately, the server would point the client top another server by it's internal name/IP and the internal client would work fine - but external clients would not.

It is possible to have this setup work properly - but it needs some careful thought or how to lay out the internal network.

IIRC the issues were solved by ensuring that the public servers had private IP's no a separate internal subnet to the internal clients and ensuring routing at the clients default gateway was properly configured.

I'm not saying don't do it, just adding in something that should be considered.