My router has a bridge (br-office) that contains eth0.3 and eth3, and also has an interface (office) bound to that bridge to give it 192.168.2.1/24 and its clients 192.168.2.100-200 via DHCP, where my lan interface is 192.168.1.1/24.
The first weird thing is that if I run dig @192.168.1.1 google.com on an office machine (connects to eth3), the packets never show up on the router's br-lan interface. The query and answers instead show up on the br-office interface. If I I ask Dnsmasq to not listen on office (but still listen on lan), running dig @192.168.1.1 google.com on the office machine blocks forever.
It seems the DNS query is never forwarded to the lan interface.
I also did another experiment, where I ran nc -l -p 5050 192.168.1.1 on the router, and nc 192.168.1.1 5050 on the office machine (eth3). nc on the office machines exited immediately, and tcpdump listening on the router's br-lan said that after the 3-way handshaking, router immediately sent RST + ACK.
Any idea how I could make the router forward normally? I'm running OpenWRT 21.02 X86 on the router.
That's true. Packets aren't forwarded by the router if the destination is one of the router's own IP addresses. In that case they are delivered to the local dnsmasq process.
Yes this happens inside the kernel directly. The kernel considers a packet destined to 192.168.1.1 to be for it no matter which interface it arrives on.
@mikma@mk24 Thanks, that makes sense. I presume the packets go through the INPUT chain instead of the FORWARD chain in this case?
However, I don't quite understand why I couldn't get answers with dig @192.168.1.1 google.com on an office machine with Dnsmasq on the router stops listening on office (but still listens on lan). The office interface uses "accept" has default input policy, and I don't have individual rule to block input packets on that interface.