I notice now that there’s some sort of issue on the host. The VMs on this host also have lost connectivity. Removing and recreating the bridge hasn’t helped. Something is up. The host itself has no connectivity issues.
ubuntu@test1201:~$ sudo systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● systemd-remount-fs.service loaded failed failed Remount Root and Kernel File Systems
No, other containers and VMs on the host are also broken. Container. Host.
So in these cases (and you’ll find several on these forums), the issue is almost always one of the following:
Some other process listening on the DHCP or DNS ports preventing LXD’s dnsmasq from starting.
Another firewall on the system preventing DHCP packets from LXD containers from reaching the DHCP server.
In your case you are using an unmanaged bridge, and so LXD won’t be running a DHCP/DNS server for your br0 bridge. This rules out 1.
So it is most likely another application on your host that is creating firewall rules blocking DHCP packets from being sent out of br0 to your network’s DHCP server.
I also note that in your host’s interface output you have a docker0 bridge, suggesting you have docker running. This is a big red light to me, as unfortunately Docker is known to modify the host’s firewall in such a way as to often cause DHCP issues.
Tom thanks so much for the detailed analysis, your valuable time is very much appreciated
You’ve given me several helpful leads here - I’ll take a detailed look at the firewall and also see what happens if I remove Docker from the host.
Thanks again Tom, that does seem to help. In a quick test a container that previously had no connectivity is now restored to digital glory. I’ll check more thoroughly and mark this thread resolved.
Reading the linked thread, I do agree there’s a race condition here. I observed that containers that are set to autostart would indeed get an IP after a host reboot most of the time, but container restarts would be the end of that.
Ah good. Yes they probably start before docker modifies the firewall. Although even if they are running OK before docker modifies the firewall, after that they won’t be able to renew their DHCP lease, so will eventually lose their IPs (assuming they are not statically configured).
You may want to tune that override rule slightly depending on your security needs, as that effectively allows all forwarded packets to/from anywhere to pass the firewall.
