DNS Resolver Leaking and DHCP addresses

johnpoz

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

disgrun

@johnpoz Resolver is doing all the work along with pfblockerNG. Here is pic of rules.

johnpoz

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

disgrun

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

johnpoz

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

disgrun

@johnpoz I entered your rule! Hopefully this will work! Fingers crossed.

hope this works.jpeg

Still would like to know why it works on all other devices, without this rule. I appreciate your help!

disgrun

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

1111 80.png

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 ;)