Native support for nftables

[rforberger]

trafficstars

Is there any configuration option to configure dockerd / moby / containerd to use nftables natively for firewalling?

I have a debian machine with docker and nftables, but my docker iptables rules get overwritten by nftables once they get restarted / reloaded.

My alternatives are set to iptables-nft for iptables as per Debian 12.

Does docker support nftables?

Ideally I would want my nftables rules be dynamically merged with any docker firewall rules.

Thanks in advance.

[vasugoriya]

Migrate Docker to iptables-legacy: If nftables is causing conflicts with Docker's iptables rules, you can consider changing the default iptables backend from iptables-nft to iptables-legacy. This can be done by updating the alternatives configuration. However, keep in mind that this may not be a long-term solution, as support for iptables-legacy might eventually be phased out in favor of nftables.

update-alternatives --set iptables /usr/sbin/iptables-legacy update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

Use Docker Compose: If you're using Docker Compose to manage your containers, you can define custom network rules in your Compose file using the network_mode option. This allows you to manage network rules separately from Docker.

Here's an example of how you can define a custom network in your docker-compose.yml version: '3' services: myapp: image: myapp:latest network_mode: bridge # Other service configurations networks: bridge: external: true

[rforberger]

I don't have problems with nftables, but with docker's iptables implementation.

As from my understanding it is still using iptables right, as it creates iptables rules?

I don't want to migrate to legacy iptables-legacy backend.

If docker is already using nftables, why do my nftables the overwrite docker's iptables rules, when reloading?

[jeromecst]

If docker is already using nftables, why do my nftables the overwrite docker's iptables rules, when reloading?

If your nftables.conf contains flush ruleset, it will flush all previous rules (including docker's) when reloading

[trallnag]

Is this really a problem with Docker? As @jeromecst mentioned, if the primary nftables.conf contains flush ruleset, which is often the case, dynamically added rules will be removed.

One solution would be for Docker to write it's rules to a dedicated file and include this file from the primary nftables.conf.

[rforberger]

No.

[wcasanova]

As from my understanding it is still using iptables right, as it creates iptables rules? If docker is already using nftables, why do my nftables the overwrite docker's iptables rules, when reloading?

Actually docker does not use nftables natively, from debian 10 onwards nftables is the default framework, debian installs the iptables-nft package which translates iptables rules to nft rules.

[bluikko]

If docker is already using nftables, why do my nftables the overwrite docker's iptables rules, when reloading?

If your nftables.conf contains flush ruleset, it will flush all previous rules (including docker's) when reloading

Without flush ruleset all the rules will be duplicated since the new ruleset will just be added to the already existing chain.
I guess that could be worked around with just flush table / flush chain instead.

Do you have this working? Wondering because the iptables tools stop working after modifications with nft on EL9 -- is Docker still able to change its rules after direct modifications to nftables?

I believe the point of this issue is that sooner or later iptables wrappers will be deprecated and nftables is the only way forward.

[rforberger]

I didn’t try any longer. I think docker should natively understand nftables rulesets, but still iptables. Otherwise in my opinion it’s useless if you have an existing nftables ruleset and want to load the rules from docker into it.Or did I completely misunderstand the concept?Sent from my iPhoneOn 3. Apr 2024, at 13:26, bluikko @.***> wrote:

If docker is already using nftables, why do my nftables the overwrite docker's iptables rules, when reloading?

If your nftables.conf contains flush ruleset, it will flush all previous rules (including docker's) when reloading

Without flush ruleset all the rules will be duplicated since the new ruleset will just be added to the already existing chain. I guess that could be worked around with just flush table / flush chain instead. Do you have this working? Wondering because the iptables tools stop working after modifications with nft on EL9 -- is Docker still able to change its rules after direct modifications to nftables? I believe the point of this issue is that sooner or later iptables wrappers will be deprecated and nftables is the only way forward.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[ghost]

I agree with the author it's a mess to work like that on distro that use nftables as main way to manage firewall.

[cpuguy83]

nftables support is being worked on, however it is not a small change and cuts through just about every bit of the network stack.

[jeromecst]

In the meantime, destroy has recently been added on nftables. Consider using it inside your nftables.conf instead of flush ruleset to avoid flushing every docker rules upon reload.

https://git.netfilter.org/nftables/commit/?id=e1dfd5cc4c46514a84dd8a2063b45517b596e1ca

[jcmcken]

Just want to throw some comments in here. These are based on RHEL9 or compatible systems with a very simple network setup (single main interface eth0).

Installing iptables-nft package and running alternatives --set iptables /usr/sbin/iptables-nft gets you almost all the way there. (This allows dockerd to use the compatibility shims to automatically convert iptables to nftables)

The main problem is that dockerd does a few things which make it incompatible (or to be more accurate, when you translate Docker's generated rules through the NFT translation utilities, it spits out something incompatible):

• It tries to update the ip table (IPv4 only) instead of the inet table (IPv4 + IPv6). The latter is the default table. Because it's updating the ip and not the inet table, it wants to add an input chain to that table. But an input chain already exists on inet table. So the effect of this is that the entire ip table gets ignored since you can't have an input chain on inet and on ip at the same time
• It tries to reference chains with capitalized lettering such as FORWARD instead of forward. The default nftables identifiers for chains and other entities don't use upper case.

In my testing, if these two things are fixed, Docker would work with nftables pretty seamlessly using iptables-nft

Since this isn't supported currently, instead what we've had to do is create an /etc/nftables/docker.nft with the following process:

• Start Docker daemon and then run iptables-save > legacy-rules.txt
• Convert to NFT: iptables-restore-translate -f legacy-rules.txt > new-rules.nft
• Edit the rules and fix the issues mentioned above (inet, capitalization, etc.). You can remove some lines too, for example creation of inet tables, if that's already accomplished by the base rules.
• Move the rules to /etc/nftables/docker.nft.
• On RHEL, edit /etc/sysconfig/nftables.conf and add include "/etc/nftables/docker.nft"
• Run systemctl restart nftables to install the new rules.
• Run nft list rulset and validate everything merged correctly. In particular, the DOCKER* chains should be within the inet table, and the forward chain (not the FORWARD chain) should have updates.

The downside of this approach is dockerd is no longer responsible for making these updates automatically. So if the daemon's firewall design changes in some way, users now need to retrofit it to the above process

[FrankE-Aqura]

nftables support is being worked on, however it is not a small change and cuts through just about every bit of the network stack.

Is there an ETA for a release that supports nftables?

[initiateit]

nftables support is being worked on, however it is not a small change and cuts through just about every bit of the network stack.

Its not like we havent known nftables is replacing iptables for a long long time!

Still its nice to know thanks.

[FrankE-Aqura]

iptables and the iptables-nft package have been deprecated in RHEL 9: https://access.redhat.com/solutions/6739041 nftables is the default and recommended firewall in many distros now as well.

[TurnOffNOD]

The project netavark has nftables support now, and it claims:

Netavark is a rust based network stack for containers. It is being designed to work with Podman but is also applicable for other OCI container management applications.