DNS Resolver Leaking and DHCP addresses

disgrun

@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!

johnpoz

@disgrun said in DNS Resolver Leaking and DHCP addresses:

Still disappointed in Resolver and pfBlockerNg, as they failed to stop it without your rule.

they do different things, they resolve.. I use pfblocker for aliases, but I believe its possible to create rules that block IPs with it..

if your client was trying to resolve

;; QUESTION SECTION:
;one.one.one.one.               IN      A

;; ANSWER SECTION:
one.one.one.one.        86400   IN      A       1.1.1.1
one.one.one.one.        86400   IN      A       1.0.0.1

You could stop one.one.one.one from resolving to 1.1.1.1 and have it resolve to say 127.0.0.1 or something or just NX - but that doesn't stop a client from talking to 1.1.1.1 that just stops the client from resolve one.one.one.one to the IP address 1.1.1.1

AndyRH

@disgrun Your first rule says let all go to anywhere on 80 and 443. The Block rule is never evaluated. Move the block rule to the top and try again.
If it is on top, then the first rule will say block all to 1.1.1.1 If that is the destination the rule is matched, and the traffic is blocked.

johnpoz

@AndyRH look again that is the antilock out, it allows 80 and 443 only to pfsense address.

Gertjan

@disgrun said in DNS Resolver Leaking and DHCP addresses:

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?

An access to 1.1.1.1 using port 443 is a TLS access.
And TLS, as 'https', you do not want that to be intercepted.
Because if you want that to happen, world's economy will fall into a black hole within the hour.
If TLS breaks, no more secured access to your bank, personal info, we're all back to the 'http' age. Let that sink in for a minute or two.
It would be ..... the end. Like the Walking Dead without the zombies.

What you can do : block it. By using pfBlockerng, at has list build in, or a plain good old firewall rule.
I'm pretty sure that even if a device insists on using 1.1.1.1, it will fall back to the DNS server IP supplied by the local (pfSebnse) DHCP server, so it winds up using (default) 192.168.1.1, and at that address, the pfSEnse LAN port, the resolver will be happy to reply to any DNS needs.

@disgrun said in DNS Resolver Leaking and DHCP addresses:

It went bad again, this time it sneaked it's way to 1.1.1.1:80 !

There you have it.
DNS is send using non encrypted packets. So (your) security wasn't their goal.
They are after the data.
Next time you buy a device, ask the seller about colors and all that.
As they don't want you to test drive the device, you have to use other means to know upfront what the OS is, who's behind it. Only then you'll know if you have control, or if you are being controlled. Then, knowing these details, make your pick.

Btw ;: good news is that 1.1.1.1:80 can be redirected easily on pfSense using a classic NAT rule.

You see this (green) :

that measn that that rule starts to match traffic.
Which means some device on your Office LAN is sending traffic using "1.1.1.1" as a destination IP.
So the rule matches on entering traffic, and it gets blocked, as it is a block rule.

elvisimprsntr

This post is deleted!

disgrun

@Gertjan Hi, I have the resolver to redirect 1.1.1.1:80 to 127.0.0.1 and I use pfBlockerNG to block the aliases to 1.1.1.1:443 and as you saw, Data is still trying to get through, so I had to add the 1.1.1.1 block rule.

That is the whole issue, why is any device able to bypass Resolver and pfBlockerNG!

Adding the block rule is a good patch for now. But shouldn't we be worried that we even need a Patch!

Hopefully I am doing something wrong or pfsense needs to be tweaked to fix the leak.

johnpoz

@disgrun said in DNS Resolver Leaking and DHCP addresses:

That is the whole issue, why is any device able to bypass Resolver and pfBlockerNG!

what part do you not understand that its not asking for any dns, its just going to 1.1.1.1

Lets see your redirection, lets see what you have setup in pfblocker - is it creating a firewall rule that includes 1.1.1.1 as an IP and blocking it.. Lets see the table it creates for this rule, and where is the firewall rule? is it on your floating tab, because it sure isn't on your office interface.

disgrun

@johnpoz

johnpoz

