[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