LXC on Debian 11 - no IPv4 in containers

LXC
1

I am a LXC newbie and working on a project to configure LXC-hosts with ansible.

I have a working configuration to deploy a Debian 10.9 host and several containers, I use the debops-project ( https://docs.debops.org/en/master/ ) to define all the config.

Now the wish is to also test and prepare a deployment to Debian 11.x, as far as I learned this also leads to LXC-4 and the use of cgroups v2?

I try to adjust my setup to make things work, with a small ajdustment to the system capabilities I was able to create containers. I can attach to them, but they don’t get any IP-adresses via DHCP.

The customer would prefer to get a “modern” setup with cgroups v2 etc / so I would like not to disable cgroups v2, if possible.

Are there any documented differences in configuration? I also have apparmor set to “unconfined”, for example, but to me it seems quite obvious I miss something.

Addition: I already tested to lxc-create containers on the host itself, without any ansible. Same result.

Thanks for any pointers on this. For sure I will provide more logs etc if necessary.

EDIT: the container hang at “Raise network interfaces” at start, the NIC comes up, but without IP, route, DNS. bridge lxcbr0 on host is UP.

2

some infos:

# ss -ulpn
State                   Recv-Q                  Send-Q                                    Local Address:Port                                   Peer Address:Port                 Process                                             
UNCONN                  0                       0                                              10.0.3.1:53                                          0.0.0.0:*                     users:(("dnsmasq",pid=646,fd=6))                   
UNCONN                  0                       0                                             127.0.0.1:53                                          0.0.0.0:*                     users:(("dnsmasq",pid=627,fd=4))                   
UNCONN                  0                       0                                        0.0.0.0%lxcbr0:67                                          0.0.0.0:*                     users:(("dnsmasq",pid=646,fd=4))                   
UNCONN                  0                       0                                               0.0.0.0:68                                          0.0.0.0:*                     users:(("dhclient",pid=563,fd=9))                  
UNCONN                  0                       0                                                 [::1]:53                                             [::]:*                     users:(("dnsmasq",pid=627,fd=6))

# ps aux | grep dnsmasq
dnsmasq      627  0.0  0.0  15064  2464 ?        S    12:50   0:00 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service
dnsmasq      646  0.0  0.0  14912  2424 ?        S    12:50   0:00 dnsmasq --conf-file=/etc/lxc/lxc-net-dnsmasq.conf -s lxc.some.cloud -S /lxc.some.cloud/ -u dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=252 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative
root        1283  0.0  0.0   6544   660 pts/0    S+   12:52   0:00 grep dnsmasq
3

May be worth running tcpdump on lxcbr0 to see what’s going on.
This kind of issue usually comes from either a conflict preventing dnsmasq from working (though yours is running so somewhat unlikely) or firewalling accidentally blocking the traffic from hitting dnsmasq.

4

exactly. Stopping “ferm” on the host make the network work in the containers.
So I have to figure out which rules to add or remove on the host.
thanks

5

Excellent, glad you could track it down!

6

Well, it’s the direction, not the solution yet :wink:

7

I try to log dropped packages with iptables.

In journalctl I see lines like:

lxcbr0: port 1(vethTkDodk) entered blocking state
lxcbr0: port 1(vethTkDodk) entered forwarding state

correct?

8

That’s normal behavior for a port being added to a bridge, all ports join as blocking, then go to forwarding once the bridge believes there’s no loop.

9

ok, I understand. I try to log dropped packages now.

10

It seems to be related to the new iptables-nft used with Debian 11.
ferm might not be compatible … or needs improved configuration.

11

I switched back to iptables-legacy for now to stay compatible with ferm, as it is neatly integrated in our used ansible-roles.

So far the initial issue is solved for me, thanks.

Now I am looking into mounting a host-directory via lxc.mount.fstab …