Networking - Debian 13 instances not getting IP from DHCP/SLAAC?

Hi,

I’m using Incus with an un-managed bridge. The bridge (lxContBBR0) is configured on the host via NetPlan, where it gets IP details for the host via a DHCP server on the LAN.

That all works fine. I’m now trying to get Debian 13 LXC instances to pick up IPv4 and IPv6 off an existing server on the LAN. Unfortunately, they don’t seem to get an address, and I’m not sure if it’s a firewall issue, Incus host confg issue, or the config of the networking in the instances themselves.

I’ve passed the linux bridge (lxContBBR0) through to the default profile:

description: Default Incus profile
devices:
  eth0:
    nictype: bridged
    parent: lxContBBR0
    type: nic

The profile appears to have correctly associated it to the profile and instance that is using it:

incus network list
+------------+----------+---------+------+------+-------------+---------+-------+
|    NAME    |   TYPE   | MANAGED | IPV4 | IPV6 | DESCRIPTION | USED BY | STATE |
+------------+----------+---------+------+------+-------------+---------+-------+
| docker0    | bridge   | NO      |      |      |             | 0       |       |
+------------+----------+---------+------+------+-------------+---------+-------+
| eno1       | physical | NO      |      |      |             | 0       |       |
+------------+----------+---------+------+------+-------------+---------+-------+
| enp5s0     | physical | NO      |      |      |             | 0       |       |
+------------+----------+---------+------+------+-------------+---------+-------+
| lo         | loopback | NO      |      |      |             | 0       |       |
+------------+----------+---------+------+------+-------------+---------+-------+
| lxContBBR0 | bridge   | NO      |      |      |             | 2       |       |
+------------+----------+---------+------+------+-------------+---------+-------+
| wlp6s0     | physical | NO      |      |      |             | 0       |       |
+------------+----------+---------+------+------+-------------+---------+-------+

(At this point in time there is just one other test instance running for me to work with: third)

incus network show lxContBBR0
config: {}
description: ""
name: lxContBBR0
type: bridge
used_by:
- /1.0/instances/third
- /1.0/profiles/default
managed: false
status: ""
locations: []
project: default

Config for ‘third’:

incus config show third
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Debian trixie amd64 (20260222_05:24)
  image.os: Debian
  image.release: trixie
  image.serial: "20260222_05:24"
  image.type: squashfs
  image.variant: default
  volatile.base_image: 818654532564845dbd056522a3fd953f094fdd4f9877facc9b84441e0768e2a7
  volatile.cloud-init.instance-id: b341474a-85ae-4fc7-9425-f835a2c6618e
  volatile.eth0.host_name: veth9e473f8b
  volatile.eth0.hwaddr: 10:66:6a:c6:b3:91
  volatile.eth0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.last_state.ready: "false"
  volatile.uuid: c7f89dd3-52b9-4d21-8c32-c9053bf89d77
  volatile.uuid.generation: c7f89dd3-52b9-4d21-8c32-c9053bf89d77
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

Here’s the networkd config from inside the Deb 13 LXC instance called ‘third’:

[Match]
Name=eth0

[Network]
DHCP=true

[DHCPv4]
UseDomains=true
UseMTU=true

[DHCP]
ClientIdentifier=mac

Anyone able to suggest what might be going wrong?

Thanks

More digging with wireshark on the host shows that restarting systemd-networkd in the Incus Deb 13 instance ‘third’, sends out a DHCP Discover over the bridge to the LAN, and the server on the LAN is responding with a DHCP Offer.

So, it seems like at least outbound traffic from the LXC instance works. I’m assuming now that it’s due to one or more of the following:

  • Firewall on host dropping the response
  • Firewall on the LXC instance dropping the response
  • Something wrong with the LXC instance’s networking config?

So, guessing it’s related to the Deb 13 LXC instance running unprivileged, as the systemd-networkd logs report a few non-permitted operations:
Feb 23 22:11:44 third systemd-networkd[217]: eth0: Configuring with /etc/systemd/network/eth0.network.
Feb 23 22:11:44 third systemd[1]: Started systemd-networkd.service - Network Configuration.
Feb 23 22:25:31 third systemd[1]: Stopping systemd-networkd.service - Network Configuration…
Feb 23 22:25:31 third systemd[1]: systemd-networkd.service: Deactivated successfully.
Feb 23 22:25:31 third systemd[1]: Stopped systemd-networkd.service - Network Configuration.
Feb 23 22:25:31 third systemd[1]: Starting systemd-networkd.service - Network Configuration…
Feb 23 22:25:31 third systemd-networkd[250]: Failed to increase receive buffer size for general netlink socket, ignoring: Operation not permitted
Feb 23 22:25:31 third systemd-networkd[250]: lo: Link UP
Feb 23 22:25:31 third systemd-networkd[250]: lo: Gained carrier
Feb 23 22:25:31 third systemd-networkd[250]: eth0: Link UP
Feb 23 22:25:31 third systemd-networkd[250]: eth0: Gained carrier
Feb 23 22:25:31 third systemd-networkd[250]: eth0: Gained IPv6LL
Feb 23 22:25:31 third systemd-networkd[250]: Unable to load sysctl monitor BPF program, ignoring: Operation not permitted.

Seems like this person ran into a similar issue, but not sure if/how they solved it:

EDIT: Seems to be a common issue, will have to keep reading:

Not the firewall on the host, that is now disabled.

Doesn’t seem to be any firewall in the container as neither ufw or firewalld services are running.

I’m starting to run out of ideas, other than trying a privileged container?

This host does have Docker installed, possible that is part of the issue?

Dear god, this turned out to be because the port on the network switch that the host is connected to was configured as a monitor destination for a SPAN. In Cisco SG land, that has an optional ‘network’ setting on the span destination port, which also allows the port to function as a normal switch port……The caveat to that being:

“mostly, enough that the host on the end works with it, but not a host on the end of it with LXC containers using a linux bridge to the host nic.”

FML.