[oarsinsync]

It's less of a 'networking purist', and more of a 'order of events' thing.

If I send a packet from SRCIP1:SRCPORT1 to DESTIP1:DESTPORT1, and his real desktop IP is DESTIP2, the first event to occur is the stateful firewall checks if there's a session that exists between SRCIP1:SRCPORT1 and DESTIP1:DESTPORT1.

If the session does not exist, the firewall drops the connection.

If the session does exist, the next step is to hit the NAT table, to look up what to translate, for session SRCIP1,SRCPORT1,DESTIP1,DESTPORT1 into SRCIP2,SRCPORT2,DESTIP2,DESTPORT2.

Note that it's possible that source ip, source port, destination port may not change in this scenario, where there's an RFC1918 DESTIP2. It depends on the NAT configuration.

So again, strictly speaking, NAT does not prevent the connection. The stateful firewall does. NAT does not protect you, the firewall does.

"Old fashioned stateless firewalls" are also not widely deployed on consumer grade CPEs.

[jfindley]

That only allows you to send replies along an existing TCP stream. In order to exploit this to compromise some home desktop, you first must persaude them to connect to you. Except... Oops! You now aren't bypassing NAT at all, you're just yet another malicious host that you tricked the user into connecting to.

Every argument I've heard against NAT being an effective practical mitigation for home users runs smack into the problem of being a oh-well-actually scenario that's fantastically contrived and doesn't represent a realistic threat model for the average home user.

[oarsinsync]

I'm not talking about threat models or exploits, I'm talking about the order of events, how most consumer grade CPEs actually work.

For an inbound connection again, there is a packet filter first, that will permit inbound connections based on whatever filter parameters are defined (usually matching established sessions, or new sessions filtered by just protocol and dport), and if that clears, the second step is NAT.

In both cases, the filter happens before the translation.

[411111111111111]

Its just basically impossible to get a consumer grade nat without an inbuilt stateful firewall.

He's correct that the NAT doesn't stop the connection, but the stateful firewall is another service on the same device so you will never really notice the difference

With the theoretical situation of a NAT without a firewall a connection is technically possible, as long as you are able to inspect any previously sent TCP packets and use the sender bits to route your new packets