Nitpicky, but I think this is not true. NAT's security is based on the router not knowing where to route the traffic and dropping it, where the firewall intentionally drops the traffic.
Agreed that it's functionally equivalent, though.
-A INPUT -i wan-interface -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING -o wan-interface -j MASQUERADE
It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0] But it's the decisions made in the firewall that both make the NAT work, and ensure that WAN traffic that hasn't been requested stays out.
[0] Unless the router were "excitingly" misconfigured!
This is probably the pivotal difference lol. Most of the ISP-provided routers I've used either have a default-allow policy or auto-create firewall rules when you add a NAT forwarding rule. I don't honestly recall which because it's been like a decade, but I do remember that I didn't have to explicitly add a firewall rule.
On a Linux router, perhaps setting ip_forward to 1 and leaving rp_filter at 0 would do the trick? It has been ages since I've had to play with rp_filter, so I can't remember exactly what its behavior is.
NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.
> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]
Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.
Nope, the router does know where to route the traffic for obvious reasons. At least for Linux if it's able to do NAT then it's ipso facto able to forward packets from one interface to another, and will do so unless explicitly told not to.