Any gotchas to consider when running OpenWrt in container?

[jock (Jock Busuttil)]

I’m tinkering with OpenWrt in both containers and a custom built VM. Both appear to work as expected, which probably means I’m missing something

Can anyone (maybe @simos ?) point out any compromises when running a vanilla OpenWrt install (current version) in a container vs VM?

i.e. anything that just doesn’t work as intended

[PaddraighOS]

The main gotchas I’ve run into:

**Kernel modules**: The container shares your host kernel, so OpenWrt’s kmod-* packages won’t work unless the host kernel already has those modules. Hardware-specific offloading, custom drivers, that sort of thing is out.

**Network interfaces**: You need to explicitly pass through physical interfaces (via macvlan, ipvlan, or phys device type in Incus). OpenWrt expects to own its WAN and LAN interfaces. It won’t just see the container’s default eth0 as a real NIC.

**Capabilities**: The container needs NET_ADMIN at minimum for nftables rules to work. In Incus this usually means `security.privileged=true` or adding the capability explicitly. Without it, OpenWrt’s firewall startup will fail silently.

**What works fine**: dnsmasq (DNS/DHCP), nftables filtering within the container’s network namespace, the luci web interface, most OpenWrt packages that don’t touch hardware directly.

**What doesn’t work well**: Hardware offloading, SQM/QoS that relies on kernel schedulers, anything needing SYS_MODULE capability, bridge VLAN filtering at the hardware level.

In my experience containers are great if you’re using OpenWrt mainly as a DNS/DHCP server or software firewall in a lab. For actual router duties with real traffic shaping on physical interfaces, the VM route is more predictable.

[jock (Jock Busuttil)]

That’s tremendously helpful. Thank you for the clear breakdown. I would probably have not noticed the non-functional firewall until waaaay too late

[moonpiedumplings]

Are you sure ip/nftables doesn’t work in containers?

How much of iptables work inside containers?

It seems that some support for iptables exist inside (non-privileged) containers. For example, I have installed software in a container that installs a ufw firewall, and ufw prevents connections to ports from other containers. But I’ve also read in this forum, that fail2ban does not work inside containers, so you have to set it up on the host: Fail2ban for Wordpress on containers So, how much of iptables works inside a container? Why does ufw work, but fail2ban doesn’t work?

It seems to work based on this posts and some quick testing. Although, I am not passing through physical devices so that might be it?

[stgraber (Stéphane Graber)]

Yeah, iptables/nftables definitely work just fine in unprivileged containers.

They do net CAP_NET_ADMIN but they check for that capability against the network namespace and not against the entire kernel. Root in an unprivileged container absolutely has CAP_NET_ADMIN against its own network namespace.