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??


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).

  • How does NATing "preserve" public IPs? For every server that needs to be exposed publicly, wouldn't you have to NAT a separate public IP to its private IP? So, isn't the number of public IPs required equal to the number of servers to be publicly exposed? – Anjan Mar 7 '14 at 7:25
  • @Anjan Properly speaking, PNAT, which tracks connections and remaps ports so one address can be shared. It is therefore many-to-one. Often, very many. – mattdm Mar 7 '14 at 7:33
  • Okay, so: One Public IP -> different ports -> each port mapped to a separate private IP. Am I right? If two servers are running, say a website, for which port 80 needs to be exposed to the outside world. Then, for sure you would need two separate public IPs, each mapped to a server's private IP, right? – Anjan Mar 7 '14 at 8:50

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.

  • Thanks for the answer! I am not trying to fix the address shortage problem. I just want to preserve my resources (including public IPs). Actually, I prefer to do it in the way you are describing (without NAT). However, I did not try assigning multiple IP (from different subnets/ranges) to the same interface. I am talking about the VIP case. For assigning multiple IPs, it can be useful when the destination server imposes a limit on the number of connections. So, I can still get connected using different source IPs. – Khaled Dec 7 '10 at 10:06

@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.

  • — not sure why that was addressed to me. We're using NAT with the firewall, as I said. And anyway, using NAT without a firewall isn't any less "smart" than having a directly-connected system. In either case, a firewall is an additional layer of defense, but not magic. – mattdm Dec 5 '10 at 18:00
  • @mattdm Very sorry about that comment; I had read that you were only relying on NAT, without using a firewall. My bad! – Aurélien Derouineau Dec 6 '10 at 23:35
  • No problem; I was just confused! – mattdm Dec 7 '10 at 4:24

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.

  • Did you mean to say I've had issues with the "With Natting" scenario.? Because your entire answer after the first line clearly describes a "with NAT" scenario, not "without NAT". – Steven Monday Dec 5 '10 at 17:07
  • @Steven: No, I did mean "Without NAT" but explained poorly. I'd editted my post to hopefully make the point I was trying to make clearer. I was trying to highlight a potential issue with the "without NAT" scenario - but obviously failed. – Grhm Dec 7 '10 at 9:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.