Dagger2

We haven't forgotten that, but we're also aware that non-IT people can't run NAT either. They can plug in a box that already has NAT configured though, and if they can manage that then they can also plug in a box that already has a firewall configured.

VMs work fine without NAT too -- DHCPv6-PD lets the VM software automatically request a routed prefix.

You could turn NAT off completely and still no-one on the Internet could reach your 192.168.0.7. There's no security perimeter coming from NAT here.

> And the NAT router won't send a packet that arrives with its public IP as dstIP to any machine behind it

Yes, of course. The problem is when a packet arrives with the IP of a LAN machine.

I'm not. You literally can do this, provided there's no firewall. All you need to do is send the router a packet that's already addressed to a LAN machine, and in it goes. "NAT won't translate the packet" doesn't matter if the address is already set to an IP from the LAN.

Most consumer-level routers do have a firewall to prevent it from happening, and if they don't then people describe that router as being "grossly misconfigured" or as having a security vulnerability and similar things, so in practice it'll be blocked. But that's my point: they need the firewall to do the job precisely because NAT doesn't do it.

RPF wouldn't help, because the reverse route for 192.168.80.26 is going to be the LAN interface, not the WAN interface. You need a firewall.

You don't need prefix translation to use a ULA prefix. You just configure both the ULA and the ISP-delegated GUA prefixes simultaneously.

And like I said, I can do that if you get me into a place where I can demonstrate it.

If you want me to demonstrate that the lock on your safe isn't doing anything, you have to let me into the room where the safe is. Otherwise you won't learn anything about the lock on the safe.

NAT doesn't protect you from 99.999% of attackers though. It doesn't do anything to incoming connections, so it actually protects you from 0% of attackers.

I'm reasonably sure I do. I've done that exact test literally half a dozen times now due to people telling me that I'm wrong, and each time I test it turns out that I'm right. What other conclusion am I supposed to come to?

I think it's someone else's turn to do the test now.

> The inbound packets from the internet are to a public IP that belongs to the device performing NAT.

If the inbound packets are addressed to the router, they get delivered to the router. But you cannot just declare that that's where they'll be addressed. You aren't in control of what packets show up to your router, you're only in control of how you process them after they show up.

Of course it won't do that -- when did I ever claim it would? But that's not the same behavior as a stateful firewall at all.

A stateful firewall would block packets addressed to the router, or to machines behind it. NAT not translating a packet won't do either of those things.

No, I'm not going to "admit" that, because I know full well that it won't.

It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.

How does the router rejecting a connection to the router protect the machines behind the router? That doesn't make any sense.

Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant?

> Sure, but the Internet will not route packets going to RFC1918 addresses

This is about RFC1918, not NAT.

> So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped.

This is about reverse path filtering, not NAT.

> And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.

And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.

Again, I ask: what is NAT doing to make those internal addresses unreachable? What side effect of NAT is making it basically impossible to expose your devices?

In the post I was replying to, the hosts were already unreachable (or... mostly unreachable, not completely unreachable) before NAT was even in the picture.

It will reach the router, obviously. If it's a TCP SYN packet and there's a server listening on that port, you'll connect to that server. If there's no listener then you get a RST.

So? How is any of that relevant?

Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.

Sure, okay. You're using RFC1918 on the internal network, so I'll need to connect to your router's WAN interface to do it, but after that it's just a matter of doing `ip route add 192.168.1.0/24 via 58.19.1.129` and then connecting to whatever I want.

How do you want to get me onto your WAN interface? Unless you happen to live near me it'd probably be easiest if you give me a tunnel. Alternately, if you change the internal network to a properly-routed non-RFC1918 range, I can demonstrate this over the Internet too.

I offered to do this once before, and the person I was talking to replied with "so, you're refusing to do it then" and blocked me. So just for the avoidance of doubt: I'm offering to do this, but if you're going to provide the test environment, you're responsible for making sure I can actually reach the test environment. Otherwise you aren't going to learn anything about NAT.

The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.

Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.

No, NAT requires state tracking, not a stateful firewall. If you want a firewall when NATing, you have to configure that separately. You can absolutely NAT without a firewall, and it won't act like one by itself.

