Aha!
root@HOLODECK:~# lxc info | grep 'firewall:'
firewall: nftables
root@HOLODECK:~# nft list ruleset
Command 'nft' not found, but can be installed with:
apt install nftables
root@HOLODECK:~#
It’s a minimal desktop installation of Groovy, I didn’t touch anything firewall related other than:
ufw enable
As far as I understand it’s still the default way to interact with firewall, regardless of underlying technology.
If when LXD started there were no iptables rules active, then it would prefer to use nftables if the kernel is recent enough (and the tool is bundled in the snap).
If after that additional iptables rules are added, then you can end up in a mixed environment.
LXD tries to detect various combinations and make the ‘best’ decision at start up, and after that its own rules it adds can influence its driver choice on subsequent start up.
To further complicate matters, nftables provides an iptables shim compatibility layer, except its not fully compatible with iptables or ebtables, so in that scenario we would prefer nftables too.
The logic is here:
Can you install nftables sudo apt install nftables and then try listing the ruleset again.
I recreated the issue.
So on Groovy, installing ufw and using its default configuration will use the iptables shim to insert nftables rules.
So LXD then uses nftables.
Installing nftables package allows you see both the rules added by UFW and by LXD.
However in its default configuration ufw drops all incoming traffic.
Although LXD has added allow rules for DHCP and DNS, these are still blocked because, as per nftables documentation: Configuring chains - nftables wiki
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.
For more details on using ufw with LXD see
@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.
@stgraber So for example LXD creates this:
table ip lxd {
chain in.lxdbr0 {
type filter hook input priority 0; policy accept;
iifname "lxdbr0" tcp dport 53 accept
iifname "lxdbr0" udp dport 53 accept
iifname "lxdbr0" udp dport 67 accept
}
chain out.lxdbr0 {
type filter hook output priority 0; policy accept;
oifname "lxdbr0" tcp sport 53 accept
oifname "lxdbr0" udp sport 53 accept
oifname "lxdbr0" udp sport 67 accept
}
chain fwd.lxdbr0 {
type filter hook forward priority 0; policy accept;
oifname "lxdbr0" accept
iifname "lxdbr0" accept
}
chain pstrt.lxdbr0 {
type nat hook postrouting priority 100; policy accept;
ip saddr 10.63.37.0/24 ip daddr != 10.63.37.0/24 masquerade
}
}
and UFW (via the iptables shim) creates this:
table ip filter {
chain INPUT {
type filter hook input priority 0; policy drop;
}
chain FORWARD {
type filter hook forward priority 0; policy drop;
}
chain OUTPUT {
type filter hook output priority 0; policy accept;
}
}
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
See our page in the docs about this also:
@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 (91.189.88.142), connection timed out Could not connect to
archive.ubuntu.com:80 (91.189.88.152), connection timed out
[...snap...]
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 (91.189.88.142) 56(84) bytes of data.
64 bytes from aerodent.canonical.com (91.189.88.142): icmp_seq=1 ttl=50 time=58.3 ms
64 bytes from aerodent.canonical.com (91.189.88.142): icmp_seq=2 ttl=50 time=66.4 ms
^C
root@test:~# curl -m 30 archive.ubuntu.com
curl: (28) Connection timed out after 30000 milliseconds
Ah you also need to allow routed traffic to traverse from lxdbr0 to the external network using:
sudo ufw route allow in on lxdbr0
Works like a charm
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.
LXD will prefer using nftables if there are any nftables rules active (including its own) even if there are also xtables legacy rules active.
So to force LXD to go back to xtables legacy (assuming there are already xtables rules present) is to run:
sudo nft flush ruleset
sudo systemctl reload snap.lxd.daemon
Uninstalling UFW and reinstalling it with snap seems to have resolved the issue for me.
sudo ufw disable
sudo apt remove ufw
sudo apt purge ufw
sudo snap install ufw
sudo ufw enableI 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.
that worked, thx
it worked for me also, LXD running on Fedora 35. Thanks a lot.
Sorry about reviving an old thread, but I just want to add some helpful tip here. If you are using Ubuntu 22.04 and nat=true in port forwarding, I’ve discovered that you’ll also need:
ufw route allow out on lxdbr0
Otherwise, the latest ufw blocks traffic that tries to get out on lxdbr0 (which is only true if nat=true is used in forwarding a port). Also, the rule above is kinda too permissive - you may want to specify ports that are relevant.
When I upgraded from 20.04 to 22.04 Jammy, lxd stopped working. It didn’t hand out IPv4 addresses. This solution worked for me. Thank you.
yes this helped me when i upgraded the host but when i upgrade a container from Debian 10 to 11 this solution stopped work for me. I tried disabling reseting reinstalling with snap version the ufw firewall also tried to disable lxd firewall and still doesn’t get ipv4 from lxdbr0 to eth0 into container (btw i also tried to use macvlan type instead of nic or whatever still nothing) also i uninstall docker to prevent conflict or whatever still not getting this f ipv4 address