This is a fresh install of 22.03.5 in an LXD container on Arch Linux host.
eth0 passed through (physical) to container - works fine, gets DHCP form ISP lan0 (192.168.18.1) - bridged to a bridge br0 on host (192.168.18.2), which is bridged to eth1 (no ip) Client(s) - connected to eth1 by cable.
This works fine (internet access) as long, as clients have manually set IPs (eg: 192.168.18.6), but DHCP doesn't work. I have been trying to fix it for two days, but found no solution or even cause. Everything seem to be set correctly - I have another setup which is almost identical (the only difference, br0 on host is bridged to 3 nics, instead of 1) and there were no issues like that. I also set up several other systems in this way in the past without issues.
The host 192.168.18.2 can ping 192.168.18.1
Other lan hosts can also ping it as long as their IP is set manually to 192.168.18.x
/etc/config/firewall
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
If you set an external host (i.e. one not on the same VM host) and set it with a static IP (i.e. 192.168.18.5, subnet mask 255.255.255.0, DNS 192.168.18.1, router/gateway 192.168.18.1), can you reach the internet using ping tests to 8.8.8.8 and google.com.
You may need to run something like tcpdump and then force a client to request/renew a DHCP lease so that you can see if the DHCP traffic is hitting br0 in OpenWrt, and what is happening (are responses happening, and if so, are they making it back out, etc.).
I think they were coming from the WAN port, as the IPs seen in details were 192.168.7.x range (the wan port is connected to my production lan, which is run by another openwrt (the one that works).
I unplugged the cable from WAN and repeated the exercise with the same results, except not instead of 192.168.7.x ip, they are 0.0.0.0 in most cases:
Yeah.... check to see that tcpdump is looking at the right interface.
Running OpenWrt in VMs can be tricky insofar as getting the interface I/O to work properly. Your config appears to be okay and would be expected to work... so I'm thinking that there is something happening at the VM level that is impacting the situatoin here.
@shdf suggested to try a snapshot, but that didn't fix things. But then I tried 21.02, and now the clients do get IPs from DHCP. Finally! There must have been some regression in 22.03 recently, as I am running 22.03.3 r20028-43d71ad93e on another machine, and it works flawless.
The problem is, now my clients (nor openwrt vm, or the host) can access the internet. 192.168.7.1 cannot be reached.