[deng]

> No, the side effect of NAT is that outbound connections made from your network look like they come from the router's WAN IP.

That's the primary function of NAT, not a side effect.

> It doesn't filter incoming traffic.

Of course it does, it drops any incoming traffic for which it cannot find a corresponding connection. How is this not a filter?

I know that internally these two are vastly different. The reality is that NAT is used as protection for millions of home networks.

[bandrami]

It really doesn't, it's just that in 99% of SO/HO setups it's the firewall that's also doing the NAT. NAT by itself just mangles packets.

[deng]

And again, yes, by the original definition of NAT in RFC1631, you are technically correct, which as we all know is the best kind of correctness and will move things forward. However, here in the real world, practically all NAT implementations are stateful and ignore (effectively: drop) incoming packets for which no corresponding connection can be found, meaning they do "NAT filtering" as "defined" (it's not really defined there) by RFC4787. When we say "this box here is doing NAT" everyone expects this behavior. To call this "NAT and firewall" is pointless semantics, and even the people writing RFCs agree here, which is quite something. You will see that RFC4787 says "This section describes various filtering behaviors observed in NATs", and they also say that NATs provide "firewall behaviors" without calling it "a firewall".

[Dagger2]

> ignore (effectively: drop)

Well, no. They do ignore them, but that's not effectively a drop. It's an ignore. It just means that they don't edit the packet. Whether it gets dropped or not depends completely on the routing and firewalling parts of the router.

People do generally expect a NATing router to firewall inbound connections, but it's important to realize that you won't get that behavior from NAT. You must have a firewall, which is a separate thing.