Why is it a bad idea to use multiple NAT layers or is it?

The only real problem with doing multi-layered NATing is that it makes your network topology confusing. If you use multiple layers of NAT then you throw out the symmetric routing between all hosts in the organization and you also run into the potential for overlapping private address spaces inside your network. Imagine if you used an address range in your n+1 NAT layer that was being used in the n NAT layer. Those networks would never be able to route to each other, but hosts in the n+1 layer could have the same address as the n layer, making the identity of the server confusing.

If I were laying out the topology of a large network, I would use only 10.* or 172.16-24.* addresses for hosts on any of our subnets. Then if some department or individual wanted to double NAT, they could (using the 192.168.* network) with the understanding that they are responsibly for the network behind their NAT host. I would also be more inclined to create more subnets than to let any of those double NAT'd networks get too big.


Problems with multi-level NAT are essentially the same as for single layer NAT but compounded. Such as:

  1. Latency due to extra work being done in a packets lifetime (though this is unlikely to be significant in most cases)

  2. Knowing where anything comes from. If you are trying to track down where certain requests came from (perhaps your outgoing firewall has logged what looks like a compromised machine trying to spew spam or search for other infection targets), NAT makes such diagnostics much more difficult.

  3. Incoming connection port forwarding, if you need incoming connections, is more faf to setup and maintain.

  4. Limited number of ports. NAT works by translating source addresses to itself on different ports, so for example:

    • machine 1 talks to an external web server using port 1024 as it's source gets translated to the NAT box's address on, say, port 10000.
    • the same machine makes two requests to that, or another, web server concurrently (not unusual) using source port 1025 (two concurrent connections need to have different source ports). The NAT box translates this to "me on source port 10001"
    • another machine talks makes three connections to external servers. Fine, the NAT box translates these to "me on ports 10002, 10003 and 10004"
    • as packets come back in form the external machines the NAT box knows that it stuff destined for itself on port 10000 are really supposed to go to machine 1 on port 1024, and so on for the other active connections.

    This is all fine and dandy until you have many outgoing connections - i.e. a large network or a smaller network with machines that make many connections (P2P applications like those that implement the bittorrent protocol can create many concurrent connections). There are only 65536 ports in the IP protocol, less the 1024 that are reserved. While 60,000 might sound like a lot it can quickly be consumed then the NAT box needs to decide which old mappings can be removed which usually isn't as simple as "drop the oldest". This can result in odd bugs (random connections dropping for difficult to diagnose reasons) or the machine simply not being able to make new connections for a while.

  5. load on the NAT box(es). If you are using little low power boxes (off-the-shelf NAT supporting routers for instance, rather then a full PC with a chunky CPU) to do your NAT the extra translation work (compared to simply forwarding packets as per a basic routing table) could slow transfers through them down. For Internet access this is not likely to be an issue (your 'net connection will be the bottleneck) but as you are NATing between local network segments it could become quite noticable.


Performance loss / speed is really down to the quality of the router you use.

As for good/bad idea, I am against it when it is possible to simply use routing, however, it really depends on the environment and what you are trying to accomplish.

If the machines only ever need to run a few things that are shared over standard ports, you can go in to the router/nat-giving device and set a rule to allow what you want (1) . However, if you are going to be doing a lot of device to device tasks, it will be a lot easier to have a proper route with each machine having it's own unique IP (2).

(1) For example, one to many - One machine has a web server and you want to share it to others - you would set a rule in the router to port 80 of the machine, then any machine from the outside network (or inside if nat-loopback is enabled) can simply go to http://router.ip and can access.

(2) If however every machine is going to have a web server on, or you are going to be using a lot of services, you are going to have a nightmare setting up all the rules (but it is not impossible).

As for your scenario - If one department is using 192.168.x.x and the other 192.168.y.x, I would go through the devices and if there is no overlaps, it may simply be possible to change the subnet from /24 to /16 (or the other way round), then replace the routers with switches / or similar and have no loss of services.

It is really hard to help without knowing more about your network, there is nothing that "wrong" with double NAT, as long as it is set up correctly. However, unless you really need it, or there is a very good reason for it, I would look at migrating away if you can (personal opinion)


@iamrohitbanga - In response to your questions (to much for comments).

Comparing is hard - Routing works well for private networks where every machine has the ability to access every machine. Nat works well, but it is used mainly for networks that do not need routing as you usually have to manually set up incoming rules/routes.

For example, if you have an internet connection and disable NAT, then manually set up routes or bridged mode - your machine will be directly on the internet - all ports accessible and any machine can do what it wants to it.

If you have a router on the other hand with NAT, it will take the outside IP and provide "Nat-ed?" (not sure on terminology...) internet - all internal machines have an IP not accessible from the internet, but, you can set up manual rules - e.g. port 80 to one machine... It works very well for outgoing connections (firewall rules permitting), but can be a nightmare to set up incoming rules if you host many services... and if you do anything requiring dynamic ports (ftp, Windows AD etc.) it can be a nightmare.

Hope this helps, if you want to know anything else, feel free to ask.