Allow configuration of host firewall (nftables/iptables)

Feature Requests
,
1

Problem/Justification
It would be good if there was a supported way to configure the host firewall (nftables/nft) on TrueNAS SCALE. It does not need to support all of the functionality of nftables, such as NAT and forwarding, just the ability to set the default policies (inbound/outbound default ALLOW or DENY) and add explicit rules, perhaps with some predefined/automatic rules for supported services like NFS, SMB, and HTTP(S). “Defense in depth” is considered a cornerstone of a good security posture, and that includes combining host level firewalls with network firewalls.

Impact
This feature would have the impact of allowing all users to improve their security posture if they so desire. To avoid a negative impact to existing users who do not wish to use the firewall, the default could possibly remain to allow all traffic, requiring users to opt-in to more explicit firewall configuration.

User Story
A user could either explicitly block a known-bad host or network if they wish to keep using default ALLOW, or they could use default DENY with rules to allow access to specific ports from only the hosts and networks they determine should have such access. This would provide defense in depth, by not only allowing the user to not trust all hosts on their LAN but it can also provide protection against compromises or configuration errors on other parts of the network such as the network firewall. For instance, a configuration change on the network firewall could inadvertently allow inbound access from the world to any port on the TrueNAS system; with a host firewall on the TrueNAS system, the risk of such an incident is mitigated.

since TrueNAS already has its own middleware, directly creating rules for nft probably makes the most sense but ufw (default on debian) or firewalld are other options.

3 Likes
2

I think this is deserving of a bump…

1 Like
3

If I remember correctly, Truenas Team in the past said they dont plan to add firewall configuration.

But I can think of at least one good reason. Setting Apps (Docker) to be able only connect to LAN. Currently Apps can simply connect to internet the same as Truenas host. But maybe you would like to limit them only to LAN so you dont risk any unwanted outside communication.

4

If so, I think that’s a major mistake… It would not be that hard to add the functionality while providing major security benefits.

5

Just another important note.

Docker is important part of Truenas so any such firewall cannot break it.

And docker famously expects it’s the only thing managing firewall so you can’t use UFW or firewalld.

Also, docker uses iptables, so you can’t use nftables. Docker with iptables | Docker Docs

But I must say being able to configure chain docker-user would be nice.

  • DOCKER-USER

    • A placeholder for user-defined rules that will be processed before rules in the DOCKER-FORWARD and DOCKER chains.

But I guess I can put those rules in truenas init script.

6

According to Google Statics, IPv6 adoption in the Internet reached nearly 50%, and most home routers can’t filter connections for a single IPv6 host. Firewall should be necessary for all devices with a IPv6 address.

7

In my default docker+ufw setup in Debian, docker works fine with nftables (iptables-nft) and ufw. The only problem I encounter is docker bypassing ufw rules.

8

Some home routers, depending on configuration, may assign GUA IPv6 addresses to devices by default, so a TrueNAS could be exposed to the internet by IPv6. Granted, that’s basically the point of IPv6 - to provide connectivity without NAT; nevertheless it’s probably advisable to avoid this on a device meant for only private LAN access. The TrueNAS web interface can (should) be locked down by setting “Allowed IP Addresses” in the Advanced Settings, which can protect against IPv6 exposure.
But as yet another protective measure, you can also set the sysctl net.ipv6.conf.all.disable_ipv6=1 in Advanced Settings, which provides complete system-wide protection against inadvertent IPv6 exposure without needing a firewall.

9

But those normally also block all inbound connections just like they do for IPv4. So nothing is exposed, really.

1 Like
10

I think it depends whether the router is in native or passthrough mode for IPv6 doesn’t it? With the latter the router is acting more like a L2 bridge and you should be relying on some upstream device for firewalling. But anyway this is a bit off-topic; I was just saying that if you want to be 100% sure to avoid public IPv6 exposure, or want defense in depth, you can do it with existing functionality using a sysctl instead of a firewall.

11

Or you use a router as your edge device instead of a bridge.

12

What does that even mean? Sorry. Every consumer router I have seen in my life by default blocks all inbound connections - IPv4 or IPv6.

Publicly routable address (GUA) does not imply public accessibility. It never did, not even with IPv4. NAT is not a security feature. A firewall is.

13

This is not the correct answer. There is simply no reason to not have firewall capabilities and IPv6 is not going away.

Not everyone is a home user and in fact, those who need this most are enterprise users who are paying for this platform.

14

There is no reason to have them, and the reason not to have them is that it would take a great deal of development time that could be spent on more useful things (which would be just about anything).

Irrelevant.

Nonsense–their networks would already be properly segmented to restrict traffic to where it needs to be.

15

Defense in depth, not that much development time as most of the tooling already exists

not irrelevant at all. “just turn off IPv6” is a non-answer.

See again: defense in depth.