DNS Resolver Leaking and DHCP addresses

[disgrun]

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

[AndyRH]

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

[johnpoz]

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

[disgrun]

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

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

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 !

[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