Wireguard gateway connection issues when using domain names for peer endpoints
-
@Bob-Dig Thank you Bob! I'm glad to know it's not just me with that issue. I will give that a try and see what it does, but if I remember I didn't do it because like you said I get DNS leaks and I don't like DNS leaks.
-
@Bob-Dig Hi again Bob,
Interestingly, I change General setting dropdown DNS menus to WAN and change dns resolver outgoing network interfaces to only WAN.
The outcome:
-
Now using domains in all wireguard endpoints work when I restart the wireguard service on pfsense everytime, where as before the OP issue would occur every time.
-
DNS leak test shows i'm still using QUAD 9 for DNS but also shows Calgary Unix User Group. Before, it would show DNS location of USA (same as my wireguard). The new location it shows is now in my country but not close to me.
Do you know what's going on there? Why isn't it showing location close to me? Quad9 definitely has dns servers way closer to me. And that UNIX group doesn't seem to be affiliated with Quad9. And Woodyneed is only showing ipv6 addresses.
Sorry to pick your brain but do you know of any work arounds to not use WAN as dns to make this work? I guess you already said you don't have a solution :(
Thanks!
-
-
@pfsenseuser10293 The easiest solution is to live with some DNS-Leak, although it will go to Quad9 anyways so you can ask yourself if this makes any difference to you.
And for some hosts, where you don't want any dns-leak, you give those hosts or networks a dns-server of your liking via dhcp and not Unbound in pfSense, done. -
@Bob-Dig Thank you. So in this context of having selected WAN for DNS in the pfsense settings - Does this mean my ISP is getting all my DNS traffic and can see websites I visit (on top of quad9 public dns)?
Im using DNS over TLS so maybe they can't..
Meh, maybe i'll just keep using IP for wireguard endpoint...it's not the end of the world I guess. Having more privacy is more important to me i think.. Everything else seems to work fine..
-
@pfsenseuser10293 said in Wireguard gateway connection issues when using domain names for peer endpoints:
Does this mean my ISP is getting all my DNS traffic and can see websites I visit
With your config, your ISP never sees anything because it is encrypted towards Quad9. In your case the only DNS-Leak happens to Quad9. They know your WAN-IP if goes through your WAN. Again, I think in your case your good anyways.
-
@Bob-Dig Thanks!! I'll have a long think about it.
-
@Bob-Dig Hi Bob,
Do you think I should report this as a bug in the pfsense bugtracker? I know you mentioned you have the same issue too.
Or would you consider this not a bug?
TY
-
I use VPNs differently (policy based routing) so never had this issue.
But as explained, the issue is, if you try to lock down all DNS to a VPN end point which in itself requires working DNS to connect, then you will hit a failure at some point.
Options.
1 - Use a dedicated DNS pathway thats just used for OpenVPN setup, as far as I know pfSense doesnt offer this natively as a tick box, but you can make it so pfSense itself is allowed to query DNS directly, whilst all clients only use VPN DNS.
2 - Use policy based routing to force everything for clients including DNS out over a VPN gateway, but non LAN sourced traffic such as pfSense originator is allowed direct access, this would solve the problem in a similar way to #1.Both of these options should still prevent DNS leaks providing you only care about traffic on clients.
-
@chrcoluk Hi chrcoluk,
Thank you for that information.
For option #1, did you mean create a wireguard tunnel/peer on pfsense with the details from my VPN provider's config (to whatever location I choose) and only use that for DNS queries for all clients?
So to do this I would just select the wireguard I created (just for DNS) in Services -> DNS Resolver -> Outgoing Network Interfaces? This would be the only thing I select in the list.
This should allow me to set domain name (instead of IP addresses) as the endpoint for all my wireguard peers?
-
@pfsenseuser10293 This can end up being quite long technically.
One way of doing is it have DHCP send the clients, the VPN ip as the DNS server, so all clients dont use the firewall for DNS queries, they go straight to the VPN, meaning if the VPN is down they simply fail instead of leaking. Policy based routing can still ensure all client traffic goes out over VPN, and again it can be configured so if VPN is down, the clients fail instead of leaking.
pfSense itself, in the general settings configure a DNS resolver thats "not" on the VPN. That is your dedicated pathway pfSense to assure the OpenVPN host name can be resolved when establishing the tunnel link. But wont be used by the network clients.
As a bonus you can setup outbound NAT rules which will prevent leaks from app's trying to use other resolves that are hardcoded, so e.g. if your VPN ip is 10.10.50.1, and some app is trying to use 8.8.8.8, although that query will still likely go over the VPN from the policy based rule, you can as a bonus measure force pfSense to redirect all outbound DNS queries from LAN subnet to the VPN IP 10.10.50.1.
Add a DoH blocklist in pfblockerNG as well to deal with potential DoH leaks, although that should be handled by the policy routing, its a second layer.
Also if you using policy based, in advanced -> misc, make sure you tick the box for "Skip rules when gateway is down". Then add a rule below the policy based rule with gateway as default, as a reject rule. This rule then kicks in when VPN is down.
Another method is to tag the traffic on the VPN rule, and then on a floating rule deny that tagged traffic going out over WAN, so there is multiple ways of doing it. -
@chrcoluk Thank you very much for detailed response.
The way I have it setup right now is:
-
#1 Active directory interfaces have a firewall rule that allows dns on the subnet to windows domain controller (I found this worked the best for active directory connectivity)
-
#2 Domain controller DNS manager is set to forward to pfsense for DNS queries it cannot handle (anything that's not local AD DNS)
-
#3 Pfsense then filters DNS queries via pfblockerng DNSBL lists
-
#4 Lastly, DNS over TLS is used by pfsense to Quad9 (Using dns resolver outgoing network interface as two of my wireguard gateway tunnels)
Unfortunately, I think if I hand out VPN DNS via DHCP like you said (which I think I used to do) - some or all of above cannot be used.
Pfblockerng has DoH blocklist enabled already. I also have Skip rules when gateway is down checked but didn't have a reject rule afterwards. I've added that now.
Just to clarify, i'm not having any DNS leaks the way my stuff is setup currently.
But my issue was: in DNS resolver settings, when I set outgoing network interface to WAN it's the only way i can get domain names instead of IPs to work in the wireguard peer endpoint fields. But then this causes some DNS leaks but could be acceptable to some users. If I don't set DNS resolver outgoing network interface to WAN (and instead use my wireguard gateway tunnel), I can't set my VPN's domain name as the wireguard peer endpoint (I think it only doesn't work for the interfaces I select for the DNS resolver's outgoing network interfaces - or at least one of them). Only IP address will work.But as Bob said, maybe it just doesn't work and I can either just use IP address for WG's endpoint or live with a DNS leak by selecting WAN as outgoing network interface in DNS resolver settings. Or if it was a bug I could try reporting it. Sorry if I have your info confused, i'm not super technical.
-
-
@pfsenseuser10293 You might be able to do what you need with bind which should support view clauses,, pfsense has a bind package.
So different ip's making the request get routed differently over DNS, you could set localhost to bypass unbound, and put everything else to forward to unbound (dns resolver) and work as you have now configured.
I just had a quick look, no patching/hacking needed, views are configurable in the GUI, and you can change the port for unbound in the GUI, so bind is 53, and put unbound on a different port to listen for queries sent to it from bind.
pfSense -> bind -> internet
LAN -> bind-> dns resolver (unbound) -> (filtered) VPN/domain controller
