DNS Resolver Leaking and DHCP addresses
-
Hi,
I believe I setup the DNS resolver properly and it is working GREAT 99% of the time. However the 1% error is troubling, shouldn't it work 100%?
My phone is able to connect to 1.1.1.1:443 when it feels like it. Mind you I cannot get my phone to bypass the resolver and get to 1.1.1.1:443, but some how it seems the phone on its own, whenever it wants to, can indeed connect to 1.1.1.1:443 and i have no idea how or what / where it is connecting to.
Please let me know what i am doing wrong or is this normal (hopefully not).
Also, my devices on the network are receiving ipv6 addresses even though i have ipv6 dhcp server off. How is that possible? Is it a device issue?
Thank you!
-
@disgrun said in DNS Resolver Leaking and DHCP addresses:
My phone is able to connect to 1.1.1.1:443 when it feels like it. Mind you I cannot get my phone to bypass the resolver and get to 1.1.1.1:443, but some how it seems the phone on its own, whenever it wants to, can indeed connect to 1.1.1.1:443 and i have no idea how or what / where it is connecting to.
So you phone connects to 1.1.1.1:443
That's what you want, right ?Btw : if your phone goes directly to "1.1.1.1" then it bypasses the pfSense resolver.
What you've shown isn't wrong.
IMHO, what is wrong here, is that your phone (OS ?!) creator decides for you that your DNS has to go to "1.1.1.1".
Don't you have a word to say in what happens with your data ?
( I wouldn't event thinking of getting a phone like that )My phone uses the DNS supplied with the DHCP lease from pfSense, so it uses the pfSense IPv4 and my devices don't do 'DNS' as they see fit.
As I am the boss here on my network. I decide who is doing DNS on my network.
I'm even blocking x.x.x.x:443 access with the pfBlockerng "DoH/DoT/DoQ Blocking List".Why do you think that unbound is 'leaking' ?
-
@Gertjan Hi, No, i do not want the phone to be able to go to 1.1.1.1:443, it should always go to 127.0.0.1:53. i have pfblockerng blocking all DOH, so if i set my phone to secure dns 1.1.1.1 it is blocked and it can not connect. However the phone at its own will, connects to 1.1.1.1:443. So it is even bypassing pfBlockerNG somehow.
Not sure where to find the logs, (i'm an amateur at this). But the last Resolver log was yesterday and no new entries, does pfblockerNG stop those? If you can direct me to the logs needed. I will be happy to post them. Thanks!
-
@disgrun said in DNS Resolver Leaking and DHCP addresses:
it should always go to 127.0.0.1:53.
that is itself, not some other dns.. 127.0.0.1 is localhost..
There are lots of devices that have dns hardcoded, 1.1.1.1, 8.8.8.8 etc.. I am with @Gertjan that is a horrible horrible idea from makers of devices or software.. I block them by IP myself.. So they can try all they want, they ain't talking to it over my wifi.. Now if phone you have little control normally what they do over the cell data connection.
-
@johnpoz Hi, I also found a TV that is still able to connect to 1.1.1.1:43, it is the newest one. Regardless of what the devices are dns hardcoded to, isn't pfsense supposed to be able to redirect them via the resolver? Thanks
-
pfSense will only redirect DNS if you tell it to do so. Roku is famous for using 8.8.8.8 and ignoring the local DNS settings.
You cannot redirect DOH, those I block with pfBlocker and a list.In my world, if you use port 53, you either voluntarily use my DNS servers, or I silently do it for you.
Years ago I wrote instructions:
https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1663853296484 -
@AndyRH Hi, I am redirecting All DNS, all the roku's are working fine and not using 8.8.8.8, it is working beautifully, except for the phone and 1 TV.
Even when i use the phone or Tv they are being redirected perfectly. However the phone and tv are still getting thru to 1.1.1.1:443 even with pfblockerng on and blocking all DOH servers.
That is what is so troubling, this should not be happening, especially on their own. Thanks
-
@disgrun Sorry for the redundant stuff. You did not state or show what you were doing.
You could explicitly block 1.1.1.1:443 and see what happens. -
@AndyRH hi, Not sure how to block 1.1.1.1:443. So i used the dns resolver with tls to forward all requests to 1.1.1.1:853.
Then i setup pfblockerNG to block all the doh servers so it would block the 1.1.1.1:443, 8.8.8.8 tls etc.
Everything seems to work great and nothing is getting thru, except for the 1 phone and 1 tv.
The phone does not get though when i use it, but somehow it does on it's own, maybe thru some background app?
Just wondering how the firewall can possibly be letting it thru.
-
@disgrun On the network where the phone lives add a block rule. You would block either * or the phone address going to 1.1.1.1 I am not in front of my FW or I could post a picture of the rule.
-
@disgrun if a state already exists, and you add a block rule you would need to kill the state.. Now when it goes to create a new state the firewall rules would prevent the creation of the state, and they wouldn't get thru.
That state you show to 1.1.1.1:443, you would need to kill that.. Just look in the diagnostic states, filter on say 1.1.1.1 and kill any active states.. Now your phone/tv or whatever won't be able to get out.
-
@johnpoz Hi, I went to the states page and killed the 1.1.1.1:443, rebooted the firewall and it still comes back. i don't even know what the phone is connecting to, how or when. It just randomly pops up again connected to 1.1.1.1:443. Disappears and then randomly comes back. Same with the 1 Tv.
I am using a roku and chromecast, it is a smart tv, but not using any tv functions and it to will randomly show connection to 1.1.1.1:443. If devices can be hard coded to bypass the firewall at will, seems all firewalls will become useless.
I reset all States and it the phone reconnected immediately to 1.1.1.1:443.
-
@disgrun well then your firewall rules are not correct for blocking 1.1.1.1:443
Pretty simple destination 1.1.1.1:443 can you post a picture of the rules..
Understanding that rules are evaluated in order, top down, first rule to trigger wins, no other rules evaluated - so if you have a rule above where you block that allows, then the block wouldn't ever even trigger.
Its not bypassing the firewall if you see a state for it.. Your firewall is allowing it.
edit: on whatever interface your devices are connected to? lan? some other network on pfsense.. Create a rule like this.
For that matter you could just make it a full any any to 1.1.1.1 - I mean your not going to be talking to that address on any other ports are you?
-
@johnpoz Resolver is doing all the work along with pfblockerNG. Here is pic of rules.
-
@disgrun and how is that going to do anything? Where is your port forward for the redirection, your trying to redirect 443 to 53?
Your 3 rule there your default allow would allowing anyone that network to talk to any IP on any port.. So if client says I want to talk to 1.1.1.1 it would be allowed..
If you don't want devices on this office network talking to 1.1.1.1 on 443 then create a simple rule to block it.
-
@johnpoz I believed that was all done via the DNS Resolver and pfBlockerNG. It does block all access to 1.1.1.1:443 when i try to use it via laptop or phone, it is blocked.
Somehow phone is bypassing the Resolver and pfBlockerNG, not when i try to, That is blocked. but on it's own, it goes right through.
I will try adding your rule, hopefully that will patch the hole, but still wary of how it is bypassing resolver and pfblockerng.
-
@disgrun have no idea what you did in pfblocker or the resolver, but they have zero to do with a device opening a connect direct to an IP on a port..
-
@johnpoz I entered your rule! Hopefully this will work! Fingers crossed.
Still would like to know why it works on all other devices, without this rule. I appreciate your help!
-
@johnpoz Hi, It went bad again, this time it sneaked it's way to 1.1.1.1:80 !
-
@johnpoz Hi, I changed to your second rule, blocking everything to 1.1.1.1 That should do it and i am logging the results to track what is making it to 1.1.1.1 again Thank You! Appreciate your help, one rule to rule them all.
Still disappointed in Resolver and pfBlockerNg, as they failed to stop it without your rule.
Thanks!
