pfSense + Pi-hole & Unbound + Brave Browser = DNS Leaks!

Networking & Firewalls
1

Greetings, forum, this my first post here.

My home lab is about 2 years old now and during that time I’ve avoided playing with the router because it basically terrifies me … yawn … hence, I’ve learned almost nothing about the firewall or router config … and I’m pretty sure therein lies the solution to my DNS leaks …

But, of course, I am in this forum to hear from the experts before I waste yet another day (of my essentially worthless time) on this nonsense …

My home network has a single upstream WAN, 4 subnets on 192.168 … , three OpenVPN tunnels running on ExpressVPN which is installed on a Quotom 4125. This is gen 10 Celeron architecture, with 4 RJ45 subnet NICs …

Recently I decided to try running Pi-Hole on the home net … and so I added a spare mini to a local subnet, installed Deb 13 RC2 (req’d because the mini has Alder Lake N series integrated PCI stack) and then installed Unbound with PI-hole.

Correct operation of pi-hole/unbound with DnsSec was verified after installing those.

After setting the pi-hole IP as DNS for the test subnet and using an old laptop running Deb12 with Brave Browser, I tested for DNS leaks at dnsleaktest.com.

It failed … and everything I’ve done to try and fix it has failed as well … I was also reminded of my deep lack of understanding of how the firewall rules really work …

So, after restoring the router to its last known functional config (as of about midnight last night), I felt very happy and fortunate to have an operating home network again …

Although the Brave browser is hard coded to query upstream DNS sites (and for some reason this setting is immutable) I remain convinced the solution lies in simply configuring the firewall correctly.

I’ll leave it there as this is already way too long …

Thanks in advance for your kind attention … g

2

This might help.

3

Thanks for the link, MAX.

This is the video I used to get my VPN’s set up maybe 18 mos ago.

I have not yet watched it since, but I will !

I was actually reminded of that video when I looked at the port 53 re-direct rules for the VPN’s last evening … I remembered they came from this video, which got me started thinking about doing sort of the same thing for my test subnet …

I’ll follow up here, hopefully with a nice success story.

4

How can I post an image ?

5

It’s better if you start by posting details about the problem you are having in text form as it’s often easier to parse.

6

OK about posting an image …

I just wanted to illustrate the test I am trying set up on the subnet … this is all probably an unnecessary exercise, as I should use the Pi-hole IP as the system DNS and go from there, but I first wanted to set up the Pi-hole as DNS for the single test subnet … anyways that’s what I wanted to illustrate with a high-level block diagram …

Additionally, before making any further changes to my router I watched the ‘Privacy VPN + Policy Routing’ link MAX posted back on day one of this thread …

Being somewhat stubborn and carrying on with the subnet test objective, I added a floating rule to block WAN egress for any tagged packets from the test machine residing on the test subnet …

So, this is the fourth floating rule configured for my firewall, the first three being the ‘kill switches’ for each of the three VPN interfaces which I set up the first time I watched that video some 18 months or so ago.

I added a rule to the test subnet to apply the tag to all egress traffic from the test machine.

This is ‘the kill switch’ described in the video, if I understand it correctly.

I did some very simple testing by just hitting any external IP and that’s when I observed that none of the floating rules are doing anything. Threy’ve all got no states and no data count …

So, I don’t think any of the floating VPN rules ever worked either, but as usual with pfSense, I’m not too sure about that too.

After adding the above described two new rules, I was able to get out to the internet from the test machine, but the kill switch blocked no packets … so I really don’t know how the packets got out …

At this point, I would appreciate some advice on how I should actually proceed to stand up Pi-hole on my home network.

I am perfectly willing to scrap my test-subnet-only idea and try whatever you think is best.

7

On the kill switch, you can’t do the test like that. Pfsense tries to be helpful (not so helpful in this case) to keep traffic passing on policy routing even if the gateway is down on your VPN tunnel. Hints why you have to create a floating rule that has tagged traffic on your firewall rule on the interface you are setting the policy routing on.That video is spot on for what you need to do for this to work properly.

