The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.
You need to explicitly reconfigure the iptables/nftables to prevent that from happening.
Some software, say LXD/Incus, enable forwarding automatically upon installation/startup, and do not configure firewall to block non-their traffic, making the machine an open router. I've reported that, the developers said that's by design (despite other virtualization/containerization systems block forwarding if they happen to enable the sysctl).
Respectfully- I don’t think this statement applies to the scenario I presented.
“The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.”
In the setup I presented, we are bridging an Ethernet and a WiFi network. This would be desirable if you wanted to use an upstream dhcp server for your WiFi clients- or if you wanted to avoid double nat’ing.
In 802.11 infrastructure mode, a station can only send frames with its own MAC address. The AP won’t accept or forward frames from unknown MACs. So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd.
In every other circumstance- I think your statement holds.
I tried to do some weird alerting on new MAC addresses and ran into this weirdness. Bridging WiFi and Ethernet gets weird.
Respectfully the scenario you want to present seems to change. The title you submitted this under doesn’t have any mention of switching, firewalls, dhcp server or WiFi access point.
Then the actual title of the article mentions routing and switching but not a firewall, dhcp server or WiFi access point. Then at the end you seem to change the goal to being a WiFi router but really you have presented more steps than required for that. You have also setup switching, a firewall and a dhcp server which are not required to be a router with WiFi access point.
"So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd."
I think that is incorrect. hostapd handles the authentication side of things, but 4addr tuples are controlled by 'struct wireless_dev.use_4addr', and can be set by 'ip link set type bridge_slave ... proxy_arp_wifi on', `iw dev ... 4addr on', and if using systemd-networkd, with slave interface's
[Bridge]
ProxyARPWiFi=yes
(and networkd doesn't need hostapd's bridge= option since networkd handles that aspect.)
Kernel then uses NL80211_IFTYPE_AP_VLAN and handles the proxy operation.
Could you share more details about this? Do you mean that e.g., if I run LXD/Incus on a machine with a public IP address, anyone on the internet could route traffic through it?
The risk is minimal if you control or trust both networks. A network boundary is a natural choke point for access control, so that's where it's usually implemented. For an ipv4 boundary router (as is the topic of the post) you almost certainly need to configure Network Address Translation because your internal network addresses are non-routable on the Internet (at uni my dorm had public IP addresses for each student computer, fun times).
As for the GP's example, running VM's or containers* on your own machine? I'd say the default ACCEPT policy is fine. However, silently changing such a setting on software installation is a problem because if the machine is multi-homed (i.e. has more than one network interface), you've now created a network route outside of the network admin's control.
* The default for docker and podman is to use a private network, not a bridge anyway.
Basically you're introducing a hole. For example, if you have some devices in your network (like a dodgy TV box) that are not supposed to reach the internet or other parts of the network, the computer with net.ipv4.ip_forward=1 could be used as a pivot. Depending on the routing tables you probably would also need to enable IP masquerading (NAT) to allow bidirectional communication.
Used to run a virtualized firewall setup. And then one day discovered that somewhere along the lines I had made a change (or an update changed something) that meant proxmox admin interface was being served publicly. That's despite confirming during initial setup that it isn't.
So now I do not do any funky stuff with firewalls anymore. Separate appliance with opnsense bare metal.
My router is a 16GB n150 mini PC with dual NICs. The actual router OS is within openwrt VM managed by Incus (VM/Container hypervisor) that has both NICs passed through.
One of the NICs is connected to another OpenWrt wifi access point, and the other is connected to the ISP modem.
The n150 also has a wifi card that I setup as an additional AP I can connect to if something goes wrong with the virtualization setup.
Been running this for at least 6 months and has been working pretty well.
Both port specific firewall rules, and web-server IP permissions are important.
For example, bandwidth rate-limiting may be inhibited for admin SSH or package updates, and LAN IPv4 private ranges for your host address pool are set.
Finally, your internal DHCP should statically bind your admin computer MAC to a fixed LAN host IP to further reduce issues.
Personally, I always build my NAS from scratch, as I have lost count of the number of problems web-GUI have caused over the years. =3
Dedicated appliances are the way to go for the most important parts of your setup. I've always had my router as an appliance because I don't like the idea of my network failing due to something going wrong with the server that runs a bunch of other things that are less important. I also have Home Assistant running on a dedicated machine because that's also important.
Btw you do also need to be careful with opnsense. I was years behind on updates for mine because every time I updated I assumed that it would bring me up to date with the latest version. But opnsense has to install the upgrades in order. After you reboot you need to check again for updates and repeat until there's no more to install.
I don't bother with virtualization, and use the machine at the edge of my network as router, email server, Web server, DNS server, and countless or other things such as hostapd.
An x86 mini PC can run all this without breaking a sweat; using separate appliances seems very wasteful. That being said, I configure everything in DIY mode, and don't rely on GUIs or other similar things that increase the attack surface considerably.
I used to try to combine everything, but now I don't. Separate appliances isolates issues to a subset of services. If everything is on a single PC and that one dies or even just needs a reboot, everything goes down.
Fair enough and I think you have done the right thing - opnsense is pretty decent - and the clear delineation between collision domains helps avoid showing too much ankle to the internet 8)
I think your initial setup was perfectly valid. Then you diagnosed a fault and fixed it with aplomb, in a way that you could verify. The key point is: "in a way you could verify" and you failed safe. Well played.
Proxmox itself has a useful firewall implementation too, although it takes a bit of getting used to because you can set it at the cluster, host and VM levels. I personally love it because it is easier to manage than individual host based firewalls, which I also do, but I'm a masochist! For smaller systems I generally use the cluster level to keep all the rules in one place.
This is an excellent post and great reference material. I’ve done this a few times before and the information was scattered all over the place. I appreciate the clear and concise writing here. I even added it to my HN favorites - a rare accolade!
One thing I’d add, is that the best explanation I’ve ever seen for this, is the famous diagram [0] on Wikipedia of the netfilter API — I remember when I saw that, everything clicked into place. I’m not sure how up to date it is now, but it’s really good.
Are there any preconfigured images/installers available for a major Linux distro to turn them a router with safe and sensible defaults?
I know there is OpenWrt, but my experience is that is more geared toward running on embedded wifi hardware than an x86 machine. The x86 install comes with a tiny root partition that's actually pretty difficult to resize, for example, and upgrades are quite brittle compared to standard Linux distros.
And there's also pfSense and OPNsense, but these run on FreeBSD which seems to lag behind Linux for hardware support. There's no support for the Aquantia AQC113 NIC, for example (although it looks like this may finally have been added in the last month or so).
Something like an Ubuntu Appliance [1] would be quite nice.
Modified Ubuntu LTS server image will work, and a minimal Debian kernel will have far less bloat. Note pfSense/FreeBSD is fairly robust, and a mature project.
Keep in mind most network appliances have dedicated hardware hand-off adapters, and so the CPU isn't involved in routing once the connection is setup. It is why people can use a $30 SoC, and still be able to saturate several 10Gb/100Gb ports. =3
While I run Linux on my production workstation, I use OpenBSD as my router and firewall at home. I find the configuration of OpenBSD for this a lot more simple and everything that's needed, even for IPv6, is in the base install.
- nftables is default to `ip` family which only applies to IPv4. Setting it to `inet` will allow rules to apply to both IPv4 & 6; or `ip6` for IPv6 only. You can skip NAT rules, usually.
- dnsmasq: in addition to DNS and DHCP, turns on router advertisement with SLAAC. Some devices can get IPv6 address from stateful DHCPv6 server, others (e.g. Android) only work with SLAAC.
The FORWARD chain defaulting to ACCEPT is one of those things that bites people hard in incident investigations. A compromised host with ip_forward enabled silently becomes a pivot point — the attacker can route through it to reach internal networks that were never meant to be reachable from that segment.
Worth adding to any hardening checklist: if you don't explicitly need forwarding, set the default FORWARD policy to DROP and only whitelist the routes you actually want.
Stories like these make me sad when I think about chat control and age verification. Kids in the future may no longer be allowed to talk to random helpful strangers on the internet about computers and other technical topics, because apparently the internet is too dangerous for children.
Suppose the age verification checks stopped. Where exactly are these kids supposed to find "random helpful strangers" on the Internet that isn't also a major vector for predation or nonsensical AI spam?
Around the same time I set up an old pentium 80 that booted linux off a floppy to be a router. It ran for a few years later until Linksys wifi routers got cheaper.
People saying "the FOWARD chain defaults to ACCEPT" are missing the deeper point: with the kconfig most distros use, the filtering code doesn't even exist at all until you load the kernel modules!
At the lowest level, it is impossible to have a default DROP for forwarding, because nftables is an optional piece of the kernel that often isn't loaded.
The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.
You need to explicitly reconfigure the iptables/nftables to prevent that from happening.
Some software, say LXD/Incus, enable forwarding automatically upon installation/startup, and do not configure firewall to block non-their traffic, making the machine an open router. I've reported that, the developers said that's by design (despite other virtualization/containerization systems block forwarding if they happen to enable the sysctl).
Respectfully- I don’t think this statement applies to the scenario I presented.
“The Linux box instantly turns into a router as soon as you run `sysctl net.ipv4.ip_forward=1`, because the default policy for FORWARD table is ACCEPT.”
In the setup I presented, we are bridging an Ethernet and a WiFi network. This would be desirable if you wanted to use an upstream dhcp server for your WiFi clients- or if you wanted to avoid double nat’ing.
In 802.11 infrastructure mode, a station can only send frames with its own MAC address. The AP won’t accept or forward frames from unknown MACs. So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd.
In every other circumstance- I think your statement holds.
I tried to do some weird alerting on new MAC addresses and ran into this weirdness. Bridging WiFi and Ethernet gets weird.
Respectfully the scenario you want to present seems to change. The title you submitted this under doesn’t have any mention of switching, firewalls, dhcp server or WiFi access point.
Then the actual title of the article mentions routing and switching but not a firewall, dhcp server or WiFi access point. Then at the end you seem to change the goal to being a WiFi router but really you have presented more steps than required for that. You have also setup switching, a firewall and a dhcp server which are not required to be a router with WiFi access point.
"So you can’t transparently bridge Ethernet devices’ MAC addresses through a WiFi client interface. This is why we need hostapd."
I think that is incorrect. hostapd handles the authentication side of things, but 4addr tuples are controlled by 'struct wireless_dev.use_4addr', and can be set by 'ip link set type bridge_slave ... proxy_arp_wifi on', `iw dev ... 4addr on', and if using systemd-networkd, with slave interface's
(and networkd doesn't need hostapd's bridge= option since networkd handles that aspect.)Kernel then uses NL80211_IFTYPE_AP_VLAN and handles the proxy operation.
When regular people say 'router', they assume this one box will be all three of these things:
- router
- NAT gateway
- DHCP server
In a typical scenario, turning IP forwarding on will do nothing unless:
- DHCP has given the devices on the 'inside' IP addresses and told them the gateway address, and
- the router is set up to do IP masquerading
You forgot the -WIFI access point
And a - switch
Could you share more details about this? Do you mean that e.g., if I run LXD/Incus on a machine with a public IP address, anyone on the internet could route traffic through it?
A stupid question, what's the risk?
The risk is minimal if you control or trust both networks. A network boundary is a natural choke point for access control, so that's where it's usually implemented. For an ipv4 boundary router (as is the topic of the post) you almost certainly need to configure Network Address Translation because your internal network addresses are non-routable on the Internet (at uni my dorm had public IP addresses for each student computer, fun times).
As for the GP's example, running VM's or containers* on your own machine? I'd say the default ACCEPT policy is fine. However, silently changing such a setting on software installation is a problem because if the machine is multi-homed (i.e. has more than one network interface), you've now created a network route outside of the network admin's control.
* The default for docker and podman is to use a private network, not a bridge anyway.
It's can also commonly be a problem if for example you are connected to multiple LANs via wireguard or similar.
Basically you're introducing a hole. For example, if you have some devices in your network (like a dodgy TV box) that are not supposed to reach the internet or other parts of the network, the computer with net.ipv4.ip_forward=1 could be used as a pivot. Depending on the routing tables you probably would also need to enable IP masquerading (NAT) to allow bidirectional communication.
that you'll get it wrong, I suppose.
after all, most routers/WAP/gateways that you buy today will have linux on the inside, configured similarly.
In almost all Linux based router setups: folks end up using 6to4 tunnels, packet marking, and interface routing priority.
Setting that up with safe/fair bandwidth-sharing requires intermediate IT skill level. Still a great hobby project =3
Used to run a virtualized firewall setup. And then one day discovered that somewhere along the lines I had made a change (or an update changed something) that meant proxmox admin interface was being served publicly. That's despite confirming during initial setup that it isn't.
So now I do not do any funky stuff with firewalls anymore. Separate appliance with opnsense bare metal.
I currently do something similar.
My router is a 16GB n150 mini PC with dual NICs. The actual router OS is within openwrt VM managed by Incus (VM/Container hypervisor) that has both NICs passed through.
One of the NICs is connected to another OpenWrt wifi access point, and the other is connected to the ISP modem.
The n150 also has a wifi card that I setup as an additional AP I can connect to if something goes wrong with the virtualization setup.
Been running this for at least 6 months and has been working pretty well.
Both port specific firewall rules, and web-server IP permissions are important.
For example, bandwidth rate-limiting may be inhibited for admin SSH or package updates, and LAN IPv4 private ranges for your host address pool are set.
Finally, your internal DHCP should statically bind your admin computer MAC to a fixed LAN host IP to further reduce issues.
Personally, I always build my NAS from scratch, as I have lost count of the number of problems web-GUI have caused over the years. =3
Dedicated appliances are the way to go for the most important parts of your setup. I've always had my router as an appliance because I don't like the idea of my network failing due to something going wrong with the server that runs a bunch of other things that are less important. I also have Home Assistant running on a dedicated machine because that's also important.
Btw you do also need to be careful with opnsense. I was years behind on updates for mine because every time I updated I assumed that it would bring me up to date with the latest version. But opnsense has to install the upgrades in order. After you reboot you need to check again for updates and repeat until there's no more to install.
I don't bother with virtualization, and use the machine at the edge of my network as router, email server, Web server, DNS server, and countless or other things such as hostapd.
An x86 mini PC can run all this without breaking a sweat; using separate appliances seems very wasteful. That being said, I configure everything in DIY mode, and don't rely on GUIs or other similar things that increase the attack surface considerably.
I used to try to combine everything, but now I don't. Separate appliances isolates issues to a subset of services. If everything is on a single PC and that one dies or even just needs a reboot, everything goes down.
Fair enough and I think you have done the right thing - opnsense is pretty decent - and the clear delineation between collision domains helps avoid showing too much ankle to the internet 8)
I think your initial setup was perfectly valid. Then you diagnosed a fault and fixed it with aplomb, in a way that you could verify. The key point is: "in a way you could verify" and you failed safe. Well played.
Proxmox itself has a useful firewall implementation too, although it takes a bit of getting used to because you can set it at the cluster, host and VM levels. I personally love it because it is easier to manage than individual host based firewalls, which I also do, but I'm a masochist! For smaller systems I generally use the cluster level to keep all the rules in one place.
This is an excellent post and great reference material. I’ve done this a few times before and the information was scattered all over the place. I appreciate the clear and concise writing here. I even added it to my HN favorites - a rare accolade!
One thing I’d add, is that the best explanation I’ve ever seen for this, is the famous diagram [0] on Wikipedia of the netfilter API — I remember when I saw that, everything clicked into place. I’m not sure how up to date it is now, but it’s really good.
[0] https://commons.wikimedia.org/wiki/File:Netfilter-packet-flo...
The wiki diagram helped me too, thanks!
One thing I did not understand before: why SNAT must happen at POSTROUTING?
Because the exit interface is only known after the routing decision... before that kernel does not know which source IP to write
this visual schematic made it click for me - https://vectree.io/c/linux-netfilter-packet-flow-tables-chai...
Are there any preconfigured images/installers available for a major Linux distro to turn them a router with safe and sensible defaults?
I know there is OpenWrt, but my experience is that is more geared toward running on embedded wifi hardware than an x86 machine. The x86 install comes with a tiny root partition that's actually pretty difficult to resize, for example, and upgrades are quite brittle compared to standard Linux distros.
And there's also pfSense and OPNsense, but these run on FreeBSD which seems to lag behind Linux for hardware support. There's no support for the Aquantia AQC113 NIC, for example (although it looks like this may finally have been added in the last month or so).
Something like an Ubuntu Appliance [1] would be quite nice.
[1] https://ubuntu.com/appliance
The best is likely Vyos. It acts quite similarly to routers from the likes of Arista/Cisco/Juniper.
https://vyos.io/
Ipfire and Untangle seems suitable for your use case
Those look pretty cool too. =3
FreeBSD probably supports the hardware you have. If not, just buy the hardware that supports FreeBSD.
Modified Ubuntu LTS server image will work, and a minimal Debian kernel will have far less bloat. Note pfSense/FreeBSD is fairly robust, and a mature project.
Keep in mind most network appliances have dedicated hardware hand-off adapters, and so the CPU isn't involved in routing once the connection is setup. It is why people can use a $30 SoC, and still be able to saturate several 10Gb/100Gb ports. =3
While I run Linux on my production workstation, I use OpenBSD as my router and firewall at home. I find the configuration of OpenBSD for this a lot more simple and everything that's needed, even for IPv6, is in the base install.
I feels wrong to not mention IPv6 in 2026.
- net.ipv6.conf.all.forwarding=1
- nftables is default to `ip` family which only applies to IPv4. Setting it to `inet` will allow rules to apply to both IPv4 & 6; or `ip6` for IPv6 only. You can skip NAT rules, usually.
- dnsmasq: in addition to DNS and DHCP, turns on router advertisement with SLAAC. Some devices can get IPv6 address from stateful DHCPv6 server, others (e.g. Android) only work with SLAAC.
The FORWARD chain defaulting to ACCEPT is one of those things that bites people hard in incident investigations. A compromised host with ip_forward enabled silently becomes a pivot point — the attacker can route through it to reach internal networks that were never meant to be reachable from that segment.
Worth adding to any hardening checklist: if you don't explicitly need forwarding, set the default FORWARD policy to DROP and only whitelist the routes you actually want.
My very first exposure to Linux was in 2000, my school was about to throw away an old gateway computer and I took it home and turned it into router
As a kid with no AI, no google, it was quite a feat and I’m still very proud of it
Was my introduction into how the internet works and I’ll never forget working with ipchains
I remember enduring a lot of people in forums calling me a noob, but only after spending collective hours answering my dumb questions
I credit a big part of my moderate success in tech, to being familiar with stuff at just a tad bit lower of a level than the average bear
To my friend Sam who I haven’t talked to in 20 years, thanks for the idea
Stories like these make me sad when I think about chat control and age verification. Kids in the future may no longer be allowed to talk to random helpful strangers on the internet about computers and other technical topics, because apparently the internet is too dangerous for children.
Suppose the age verification checks stopped. Where exactly are these kids supposed to find "random helpful strangers" on the Internet that isn't also a major vector for predation or nonsensical AI spam?
The open friendly ~safe Internet died long ago.
Around the same time I set up an old pentium 80 that booted linux off a floppy to be a router. It ran for a few years later until Linksys wifi routers got cheaper.
People saying "the FOWARD chain defaults to ACCEPT" are missing the deeper point: with the kconfig most distros use, the filtering code doesn't even exist at all until you load the kernel modules!
At the lowest level, it is impossible to have a default DROP for forwarding, because nftables is an optional piece of the kernel that often isn't loaded.