Wireguard gateway connection issues when using domain names for peer endpoints
-
@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 -
@chrcoluk Thank you!! I'm going to give it a try tomorrow probably! Hopefully I can figure it out. I'll let you know!
-
@chrcoluk Hi again chrcoluk, I started researching bind and started to understand it more. But I happened to try setting domain name again for wireguard peer endpoint field.
I noticed that when I did this, I immediately got WAN_ISP interface blocks with source: being my mullvad wireguard gateway ips and destination: my quad9 public ips using dns over tls port 853 set at system -> General setup -> DNS Servers.
These are the blocks in the firewall log:
and if I hover over the red X, I see:
Could this be causing my issue? How can I find this block rule and remove it? I looked at firewall rules on WAN interface and I don't think I saw a WAN rule that matched that ID when I hover over the red Xs:
Thank you
EDIT: after doing some digging I think this is some sort of default rule that cannot be removed? Do you know if there is some allow rule I can create to make this work in a secure manner? The only thing is, I think the wireguard mullvad gateways IPs can/will change...
-
@pfsenseuser10293 WAN is for inbound traffic. by default all outbound is allowed.
Did you change default outbound block/allow setting?
-
@chrcoluk Not that I can think of (at least intentionally)
- I have pfblockerng enabled. For IP tab, I only have a few TOR lists to block.
It has these interface settings:
-
DNSBL has a bunch of custom ad blocking lists and DNSBL safesearch has DNS over HTTPS/TLS/Quic blocking enabled but this is DNS not "default deny rule ipv4" as stated by the block entry. The DNSBL firewall rules are set to not be permitted on any wireguard interface and WAN isn't even selectable.
-
All of my wireguard interfaces have this block rule:
None of those match the tracking id: 1000000104 that is stated by in the block entry
-
Suricata is enabled but only on two interfaces completely unrelated (A IoT network for example). Also shows no blocks in the log for suricata.
-
For wireguard mullvad peers I created, allowed ips are all set to: 0.0.0.0/0
-
DNS Resolver settings has this rule unchecked, do I have to enable this?
It also has this enabled (which I know isn't enabled by default):
- Floating rules only has the pfblockerng rules in it.
This is all I can think of right now.
-
I tried testing remove quad9 from the DNSBL safesearch blocking and reloaded pfblockerng but the blocks on the firewall to quad9 still appear.
-
@chrcoluk Under System logs -> Firewall -> Normal view where the blocks to quad9 were appearing on wan interface, I also tested clicking the + sign on the desintation column "EasyRule: Pass this traffic" for all the entries. After that I restarted wireguard and it some how made the issue worse. None of the wireguard interfaces go up now. Before, at least some of them would successfully come online. They're all Offline, Packetloss 100% now, even after removing the new WAN interface allow rules and restarting wireguard. I had to add the IP address to the mullvad wireguard peer endpoint.
I think this just may be a distraction. I will focus back on understanding and doing the bind method
-
@chrcoluk going back to the Bind method: I think I understand what it's doing; making localhost (pfsense) bypass unbound but i'm really confused on what settings to change on Bind..
been trying to find resource online for editing it.
-
Hi again,
Interestingly, after playing around with more settings, this seems to have fixed is completely!:
in system -> general setup:
I change it from:
use local DNS (127.0.0.1), ignore remote DNS Servers to
Use local DNS (127.0.0.1), fall back to remote dns servers (default)I dont seem to be getting DNS leaks (from dnscheck.tools) and now I can restart, stop/start wireguard and all wireguard gateways come up really fast now.
Do you know what Use local DNS (127.0.0.1), fall back to remote dns servers (default) is doing? and why this works? Any privacy concern using this?
Thank you!
-
@pfsenseuser10293 using localhost will make it use the service you have configured whether thats unbound or bind. otherwise pfSense can query forwarders directly.
It will probably be fine how you set it now, pfSense only needs DNS for its own updates, news widget on dash, and to connect to the VPN's.
I did forget about that option.
-
@chrcoluk SWEEEEEEEEEEEEEEEEET. Thank you so much for your help!!!! I guess I dont need to do the bind method then! Thank goodness!!