NAT automatically prevents attackers from scanning for and attacking listening ports on the hosts behind it. Given that those who want a service to listen to the Internet should also know enough to forward the ports, I'd say it's a pretty important security benefit and one that has greatly slowed the spread of worms.

Can I send GET requests to your router with a webpage full of hidden/obscured img tags

That requires extra action on the part of the "attackee", whereas without NAT the attacker would be able to directly connect to a port, to any machine anywhere on the Internet.

So does a few lines of iptables (which work just as well with IPv4), which even most ISP routers that support IPv6 have managed to get right. On the other hand the workarounds for when you actually do want to accept connections through a NAT (cough UPnP) have been consistently misconfigured or had implementations which are simply vulnerable.

Here's NAT, as implemented on a Linux machine: `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`. You see that "-o wan0" there? That means the rule only applies to outbound connections, and it does nothing whatsoever to inbound connections. How can a rule that doesn't apply to inbound connections possibly do anything about the behavior of inbound connections?

On the other hand, v6 does do something about the spread of worms: networks use 64 bits of address space, so it's difficult to even find an active network host by scanning. On v4, you can find all active vulnerable hosts by just trivially scanning the entire 32-bit address space. An exhaustive search of a /64, which is just one single network, requires 0.9 ZB of traffic.

(Of course there are other ways of finding active hosts, and being obscure doesn't make the hosts in question secure -- but it _does_ render network scanning as a tool for spreading worms more or less obsolete.)

Outside of exotic situations, part of setting up a NAT is putting your internal hosts on a private IP range. This makes inbound packets impossible (if your ISP didn't screw up).

Even if you didn't do that, all you have to clarify is that you're replacing the existing routing rules with NAT. Mystery solved.

And in fact, putting your internal hosts on a private IP range doesn't prevent inbound connections either. It'll limit the set of people that can do them, but anybody on your immediate upstream connection can do it just by sending packets to your router. That probably means at least your ISP and anybody who can order them to cooperate.

NAT isn't a security boundary.

(And if you replace your routing rules with NAT then everything will break, because the only thing NAT does is rewrite addresses in packets. They still need to go through the routing table to be routed.)

Maybe not private, but I think it's fair to say that putting them on a different IP range is expected enough that you can reasonably call it part of NAT.

> They still need to go through the routing table to be routed.

You're looking at things from a very iptables-centric view.

"Accept packets on one network interface, rewrite them, spit out the other interface if the rewrite succeeded" is a valid description of NAT that replaces all other routing.

It also prevents the "ISP screwed up" and "malicious ISP" scenarios, if your NAT is port-based. It doesn't even care if you used different IP spaces or just one.

Yes, I'm describing behavior from the perspective of Linux and iptables because that's what I'm familiar with... but this is the generally-understood meaning of "NAT" when used in this context, and as far as I'm aware this is how basically everything implements it. This is the behavior you'll be seeing.

> this is the generally-understood meaning of "NAT"

If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right? I think that's a reasonable expectation, and it does not require any routing to do. And since the attack we're talking about depends on using routing to bypass the NAT, a dumb device that doesn't route is not vulnerable, and does not make your network vulnerable.

> If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right?

Only if they haven't read RFC 2883 (or similar documentation). I would describe a "device that does NAT but not routing" as highly unusual, possibly purpose-built to update an older network or workaround some kind of compatibility/interoperability problem. Such a device would probably be a custom iptables (or equiv) configuration on a standard linux (or equiv) box, not a branded "router".

However, another interpretation is that the terms "NAT" and "routing" are being used in the colloquial sense that usually only refers to NAT and routing to refer to something roughly similar to the home devices that sit between the LAN and a {cable,ADSL} modem. In that sense, a device with two cables attached might not appear to "routing" anything. In previous posts, I'm using the technical definition of NAT as defined by RFC 2883, not this broader colloquial definition.

By the technical definition, the device is "routing packets"! NAT is defined as something that performs "transparent routing" between address realms. From RFC 2883: [1]

    2.2. Transparent routing

       The term "transparent routing" is used throughout the document to
       identify the routing functionality that a NAT device provides.  This
       is different from the routing functionality provided by a traditional
       router device in that a traditional router routes packets within a
       single address realm.

       Transparent routing refers to routing a datagram between disparate
       address realms, by modifying address contents in the IP header to be
       valid in the address realm into which the datagram is routed.

   2.1. Address realm or realm

   An address realm is a network domain in which the network addresses
   are uniquely assigned to entities such that datagrams can be routed
   to them. Routing protocols used within the network domain are
   responsible for finding routes to entities given their network
   addresses.

    |                       |        /-----------\
    |                       |       / [Firewall]  \
    \  New Packet Received  /       | unroutable, |
     \      From NIC       /        \ drop packet /
      \-------------------/          \-----------/
                 |                            ^
                 v              addr: unknown |
         +----------------+    +-----------------+
         | is DST addr in | Y  | [Packet Router] |
         | realm "WAN"?   |--->| rules: "WAN"    |
         +----------------+    +-----------------+
           N |                     addr: NAT |
             v                               v
         +----------------+   /--------------------------\
         | is DST addr in |  / "Route" from realm "WAN"   \
         | realm "LAN"    |  | to realm "LAN" by changing |
         +----------------+  \ the IP header address      /
           N |       | Y      \--------------------------/
             v       |                       | 
     /-----------\   |                       v
    / [Firewall]  \  |      +---------------------------+
    | Bad addr,   |  |      | Hand off packet to be     |
    \ drop packet /  |      | routed into its new realm |
     \-----------/   |      +---------------------------+
                     v                       |
         +-----------------+                /
         | [Packet Router] |<--------------/
         | rules: "LAN"    |
         +-----------------+
            |  To: the "LAN" firewall,
            |      other processing,
            |      maybe TX at the
            v      LAN's NIC
          (...)

> a dumb device that doesn't route is not vulnerable

If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet. Fortunately, most devices include a stateful firewall that DOES make important decisions about how to handle each individual packet.

> does not make your network vulnerable.

*If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?). They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.

The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router. Fortunately, most routers are not vulnerable.... because they include a firewall that drops "obviously invalid" packets.

[1] https://tools.ietf.org/html/rfc2663#section-2.2

[2] Transparent to the src and dst hosts that sent/received the packet. This "transparent" is referring to the hosts using the NATing router do not need to do anything special when sending/receiving packets. The address changes are invisible to the endpoints.

A hub is not a router. An inline repeater is not a router. That is not a normal or useful definition.

> flowchart

When most people talk about routing, I think they mean the boxes you labeled [Packet Router]. A NAT-only device would basically remove every conditional box, remove every box labeled [Firewall], and remove every box labeled [Packet Router].

Packet received -> Rewrite headers -> Packet output.

Technically you'd have two identical flowcharts, one for each direction.

> If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?).

