Transparent DNS Proxy

deadbolt_forum

Actually I have the same issue regarding NTP. I am trying to force all local machines to use NTP served from the router but the clients see the unexpected reply and ignore the traffic.

Nullity

Yes.

I use NAT to force all DNS and NTP traffic to pfSense. https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense

Your clients should have no problem with it.

deadbolt_forum

Those are the settings I am using and while it does translate the packets to the router's address, it does not spoof the address of the remote server like a transparent proxy. I suspect that these settings appear to be working for you because all of your clients are configured correctly anyways and are not relying on the NAT settings.

When I manually test a remote server using the terminal this fails.

Perform a DNS lookup of www.google.com using Google's secondary DNS server 8.8.4.4 instead of your default DNS server.

host www.google.com 8.8.4.4;

Perform an NTP query using Apple's time server instead of your default NTP server.

ntpdate -q time.apple.com;

Both examples return errors that they are receiving unexpected responses. This is happening not because the NAT command isn't correctly configured to use your router's IP address but because redirecting all traffic to the LAN address is not sufficient. It also has to respond that the answer came from the original server that was expected and not the router or it looks like the traffic was hijacked which it was.

Nullity

Before my previous post I ran "dig @4.4.2.2 google.com" and "dig @8.8.8.8 google.com" and both responses were transparently masqueraded as originating from the respective SERVERs even though all DNS responses are coming from my pfSense router's dnsmasq forwarder @192.168.1.1. My pfSense uses 8.8.8.8 as my primary and 8.8.4.4 as my secondary.

So, it works fine. No errors on any of my Windows, iOS, Android, or Linux clients.

You seem to have something misconfigured.

johnpoz

I am not a fan of doing something like this. Either block access to other dns, which would force client to use your dns.. Or just let the query who they want.

But the instructions work just fine.. https://doc.pfsense.org/index.php/Redirecting_all_DNS_Requests_to_pfSense


user@ubuntu:~$ host www.google.com 4.2.2.2
Using domain server:
Name: 4.2.2.2
Address: 4.2.2.2#53
Aliases:

www.google.com has address 216.58.192.228
www.google.com has IPv6 address 2607:f8b0:4009:80f::2004

I setup the listed port forward, and even sniffed. The sniff looks like the answer came back from 4.2.2.2, but nothing went out the wan to 4.2.2.2

I even did a host to 4.2.2.2 asking about a local override.. And that works just fine as well client thinks it asked 4.2.2.2


user@ubuntu:~$ host pfsense.local.lan 4.2.2.2
Using domain server:
Name: 4.2.2.2
Address: 4.2.2.2#53
Aliases:

pfsense.local.lan has address 192.168.9.253
pfsense.local.lan has IPv6 address 2001:470:snipped:1

deadbolt_forum

Thanks for the feedback. In that case it might be an issue with IPv4/6 dual stacking. I will test more carefully and update with my results.

johnpoz

I run a dual stack.. Your client could be asking via IPv6 that is for sure!!! So if your port forward trying to redirect to ipv4 could be an issue. Have to test that out. But where you not doing a direct query to an ipv4 address and saying it was failing?

In my dual stack setup I have changed my clients preference back to ipv4. And quite often I don't even have ipv6 enabled on the client. While I am a big fan of ipv6 and I do make sure all of my stuff supports it.. To be honest there is no content that requires ipv6 as of yet.. It only causes more issues if you ask me.. So while I have it enabled, and can use it for testing - currently to me in the big picture it does not warrant being the first choice for connections.

If your having issues with IPv6 - just turn it off ;)

Should prob update that doc to reflect possible issues with ipv6, etc. have to do some testing to see what happens. They talk about create a block i the doc, which would assume would be for both ipv4 and ipv6.. So in worse case scenario if that was done ipv6 queries would just fail.

deadbolt_forum

Solved. I was using the LAN interface (192.168.1.1) in the NAT rule but it looks like it only works if you use the loopback interface (127.0.0.1). Something tricky must be going on behind the scenes when it sees that address.

johnpoz

So you didn't follow the instructions ;)

Nullity

@johnpoz:

I am not a fan of doing something like this. Either block access to other dns, which would force client to use your dns.. Or just let the query who they want.

Why?

I really only use it in the hope that DNS requests will be cached more often. I haven't ran into any problems that I know of.

I guess only allowing access to the DNS servers my forwarder uses (while still forcing my DNS forwarder with NAT) might be a more optimal approach.

johnpoz

So your goal is to have less dns queries going out your wan, so vs clients sending querys to outside dns A, B and C… They would think they are asking them but really just get back your cache (if there was one) in pfsense.

While this might be useful if you had 1000's of clients, or even say hundreds of them all asking some outside dns. You can lower your wan queries for dns by just blocking outside and they should be using what you hand them via dhcp, or what you tell them to setup statically. If they don't then dns just wouldn't work for them - and then you save all their wan traffic ;)

If what your wanting to do is have all your iot sort of devices that hard code dns and use your pfsense cache. Ok - but how many iot devices do you have? dns traffic really not all that much.. The few bits you save by just using your pfsense cache wouldn't be much unless you had a shitton of devices ;)

Also the stuff iot devices dns for, their CC hosted on CDNs normally has really low TTL's in the first place.. So while you might cache it for 5 minutes, next device would just create another wan query.. So again unless you really had a shitton of devices doing a shitton of queries to all kinds of stuff with longer ttl's the bandwidth savings is going to be very very minor..