Those works though. Except, once again, if I specify static DNS on my local machine.
What could prevent the router from seeing the DNS request on port 53 made by a local machine directly? I think that maybe the router just doesn't see the request and therefore cannot redirect it. Maybe the DNS request is encrypted of some sort, https for example. (I don't use DNSSEC or anything like that) I'm just throwing this out there, I'm not really sure if it would make sense.
I've attached some screenshot of my config.
I try to redirect request to the Pi and not the router itself as I would like to see which IP made the request, but if I redirect everything to the router, the PiHole will only sees 192.168.1.1 as the requester. But that is a problem I can play with after we figured out how to make the DNS resolution locally.
EDIT:
With Wireshark, I can see the request:
Code:
6284 91.958274365 192.168.1.20 1.1.1.1 DNS 77 Standard query 0xe5a4 A cdn1.edgedatg.com
11 0.737462563 192.168.1.20 192.168.1.2 DNS 91 Standard query 0xf77a A push.services.mozilla.com.local
I also see requests to my ISP DNS, but they do not return any results either. So my guess is it's redirecting to the PiHole but the ".local" thing mess it up or something. I don't know.
Once I try a website, it takes about 3-4 minutes for it to appear in the PiHole logs. The router CPU is 5% and there is plenty of RAM. Same for the PiHole.
I attached 2 wireshark DNS resquests and 1 PiHole request history. I believe none of the requests had a response even though the PiHole catches the requests.
I'm sorry this is way harder than I thought it would. I guess we just need to find the right commands and config...
If the request is for port 53, if it's coming from br0 and not from 192.168.1.2, this should redirect the request to 192.168.1.2 port 53, right? But it does not. I tried ROUTING instead of DNAT and it didn't work either.
I tried blocking DNS requests if it's not from 192.168.1.2 and it works. Why does rerouting the requests doesn't?
My understanding: If the source or the destination is the Pi on destination port 53, accept. If it's on port 53 but not for the Pi, reject.
I added the 3rd and the 4th FORWARD rules, trying to make sure it can accept request if the destination is 192.168.1.2. I also added "-d ! 192.168.1.2" on the last 2 to make sure not to block requests going to the Pi. I think it's redundant because I already allow requests to it just before, but since it's not working I want to make sure I'm not missing anything.
It blocks all DNS queries if I set DNS to 1.1.1.1 but works perfectly when on Auto DNS.
After reading the iptable manual, I also tried adding "iptables -t nat -A POSTROUTING -j MASQUERADE" after the prerouting rules... didn't do anything, so I removed it.
The Pi can 'nslookup' and so can the router with the above iptables rules. I won't make that mistake again.
EDIT: I found this website where the only rules are:
nslookup google.com
;; reply from unexpected source: 192.168.1.2#53, expected 1.1.1.1#53
;; reply from unexpected source: 192.168.1.2#53, expected 1.1.1.1#53
;; connection timed out; no servers could be reached
Is there a way to "authorize" this? I would like to avoid MASQUARADE because then all requests would be mark as if they were coming from the router, but I'd like to know which client made the request.
EDIT:
I found a way, maybe. According to this reddit post:
Quote:
As for the second solution (multiple subnets), I have no experience with OpenWRT whatsoever, so I can't provide details or examples, but the general actions that you need and should be able to google for are:
If the LAN-ports all behave like one switch on your router (=>you can't configure multiple separate ports/interfaces), find how to configure an additional IP address on the LAN-side of the router, with different subnet. (let's say 192.168.10.0/24) ===> this will allow the additional subnet
2, Make sure the router is the gateway for both the clients (->192.168.1.1) and the pihole (->192.168.10.1). This ensures both clients and pihole must go through the router to reach any subnet than their local one. ===> this will ensure the DNS reply goes through the router, allowing it to remove the DNAT on the reply packet
3, If the traffic between clients and pihole's subnet isn't implicity allowed, find how to add a firewall rule to allow this communication.
4, If the DNAT rule is still applying source-NAT, find how to disable the source-NAT-ing.
note: this is all assuming that you're implementing the DNAT rule to redirect DNS traffic of clients that refuse to use the DHCP-provided DNS server. If on the other hand the actual problem is that your DHCP server is undesirably distributing its own/other IP as the DNS server IP, then you should prioritize fixing that first (->if nothing else works, move DHCP functionality to the pihole), since that will probably fix most or all of the unwanted DNS requests to other servers.
The Pi needs to be on another subnet.
So I assigned port 3 to VLAN 3. Set static IP to 192.168.2.2 in the DHCP static leases.
In Networking I set the IP to 192.168.2.1 (Unbridged) for vlan3.
On the Pi, static ip set to 192.168.2.2... but for the gateway I'm not quite sure if it needs to remain on 192.168.1.1 but I changed it for testing.
As the reddit post said:
Client request Duckduckgo.com
Received by router (192.168.1.1)
Transfered to PiHole (192.168.2.2)
PiHole response to router (192.168.2.1)
Router masquarade the IP
Deliver to client
The request must come from the router so it can change the IP. If the Pihole respond directly to the client, the client will know it's not originated from the server it made the request to.
Setup Tab:
Static DNS 1: 192.168.2.2
Use DNSMasq for DNS: Disable
VLANs tab:
Since my Raspberry Pi is connected to the 3rd port I assigned VLAN 3 to port 3. Not assigned to bridge.
:
) :
I tried ROUTING instead of DNAT and it didn't work either.
