DNS redirect (NAT) doesn't work 100 procent
-
I must be missing something but I cannot get my DNS redirect to work properly. Hopefully somebody can help.
In short I have 3 VLANS (192.168.2.0/24 , 172.16.108.0/24 and 10.10.10.0/24) and Pfsense gives clients the DNS server of my pihole. DNS lookup is done through pfsense (resolver) and cloudlfare. Pihole also has 3 ip's with VLANs for each subnet and this all works perfectly. Clients can browse the internet and all DNS queries are sent to the pihole and then to pfsense.
To prevent unauthorized dns lookups or devices that use hardcoded 8.8.8.8 I created a NAT redirect rule as explained here: https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html. All DNS traffic is redirected to my Pihole IP.
For some reason I am not getting it to work and I cannot see any rules being blocked.
Anybody know what is going wrong?See example from a nslookup on a workstation client 172.16.108.107 to apple.com. First with pihole IP (so no dns server specified) and 2nd with google DNS specified to see if NAT redirect works.
These logs are from the Pihole during the manual dns lookup on 8.8.8.8 (so redirect seems to work part of the way?)
Sep 15 21:50:29 dnsmasq[10039]: query[A] apple.com from 172.16.108.107
Sep 15 21:50:29 dnsmasq[10039]: forwarded apple.com to 192.168.2.1
Sep 15 21:50:29 dnsmasq[10039]: reply apple.com is 17.178.96.59
Sep 15 21:50:29 dnsmasq[10039]: reply apple.com is 17.172.224.47
Sep 15 21:50:29 dnsmasq[10039]: reply apple.com is 17.142.160.59
Sep 15 21:50:31 dnsmasq[10039]: query[AAAA] apple.com from 172.16.108.107
Sep 15 21:50:31 dnsmasq[10039]: forwarded apple.com to 192.168.2.1
Sep 15 21:50:31 dnsmasq[10039]: reply apple.com is NODATA-IPv6
Is the reply back to the host "lost" causing the dns request time out?
-
Anybody know how to solve this :)? I'm going to add some more pictures to help explain / debug:
Network overview
Packet trace from Laptop in IoT Subnet (172.16.108.107). First results are with no dns server specified (so nslookup through pihole at 172.16.108.4) and the other with google dns specified (8.8.8.8)
Last packet trace but this time from pfsense instead of the client.
So in summary:
DNS lookup works perfectly when clients use the default dns of pihole (which is given through DHCP). But when clients use a hardcoded or manual dns -> the NAT forwarder only works 50% (packets seem to be re-routed) but I'm getting a timeout with nslookup
-
Already tell you what the problem is.. You need to have your pihole on a different vlan than your clients asking for 8.8.8.8 that you redirect too.
Or your redirect has to be to pfsense loopback, so it does the lookup.. And then sends to pihole. So pihole sends the traffic back to pfsense, to get sent back to the client.
Gone over this a few times in past already.. Let me finish my coffee and will look up the past threads.
Problem is the answer is coming from different mac than the traffic was sent too.
-
Appreciate your help here! I've been stuck on this for days..
I've tried changing the NAT rule to point to 127.0.0.1 rather than my pihole IP. That also doesn't work. I'm assuming this is what you mean with the loopback address?
The other suggested approach (other vlan) -> the pihole has 3 ip's so clients do not have to go through the firewall to do dns lookups (and traffic will stay on the same subnet). Would be great if I could leave it this way.
-
Well what does your pfsense do with it?? Does it send it to pihole? Then where does pihole send it?
Here is old thread where I went over this
https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns/43 -
Packet trace on pfsense on LAN when NAT rule is set to loopback (127.0.0.1)
13:34:03.773441 IP 192.168.2.4.12682 > 192.168.2.1.53: UDP, length 40
13:34:04.064026 IP 192.168.2.1.53 > 192.168.2.4.12682: UDP, length 327
13:34:05.600760 IP 192.168.2.4.19122 > 192.168.2.1.53: UDP, length 43
13:34:05.670945 IP 192.168.2.1.53 > 192.168.2.4.19122: UDP, length 326
13:34:11.323363 IP 192.168.2.4.8452 > 192.168.2.1.53: UDP, length 32
13:34:11.323537 IP 192.168.2.1.53 > 192.168.2.4.8452: UDP, length 48
13:34:13.754859 IP 192.168.2.4.15342 > 192.168.2.1.53: UDP, length 52
13:34:13.827290 IP 192.168.2.1.53 > 192.168.2.4.15342: UDP, length 247Packet trace on pfsense IoT (where the laptop client is in doing the nslookup) when NAT rule is set to loopback (127.0.0.1)
13:35:08.680905 IP 172.16.108.107.56779 > 8.8.8.8.53: UDP, length 38
13:35:10.699040 IP 172.16.108.107.56780 > 8.8.8.8.53: UDP, length 41
13:35:12.707457 IP 172.16.108.107.56781 > 8.8.8.8.53: UDP, length 41
13:35:14.711181 IP 172.16.108.107.56782 > 8.8.8.8.53: UDP, length 31
13:35:16.724093 IP 172.16.108.107.56783 > 8.8.8.8.53: UDP, length 31 -
@AudiAddict said in DNS redirect (NAT) doesn't work 100 procent:
when NAT rule is set to loopback (127.0.0.1)
And again what is on pfsense.. What does it do with this query it sees on its loopback? Do you have unbound listening?
Been over this so many freaking times. If a client gets an answer back from different mac then it sent it to - its going to balk at you!! dig will even tell you..
-
Thanks for your patience...
Ok I did packet traces with loopback set and I found out that it was blocking 127.0.0.1 traffic in a firewall rule. Unblocked that and now the DNS lookups work when doing nslookup microsoft.com 8.8.8.8 BUT the dns lookup is not going through the pihole which I guess is normal because the NAT rule is pointing to pfsense.
13:41:26.400022 IP 172.16.108.76.50691 > 8.8.8.8.53: UDP, length 32
13:41:26.400111 IP 172.16.108.76.50691 > 8.8.8.8.53: UDP, length 32
13:41:26.400180 IP 8.8.8.8.53 > 172.16.108.76.50691: UDP, length 60
13:41:26.472377 IP 8.8.8.8.53 > 172.16.108.76.50691: UDP, length 48Pihole uses pfsense to do the external dns lookups - so pointing pfsense to pihole doesn't solve this issue.
I guess the only way to solve this is to point to the pihole IP in a different subnet IP?
I tried changing the NAT rule to point to 10.10.1.4 (pihole ip in another subnet) but that still gives a timeout.Packet capture with 10.10.1.4 NAT rule set:
Sorry for not understanding...
-
client on 192.168.3.32 sending to 8.8.8.8, which pfsense directs to 3.10
pi@ntp:~ $ dig @8.8.8.8 www.google.com ;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53 ;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53This done with redirect to same network.. Did you set your outbound nat for auto for outbound?
pi@ntp:~ $ dig @8.8.8.8 www.google.com ; <<>> DiG 9.10.3-P4-Raspbian <<>> @8.8.8.8 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34314 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 1315 IN A 172.217.8.164 ;; Query time: 4 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Sep 20 06:58:53 CDT 2020 ;; MSG SIZE rcvd: 59I specifically stated that in the post I linked too
"or if setup nat reflect auto outbound nat rules so it"The different ways to skin this cat depends on your setup... Best to just put your pihole on different segment than your clients.. because you then don't have to do nat relfection nonsense tricks ;)
edit "the pihole has 3 ip's so clients"
What? So your pihole is multihomed and has an IP in all your vlans? Dude that is just borked!!
-
Thanks again for your patience. I have set the Automatic create outbound NAT rule (this wasn't enabled before). But no difference yet.
Also tried using a debian virtual machine on the same subnet with IP 172.16.108.124 just so I can use dig like you are. At least it is giving me a better error message rather than the timeout on windows.
What am I missing here? I understand that it's giving the wrong IP (hence the unexpected source message) but what do I need to do in pfsense to counter this?
root@debiantest:/home/adminj# dig netgate.com ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> netgate.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26618 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;netgate.com. IN A ;; ANSWER SECTION: netgate.com. 2715 IN A 208.123.73.73 ;; Query time: 3 msec ;; SERVER: 172.16.108.4#53(172.16.108.4) ;; WHEN: Sun Sep 20 14:57:29 CEST 2020 ;; MSG SIZE rcvd: 56 root@debiantest:/home/adminj# dig @8.8.8.8 netgate.com ;; reply from unexpected source: 10.10.10.4#53, expected 8.8.8.8#53 ;; reply from unexpected source: 10.10.10.4#53, expected 8.8.8.8#53 ;; reply from unexpected source: 10.10.10.4#53, expected 8.8.8.8#53 ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @8.8.8.8 netgate.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached root@debiantest:/home/adminj#
To comment on the multihome: Sorry, I'm not a network expert but I was thinking this was safer because I want to prevent traffic between my VLANS. So each client per vlan can do DNSlookups without going to another subnet? Would you recommend doing this differently? I was thinking that if I only have one pihole IP in the LAN subnet, I would have to allow traffic from the guest and IoT subnets (172 and 10) to the LAN subnet and this would also slow down dns lookups as they go through the FW?
-
Ok did some testing. If I turn off my eth0.10 adapter on my pihole with the 172.16.108.4 pihole IP that is in the SAME SUBNET as my debian and windows test machines everything does work.
I'm curious on how and why this solves the problem as I would need to have clients out of each VLAN be able to access my LAN subnet for pihole..
Is there a work a round / pfsense setting to allow the Eth0.10 adapter enabled + having a pihole IP per subnet?
-
@AudiAddict said in DNS redirect (NAT) doesn't work 100 procent:
But no difference yet.
Did you clear your states.
I just showed you this working..
Would you recommend doing this differently?
Yes.. Put your pihole on 1 vlan! Allow your different vlans to talk to pihole on IP and 53 tcp/udp. The whole point of a firewall is to block/allow specific traffic between vlans. Not everything - unless that is what you want. But you want your clients to talk to your pihole, so allow that traffic.. Placing a device on every vlan (multihomed) compromises the security of your network. If the pihole was compromised then it has complete access to every other network it has an IP on without having to go through your firewall.
It can also lead to asymmetrical routing problems.
If you want your redirect to work without having to do any nat reflection stuff - then put it on a vlan all by itself.. So now all traffic even when redirected will look like it came back from where the client sent it.
