Question: Is dfw ready for nftables?
Closed this issue · 11 comments
Again sorry for my lack of knowledge of iptables.
I updated my host to Debian Buster (10) where nftables is the default backend (at least for new installations), my old rules are still in place and dfw is working.
If I switch to nftables (https://wiki.debian.org/nftables) will dfw honor this change?
I have yet to work with nftables, so I really couldn't tell you. 😕
Under the hood the application expects an iptables binary to exist (which is included in the Docker image), which will internally communicate with the netfilter kernel module. Since this module didn't change, it presumably doesn't matter what frontend the distribution provides. But AFAIK nftables-based distributions no longer have to provide the default chains that were present with iptables, like INPUT in the filter-table, which can cause issues if dfw's assumptions aren't fulfilled.
If you are able to test it, I'd love to hear some feedback on how it worked out for you. I can't promise anything, but I would definitely like to add support for nftables-based systems.
Sorry for my delayed answer, I was busy.
I set up a new Debian Buster OS which uses nftables. If dfw sets rules they appear in the legacy settings. So in my point of view (with very little knowledge of iptables) dfw is not really ready to use nftables. I think it will be confusing for users with a fresh Buster because host OS settings will be placed in the iptables-nft and dfw settings in the iptables-legacy "section" (readme warns about mixing those two).
Just to give you an update: I have been working on nftables support on-and-off for the last few weeks and I've been making some good progress (this has also given me the chance to look into some refactorings I wanted to do for quite some time, and looking into IPv6-support, too).
It is not quite ready for prime-time yet, but I hope to get a working state that I'm feeling comfortable to share within the next week or two. It will probably be somewhat of a beta, but I'll try to provide whatever documentation is required for transitioning off of an iptables-setup, should you have the chance to try it.
I'll keep you posted!
Sorry I didn't update you yet, but I assume you have seen already: I release dfw v1.0 with support for nftables. It seems to be working just fine for me, but would love a quick response if it is working for you, too! 👍
Thanks. I'll migrate my settings and report back (just noticed that my lab wasn't working due to autoupdate feature, replacing my current dfw container).
I played around a bit, currently I'm stuck. Using a blank dfw.toml file -> working.
setup my old toml file, converting the relevant parts to nftables -> error
Sep 23 21:25:44.255 INFO Applying rules (using nft), module: dfw::process:1099
dfw | Sep 23 21:25:44.294 ERRO Encountered error, error: NFTables error:
dfw |
dfw | /tmp/.tmpjqR70P:17:1-117: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter input meta mark and 0xdf == 0xdf accept comment "DFW-MARKER:defaults;filter;input;meta-mark"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:18:40-63: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter input ct state { related, established } accept comment "DFW-MARKER:defaults;filter;input;ct-state-relatedestablished-accept"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:18:40-63: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter input ct state { related, established } accept comment "DFW-MARKER:defaults;filter;input;ct-state-relatedestablished-accept"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:18:1-149: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter input ct state { related, established } accept comment "DFW-MARKER:defaults;filter;input;ct-state-relatedestablished-accept"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:19:1-117: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter input ct state invalid drop comment "DFW-MARKER:defaults;filter;input;ct-state-invalid-drop"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:20:1-121: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter forward meta mark and 0xdf == 0xdf accept comment "DFW-MARKER:defaults;filter;forward;meta-mark"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:21:42-65: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter forward ct state { related, established } accept comment "DFW-MARKER:defaults;filter;forward;ct-state-relatedestablished-accept"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:21:42-65: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter forward ct state { related, established } accept comment "DFW-MARKER:defaults;filter;forward;ct-state-relatedestablished-accept"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:21:1-153: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter forward ct state { related, established } accept comment "DFW-MARKER:defaults;filter;forward;ct-state-relatedestablished-accept"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dfw | /tmp/.tmpjqR70P:22:1-121: Error: Could not process rule: No such file or directory
dfw | insert rule inet filter forward ct state invalid drop comment "DFW-MARKER:defaults;filter;forward;ct-state-invalid-drop"
dfw | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dfw | , module: dfw:503
Any idea where to look for the error?
Can you provide the output of nft list ruleset when run on your host? You can strip all rules from the output in case you don't want to show the entire ruleset here, the important information is in the available tables and the chains within those.
Judging from the errors you have configured the defaults.custom_tables key to { name = "filter", chains = ["input", "forward"] }. This says that DFW should expect a inet-table with name filter to exist, and this table should have two chains named input and forward. This matches the default configuration on (I guess) most repos, but might not match your config.
The error states though that either the chains or the table doesn't exist.
I started over and now it is working, no idea what went wrong the first time.
But one "bug" left. You implemented source net filtering within wider_world_to_container.rules
external_network_interface = "ens3"
source_cidr = ["127.0.0.0/8", "172.16.0.0/12"]
This isn't working any more
Indeed it isn't, but from what I can see only as a side-effect: I added some IPv6 support but used the IPv4 addresses in the IPv6 context -- which obviously isn't right.
I'm working on a fix and will let you know once it is ready! 👍
I merged what I believe should fix your issue -- at least it worked correctly on my machine. Knowing Docker Hub, it could be up to 2 more hours until the latest-tag is updated.
Pulled the latest image, source_cidr is working again. Thank you!!