I've heard before that "NAT is not intended as security", but isn't the effect still the same, that an external device can't connect to a device behind NAT without explicit configuration allowing it?
That is generally true, but has weird edge cases. For example using not so specially crafted ICMP packets[1] two hosts each behind independent NATs can communicate with each other without any change to a firewall configuration.
Also honorable mentions: The UPnP protocol & STUN servers
Server sends constant icmp pings with fixed payload to unreachable dead Internet IP. Client sends icmp time exceeded message to server containing original fixed ping subpayload, which the server NAT lets through because the payloads match as related traffic. Server then learns client IP and usual chownat udp hole punching tricks apply.
I find this argument to be completely ridiculous, and it’s become remarkably common among those who wish to justify some of IPv6s shortcomings. Whether it was designed to be a security control or not, it is one, and it’s an incredibly important one. Anything that controls how hosts are allowed to communicate with each other is a security control. The argument is so absurd that I literally can’t believe people go around parroting it.
It allows you to connect a private network to any other network, including the internet, without allowing hosts on that network access to hosts on the private network. It’s a form of access control. What is your justification for saying that access control measures are not security controls? That is so incredibly contrived.
> It allows you to connect a private network to any other network, including the internet, without allowing hosts on that network access to hosts on the private network.
So, how does it do that?
> What is your justification for saying that access control measures are not security controls?
I am not saying that. It simply isn't an access control measure.
By rewriting the IP headers of packets as they traverse routing devices. If you’re trying to say that all NAT devices are stateless firewalls, then your point is even more contrived than I first thought.
> It simply isn't an access control measure.
Then why can’t other internet connected devices connect to my internet connected laptop? If I’d connected my laptop directly to my ISP then they would be able to. But I didn’t do that, I connected my home router to my ISP, and I connected my laptop to my home router, which is providing access control for me.
> Then why can’t other internet connected devices connect to my internet connected laptop?
Some of them can. For example a device in the ISP network that can deliver a packet directly to your router's WAN interface can connect to your LAN devices in the absence of a firewall that would drop them.
As an example consider this:
A packet from src 10.10.10.10 to dst 192.168.1.1 arrives on the WAN interface. There are no firewall rules that match and the NAT is stateless. The router looks at the route table and sees a route for 192.168.1.0/24 on the LAN interface. It puts the packet on the LAN interface and calls it a day. Since 10.10.10.10 was a device on the same ISP network segment/broadcast domain as your router's WAN interface, it just reached a device in your NATed LAN.
On the campus LAN we used as a best practice to drop all packets that arrived on the WAN interface with a destination to the private LAN IP range, that had no entries in the state table.
> By rewriting the IP headers of packets as they traverse routing devices.
How does that prevent hosts on that other network from accessing hosts on your "private network"? Like, a packet addressed to one of the hosts on your "private network" arrives at your NAT gateway from the "other network". How does the NAT rewrite the IP headers, and how does that provide access control?
> If you’re trying to say that all NAT devices are stateless firewalls, then your point is even more contrived than I first thought.
Even that would not be contrived. If removing the NAT function does not change the security functions of a router, then the NAT obviously does not provide security, at best it implies the presence of certain security functions. But even that just isn't the case.
> But I didn’t do that, I connected my home router to my ISP, and I connected my laptop to my home router, which is providing access control for me.
Then that presumably is because your home router provides access control? What does that have to do with NAT, though?
No, NAT does not prevent connections, it only rewrites addresses. If your NAT router also has a stateful firewall, that is what prevents inbound connections, and removing the NAT from that equation does not change that.
The point is NAT is actually a couple of rules in router's stateful firewall, it is done by firewall, and firewall can't do it without explicit configuration. There can't be 'default allow NAT' config.
... which doesn't change that that "default allow" firewall will still pass through all packets, and thus allow access to all your internal devices/machines? Absence of NAT rules does not prevent packets from passing through the firewall, it only prevents rewriting of addresses.
The point you were objecting to was "external device can't connect to a device behind NAT without explicit configuration". Without NAT rules access to internal devices is prevented because packets don't get routed to private IPs.
That just isn't the case, though. A router without NAT and without a firewall (or a combined NAT/firewall thingy with default allow and no further rules) will route packets addressed to "private addresses" just fine. An IP router does not distinguish between "private addresses" and "non-private addresses": As long as there is a route for a prefix in the routing table, the router will route packets addressed to that prefix, and your typical home router most definitely does have a route for your LAN prefix.
So your example depends on the incoming packet already being addressed to a device behind the home router, which in a home network is in a private range. Thus, your example depends on the ISP's network delivering a packet to the customer despite that packet having an IP address that doesn't match the IP address the customer leased. Do you agree, and if so, do you know that this has ever happened in a residential setting?
Or do you mean an adversary who is or who compromises the ISP, possibly by tapping into the coax/fiber/etc in the last mile or by pwning the related nodes?
If there is no entry in the state table, then NAT rules are consulted to see whether a new rewrite entry should be added (such as DNAT/port forwarding rules on your home router), and if there is no matching rule either, it simply is forwarded without address rewriting.
Why would it be forwarded? Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP? Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it."
I am sure a NAT could be configured any number of ways, though, and could probably do anything you want with such packets.
Because the device is a router, and that is what routers do.
> Do you mean that it forwards it to itself, the NAT device addressed by the actual public IP?
No, it forwards it to whatever destination address is in the destination address field of the IP headers, because that is what IP routers do.
If it is addressed to one of the NAT device's own addresses, of course, the routing decision would deliver it to the local protocol stack instead of forwarding it, and if there was any service listening on the respective protocol/port, that service would receive the packet (or the TCP stack would respond with a SYN+ACK, or whatever), and if nothing is listening there, the IP stack should respond with either some ICMP error message or possibly a TCP reset or something.
> Wikipedia seems to disagree [0] "if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it."
Well, maybe that is good enough for explaining to a lay audience what a NAT gateway does, because that is what home routers typically will do, because they tend to also have a stateful firewall built in, but it's pretty misleading if you are trying to understand what is actually going on.
> I am sure a NAT could be configured any number of ways, though, and could probably do anything you want with such packets.
Not really, simply by definition: The function of a NAT is the translation of addresses. A router can have many more features, of course, such as a stateful firewall, but the point is that if you only had the address translation functionality, that would not prevent inbound connections, and if you remove the address translation functionality and keep the stateful firewall, inbound connections still aren't possible. Hence, NAT has nothing to do with whether inbound connections are possible, other than that devices that have NAT functionality commonly also have a stateful firewall.
Wouldn't the router only have a route for 192.168.0.x or whatever to go to the private interface? Why would a packet still addressed to the public IP get routed to the private network interface?
>NAT has nothing to do with whether inbound connections are possible
So how would you address a device on the private network from outside?
edit: I read your other response. Fair enough, if your ISP is sending you privately addressed packets they could get through.
Also honorable mentions: The UPnP protocol & STUN servers
[1]: https://samy.pl/chownat/