Why my router forwards packets weirdly?

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 and its clients via DHCP, where my lan interface is

The first weird thing is that if I run dig @ 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 @ 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 on the router, and nc 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 to be for it no matter which interface it arrives on.

The firewall can still block them though.

1 Like

@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 @ 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.

Any idea why that could happen?

Yes the input chain that's correct.

By default "local service only" is enabled which probably is the reson you didn't get any answer.

Local Service Only

Limit DNS service to subnets interfaces on which we are serving DNS.


Indeed that was the cause, thank you very much!