Setup is a Pi4B with a recent 3 days old snapshot, enabled DNS hijack to steer requests to my Pi-Hole. Everything on the tunnel now works, clients have both internet access and access to everything except the PiHole. I suspect this is in with the DNSHIJACKv4 instructions that have been given elsewhere. Otherwise the Hijack is working. I can verify that by doing a nslookup on the mobile, sends it to 8.8.8.8 but I see the request in the Pihole log from the router.
To get my DNS served by the PiHole I have to set the server as the router on the client and rely on that forwarding to the Pihole. I can ping every other active device and reach their web pages if they have them. It is not a big problem but I can's see why it is happening or think of a workaround.
When I am connected via my mobile and the Wireguard tunnel the only client I cannot access is the the PiHole. Everything else seems okay. I have internet access and dns but via the router not the PiHole albeit the router sends the query via PiHole. The only extra firewall rules I have are relating to the PiHole dnshijack but it is of course all port related. Connected locally via WiFi I can access the PiHole, if I use an OpenVPN tunnel on my NAS which will eventually be replaced by the the Wireguard on the router all is okay too and I can access the PiHole address.
Thanks. That did it although only after restarting the PiHole I have to think that the OpenVPN via the NAS must show up as if it comes from the NAS rather than 172.x.x.x associated with its VPN
I have these rules to deal with DNS traffic albeit much more of that seems to come from the router than it did. Certainly if I use a terminal on my mobile to run nslookup.
iptables -t nat -N dnshijack
#iptables -t nat -I dnshijack -j LOG --log-prefix "dnshijack4 "
iptables -t nat -A dnshijack -j DNAT --to-destination 192.168.70.250
# allow Pihole to query internet
# Eth0
iptables -t nat -A prerouting_lan_rule -m mac --mac-source dc:a6:32:91:0c:51 -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source dc:a6:32:91:0c:51 -p tcp --dport 53 -j ACCEPT
#Wlan0
iptables -t nat -A prerouting_lan_rule -m mac --mac-source dc:a6:32:91:0c:52 -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source dc:a6:32:91:0c:52 -p tcp --dport 53 -j ACCEPT
# allow queries to OpenWrt
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d 192.168.70.1 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 192.168.70.1 -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
#iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -d 192.168.70.250 -j ACCEPT
#iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -d 192.168.70.250 -j ACCEPT
#iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -j dnshijack
#iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -j dnshijack
#iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -d 192.168.70.250 -j ACCEPT
#iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -d 192.168.70.250 -j ACCEPT
#iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -j dnshijack
#iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -j dnshijack
# fix "reply from unexpected source"
iptables -t nat -A postrouting_lan_rule -d 192.168.70.250 -p tcp -m tcp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
iptables -t nat -A postrouting_lan_rule -d 192.168.70.250 -p udp -m udp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
What else needs to be done if these are insufficient please? I only reference the eth0 in the Pi as a DNS server, I keep the WiFi on so I have an alternative address to access the device via that if need be.
You already have these 2 rules to masquerade the traffic being redirected to the Pihole.
However, if I understand properly, you want to masquerade the tunneled traffic. Therefore you need to apply a masquerade rule on the NAS, which, if again I understand properly, is the wireguard server in your lan.
Sorry I have not explained clearly. I'll try to summarise better.
The Wireguard is on the router and that now seems to work okay, gets DNS etc and I can access now the various servers on my lan if I open them to the Wireguard IP range it was only an observation that I did not need to do this for the OpenVPN server I was previously using on the NAS. So a guess that it must have presented the VPN address as its own lan address. I specifically wanted to retire that since Synology are way behind the curve with updates and functionality for their devices.
I was seeing some queries bypassing the PiHole and hitting the servers I supplied on the lan, I knew one of these must have been the Nas, as it was Synology ddns it was querying. That I fixed by making the PiHole also the wan DHCP server.
Now I think everything is working albeit the majority of the queries ~60% seem to come from the router after being hijacked by the rules above. I am certainly seeing more than before so have stopped a lot of devices bypassing the PiHole unless there are rules I can apply that would adequately mark those queries with the IP of the correct devices I'll mark this as closed. I tend to for our devices use reserved IP in case in some way later I want to separate them from those of visitors.
When you hijack a dns query and the Pihole is in the same subnet as the requestor, then masquerading has to be applied, otherwise the pihole will respond directly to the requestor and the latter will discard it as "reply from unexpected source". This of course ruins the statistics in Pihole, as all requests seem to come from OpenWrt.
One solution is to move the pihole in a different interface, e.g dmz, iot, etc. Then you don't need the masquerade rules any more.
