Ah, you seem to be under the misapprehension that consumer NAT devices act as BGP routers. No, in all normal configurations the “WAN” port listens on one IP only. Any traffic bound for a private/bogon range—even if it matches your internal range is discarded, not routed or forwarded.
This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first.
But even if that were true, it would be a mere technicality that doesn’t refute the point made ten or so posts ago. NAT does remain an imperfect yet semi-functional pseudo-firewall for stray inbound connections from the Internet at large.
I don't think they act as BGP routers. They do act as regular routers though, and will accept and forward traffic for any range unless they have a firewall rejecting it.
> This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first.
I've done this test before, as I mentioned. But okay, since I can be wrong and you seem confidant that I am, I'll do it again.
I just plugged a NAT router into my internal network, and attached my laptop behind it. The router got 172.16.1.130/24 as its WAN address, and is using 192.168.3.1/24 on the LAN side. My laptop got 192.168.3.158. I disabled the firewall on the router, since we both know that a firewall definitely will drop an inbound connection. On my desktop, connected to the main network, I ran `ip route add 192.168.3.0/24 via 172.16.1.130` to get the routing to work, and then I did this:
# telnet 192.168.3.158 22
Trying 192.168.3.158...
Connected to 192.168.3.158.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
I verified with `tcpdump` on my desktop that outbound connections from the laptop are being NATed to appear to come from 172.16.1.130, and yet I can still telnet into the laptop from the desktop. This appears to contradict your assertion that this traffic will be discarded, and it exactly matches my own assertion that someone on your immediate upstream network can connect inwards over NAT.
This is the same result I got the last time I tested this. So... can you explain what's going on? Because your trivial test seems to back me up here. If NAT was an imperfect yet semi-functional pseudo-firewall, why isn't it doing something here?
Curious. What brand/model of router did you use? My suspicion is that the manufacturer might be being "helpful" by bundling aspects of NAT configuration into its firewall configuration screen—so by disabling the firewall, you've also reconfigured the pseudo-firewall packet dropping behaviour of a typical NAT implementation.
Regardless as I have repeatedly said, this isn't sufficient to invalidate my claim. To recap, here's claim I made which you are attempting to dispute:
"NAT does provide some security, it’s just uncertain, unreliable..."
and
"...it sometimes makes inbound more difficult under certain circumstances. It’s not real security. But it’s also not nothing."
and
"however weak it may be, in the real world where normal people live, NAT is the first line of defence against inbound attacks for most personal computers"
Your counterpoint is that some non-zero number of NAT routing implementations will pass a very specific kind of traffic onto local IPs. Cool. For the sake of argument let's assume that's true of all consumer routers. All you've proven is that you're potentially at risk if the attacker has assumed control of the first outbound hop at your ISP. This doesn't for one second disprove that NAT has pseudo-firewall behaviour for any traffic passing through your ISP, which is the case for 99.99% of real world security threats.
I used OpenWRT, and bypassed the firewall with `iptables -I FORWARD -j ACCEPT`. There are no NAT-related rules in that chain, so I didn't do anything to the behavior of the NAT.
> Regardless as I have repeatedly said, this isn't sufficient to invalidate my claim
Okay, let's be clear: you've made an unsubstantiated claim with no evidence that isn't backed up by the known behavior of NAT. Your only support for this claim is to say that it's "trivial to prove" by doing this test, and when I actually went and did this test, it failed to prove your point.
Rather than invalidating your claim, it would be more accurate to say that neither of us has been able to validate it.
> This doesn't for one second disprove that NAT has pseudo-firewall behaviour for any traffic passing through your ISP, which is the case for 99.99% of real world security threats.
You're in luck: I have the necessary setup to test this as well. I happen to have a server subnet that's reachable from the internet, so let's try NATing the outbound connections from it and seeing what happens. (I'm going to edit the prefix on these IPs because I don't particularly want to commit them to the public record, but the suffix remains unedited.)
First, let's check what IP the outbound connections come from, and see what happens when we connect to that IP from a client elsewhere on the internet:
internetclient# curl -i http://203.0.113.136/200
HTTP/1.1 200 OK
So yeah, I added NAT and it did nothing to inbound connections coming from the internet, which demonstrates the lack of pseudo-firewall behavior for packets that traverse the ISP and not just ones from the next network over.
This is trivial to prove by placing a NAT router on your internal network (“double-NAT”) and attempting to connect to devices on the second layer of NAT from a device on the first.
But even if that were true, it would be a mere technicality that doesn’t refute the point made ten or so posts ago. NAT does remain an imperfect yet semi-functional pseudo-firewall for stray inbound connections from the Internet at large.