Unbound DNS Resolver through Wireguard Tunnel (Mullvad VPN)
-
@packetpirate Sorry, no real help here, just in the same spot as you. I'm a novice at this stuff, main reason I got into pfsense and such was for unbound dns resolver and by proxy pfblockerng. How exactly would I use OpenVPN for queries? Just install the Mullvad linux config like you usually do through openvpn and have the DNS resolver's outbound interface set to openvpn?
-
@shrinkmyprostatenow Yes exactly. Just follow the Mullvad instructions to setup an OpenVPN connection, then for the Unbound DNS resolver set the "Outbound Interface" to your OpenVPN interface.
-
@packetpirate said in Unbound DNS Resolver through Wireguard Tunnel (Mullvad VPN):
Thank you for confirming this.
I am currently doing exactly as you said, putting Unbound in forwarding mode and forwarding to the Mullvad servers. The one you listed is I guess the non HTTPS version, they now have DNS over HTTPS at doh.mullvad.net (194.242.2.2), so I am using that now.
https://mullvad.net/en/help/dns-over-https-and-dns-over-tls/
I would much prefer to run Unbound in "normal" mode, and act as my own DNS server. Is there any way for me to do this without leaking my IP? So far the only solution I have found is to run OpenVPN in parallel and then send my queries over the OpenVPN interface. It just feels quite overkill to have OpenVPN and Wireguard running on the box.
I’ve found this: https://schnerring.net/blog/use-custom-dns-servers-with-mullvad-and-any-wireguard-client/
It looks like there is a way to send DNS queries to root servers through Mullvad’s WireGuard tunnel.
Maybe worth a try? -
@emikaadeo It worked! Amazing. Thank you for finding that blog post.
I setup two WG interfaces, one using the regular IP generated from Mullvad, and one using the non-hijacked IP as described in the blog post, and only the non-hijacked is able to resolve DNS.
In both cases I see the connections to the root servers, but only when using the second IP am I actually able to resolve.
-
@packetpirate Yep, it works here too ;)
-
-
-
@emikaadeo My firewall log is exploding with blocks to and from the internal WG interface IP and the root name servers, for example the k-root server.
The log entries are:
WAN out -Default deny rule IPv4: Internal WG IP:port --> root server:53
WG_Interface in - Default deny rule IPv4: root server:53--> Internal WG IP : random portThe strange thing is that DNS works fine over the WG interface, so the communication must be happening, but I am seeing a lot of these log entries.
Any idea? Do you see the same?
-
@packetpirate
No, I don't see anything like it.
My traffic to root servers on port 53 is on the "pass" side. -
@emikaadeo
Do you have pass all firewall rules on the WG interface? Currently I have no rules at all in there.Then again I don't think that would change anything, these blocks are happening on the WAN Outbound, so I would in theory need a rule on WAN saying pass WG interface to any port 53? Do you have such a rule?
-
@packetpirate said in Unbound DNS Resolver through Wireguard Tunnel (Mullvad VPN):
@emikaadeo
Do you have pass all firewall rules on the WG interface? Currently I have no rules at all in there.Then again I don't think that would change anything, these blocks are happening on the WAN Outbound, so I would in theory need a rule on WAN saying pass WG interface to any port 53? Do you have such a rule?
My pfSense setup is almost the same as here
The main difference is I don't have CLEARNET subnet and use WG instead of OpenVPN. You can compare this to your rules/setup. -
@emikaadeo
Wow, that is quite the guide.I guess the part which confuses me is that when using wireguard, the wireguard interface itself gets an IP address (the internal IP given from Mullvad). When using OpenVPN as in the guide, the interface itself doesn't get any IP.
The issue I am seeing in my logs comes from this internal IP trying to access root servers directly, and I am not sure how to control that interaction.
I will have a good read through the guide to see if I can sort this out in my head, thanks.
-
@emikaadeo
After quite a bit of head scratching I found the root cause. In the DNS Resolver Network Interface section I had ALL selected, this guide only chooses the interfaces which are set to use the DNS resolver. It seems that including the WAN and WG interfaces in that selection is what was causing my strange log entries. Thanks! -
@packetpirate
Glad you figured this out! :)