There's always somewhere to forward a packet to. The router looks at the dest IP field in the packet header, and that's where it goes.

> If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.

This is generally going to be true, but it's not relevant to how NAT behaves when it receives inbound connections.

It might be dropped by a firewall, but not by NAT.

IP packets have a "destination IP" field in the header. The router knows where to forward packets because it reads that IP out of the header.

If you have NAT, that doesn't tell you anything about whether the router is secure. All it tells you is that outbound connections made through the router will appear to come from the router's own IP; it doesn't tell you whether inbound connections will work or not.

That will only give the NTP server the IP you use for outbound connections. If you use privacy extensions, they'll get a temporary address.

If you don't configure your firewall to allow inbound connections to the temporary address, knowing your temporary address doesn't help them connect back to you. (Also, it's temporary, so their logs of IPs will be useless after a small window.)

Compare this to v4, where connecting out to someone gives them enough information to exhaustively port scan your whole network and trivially find every server you're running.

It's not isomorphic to a firewall, because it doesn't have default-deny semantics for incoming connections.

Think about it for a second. These NAT implementations change the apparent source IP of your outbound connections. How does that block inbound connections? Changing the IP isn't blocking, and outbound connections are the wrong ones.

If a connection comes into your router with a dest IP set to one of your LAN machines, no amount of changing the IPs on your outbound connections will block it.

The point was that turning NAT on or off doesn't affect whether your LAN is reachable or not. NAT just edits the source address of your outbound connections. It's irrelevant to how your inbound connections behave.

> Correction: It will have ONE publicly-routable IP, and if I assign it to my router, but don't use NAT, then none of my devices on the network will be able to talk to the Internet, either in or out.

Right, and then if you add NAT you'll be able to make outbound connections, but inbound connections will be unaffected and will still not work. So what is NAT doing here to prevent inbound connections, given that the exact same connections already didn't work before you were NATing?

No, it doesn't imply that.

Let's say your LAN is using 192.0.2.0/24, and your router has 203.0.113.42 on its WAN interface. With NAT, outbound connections from 192.0.2.x will appear to be coming from 203.0.113.42 -- in your words, the 192.0.2.x addresses on the LAN are hidden behind 203.0.113.42.

Now imagine an inbound connection to 192.0.2.10. Does this connection need to be told where to go? It already clearly states where it needs to go in the packet itself: to 192.0.2.10, and the fact that your outbound connections all appear to be coming from 203.0.113.42 didn't prevent that at all.

So no, NAT doesn't necessarily imply that incoming connections need to be told where to go. The packets themselves can specify that.

It doesn't though. NAT edits your outbound connections to appear to come from the router's IP; it doesn't do anything to make inbound connections harder.

> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.

No... it doesn't do that.

NAT edits your packets so that your outbound connections appear to come from your router's IP. If you set up a port forward rule, then it edits matching inbound connections so they appear to be coming to a different destination IP.

Notice how no part of that description involves blocking or preventing inbound connections. That's because that's just not something NAT does.

NAT:

    iptables -A POSTROUTING -o wan0 -j MASQUERADE

Firewall:

    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -A FORWARD -m state --state INVALID -j DROP
    iptables -A FORWARD -i lan0 -j ACCEPT
    iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited

If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This should make it pretty clear that they're orthogonal features.

If NAT functioned as an inbound firewall, the second set of lines wouldn't be necessary and removing them wouldn't let you make inbound connections. But you can just test it yourself, and you'll see that NATing your outbound connections doesn't block new inbound ones.

That whole section is talking about outbound connections:

    When an internal endpoint opens an outgoing session through a NAT,
    the NAT assigns a filtering rule for the mapping between an internal
    IP:port (X:x) and external IP:port (Y:y) tuple.

When you connect outwards, the NAT creates a state table entry which matches inbound packets corresponding to that outbound connection, and this section is discussing which packets will match those entries.

Don't get distracted by its use of the word "filtering". It's not talking about unsolicited inbound connections, which is what we're talking about in this thread.