Unmanaged bridge with VLAN filtering and DHCP not working

[bot14412]

Hello all,

I have created a Linux bridge with vlan filtering activated, so that it allows untagged vlan 20 and tagged vlan 40. My goal is to use untagged 20 for the host and tagged 40 for containers. To achieve this I have created a podman network as follows:

sudo podman network create -o mode=unmanaged -o com.docker.network.bridge.name=br0 -o vlan=40 --disable-dns --ipv6 --ipam-driver=dhcp vlan40

When I create a container with this network, it gets an IP on the untagged vlan:

sudo podman network inspect vlan40
[
     {
          "name": "vlan40",
          "id": "5c321f8411b921a2ee147d960ca14ddc8f99f07aa758952cba68f693b38c3bf4",
          "driver": "bridge",
          "network_interface": "br0",
          "created": "2025-07-31T07:46:53.478723003+02:00",
          "ipv6_enabled": true,
          "internal": false,
          "dns_enabled": false,
          "options": {
               "mode": "unmanaged",
               "vlan": "40"
          },
          "ipam_options": {
               "driver": "dhcp"
          },
          "containers": {
               "89e5c2b50b7bd2e71ddfa2079d582ef57d35ce4530d2efebe390415ef83846ff": {
                    "name": "debian",
                    "interfaces": {
                         "eth0": {
                              "subnets": [
                                   {
                                        "ipnet": "10.10.20.41/24",
                                        "gateway": "10.10.20.1"
                                   }
                              ],
                              "mac_address": "ce:43:8d:4b:3a:f9"
                         }
                    }
               }
          }
     }
]

I tried to dump some traffic and I came accross this:

14:10:07.527530 ce:43:8d:4b:3a:f9 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 40, p 0, ethertype IPv6 (0x86dd), :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
14:10:07.568956 ce:43:8d:4b:3a:f9 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 376: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ce:43:8d:4b:3a:f9, length 334
14:10:07.744183 ce:43:8d:4b:3a:f9 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 40, p 0, ethertype IPv6 (0x86dd), :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
14:10:07.820961 1c:0b:8b:16:b2:ed > ce:43:8d:4b:3a:f9, ethertype IPv4 (0x0800), length 62: 10.10.20.1 > 10.10.20.41: ICMP echo request, id 58840, seq 0, length 28
14:10:07.820962 1c:0b:8b:16:b2:ed > ce:43:8d:4b:3a:f9, ethertype IPv4 (0x0800), length 342: 10.10.20.1.67 > 10.10.20.41.68: BOOTP/DHCP, Reply, length 300
14:10:07.821233 ce:43:8d:4b:3a:f9 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 388: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ce:43:8d:4b:3a:f9, length 346
14:10:07.823259 1c:0b:8b:16:b2:ed > ce:43:8d:4b:3a:f9, ethertype IPv4 (0x0800), length 342: 10.10.20.1.67 > 10.10.20.41.68: BOOTP/DHCP, Reply, length 300
14:10:08.196057 ce:43:8d:4b:3a:f9 > 33:33:ff:4b:3a:f9, ethertype 802.1Q (0x8100), length 90: vlan 40, p 0, ethertype IPv6 (0x86dd), :: > ff02::1:ff4b:3af9: ICMP6, neighbor solicitation, who has fe80::cc43:8dff:fe4b:3af9, length 32
14:10:09.220067 ce:43:8d:4b:3a:f9 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 40, p 0, ethertype IPv6 (0x86dd), fe80::cc43:8dff:fe4b:3af9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
14:10:09.220126 ce:43:8d:4b:3a:f9 > 33:33:00:00:00:02, ethertype 802.1Q (0x8100), length 74: vlan 40, p 0, ethertype IPv6 (0x86dd), fe80::cc43:8dff:fe4b:3af9 > ff02::2: ICMP6, router solicitation, length 16
14:10:09.860033 ce:43:8d:4b:3a:f9 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 40, p 0, ethertype IPv6 (0x86dd), fe80::cc43:8dff:fe4b:3af9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28

It seems as if ipv6 link-local negociation is done on vlan 40, but dhcp request is fired on untagged vlan.

Could you tell me if this is a misunderstanding on my part to properly configure the linux bridge / podman network, or if there's an issue with the dhcp driver.

Thanks in advance !

[Luap99]

Our DHCP server has no concept of the vlan currently, it makes its own raw socket requests based on the bridge interface we give it to so it makes sense that it doesn't work right now.

I think we really need to consider moving our DHCP requests into the namespace interface instead which then should follow the right settings automatically, because that would also fix #1156 and #1008 I think.

[blackdragoon26]

Hihi @Luap99 ,
I'd like to work at fixing this issue. Here's the approach I plan to implement:

I will modify the DHCP IPAM logic to execute the DHCP client inside the container's network namespace (using setns()), so that:
The DHCP request is sent from the container's veth interface (eth0)
The VLAN tag (e.g., VLAN 40) is applied correctly by the kernel
The DHCP lease will be associated with the correct VLAN
This should allow DHCP to function correctly in unmanaged bridge setups with VLAN filtering, as intended.

Let me know if this approach work, or else please lend me your insight to dig deep in it.

Regards
Sankalp Jha

[Luap99]

Yeah it needs to be done in the netns then it the kernel takes care of the vlan I think. Although not quite sure since it uses raw sockets and ebpf there.

But also I think one issue that the socket is opened and owned by the mozim lib. And at least for a quick look there is the case where it must rebind which opens the socket in an async context not really under our control AFAICS so I am not sure how we would deal with that.