As for pi-hole it’s simple standing up a VM and then updating your DHCP setting to hand out the IP of your DNS server.

8

So, you are saying ‘use the Pi-hole IP as the system DNS and go from there’, it seems ?

As far as the VM, Pi-hole/Unbound are currently hosted in tandem on the test box as normal apps.

I would put both in a VM container to harden security, no ?

Are there other reasons to use VM containment which will help resolve the issue ?

Also is there a character length issue if the policy tags are too long ? I just assumed the entry field would lock out any more characters when some hard limit had been reached. This did not occur. The tags are intended to be self-documenting and might be 16 or 20 characters in length.

Because, as I mentioned above, the kill switches do not appear to be doing anything whatsoever.

For instance, the ‘Route_Out_Pi_Hole’ tag is applied to all WAN address egress from the pi-hole test client’s IP at the test subnet interface (I guess … this rule is presented in the test subnet rule set) .

Then the floating rule scans for anything from test-subnet-i/face looking to egress WAN_DHCP and is configured to block it.

Shouldn’t this ‘just work’ ?

This is basically my best guess and please correct me if I am wrong.

9

So I’ve been looking at ‘Ordering of NAT and Firewall Processing’ in the pfSense manual and cannot understand how a floating rule can detect ‘a tag which has been applied by another rule’ if the floating rules are evaluated prior to the interface rules, since it is the interface rule which applies the tag.

How can this make sense ?

10

You need to re-watch that video I posted at the 15 minute mark.

11

Hi MAX, Thanks for the tip - I’ll do it …

But, now that I’m here, I’d like to point out something about the firewall which I cannot wrap my head around …

After some rather careful reading of the pfSense docs it seems the filter rules are processed at a subnet interface for ingress only (unless a floating egress rule applies) … BUT … NAT is applied to the packet first, so … how can a rule on the subnet interface apply a policy tag to packets outbound on that interface if the egress packets are NAT’d first and the entire subnet rule set is ingress only ?

Won’t all outgoing packets simply be passed on without any scrutiny at all ?

I would really appreciate a comment on this because it is kind of driving me nuts …

12

I’m not sure what else to say. That video I posted shows how it is working in real time and is blocking traffic as expected for the kill switch.

13

We’re focused on the kill-switch aspect, so here’s what happened.

I went through the kill-switch material at the 15 minute mark and I am set up the way Tom did it, as far as possible … some of the screens and behaviors are different since Tom’s demo was done on v2.5.0 (I think) and I am running v2.8…

The subnet rule which tags outgoing packets from the ‘aliased’ host is counting states and data, so it seems to be working, but the floating rule isn’t blocking anything when I stop the VPN service. The test machine just happily goes out the WAN_DHCP to it’s intended destination …

You have ignored all my incidental questions, which is good practice I guess, for keeping things focused, but we’re not getting anywhere, unfortunately.

Thanks for your patience and what I believe is your sincere intention to help me out.

I am well aware that professionals find amateurs to be quite annoying.

You keep saying the same things to me and I keep giving the same answer - kill-switch no workee …

I can only conclude there are functional differences between v2.5.0 and 2.8.0 …

14

Just to wrap things up here, I did find these links earlier today -

Here, the poster restored correct policy-based routing operation by reverting from 2.8.0 to 2.7.2 …

Which refer to ‘state policy defaults have changed’ from ‘floating’ to ‘interface bound’ which ‘may impact policy-based routing’ … a possible work-around is suggested …

Additionally, a new bug fix has been released, 2.8.1, and the question arises - try the bug-fix, revert or try the 2.8.0 suggested work-around …

I was really expecting to get some help with this, but that doggie just won’t hunt, it seems …

In closing, I think a bit of philosophizing would be appropriate -

“Whereof one may not speak
thereof one cannot say. “ - L. Wittgenstein