Comment by zamadatix
23 days ago
The Archer BE3600 Pro you linked definitely has a stateful packet inspection firewall (SPI) https://www.tp-link.com/us/home-networking/wifi-router/arche... and the capabilities go well beyond state tracking (HomeShield Security enabled more on it + a few userspace tools). The Archer BE3600 Pro is also not a particularly cheap device in the first place, certainly well out of reach of the poorest in the world, it's just low cost for having such a high speed
Regardless, even with actually cheap devices, you'll find they also have the same. This is because nearly everyone, particularly the cheapest piece of crap CPU forwarding 100 Mbit routers, implement NAT using netfilter https://www.netfilter.org/ on Linux. Netfilter is most commonly known for being the firewall backend of iptables/nftables rules, but the conntrack database of nf_netfilter is also what drives the NAT state of nf_nat. It's a similar story in BSD, but it's all contained in what's called "pf" (packet filter) instead of netfilter.
I.e. one, literally, cannot implement NAT on these types of devices without first invoking a firewall and populating said firewall with the connection state. The _only_ difference in defaults between IPv4 and IPv6, on even the cheapest home routers, is whether or not the NAT is enabled on top of the stateful firewall. In no case is NAT able to be enabled on these types of boxes without having the stateful firewall functionality in place. The port forwarding is also done via netfilter. I.e., an entry in the firewall.
High end devices (most people in the US do not have home routers better than the one you linked) tend to have hardware offloads for these systems (i.e. the netfilter rules can be accelerated by dedicated hardware in either the SoC or the NIC) but otherwise are identical in implementation to the cheap ones, barring the additional crap they might bundle with the device too. It's not until you get into enterprise firewalls from companies like Fortinet you start seeing truly unique custom implementations, and even then they build it the same way at the end of the day (because why would you implement state tracking twice just to be able to build NAT with less security than normal?).
There is a common conflation that a firewall is this big beefy high end appliance which has all sorts of high end features and a dedicated config interface because it's so honkin' complex. The reality is a firewall is just a network stack implementation which tracks connection state and lets you perform actions on that (drop, deny, rewrite, send to userspace for an app to handle). NAT relies on the rewrite capabilities combined with the state table, and ticking NAT just implements a bunch of firewall rules on your behalf. Similarly, a port forward is just another rule entry which gets added to the firewall. The same ruleset which gets you NAT on home routers, minus the address & port rewriting, is what gets you a normal firewall which denies inbound.
It's possible to do NAT without firewalling in netfilter. I gave the rules for it in this comment: https://news.ycombinator.com/item?id=46709150 -- you literally only need the first one for NAT. Inserting it will make netfilter track connections, but you need the other, separate rules to do firewalling based on that state.
Most home routers will ship with those firewall rules in place, because not doing so is a security vulnerability, so in practice you're going to have the firewall, but it's not a strict requirement and routers have been discovered to not have them in the past.
At least with v6 it's more obvious that you need these rules, so it's more likely people will be checking for them.
> It's possible to do NAT without firewalling in netfilter.
That's not the claim I was making, which is that if you have netfilter/pf you are already using a device which ships a stateful firewall (and if you have NAT on a cheap home router you have netfilter/pf). This is in response to GP's claim there are cheap home routers which can NAT but not be configured as a stateful firewall, whereas your response seems to be more about how NAT can be configured.
Whether or not netfilter/pf is configured with NATs, port forwards, or block entries is a separate topic all together, somewhat split between vendor default config and what the user has changed. Regardless of what rules it's configured with at a given moment, netfilter/pf doesn't stop having the capabilities of a stateful firewall already bundled.