NOTE : If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn’t necessarily final. However, the same is not true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.
So you can get this working by allowing incoming traffic (which rather defeats the purpose of installing ufw):
ufw default allow incoming
Or you could add rules equivalent to those added in the lxd chains, to ufw to allow inbound DNS and DHCP.
@stgraber because of the way nftables allows multiple base chains to operate on a packet (those that have a netfilter hook in them), even if one of them accepts the packet, it may still be dropped later due to another chain’s rules and policies.
Because we create our own lxd chains with netfilter hooks. This means that if an application is using the iptables nftables shim and creates its own base chains with netfilter hooks and a default drop policy then our rules will not be final and packets will be dropped.
This makes it pretty tricky for two applications that create their own hook chains into netfilter to coexist as neither one can selectively accept traffic if the other has dropped all traffic.
One way around this would be for us to create another non-base chain inside a well-known table (like the one used by the iptables shim) and then add jump rules to the well-known chains it uses to give our rules a chance of accepting the packets before their policy kicks in.
We would need to add a rule to the filter table in the INPUT and FOWARD chains to jump into our own chains to stand a chance of the packets being allowed. However nftables doesn’t allow you to jump into a base chain (one that has a netfilter hook in it), and I’m not sure you can jump across tables either.
So to get compatibility with the iptables shim we’d need to add our custom chains to the filter table and then add rules to the INPUT and FOWARD chains to get our rules applied before the DROP policy kicks in.
This would only work with applications that use the filter table, and any other application that creates its own tables and sets up drop policies would cause the same problem again.
Yeah, I’m honestly not sure what’s the right thing to do here…
I’m not super optimistic about us putting workarounds in place to handle the compatibility xtables tooling. By definition this will cause issues as it’s trying to pretend that nft is xtables and so comes with the same issues around rule ordering…
I believe ufw was natively ported to nft recently so it may instead be better to see how we handle the rules generated by that version.
Cooperating properly with other native nft users and pushing distros to ship the native nft support in those tools when available feels like a more future proof way to handle this.
As you can see getting the various firewall implementations to play nicely together is a non-trivial task.
In the meantime these commands seems to suffice to allow traffic from lxdbr0 interface to the LXD host and for traffic from lxdbr0 to be routed to the external network without allowing all external inbound traffic:
sudo ufw allow in on lxdbr0
sudo ufw route allow in on lxdbr0
sudo ufw route allow out on lxdbr0
@tomp Thank you for getting to the bottom of that issue, I would have never solve it myself
Not quite. In my case, it makes container get IPv4 address. But then, inside the container, I still have networking issues.
root@test:~# apt update
Err:1 http://archive.ubuntu.com/ubuntu focal InRelease
Cannot initiate the connection to archive.ubuntu.com:80 (2001:67c:1360:8001::24). - connect (101:
Network is unreachable) Cannot initiate the connection to archive.ubuntu.com:80
(2001:67c:1360:8001::23). - connect (101: Network is unreachable) Could not connect to
archive.ubuntu.com:80 (188.8.131.52), connection timed out Could not connect to
archive.ubuntu.com:80 (184.108.40.206), connection timed out
root@test:~# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0@if14 UP 10.52.135.83/24 fe80::216:3eff:feb3:15db/64
root@test:~# ping archive.ubuntu.com
PING archive.ubuntu.com (220.127.116.11) 56(84) bytes of data.
64 bytes from aerodent.canonical.com (18.104.22.168): icmp_seq=1 ttl=50 time=58.3 ms
64 bytes from aerodent.canonical.com (22.214.171.124): icmp_seq=2 ttl=50 time=66.4 ms
root@test:~# curl -m 30 archive.ubuntu.com
curl: (28) Connection timed out after 30000 milliseconds
FYI, the ufw deb will follow update-alternatives so if it is setup for iptables-nft, then lxd using nftables is fine. IMHO, this should be true of any firewall software provided via the distro (ie, they should follow update-alternatives) and they should all agree to use xtables or nftables. AIUI, the problem here is that lxd was creating rules on the system when no firewall was in place and when the firewall was enabled, the nft backend was not setup as the default. To get out of this situation, one should be able to use the update-alternatives mechanism to use iptables-nft, then reboot (ufw will then use the nft backend (ie, there is nothing more to be done with ufw). A more complicated series of commands could be done to skip the reboot; I’m not sure if lxd can be made to use iptables-legacy/xtables after the fact).
Note 1: the ufw snap will use a similar algorithm as lxd, so it wouldn’t have this problem.
Note 2: the needed extra ufw route rules/etc are expected.
I can confirm that uninstalling UFW and reinstalling with snap resolves the issue of “No IPV4 addresses assigned to containers”. I just tested on a fresh installation of Ubuntu 21.10. No IPs assigned to new containers until after UFW was reinstalled with snap.
This may be because the ufw snap is using its own bundled iptables legacy backend rather than iptables nft backend used via the ufw apt package (because iptables on the host is actually using nftables). I don’t know for sure, but based on what we do with the LXD snap (we bundle both tools), I suspect that may not be a long-term solution.