Firewall backend selection logic

[Franck-Sorel]

Description

The firewall detection logic incorrectly tries to infer which iptables backend is active by checking which backend contains rules. This approach is fundamentally flawed because iptables-nft and iptables-legacy share the same kernel netfilter ruleset.

Steps to Reproduce

1. System configured with update-alternatives to use iptables-nft as default
2. System has rules from multiple sources (e.g., Kubernetes using iptables-nft, Multipass using iptables-legacy)
3. Observe that Multipass uses iptables-legacy despite system preference being iptables-nft

Expected Behavior

Multipass should respect the system's default iptables configuration and use the backend that /usr/sbin/iptables points to.

Root Cause

The current detect_firewall() function tries to determine the active backend by checking if rules exist in each backend. This fails on hybrid systems because both backends share the same ruleset - rules added via one backend appear in both.

The Fix

The fix implements a two-level detection strategy:

1. Primary: Check /usr/sbin/iptables symlink to determine system preference
2. Fallback: Only use rule presence detection when system config is unavailable

This properly handles systems where:

• Multiple tools use different iptables backends
• Both backends have rules present
• System configuration indicates a preference

Related Files

• src/platform/backends/qemu/linux/firewall_config.cpp

See PR #5114 for the implementation.

[Franck-Sorel]

Hello @ricab, this quick fix on the firewall logic improve an area in the codebase. Can you please look at it ?? Thanks.

we would be glad to have @sharder996 assistance on this.

[ricab]

Hi @Frank-Sorel, I don't think that diagnostic is correct. For context, this was discussed during review. Most relevant comments:

• [qemu] Support nftables #2103 (comment)
• [qemu] Support nftables #2103 (comment)

This approach is fundamentally flawed because iptables-nft and iptables-legacy share the same kernel netfilter ruleset

I don't think the claim holds. See how xtables-nft(8) even includes instructions for migrating:

To migrate your complete filter ruleset, in the case of iptables(8), you would use:

root@machine:~# iptables-legacy-save > myruleset # reads from x_tables
root@machine:~# iptables-nft-restore myruleset   # writes to nf_tables

And iptables-save under the nft alternative says:

Warning: iptables-legacy tables present, use iptables-legacy-save to see them

Furthermore, Multipass runs as a confined snap on Linux, so /usr/sbin/iptables resolves inside the snap's rootfs, not your host's. It's not a viable approach to detect the "system's default".

See also what this article has to say about mixing the two backends:

First of all, running legacy iptables and nftables rulesets in parallel is not a good idea at all. It is possible, but one may very likely run into all kinds of hard to diagnose problems so this may safely be considered a dead end.

It is generally not advised, but if you were in what you call a "hybrid system" and if you got it to work correctly with tables in both, then both would be available for use, right? A default is just what gets picked if no particular choice is made.

I am leaving this open for a while in case you there is something I am missing or you want to reply back. I do wonder what concrete problems you had that prompted you to open this issue and the corresponding PR. Do you have any? If so, could you please let us know by opening a new bug report and filling in the template with the details of what you observe. Thank you.