Passing a bridge to container

I’m trying to setup a firewall (OpenWrt) in a container.
Basic setup works as expected with no issues.
General architecture is like this:

Problems arose when I wanted to add WiFi to the mix.
Of course Wireless Adapter is attached to Incus server.

I first tried to pass it directly to OpenWrt “physical”, but that proved unfeasible because OpenWrt renames interfaces and that throws havoc with Incus (container cannot be stopped cleanly and restarting needs a full server reboot).

My next (current) attempt is to handle a full A.P. on Incus server using hostapd and to pass to OpenWrt container directly the bridge LAN+WiFi.

My current (working) setup creates a DHCP bridge (the only DHCP server is on Openwrt container) with the LAN interface, add WiFi using hostapd config and finally passing it “macvlan” to OpenWrt container.

This works and LAN can access OpenWrt and Internet (I am using it to write this post) but DHCP handling does not work and bridge cannot obtain an IP address; this effectively means Incus server is not reachable from LAN and it cannot reach the Internet (this means I need to go to physical console to control it and I cannot easily access it now and that’s the reason why I don’t include full configuration here).

I am unsure why DHCP fails, perhaps it’s simply that at startup, when DHCP request is done, OpenWrt container is not yet up-and-running.

I tried to give Incus server bridge a fixed address modifying the /etc/network/interfaces stanza from:

auto br0
iface br0 inet dhcp
    bridge_ports enxa0cec887415e


auto br0
iface br0 inet static
    bridge_ports enxa0cec887415e

and it makes the Incus server visible from LAN and Internet but completely disrupts Incus routing and no traffic seems possible from OpenWrt container and host (and thus the whole network falls apart).

I did not change at all OpenWrt container setup that has:

incus config device add openwrt eth0 nic nictype=macvlan parent=br0

What am I missing?

Note: Incus server is a Debian Bookworm server installation (no graphical desktop), if it matters.

So given the host device is a bridge, why are you using nictype=macvlan instead of nictype=bridged?

macvlan is known for having some interesting corner cases when it comes to host to guest communications which may or may not cause some of the weirdness you’re seeing.

1 Like