DNS redirect (NAT) doesn't work 100 procent
-
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.
