[Solved] LAN-to-LAN port forwarding - possible?

[rhester72]

I have a bit of a strange use case.

I'd like to create a fw4 rule that states that any LAN-to-LAN communication targeting a LAN IP other than the router itself on port 53 be redirected to router port 53 - basically internal DNS hijacking. My use case is that I'm looking to wean devices on my network off of a separate Pi-Hole device without having to wait for them to re-DHCP en masse.

I tried something along these lines:

config redirect
        option src              lan
        option proto            tcp
        option src_ip           !192.168.1.1
        option src_dport        53
        option dest_ip          192.168.1.1
        option target           DNAT

and the rule is accepted, but never triggered. Is this even possible?

[psherman]

Here's a guide for dns hijacking... does this help?

https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns

[rhester72]

I tried this - it definitely correctly redirects WAN-targeted traffic (i.e. LAN traffic destined for example to 8.8.8.8:53 is properly redirected), but it seems to ignore LAN-to-LAN entirely.

[psherman]

lan-to-lan traffic never hits the firewall because it is switched, not routed. But what other DNS servers do you have on your lan?

[rhester72]

Fair point on the lack of routing.

I implemented a Pi-Hole device on the local subnet and set DHCP option 6 to direct traffic to it, which has worked fine for quite some time.

I'm now bringing ad blocking back "in house" as it were leveraging adblock-fast on the router itself to perform the same function, so I no longer need the Pi-Hole.

Obviously, changing the DHCP option back to default (advertising the router as the DNS server) will work, but takes time for every device on the network to repoint as they re-DHCP at the half-lease mark. I'm trying to shortcut this with a rule that causes all DNS traffic destined for the Pi-Hole to hit dnsmasq on the router instead by DNATting Pi-Hole traffic "inwards".

To your point, if it's never transiting the firewall in the first place, it's kind of moot.

[psherman]

@rhester72

but takes time for every device on the network to repoint as they re-DHCP at the half-lease mark.

Just bounce the whole network. Literally restarting the router (along with any external switches and APs) will force a new DHCP request.

In the meantime, how long is your DHCP lease time currently?

[rhester72]

Restarting the router will not force a new DHCP request from clients because they are blissfully unaware there's a need. They won't even make the attempt until they reach the 12h mark (of the 24h lease). The only way to force DHCP early is to bounce the client network connection...and with 300+ devices, that's a bit much.

This isn't an entirely practical request...of course I can just wait out the twelve hours (and I shall). It was more of a "huh...this should work, why isn't it?" moment without even considering that since traffic isn't transiting zones the firewall doesn't apply, so you at least gave me the hint to understand why it can't work this way. =)

[psherman]

@rhester72

Restarting the router will not force a new DHCP request from clients because they are blissfully unaware there's a need.

The router itself plays a part if there are devices directly connected to it (i.e. via ethernet or wifi, connecting to the router hardware directly with no intermediate devices).

That's why I mentioned bouncing your entire network, too (switches, APs), which will bounce the client interface on all devices because ethernet and/or wifi will briefly go down.

@rhester72

The only way to force DHCP early is to bounce the client network connection...and with 300+ devices, that's a bit much.

You didn't say how many devices you have, nor if you are operating in a home environment or something else where the bouncing of the network is not an option (and office, school, retail location, etc.).

@rhester72

this should work, why isn't it?" moment without even considering that since traffic isn't transiting zones the firewall doesn't apply, so you at least gave me the hint to understand why it can't work this way. =)

Yup... that is precisely why it doesn't work... the router isn't involved at all, except currently (or probably the recent past) insofar as issuing the DHCP option 6 pointer to the PiHole via the DHCP server.

But yes, in 12 hours or less, this should be a non-issue, provided that you have removed option 6 from the DHCP server.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks!