Why NAT has nothing to do with Security!

During my job I am frequently discussing with people why they use NAT or why they believe that NAT adds any security to their networks, mainly some obscurity as NAT (PAT) hides the internal network structure. However, NAT does not add any real security to a network while it breaks almost any good concepts of a structured network design. To emphasize this thesis, here is a discussion:

The Intentional Purpose of NAT

(You should already know this part when reading this post. Otherwise: Wikipedia.)
Note that when I am using the term “NAT”, I am usually referring to NAT with port translation, called PAT, NAPT, NAT overload, dynamic NAT, IP masquerading, many-to-one NAT, or the like.

What NAT Breaks

The usage of NAT has several disadvantages, mainly because it breaks the end-to-end communication model which is essential for proper IP connections. For example, IPsec host-to-host tunnels cannot be used with NAT, the FTP protocol (active mode) does not work, VoIP (SIP) has troubles, and any other peer-to-peer protocols do not work out of the box if they need to establish connections to each other independently. (Refer to RFC 3027 “Protocol Complications with the IP Network Address Translator”.) To overcome this disadvantages, a few changes in the just mentioned protocols are proposed to use them also through NAT devices, called NAT traversal, e.g., IPsec NAT-T (RFC 3947, 3948), passive FTP (RFC 1579, 2428), etc.

Furthermore, the usage of NAT adds a burden to all (network) administrators that have to configure and administrate it. For vast installations, configuring and debugging connections that traverse several NAT devices is really difficult. With many Source-NATs and Destination-NATs, every intermediary firewall stores different IP addresses in its log files. Really hard to deal with.

NAT “Security” Considerations

Here comes the actual discussion concerning the “security” features NAT adds to a network. I always present a short description of common NAT “security” considerations and then refute it:

  •  “NAT hides the internal network structure which keeps my network more secure from attackers since they do not know which systems are available.” –> I have often heard this sentence. Administrators feel more secure if their network topology is hidden from the outside. However, an attacker is only able to do harmful activities if he has access to a device in the internal network. If he really wants to enter your network, he will find a way to do so, whether you are using NAT or not, e.g., via social engineering, phising e-mails, or malware at al. In that case he is even able to do network scans from the inside of the network. That is: NAT as a hiding feature is useless if the attacker is able to access any of the internal devices! Conversely: As long as the network is protected against attackers, it is no benefit to hide the internal network via a NAT device, since it is secured against malicious access anyway. The key sentence is: addressable ≠ accessible. For a network, all devices should be directly addressable, while NOT accessible. To prohibit any kind of unwanted access, a firewall should be used. If a network administrator still wants to hide his networks, he must balance the reasons between the overall burden of NAT on the one side while hiding the internal infrastructure on the other side. However, for a company, information that reside on servers should be protected from malicious outside users and not the knowledge of their underneath topology.
  • “External servers cannot distinguish between multiple inside clients. That is, we keep the privacy of our internal users.” –> It is sometimes said that NAT masks the internal hosts, i.e., a server on the Internet does not know how many devices reside behind the NAT device, nor can the server distinguish between them. However, this is not true since servers, Internet trackers, etc. count their users on more relevant information than simply the incoming IPv4 addresses. For example, they use the User-Agent ID from the HTTP header or several JavaScript variables to concretely identify each different client (web browser) on their server, independent whether many clients access the server from the same (NATed) IPv4 address or not. For example, Peter Eckersley describes in his paper “How Unique Is Your Web Browser?” that the uniqueness of browsers are over 90 %. That is: even if a company uses NAT to hide their internal users, Internet trackers are still able to track them since they use other browser-based information.
  • “A NAT router automatically creates a firewall. No new connections can pass to the inside network.” –> In fact, connections from the Internet cannot pass to a specific computer on the inside network through the NAT device since it does not know to which computer it should forward the packet. However, this function should not be counted as a firewall-feature! The NAT device is simply unable to forward these packets at all, even though some functions would need the forwarding of packets. Moreover, a real firewall only blocks certain connections based on concrete policies. A device that cannot forward packets since it is not able to process them correctly should not be called a firewall. If you want to block all incoming connections, you should acquire a firewall and apply a “deny any any” policy to it. That is: a network without any kind of NAT but with appropriate firewalls is at least as secure as a network behind a NAT device.

What about IPv6?

