I know this is a quite late response, but I would just like to chip in as I don't believe anything has really changed since the original discussion occurred.

The main reason why it still makes sense to set up Stubby (or other DoT solutions), even though Unbound has DoT support, is that unfortunately Unbound seems to be VERY inefficient at doing DoT.
While eg Stubby (getdns) reuses connections, avoiding unnecessary TLS handshaking, Unbound so far does not. (See https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089)

Unbound seems to effectively sit there handshaking all day, and as a result is notably slow in comparison.

@johnpoz said in pfSense as a private DNS resolver:

What happens when the vpn fails not sure.. But if you have unbound only bound to the vpn interfaces that will sure fail.. But can also cause issues when pfsense is booting and vpn is not up yet and unbound tries to bind to the interface, etc. Why you normally just bind unbound to the loopback

That won't be a problem. I set the Outgoing Network Interfaces in the resolver to be just Localhost as you suggested before. Also, set the WAN to be the default gateway so pfSense will use it for its internal needs etc. without any consideration to the VPN (up or down). When VPN fails, only interfaces that should use it, should be affected.

@johnpoz said in pfSense as a private DNS resolver:

then put it on your local network and policy route

Are you talking about a seperate physical device for DNS resolving?

@johnpoz said in pfSense as a private DNS resolver:

If your going to use dot, doesn't matter how unbound gets to the internet - its always going to be encrypted

I'm sorry but now I'm a bit confused. You said before that unbound won't be able to resolve using DoT, so you're talking here about forwarding to an external DNS (like Cloudflare) and use DoT?

@johnpoz said in pfSense as a private DNS resolver:

If your routing pfsense traffic out your vpn, then unbound would use that

That's exactly what I want. DNS requests coming from X interface should be encrypted via DoT or simply go through the VPN gateway or even both lol. I don't care about the rest...let pfSense do its thing.
So can I be 100% sure that for DNS requests coming from the LAN net, the unbound will also go through the VPN gateway just like the rest of the traffic originated from LAN net?
EDIT: Sorry, I think I misunderstood you. By pfSense traffic you mean the entire thing using the VPN as opposed to just certain interfaces?

Good !!
You managed to make live easy for the one who replies to your question.

You had to :

@bhjitsense said in Enabling 'Register DHCP leases in the DNS Resolver' causes crash:

disabled 'Register DHCP leases in the DNS Resolver' recently due to DHCP/DNS taking way too long to restart

which means this isn't 'unbound' only that restart, but probably some packages with a big payload.

Now, it's no more 'big wait', but clearly :

@bhjitsense said in Enabling 'Register DHCP leases in the DNS Resolver' causes crash:

swap_pager: out of swap space

You ran out of memory AND swap memory.
That's the moment any system would just die ...

Solution : more (far more) memory. Bigger processor.
Or remove the load (packages).

@jahonix EDIT: Basically the DNS leak test website asking to resolve a url and who ever resolves it for him is listed in the results. I had to think about it for a few moments and also do a test where I'm connected directly to my ISP's Modem/Router (bridge mode) and then the results were 10+ DNS servers belong to my ISP.

Now, after I setup pfSense to act a "natural resolver" I see only my personal IP in the DNS leak test results.

Bye bye Cloudflare....lol. Now I just want to make sure these DNS queries go through my VPN gateway.

Thank you for the explanations nonetheless :)

Thanks @Gertjan and I tested it in pfS....

drill -T facebook.com com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. facebook.com. 172800 IN NS a.ns.facebook.com. facebook.com. 172800 IN NS b.ns.facebook.com. facebook.com. 300 IN A 157.240.201.35

.....and the above is what I expected connecting to a root server in this case "f.gtld-servers.net", but any idea why does this test site reports that dns is from my ISP?

http://www.whatsmydnsserver.com/

Stupid Stupid 😊 I think I found out why I got mixed up, this site returns my pfSense WAN IP as DNS and relates that to my ISP

btw ...is there any similar Linux command that I can use as dig +trace doesn't work the same on Freebsd as with Linux and drill doesn't work on my Linux distro

Yes you can use pfblocker with unbound in forwarding mode.

Ok. My RA was configured in assisted mode. I changed it to managed so now all the addresses are from the DHCPv6 pool. I will monitor the status page as previously in assisted mode, I was getting the addresses from the DHCPv6 pool but after a while they stopped listing in the status page.

Ok, got the pfSense packet capture now working (had it by default limited to 100 packes and did not caputer the later dhcp packets).

Now it matches what dhcpdump captures:

First, I see a dhcprequest broadcast from my client (0.0.0.0 -> 255.255.255.255) Then I see another DHCPREQUEST from my pfSense to my DHCP server Third then is he DHCP server replying to my pfSense with DHCPACK And fourth is the DHCP server replying to my client with DHCPACK.

Still the question: Why does my pfSense dhcp relay forward these requests?

/KNEBB

i guess my first question.

are you use the internal DNS server or their external DNS server? depending on HOW you connect to mullvad the internet gateway/ DNS server will be different than what they posted..

there are a few tutorials on forcing DNS: again depending on how you setup the tunnel will depend on which server you use the external should always resolve though...

https://www.techhelpguides.com/2017/06/12/ultimate-pfsense-openvpn-guide/

when you are assigning static ip addresses I hope you are using pfsense for this. it does this very well.

good luck

Check other logs, like DHCP.

And check this :

560f44e4-e0df-4822-b49d-c40703fbe24f-image.png

if this option is checked, then for every new lease, the Resolver will get restarted.

pfsense was all good, did some reading and more reading and then tried a tiny mod to the AP config and success.

@Gertjan sorry but setting it to zero does not fix the problem. it should be debugging only at HIGH levels of verbosity.
I have it set at 3 for a reason in any case. a documented feature is that different verbosity levels provide certain information.

maybe pfsense has included a developer build of unbound or the developer forgot to turn off some test ifdef's that force debug.
problem solved for now but "sloppy"....

@NogBadTheBad

Thanks for your responses. I got access to the network room and plugged in directly, no issue over ethernet. This has to be an issue with the shitty HPE WAPs they have. They suck big time. Take care!

pfSense does not use the Unbound ipsec module, so it's a non-issue.

Thanks. I forced reload the whole list and it is working fine now. Hope it will last.

@Gertjan Got it,

Thanks

did you get this solved? im having a silimar issue