Lxd bridge doesn't work with IPv4 and UFW with nftables

LXD
21

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.

1 Like
22

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
1 Like
23

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 enable
24

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.

1 Like
25

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.

1 Like
26

that worked, thx

2 Likes
27

it worked for me also, LXD running on Fedora 35. Thanks a lot.

1 Like
28

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. :slight_smile:

3 Likes
29

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.

1 Like
30

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

31

After finishing

sudo lxd init

Could the devs please give link to this https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_firewalld/#ufw-add-rules-for-the-bridge

sudo ufw allow in on lxdbr0
sudo ufw route allow in on lxdbr0
sudo ufw route allow out on lxdbr0

for all ubuntu snap installations. I was scratching my mind for ages until I found this.

32

Please can you open an issue https://github.com/lxc/lxd/issues so your idea can be discussed further.

33
34

For posterity and to perhaps help with the docs, I found that these finer-grained rules seem to work well when ufw is enabled, iptables-nft/ip6tables-nft are in use and when ipv4.nat: "true" (seen with lxc network show lxdbr0):

# for a guest to get an ip from the lxd host
$ sudo ufw allow in on lxdbr0 to any port 67 proto udp comment 'lxd: dhcp'

# for a guest to resolve hostnames from the lxd host
$ sudo ufw allow in on lxdbr0 to any port 53 comment 'lxd: dns/resolved'

# for a guest to have access to anything outbound (10.210.254.0/24
# found with: lxc network list | grep lxdbr0)
$ sudo ufw route allow in on lxdbr0 from 10.210.254.0/24 comment 'lxd: outbound'

The first two rules limit access from the guests to the host to only dhcp and dns while the 3rd rule allows access from the guests to the world (the last rule mimics the default behavior of ufw for the host, which is to allow all outbound (from ipv4 hosts; adjust if using ipv6)). Adjust as necessary for your environment.

Note, the above doesn’t have have a fine-grained equivalent of sudo ufw route allow out on lxdbr0. If you are wanting to allow traffic from outside the host to your guests, then additional rules are in order (eg, sudo ufw route allow out on lxdbr0 to 10.210.254.123 port 443 proto tcp comment "lxd: inbound to https server").

1 Like