@disgrun and again that is not blocking IP, its blocking the resolution of that fqdn, that is all..

Where is the table it creates with IPs in that are in your rules.. See that table in your floating tab pfb_PRI1_v4 - go into diagnostic tables, and look in that table do you see 1.1.1.1 ?

If not then no that firewall rule is noting going to block access to 1.1.1.1

AndyRH

@johnpoz said in DNS Resolver Leaking and DHCP addresses:

antilock out

Well nuts. Missed that.

disgrun

@johnpoz The resolver and pfblockerng are indeed redirecting and blocking everything as they are supposed to.

I am an amateur at this so i can't explain how they are doing this without rules or diagnostic tables.

I can assure you that if i try to set my browser or phone to 1.1.1.1:443, pfSense stops ME immediately. It works great for Everything except for this one instance.

I can even recreate it, so perhaps you can duplicate it on your system and see why it is happening. Perhaps the website is doing it somehow?

Go to https://one.one.one.one/help/

That makes it happen.

johnpoz

@disgrun because you created a firewall rule that blocks 1.1.1.1..

Again - look in that table pfb_ in your diagnostic menu.. Do you see 1.1.1.1 in it, if so then it would be blocked.. But it doesn't so its not.

btw - hiding rfc1918 addresses is pretty pointless.. And you missed one there at the bottom.. what do you think anyone could do with a 192.168 address, they do not route on the internet, they say nothing about even what ISP your using, etc. etc.. This is like saying hey I live on a street with address 123.. Well yeah pretty much every street on the planet will have numbers as addresses on them. But knowing that its 123 on some street doesn't help you find the actual address ;)

disgrun

@johnpoz as you can see pfsense does block the website

but when the website is blocked 1.1.1.1:443 or 1.1.1.1:80 try to get through.

Is this normal?

johnpoz

@disgrun not sure what your not understanding how dns works?

pfblocker and unbound can be set to not resolve something, or send you a wrong IP so you can't actually get there. But this is only the resolution of the fqdn to the IP.. This does not stop actual traffic to the IP.. Only a firewall rule will do that, and for the firewall rule to block, it has to trigger..etc..

Do yourself a favor and look in that pf_ table in your floating tabs in tables under the diagnostic menu..

remove your block rule you created on your office interface and go to https://1.1.1.1 vs the name one.one.one.one

disgrun

@johnpoz went right through without the patch rule.

and website still blocked by pfsense

johnpoz

@disgrun exactly - so what part are you not getting.. see that NXdomain, that says that one.one.one.one did not resolve...

So what part are you not getting? you understand that some fqdn like www.netgate.com has to resolve to an IP to actually talk to it right.. But if you know the IP you can talk to that IP without having to look up the ip via dns.

If your client says hey I want to use doh with site called one.one.one.one and it doesn't resolve it can't get there, but if it just goes to the actual IP 1.1.1.1 unbound, ie resolving that fqdn is not involved.. Only firewall rules that actually block to IP or port would be involved.

That is why when you created a firewall that blocks access to 1.1.1.1 it fails, doesn't matter if the client looks it up from one.one.one.one or googledns or clouddns.org or whatever - you ain't talking to that IP.

disgrun

@johnpoz Hi, Ok, I think i got it . Everything is working great, the 1.1.1.1 i am seeing is NOT a dns, entry it is a website address. So the DNS is being redirected but I am seeing the 1.1.1.1 since it is the address of the website. I think that solves it!

Thank you! Your help was greatly appreciated!

Hopefully you can give me an answer to my second part of the post.

Why do I see ipv6 address for all my devices even though ipv6 is off. I always thought pfsense handed out all the addresses to my devices.

Some devices even have more than one ipv6 address.

Thanks!

johnpoz

@disgrun what IPv6 address?

Like this?

Pretty much any modern device will have those, unless you on purpose disable IPv6 on it - like this

Yes an actual GUA would come from pfsense, be it via dhcpv6 or slaac

disgrun

@johnpoz Is there no way to stop/disable them with pfSense?

Or can i do it via Terminal screen in linux?

How is netflix getting an iPV6 address from me?