Re-directing Client DNS Requests
-
Hi,
Tried to do the above by following the Negate documentation on this and adding a NAT rule as requested but for whatever reason it seems to fail.
If I do a DNS check on the PC I am using with DNS set to Auto then it picks up the WAN IP address only - ok fine.
However, if I manually set the PC DNS to 1.1.1.1 and retry I get the WAN IP address plus 2 cloudfare servers (172.69.43.42 & 172.69.43.43), which I would not expect to see.
My rules are below:-
On the general tab:-
DNS resolver :-
NAT:-
I'm trying this on a PC on the LAN network and LAN rules are:-
If someone could point me in the right direction I would appreciate it as I'm clearly doing something stupid here as it can't be that hard!
Thanks
Steve -
@stevencavanagh said in Re-directing Client DNS Requests:
If I do a DNS check on the PC I am using with DNS set to Auto
You mean DHCP ?
What was the DNS IP it obtained ?
( ipconfig /all )then it picks up the WAN IP address only - ok fine.
WAN IP ? Where ? as what ?
Btw : this :
The host name filed isn't a comment field ;)
[24.03-RELEASE][root@pfSense.bhf.tld]/etc/inc: host 1.1.1.1 1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.
So : it's "one.one.one.one".
-
You mean DHCP ?
What was the DNS IP it obtained ?
( ipconfig /all )%(#e01515)[Sorry, I meant I set the PC DNS to Auto and then went to "dnsleaktest.com" and got the following:-
Where the IP shown is my WAN IP address
ipconfig shows DNS IP as:-
Which is Pfsense.
However, if I repeat the above with the PC DNS set manually to 8.8.8.8 I get:-
Which isn't what I expected if I was re-directing client DNS and cannot figure out why!
Hostname sorted!
Steve
-
Also did some logging of the NAT firewall rule and can see it being active and forcing the DNS from the manual entry of 8.8.8.8 on the PC to 127.0.0.1.
However, if I do DNS leak check I get google's servers!!
Strange!
-
@stevencavanagh said in Re-directing Client DNS Requests:
However, if I do DNS leak check I get google's servers!!
Well your forwarding to google - so why would you think it strange that you would get google in a dns test??
Why do you have all those servers listed in dns if your resolving.. Those should be empty if your resolving, ie pfsense out of the box resolves. The only reason you would want/need to put servers in dns is if you want to forward to them, or you want pfsense to use them for its own resolving.
Out of the box, pfsense (unbound) resolves - no dns needs to be set anywhere.. Clients ask pfsense for dns, which then resolves what was asked. I if the client asks something else and you redirect it unbound, which resolves - you would not see googledns in such a leak test.
So either your redirect isn't working, or your forwarding in unbound to those vs resolving.
-
I'll remove the DNS servers in the General area.
How do I check whether I am forwarding to google servers as I didn't think I was? I'm not forwarding in the resolver!
-
@stevencavanagh then your not forwarding.. But if you put servers in there - pfsense can use its for its own queries.
But this says your forwarding
If your going to forward, you shouldn't have dnssec enabled either.
If you don't want to forward, why do you have that checked? Why did you put all those dns in the general section if you don't want to forward?
What is it you want to happen? If you don't want to forward your dns servers should be empty. And I wouldn't be checking use ssl/tls for forwarding either. Even if you don't have forwarding checked. And I would prob uncheck let dhcp override, and even set ignore remote.
-
Unticked the "Use SSL/TLS for outgoing DNS Queries to Forwarding Servers", missed that one!
Left dnssec enabled as no desire to forward. The DNS servers were left there from previous messing about.
Ideally what I was hoping to achieve is to use DNS servers that keep no logs and force any clients that have DNS servers manually set to use the no log DNS servers using the NAT rule or any other recommended way to achieve it
@johnpoz said in Re-directing Client DNS Requests:
If you don't want to forward your dns servers should be empty. And I wouldn't be checking use ssl/tls for forwarding either. Even if you don't have forwarding checked. And I would prob uncheck let dhcp override, and even set ignore remote.
Done
However, despite doing the above & restarting the resolver I still get google DNS appearing when I do a DNS Leak test with the client having manually set the DNS servers to google
-
@stevencavanagh You sure your browser that your testing with isn't using doh?
Also not a fan of the ! way of doing it... What I would do is have a rule that allows access to lan address on 53, and right below that I would have a rule that any destination to 53 would be redirected to loopback.
This doesn't fix doh, but bang rules (!) don't always play nice.
Other thing - do you have anything in floating tab that could be allowing the traffic?
You could also be running into an existing state thing.. Make sure there are no states to 8.8.8.8 once you put in the rule to redirect.
-
Browser is edge and settings below:-
Presumably, I should turn it off?
I don't like doing the "!" either but I was following the netgate documentation but will change it as suggested.
Don't think anything in floating rules:-
Found this in the states:-
192.168.0.207 is the PC I am testing on. Not sure what this means exactly!
192.168.0.21 is the managed switch connecting to Pfsense (core switch).
-
@stevencavanagh You have some rule forcing traffic out your pppoe connection?
-
@johnpoz said in Re-directing Client DNS Requests:
@stevencavanagh You have some rule forcing traffic out your pppoe connection?
@johnpoz said in Re-directing Client DNS Requests:
@stevencavanagh You have some rule forcing traffic out your pppoe connection?
Yes, saw that and have no idea where it came from unless I added it for OpenVPN or PFBlocker added it.
But that won't cause any issues with DNS redirecting will it?
-
@stevencavanagh I have no idea what that rule is doing.. disable it.. Do you still have internet?
Your browser is set to use secure dns, ie doh.. That should be OFF if you want your browser to use your local dns.
That settings says hey whatever the dns is, use doh to talk to it.. Your setting your machine to use 8.8.8.8 so yeah your browser is going to ask 8.8.8.8 via doh.
-
Yep, disabled edge setting as suggested and a DNS leak check now only shows 1 server:-
The IP is that of my ISP WAN IP address, which I assume is correct, despite having manually set the DNS server to google on the PC.
Disabling the WAN floating rule doesn't seem to break the internet or anything so unsure why it is there!
So one question not the clients will go direct to Pfsense and then out to root servers etc, how do I know which they are using and will logs be kept??
-
Another quick question, why when I look at the states I see this still (I killed the states first) :-
It still references 8.8.8.8 and cannot see where this now comes from?
-
@stevencavanagh said in Re-directing Client DNS Requests:
how do I know which they are using and will logs be kept??
Huh? The clients don't go anywhere other than pfsense.. Unbound on pfsense is the only thing that would talk to roots.. And it only talks to roots to find out what NS to talk to for the tld.. It would then ask the NS of that tld for the NS of the domain.tld, It would then ask the NS of that domain.tld for your record..
It still references 8.8.8.8 and cannot see where this now comes from?
Well yeah that is your redirection.. See in the where original dest is 8.8.8.8:53, which got redirected to loopback 127.0.0.1:53
You have a client on 0.207 trying to talk to 8.8.8.8 that was redirected, and also a 0.21 device also wanting to ask 8.8.8.8 that was redirected.
What exactly are you wanting to log, what client asked for what? You can enable logging in unbound if you want.
-
So logs are now utterly irrelevant or don't exist, which is fine.
192.168.0.207 is no longer set manually to 8.8.8.8, it is set to Auto
192.168.0.21 is also set to DHCP and DNS showing as 192.168.0.1 (LAN gateway).
So still not sure where the 8.8.8.8 is now coming from? Do I need to reboot the PC and switch?
I suppose the only issue now would be is a client decides to use DOH! Is there an easy way to prevent this, I suspect not but thought I would ask!
-
@stevencavanagh those states could be old if you have changed your clients to now use pfsense IP.
You can try and block doh, lots of people here do.. There are lists of known doh servers that you can block, pfblocker has some lists of doh servers.
But yeah since doh uses 443, just like the rest of the internet it can be hard to block.. If some client decides do use some unknown IP via doh. But most any client like some browser is going to use some well known doh server, which can be blocked via its IP..
What do you mean logs are now irrelevant? You can log what a client asks for if you want.
-
Ok, I'll clear the states and retry. Will need to add a NAT rule presumably for the other VLANs as well as LAN as it appears the server for example is using 8.8.8.8 and I'll change that DNS to Pfsense.
Log wise, I can log where clients go but I was more concerned with ISP or others logging what is going on but that will no longer happen!
Did a browse through the forum for blocking DOH previously and it did not appear to be straightforward. I'll have a look into this. I believe PfBlocker can do it also to some degree I believe.
-
@stevencavanagh said in Re-directing Client DNS Requests:
it did not appear to be straightforward.
There are few different ways to skin the cat, but the problem with doh - is one of its design features is circumvention of local dns.. If it was just about secure dns traffic via a tunnel, then dot on port 853 does this.. Which is easy to block by the local admin, etc..
Hiding the traffic inside the most common port used on the internet is not only about the client talking to some specific NS securely - its also about circumvention of local restrictions.
Your local dns blocks looking up www.domain.tld - don't worry just ask us directly on the port all other traffic uses for internet so its harder for your local admin to block and we will give you the IP..