I'm trying to migrate from a x86-64 LXD container router to a raspberry 4 based one (as my x86-64 machine died) and I have this little issue where the OpenWRT instance is able to go to Internet, but other computers in the network aren't, even the raspberry host.
Note that when I try to ping www.openwrt.org tcpdump running in the openwrt container is able to capture the ICMP packets:
18:09:10.930058 IP 192.168.0.3 > wiki-01.infra.openwrt.org: ICMP echo request, id 6, seq 1, length 64
18:09:11.906188 IP 192.168.0.3 > wiki-01.infra.openwrt.org: ICMP echo request, id 6, seq 2, length 64
18:09:12.930253 IP 192.168.0.3 > wiki-01.infra.openwrt.org: ICMP echo request, id 6, seq 3, length 64
18:09:13.956161 IP 192.168.0.3 > wiki-01.infra.openwrt.org: ICMP echo request, id 6, seq 4, length 64
18:09:14.978220 IP 192.168.0.3 > wiki-01.infra.openwrt.org: ICMP echo request, id 6, seq 5, length 64
If my memory serves well I had this very same problem back in the x86-64 when I tried to create a new container with 20.02 or a newer 19.07 and I'd get the very same problem.
Unfortunately, I didn't mess with the firewall. It's something else.
The raspberry host has a bridge network device attached to the ethernet port. It's address is set statically. Then there's a vlan device that is passed to the container.
The routes in the container look OK to me:
~ # ip route
default via 87.235.0.10 dev pppoe-wan
87.235.0.10 dev pppoe-wan scope link src 46.27.180.242
192.168.0.0/24 dev eth0 scope link src 192.168.0.101
config: {}
description: ""
devices:
eth0:
name: eth0
nictype: bridged
parent: br0
type: nic
eth1:
name: eth1
nictype: macvlan
parent: ont
type: nic
root:
path: /
pool: default
type: disk
name: router-iface
And this is the network config on the raspberry host. Note that my ISP requires me to use PPPoE with a tagged VLAN. Tagging inside the container does not work in the raspberry container while it did work in my x86-64 containers.
Indeed, looks exactly like that... very weird yet interesting.
So, following those links it ultimately seems to depend on the host's environment, and not on fw3 itself. In my experience I haven't had such an issue on Debian 11 host and plain lxc v4 (and now that i recall on Debian 10 and lxc v3 neither...).
I'm using Ubuntu 20.04 and LXC 4.0.7. Tried switching over to netfilter and the issue persists. In Debian 11-based DietPi I get the same behaviour but there's no iptables or netfilter.
What image are you using?
I'm using the one from linuxcontainers.org, which recently switched to the stock OpenWRT armvirt tarball. cvmiller's repo contains an init.sh script which reboots the firewall, and that makes me think some people (me included) did not experience this issue earlier because it was patched at the image level.
Needless to say, if I add cvmiller's firewall restart snippet inside a custom startup script, everything sort of works.