I think our setup used to work. Maybe the transition from iptables to nftables changed something.
Setup works and PiHole is doing its thing. Issue is with which client is the PiHole receiving requests from. This matters because the PiHole can apply blocking rules selectively based on who the client is.
Clients reaching the router via a wired port work great. PiHole reports the client no problem (for example, pc.lan requested www.openwrt.org).
Clients connected to wifi are being intercepted by router even when using the proper DNS of 10.0.0.25. (for example, router.lan requested forum.openwrt.org instead of pc2.lan requested forum.openwrt.org) This is the behaviour expected for ill-behaved clients that would try go to 22.214.171.124 directly for example, but not if client is behaving and using the 10.0.0.25 DNS. We have forced the wireless devices (pc2 above for example) to use DNS 10.0.0.25 and we still get the issue. If pc2 reaches the router through wired lan (either using a cable or by connecting to an AP that is not the router) it works like a charm.
Hope that makes sense. Suggestions as to what we may be missing are very appreciated. Here the setup.
We have a lan. Address 10.0.0.0/24. router.lan is at 10.0.0.1.
We have a pihole. pihole.lan at 10.0.0.25.
DHCP serves option 6,10.0.0.25
pc.lan is at 10.0.0.101 and reaching the router via wire. Works as expected.
pc2.lan is at 10.0.0.102 and connected to router WiFi. PiHole sees request from router.lan, not from pc2.lan
(if pc2.lan reaches the router through Ethernet, magically requests show as from pc2.lan)
IPv6 is not used. Port 853 is blocked overall.
We have the following two firewall rules:
config redirect option name 'DNS PI-Hole, port 53' option src 'lan' option src_ip '!10.0.0.25' option src_dport '53' option dest '*' option dest_ip '10.0.0.25' option dest_port '53' option target 'DNAT' list proto 'tcp' list proto 'udp' config nat option name 'DNS PI-Hole MASQUERADE' option src 'lan' option dest_port '53' option target 'MASQUERADE' option dest_ip '10.0.0.25' list proto 'tcp' list proto 'udp'
All I can guess is that pc.lan (or any wired device) just goes through the switch to pihole.lan so no routing is involved, but pc2.lan (or any directly connected WiFi device) is routed from WiFi to lan and therefore the MASQ kicks in.
Any ideas on why this works well if wired but doesn't if connected through WiFi?
Thanks in advance.