back

by ValdikSS·4mo ago·view on hn ↗
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).

4 comments
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.

"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.

It may be possible that this has changed. Last year I built a device and crashed into the bridging weirdness when I wanted to use upstream dhcp. There was/is some funkiness lurking with bridging wifi to Ethernet- in particular with broadcasts that traverse the bridge.
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.

>> spectfully the scenario you want to present seems to change.

Man that is totally a fair point.

I feel like I’ve struggled with the tutorials on these configs so many times in my life that I’ve kind of munged several ideas together here. There’s so much subtlety to the iptables/nftables rules that I failed to understand for so long, that I forgot that some folks might not understand that WiFi has specific weirdness. You’re right- I open with routing as a topic, but I’m in a very specific nuance right away.

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?
Anyone in "your lan" (L2 of the interface, sometimes L3 like VPN). Your containers/VMs will be fully accessible from other machines in "LAN" (hosting provider infrastructure, or ISP infrastructure), despite no port forwarding/publishing configured.

Your IP could also be used to run DoS attacks on the internet, although in this case (compared to containers/VM access) the attacker won't be able to receive replies (one-way communication only, like the address spoofing). But if you also happen to configure NAT (MASQUERADE) without additional limits, anyone in "LAN" could use your machine as a router (use your IP address to access websites).

Such misconfiguration is rarely told about in the how-tos and guides, and it's pretty common to have "additional free IPs" on your VPS/dedicated this way :D

This is also true in case of manually crafted home routers (such as in this article, and misconfigured advanced routers like Mikrotik, OpenWrt, Cisco, etc): if you happen to unconditionally enable forwarding without firewall, and think that NAT will somehow block the access to your home LAN, that's not true. Your neighbor, connected to the same ISP switch, could just add the routing record to 192.168.0.0/24 via your router's MAC address and access your 192.168.0.0/24 LAN devices without restrictions (unless ISP specifically blocks such access).

Thanks! It's always scary when container technology fiddles with your network... I wonder how they can be at peace with such defaults. Another reason to stick with good old containerd units, I guess.
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.
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

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.