I’m not asking why IP forwarding is enabled at all—I have Docker enabled (via “Apps” service), so forwarding is expected to be enabled for Docker to route to and from the containers.
I’m also not asking for more firewall control in the UI. (I do think this should exist, and I voted for the relevant feature request, but that’s a larger question.)
I am asking if anyone knows why TrueNAS configures iptables to allowing all forwarding (default ACCEPT) rather than just what Docker needs (default DROP).
This is quite surprising to me for an “appliance distro”, as it means as soon as you enable “Apps” (custom or packaged via TrueNAS), the relevant machine will happily route elsewhere, e.g., to the Internet, or other LAN subnets (if it has an address on multiple interfaces).
As a sanity check that I wasn’t missing something, I took another machine on the same subnet, gave it a static address and a default route of the TrueNAS box (IPv4 only, with IPv6 disabled for a simpler test), and was able to route to the Internet via TrueNAS. It’s not hard to change the default FORWARD policy in an init script to prevent this… but it wasn’t at all obvious to me that I’d need to do so in the first place.
Thoughts? I could file a bug for this, but it’s not clear if anything’s really wrong here: TrueNAS enables Docker on request, Docker enables IP forwarding, and Linux forwards packets according to the default iptables policy, so every individual player is doing what they should. (And AFAICT, it’s been this way forever without bothering anyone.)
On the other hand, filing a feature request and asking people to vote for “flip the default FORWARD policy” seems silly, especially when there’s already a larger FR for “proper” firewall control in the UI.
TrueNAS may not be to blame here. I suspect this is inherited from upstream Debian. The only SKU where this may possibly be different is Enterprise with FIPS applied, but someone from iX will need to weigh in to confirm.
Indeed, you’re probably right. Last time I installed Debian Trixie, it also came with no firewall by default. I was lazy then and just installed ufw.
That’s part of why I’m torn about whether to report this as a bug. There’s something to said for tracking upstream Debian with minimal changes. It’s just that the end result is quite surprising to me. I knew that TrueNAS had no firewall rules set up by default, and I knew that Docker enabled IP forwarding… but I didn’t make the connection between the two until tonight.
I think it’s a bit different on vanilla Debian, because there you know you’re getting a pretty minimal install by default, and also e.g. if you install Docker that’s a conscious choice. Whereas with TrueNAS, someone could just install it, enable “Apps”, and hypothetically not even know they’re using Docker at all, nor that it enables IP forwarding under the hood. So I find this default a fair bit less intuitive for TrueNAS than I do for Debian….
One thing that’s odd here is that Docker claims to change the FORWARD policy to DROP automatically when it enables forwarding with iptables management enabled in the Docker config (which TrueNAS has). But that doesn’t seem to take effect on TrueNAS for some reason… maybe something else in the system is enabling forwarding sooner and not triggering that logic in the Docker daemon?
The relevant PR claims a policy of DROP “results in networking for VMs getting broken”, but:
This doesn’t seem to be the case for me with a VM bound directly to a VLAN interface. I haven’t tried with a bridge, but suspect it’s true there as then the OS is involved in forwarding.
Even so, shouldn’t TrueNAS be setting targeted iptables rules to allow VM communication (like Docker sets rules to allow routing to and from containers) rather than just allowing all forwarding? The middleware knows about and manages the bridges, so it should be able to manage ACCEPT rules for them.
(In any case, if TrueNAS really wants to override the default Docker behavior, setting ip-forward-no-drop in /etc/docker/daemon.json is probably cleaner, and would make it a bit easier to get an override in an init script to stick for users that want.)
I did end up filing a bug for this (Jira), because it also turns out TrueNAS forces the policy to ACCEPTafter both the pre- and post-init script runs. Of course, the user can just remove the systemd override that TrueNAS uses, but that’s not going to survive across upgrades, etc.