I won’t start the whole “NAT for IPv6” discussion here. ;) Go for global-unicast IPv6 addresses and don’t do NAT! At least not for security. If you are an old school network administrator who used NAT for IPv4 simply for network functionalities, DO NOT transfer this knowledge to IPv6. You don’t need NAT anymore, that is: NAT66. For security policies you must use a firewall.

However, there are some exceptions: NPTv6 (Prefix Translation) must be used if a customer has no provider independent (PI) IPv6 space and wants to be flexible. In this case, they can use Unique Local Addresses (ULA) internally and must use NPTv6 for outgoing connections. Note that you MUST use a firewall as well for providing security since NPTv6 does NOT block any incoming connections by default! The other exception is NAT64, which is not an IPv6-IPv6 NAT but used as a transition method from IPv4 to IPv6.

For more information, watch this conversation:


If you keep your network secure, (that is: if no attacker can access to any device/service/etc.), it is no security leakage if the network is not hidden from the Internet by a NAT device. It is rather cumbersome that NAT breaks the end-to-end communication model and disrupts certain internet protocols.

However, I know that some people might disagree with me. So feel free to add comments! ;)

Featured image: “Was that Thunder?” by Matt Deavenport is licensed under CC BY-ND 2.0.

16 thoughts on “Why NAT has nothing to do with Security!

  1. NAT Breaks stuff, and externalises the cost of the breakage.

    Extra costs are born by users who can’t do what they want,
    software vendors who have to code NAT work-arounds for all the different NAT variants,
    service operators who have to install large central server farms to fit in with NAT’s client->server model,
    remote network support people who can’t help their users access something behind your NAT,
    innovation that is suppressed because the network is half-broken,

    These costs are not born by the security expert who decides to do a quick fix and install a NAT.

    1. Another problem with NATs is that there is no “exit strategy”. Once you start using NATs, you need to keep using them, making them bigger and faster as network traffic increases. The coming of “Carrier-Grade” NATs will further degrade network usability, and not improve security.

      In particular, the deployed NAT boxes make it hard to deploy IPv6 — which is the real solution to the address shortage problem that NATs were installed to work-around. There are millions of NAT boxes out there that don’t speak IPv6, don’t pass IPv6 packets, and blind-side people to the possibilities of global addressability and real security through fine-grained access control.

  2. If you configure NAT and only permit traffic to the Outside address in ingress ACL then that provides network security? In such a case on inside address would PAT to outside address protecting internal network?

    1. That is similar to liking baseball, but not wanting to be hit by a flying ball, so instead of playing baseball or going to see it being played, you decide to stay home and watch it on TV.

      In reality, users do see a benefit in have incoming traffic through their NAT, hence several NAT traversal strategies: STUN / ICE / UPnP, or carrying all protocols over HTTP/HTTPS, see: https://en.wikipedia.org/wiki/NAT_traversal. And Skype became the dominant V-C application because it did NAT traversal better than the rest.

      And then there is things like http://samy.pl/pwnat/ that traverse NATs using their ICMP error handling weakness.

  3. Very strange.

    “…it breaks the end-to-end communication model which is essential for proper IP connections.”
    Why is it “essential”, and what is “proper”?

    What is the alternative to NAT? That all PCs in a corporate network have their own IP address? There are probably places in the world where this is possible, but none where I am network administrator (3 countries)

    Do you have a home network? Do you then have a separate IP address for the desktops and notebooks? If not, do users complain about missing something essential?

    NAT adds of significant security to a network behind the NAT.

    Drive-by attacks from the outer side of the network is impossible. With one simple NAT interface users would have to invite it in first which would usually give you extra time.
    With directly connected computers you would have to be certain that none of them were vulnerable.

    “Moreover, a real firewall only blocks certain connections based on concrete policies.”
    What are those policies? By all means, if you need to block certain outgoing ports or IPs for some users NAT itself will not do it – but if you don’t see that need?

    1. Hi Frank,

      of course, if you don’t have the possibility to address each client with an unique IPv4 address, you must use NAT. But this dramatically changes with the advent of IPv6. With IPv6, NAT must not be used anymore, but only “security policies”.

      Default security policies should block anything from the Internet, i.e., any TCP SYN from the Internet. With this simple policy, the same (!) security level as with “outgoing NAT” is achieved. (So, yes, NAT adds some “security”. But it’s only the same as a simple security policy.)

      The basic discussion is the I won’t call NAT a “security feature”. It should be handled as a network functionality and not as a security feature. Some admins tend to misunderstand this and will argue that they need NAT for IPv6 for gaining security. That’s definitely the wrong approach.

      1. I still cannot undestand this anti-nat-security-hate. A simple example. My IP address is vs You have much smaller attack vector in the first case. Furthemore, if you create your default security policy, you destroy end to end model as well, as you are not able to initiate connection to your network.

        NAT is a technology, that has benefits and drawbacks as any other network technology. Similar to IPv6, IPSec or whatever you choose.

        1. > I still cannot undestand this anti-nat-security-hate.

          > NAT is a technology, that has benefits and drawbacks as any other network technology. Similar to IPv6 …

          Let me try explaining it a different way. Once someone has implemented NAT, they think they are “secure”. They become comfortable with a NAT mindset, and want to sit behind NAT forever. They never want to evaluate whether IPv6 has more benefits and less drawbacks than NAT.

          > My IP address is vs You have much smaller attack vector in the first case.

          “… it is trivial to hide addresses by suitable access control
          lists, even if they are globally unique – indeed that is a basic
          feature of a filtering router, the simplest form of firewall. A
          system with a hidden address is just as private as a system with a
          private address. There is of course no possible point in hiding the
          addresses of servers to which outside access is required.”

          > Furthemore, if you create your default security policy, you destroy end to end model as well …

          No, a “security policy” does not destroy the “end to end model”, its job is to filter allowed communication.

          The end-to-end communications model is _not_ describing open access from all network hosts to all other network hosts.
          The end-to-end communications model is much more about:
          a) network hosts have globally unique identifiers (addresses), and
          b) the network is a (mostly) “dumb” packet forwarding system and the “smart” network protocol processing is in the end systems.
          Network filters are still allowed in the end-to-end communications model

          In IPv6, a default security policy is a starting point. From there it is easy to add extra rules to allow traffic in to one or more server-like things.
          Compare that with IPv4 NAT where you can forward port 80 to _one_ server, but the next server gets port 81 …

          My view is that NAT breaks the end-to-end model by
          a) Introducing stateful behaviour into the network that wasn’t required before. The explicit assumption is that a NAT box has perfect knowledge of the network state of all applications on all internal hosts (which then requires NAT timeouts, keep-alives, NAT traversal techniques …) so that it can re-write IP addresses and ports.

          b) Breaking End-to-end address transparency.
          See https://tools.ietf.org/html/rfc2775#section-2.3
          and the “What NAT Breaks” section for a list of applications.

          And just now, someone just came past my desk wanting help to stop rogue Internet behaviour from behind a NAT. We do have detailed RADIUS logs for when each person connected to the WiFi, but no detailed NAT translation logs, and so we can’t identify which person it was. NAT makes administration of any medium or larger network much harder.

  4. Security by obscurity is, indeed, weak security but it is not completely worthless. It is perfectly legitimate to add a layer of weak security to other measures when you are following a security-in-depth approach. You are right that web trackers can identify individual machines but this is not a technique available to just anyone. Sure, someone who can sniff traffic persistently can piggyback on web trackers. ISPs and the NSA have both been accused of doing this. This is the reason that TLS is becoming more and more pervasive. According to various commentary (see the Security Now pod cast, for example) this appears to be the reason that the US Government is now going directly to sources like Yahoo. So NAT plus TLS will protect you from network reconnaissance but only up to a point. Still, I think that’s better than nothing.

    The other point about NAT is that it provides some level of assurance that firewalling is actually happening. It is perfectly possible to have a stateful firewall without NAT. In fact, IIRC, stateful firewalls predate NAT. The thing is that it is not possible to have NAT without a functioning stateful firewall, otherwise connections will fail. In the enterprise, you have a professional firewall administrator who will configure and test the firewall. Testing is critical. You can’t just configure an enterprise firewall and assume that it is going to work. In a home setting, the fact that you have a working connection through NAT proves that some level of firewalling is happening. Again, this is not foolproof but it is better than nothing.

    Another very important point is the legal status of having an expectation of privacy. You have legal protection, in many cases, simply by trying to protect your privacy, even if those measures are not foolproof. More generally, I think that there is definite value in arranging things so that attempts (successful or not) to violate your security or privacy are clearly unwanted. NAT, proxying and similar measures can be taken as statement that you don’t want your internal network enumerated. Without these measures, people on the outside can assume that you don’t care.

    1. “The other point about NAT is that it provides some level of assurance that firewalling is actually happening.” <- yes, good point. Thanks. I must admit that for home usage this is a pro for NAT...

  5. Some further arguments against using NAT as a default FW is that, although most people assumes NATs filter all incoming packets to a NATted host like a stateful FW does (i.e. all but the ones coming from exactly the same IP address and port you are communicating with, a.k.a. Address and Port-Dependent Filtering), NAT filtering may be different.

    From RFC4787, Section 5. “Filtering Behavior”:

    Endpoint-Independent Filtering:

    The NAT filters out only packets not destined to the internal
    address and port X:x, regardless of the external IP address and
    port source (Z:z). The NAT forwards any packets destined to
    X:x. In other words, sending packets from the internal side of
    the NAT to any external IP address is sufficient to allow any
    packets back to the internal endpoint.

    Address-Dependent Filtering:

    The NAT filters out packets not destined to the internal
    address X:x. Additionally, the NAT will filter out packets
    from Y:y destined for the internal endpoint X:x if X:x has not
    sent packets to Y:any previously (independently of the port
    used by Y). In other words, for receiving packets from a
    specific external endpoint, it is necessary for the internal
    endpoint to send packets first to that specific external
    endpoint’s IP address.

    Address and Port-Dependent Filtering:

    This is similar to the previous behavior, except that the
    external port is also relevant. The NAT filters out packets
    not destined for the internal address X:x. Additionally, the
    NAT will filter out packets from Y:y destined for the internal
    endpoint X:x if X:x has not sent packets to Y:y previously. In
    other words, for receiving packets from a specific external
    endpoint, it is necessary for the internal endpoint to send
    packets first to that external endpoint’s IP address and port.

    Actually, IETF recommends Endpoint-Independent or Address-Dependent filtering behaviors, not the “Address and Port-Dependent ” one (i.e. the FW-like behavior) , for both UDP (see REQ-8 in RFC4787) and TCP (see REQ-3 in RFC5382).

    Even worse, in many NATs, there is no way to modify the filtering behavior, or even know which one it implements. So, definitively NATs are not FWs at all!

  6. There’s a difference between intention and effect. While NAT should not be used with the intention of creating security, I do believe it has had this effect, especially for home users. Yesterday it was XP boxes which could be pwned with a simple knock on some port. Today most operating systems, even those made by Microsoft, have been patched up. Instead we have IoT devices, where as we all know, the S in IoT stands for security. (And there’s no S in IoT…) It’s already a problem, but how many more home surveillance cameras, NASes, small office photocopiers, smart bulbs and smart toasters would be doing DDoS attacks right now if it weren’t for NAT?

    The IPv6 answer is as you’re saying a firewall that denies all incoming connections. But if this is done on the firewall level, how does this not violate the principle you outlined? It breaks the end-to-end communication model out of the box and puts the burden on admins to open those ports. Especially, again for home users. The reasons are different, but the effect is similar. Incoming connections are blocked and you need a mechanism, either manual or automatic to open the ports and allow the connection. You can choose convenience or security but not both.

    When you say NAT has nothing to do with security, it come with the big assumption that the user is competent and able to set up their network correctly. This is hopefully true in a corporate environment but not universally true. IPv6 needs to happen. Obviously. But I hope that home/SOHO router manufacturers won’t let all incoming connections on IPv6 through by default to “solve the port problem once and for all”.

    1. Hi nitro, thanks for your comment.

      I absolutely agree with you that it implies that we are not talking about home users but only about corporate environments. Home users have NAT “security” for IPv4 and MUST rely on their IPv6 router-firewall that blocks everything from the Internet by default. (In fact, the most used router in Germany, FRITZ!Box, has a default deny for IPv6 implemented. Good job!)

      An IPv6 firewall does not break the end-to-end communication, but it limits it to allowed connections. That is, if the admin wants to use a connection he must permit if (of course, that’s the reason for a firewall) while it is then possible for the service to communicate end-to-end without any burden.

      And yes, I am quite interested in how IoT devices will crash the Internet in the next years. ;) Though an IPv6 firewall (or IPv4 NAT) is one step it won’t suffice the security issues from IoT devices. They will find their way to DDoS everything. E.g. via backdoors, hacked remote channels, UPnP, user stupidness, smartphone apps that configure the devices, …

Leave a Reply

Your email address will not be published. Required fields are marked *