Any packet coming in from the internet would hit the rewrite engine, the rewrite would fail, and it would not make it to the LAN.

> They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.

If you had to have a web interface, then packets coming from the NAT device itself would be sent directly to the port, not to the NAT engine.

But for this thought experiment let's just not have a web interface.

> The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router.

Packet from a LAN? It gets NAT applied and goes to the internet. The internet can decide what to do with a destination of 192.168.0.107

(I would have said you can't even have two LANs without routing, but you could force it to happen, like making every WAN->LAN packet go out to both of them.)

All these attacks you're listing are using routing to bypass the NAT functionality. Not possible in a device that cannot route.

> Changing the SRC Address field in the header is routing the packet!

That is an interesting and pretty convincing argument. Two caveats, though. One is that this is still a separate thing from "packet routing" or whatever you want to call picking a direction/vlan for a packet to go to based on routing tables.

The other caveat is that it might just be imprecise language. What if "by" means "by also". They are assuming you have a normal router as a base, are making it transparent by adding header modification. So then transparent routing is a combination of routing and header modification, but header modification all by itself is not routing.

Because the RFC assumes you started with a router, maybe I should say "just the Network Address Translation portion of the NAT RFC" instead of "NAT", but that seems like an unnecessary level of pedantry.

That the firewall, not NAT. NAT on it's own - without a firewall, a very unusual configuration - will route packets to your "private" addresses if that address is in the packet's DST address field (maybe; it depends on the rules the router uses when deciding how to rout a packet, which is also not NAT). NAT is only about changing the address field. RFC 2663 even recommends that NAT should usually be "used in conjunction with firewalls to filter unwanted traffic". Unless you're referring specifically to changing the address/port fields in the packet header, you are probably referring to a stateful firewall. That's the feature that is usually responsible for dropping packets, preventing scanning of your LAN.

TL;DR - address translation (NAT), and choosing what to do with a packet (firewall, routing rules) are separate, independent features. NAT - by itself - isn't really involved in routing/firewall step. That's why it's extremely unusual to see NAT in isolation. The thing you see on e.g. most home routers is basic use of NAT combined with a simple router and (hopefully) a powerful stateful firewall.

> should also know enough to forward the ports

That's nice iff you get to decide which ports are forwarded. Good luck getting a carrier to forward ports. It isn't going to happen if you're in some parts of China behind 7 layers of NAT. Port forward in that situation would be a nightmare, assuming it was even theoretically possible to convince the 7 upstream authorities that they should forward a port to you.

However, minutia about port forwarding doesn't address my main point: that NAT limits the type of software that is developed. Are you really going to write a network app that only works if people setup port forwarding? Would business use telephone for as many purposes if phone numbers were all shared party lines?

> That requires extra action on the part of the "attackee"

That "extra action" is probably the most common vector of infection for modern malware. Ignore it at your own peril.

And how does such a packet make it to your router, exactly?

I disagree that it's "the firewall" doing the real work here. If things are configured properly, a firewall should be 99% irrelevant.

The fact that something else can also provide that security benefit in no way means that NAT doesn't provide some security benefit. It does.

This NAT'ing for security has practically left the Internet broken. We are permanently dependent on Server to route packets to other client.

I find it really hard to understand this obsession with pining for a world where security doesn't need to exist. It does, and it always will. Design around that, it's not hard.

Nobody is doing that. We're "pining" for a world where our devices can have direct phone numbers instead of having to share a party line. Unfortunately, some people keep insisting that requiring households, businesses, or larger groups of people (i.e. CGNAT) to share a single phone number keeps everyone safer because it keeps most people from being able to receive incoming calls.

See my other post[1] for the technical reasons NAT doesn't actually provide security. TL;DR - this is a problem of definitions and a common misunderstanding about how NAT/routing works.

In the telephone analogy, I'm trying to say that you phone lines sh0uld have their own individual telephone numbers, because you might need them some day. Not having the ability to receive incoming calls will eventually limit you in important ways. "But incoming calls can be dangerous! Why are you trying to making us less secure?" We're not increase your options, which doesn't affect your security. Since incoming calls are dangerous, just disable your ringer or use a firewall that simply blocs all incoming calls.

[1] https://news.ycombinator.com/item?id=20181274

You're just as wrong now as you were then, see my up-thread post to correct your misunderstanding about security.

Edit: either direct addressing isn't possible with NAT, which provides security benefits, or it is possible, which means your complaint is mis-placed. It cannot simultaneously prevent direct addressing and provide literally no security benefit.

Block all incoming connections by default. Have your apps/OSes on firewalled machines prompt users to allow incoming connections, and use uPnP to talk to the firewall to open the port.

With NAT, you additionally have to deal with port renumbering (what if more than one host wants to run web servers, or ssh, or VNC, etc). And because the ports are a shared resource between all hosts, you may not allow uPnP so hosts can't fight over forwarding rules.

Most routers won't forward those packets. But that's got nothing to do with whether those routers are running NAT or not.

Good, we agree this is a pointless hypothetical which will never work. That does beg the question why even bring it up, though...

Well you're the person best placed to answer that, since you brought it up.

More like cgNAT makes you share the external address between many people. It gives you plausible deniability: "dear $forum admin, it's not me creating multiple accounts for trolling from the same IP address, it's the guy from the next building, I swear!" / "it's my neighbor's porn visible on https://iknowwhatyoudownload.com/en/peer/ not mine!"

Of course that's Not Security, that's just obscurity, but damn, it kinda does feel good :D

OK, you remove NAT but if firewall remains with default DROP ALL policy, what's the difference? Even worse, the firewall now isn't in your home, it's in ISP network and out of your control. So you need imprimatur as before.

In an IPv6 network without home routers the problem of malware spreading between peers remains. Chances are high that ISPs will be forced to restrict peer communications just like they did in NATed IPv4 networks.

CGNAT breaks all this, of course, since the public IP address is on the ISP's side and they're unlikely to implement port forwarding on demand. For that matter, there probably aren't enough ports available to support all the subscribers sharing a given public address, and there could be security/trust issues as well with incoming connections to the same IP being dynamically routed to different subscribers according to the port number. (All the problems associated with dynamic IP address reuse, but with much quicker turnover.)

With IPv6 you can either let the destination deal with incoming connections directly—which has about the same security as a NATed IPv4 network with UPnP—or manually configure the firewall to only allow specific connections through according to the destination IPv6 address and/or port. Either way you won't have any issues with multiple hosts wanting to accept traffic on the same port numbers. There is no technical reason why there couldn't be a protocol like UPnP(v6) just for opening ports in the router on demand, but in a NAT-free network it wouldn't really serve any purpose.

Not the same. Intranet-only services are still protected.

Assuming you're stuck with some insecure legacy protocol which relies on such rules, however, it's still quite simple to restrict incoming connections to a specific subnet on the host itself, either with local firewall rules or a few lines of code in the application. In a network with UPnP the host is the authority on which connections should be allowed, whether we're talking about Internet services or intranet-only ones, and the host can block incoming connections at least as well as the router. In the absence of NAT there is no need for the router to get involved.