Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - CactusFractal

#1
I considered spinning up a PiHole with Unbound to hand off DNS as well, let me know how it goes with your continued testing.

Do you happen to know if your VPN provider intercepts / redirects DNS traffic?  If not, it would seem that the issue could be related to my #1 or #2 theory above.
#2
Yes, I set the DNS entry to the one provided by my VPN provider.

For now, I have reverted to a base config without policy routing, which routes ALL traffic from my router through my VPN using Wireguard.  It's working great, near my rated line speed even with the WG-Go userspace implementation, so I'm super frustrated I have not yet been able to get policy routing working.  I am loving OPNSense's speed and interface so far.

My working theories are still some combination of:
1) An issue with the Wireguard protocol or WG-Go being unable to route TCP DNS traffic by design
2) The particular DNS addresses my VPN provider issues being in the RFC1918 space
3) The fact that I believe my VPN provider intercepts DNS traffic (in the name of preventing leaks, but it may break this implementation)

I look forward to your further testing, and thanks.
#3
Yes, I did remove the invert checkbox, it got no DNS at all after that.  I am using a VPN provider that I believe does DNS "hijacking" when connecting over WG, I suppose in an effort to prevent DNS leaks.  Maybe this is an issue, I'm not sure.  But I just can't fathom why even if that's the case, I would be leaking DNS to my ISP when checking at dnsleaktest.com.

Just to confirm - what do you see when you test your connection at dnsleaktest.com?  Is it working properly without leaks for you?

Thank you so much.

Edit: So I took the following steps to force ALL DNS through the WG tunnel, and it worked without leaking DNS on a client in the WG VPN Alias:

Quote
In unbound, try setting the outgoing interface to the WG interface AND set unbound to forward mode and set the DNS servers in systems: settings to 1.1.1.1. I think that may fix the issue for you. I'm not sure why it does not work in recursive mode.

I recall reading that Mullvad does DNS hijacking on WG servers. Unlike their OpenVPN servers, where you can connect to a specific port to avoid DNS hacking, they do not have the option for WG servers (perhaps to be added in the future).

Quote
OK, when I did all those three things simultaneously (unbound to forwarding mode, use only WG interface, set system settings general DNS), I actually got the Cloudflare servers returned on the DNSleaktest.com test.

Then, I set the DNS server in System -> Settings -> General to my VPN provider's DNS, and also set it to "Use Gateway: WG_VPN" and HOLY CRAP, it appears to be working without leaking DNS.

This is fantastic, I can't believe it seems to be working. Need to run some more tests to verify non-VPN client connectivity, but WOW!

OK so the net result (as we intended) is that ALL DNS traffic is forced over the VPN, even from clients not in the WG VPN alias. Clients not in the VPN alias appear to be routing non-DNS traffic over the ISP, also as intended. WOW. YOU ARE A LEGEND.

I'm not sure yet whether this setup will result in unintended breakage of services, so maybe there is a way to force clients not in the VPN alias to use different DNS servers by setting them to use DNSMASQ or something? That seems difficult given the particulars of this setup and workaround, but I don't know. It's probably fine.

The whole point in doing this exercise is that I need some clients on my network to egress over the VPN and cannot install VPN software directly on them hence this firewall solution, but I also need to forward some inbound ports to an internal IP to stand up Nextcloud behind a LEMP stack (reverse proxy). I'm hoping I can achieve this with this setup. WHEW!

EDIT: In further testing after deploying settings above, another client that I set a static mapping for and added to the VPN Hosts alias fails to resolve DNS at all.  I'm unsure as to why, but my theory is either that the limitations of Wireguard prevent DNS over TCP from working properly in this scenario, or my VPN provider's interception of DNS is causing issues.  Frustrating.


#4
Thanks for the reply, Greelan!

I have opnSense as close to default config as possible, with DNSMASQ disabled, and Unbound Enabled. 

The computer I'm browsing with receives a static IP and is in the VPN alias configured in your guide.  The device is set for standard DHCP, not static, no overrides.  Further, I have both "Allow DNS server list to be overridden by DHCP/PPP on WAN" and "Allow default gateway switching" unchecked (disabled).  There is only one DNS set in System - Settings - General and that is 1.1.1.1 (Cloudflare).

When I configure the router from stock defaults using my provider's VPN guide, I get ALL traffic routed over the VPN tunnel, no leaks at all.

Here is my latest post on the reddit thread, let me know what you think:

Quote
That's just it - Firefox on a desktop client given a static IP as defined in the step 7 alias shows the VPN IP, but shows my ISP DNS server as reported by DNSleaktest.com.

I did also set Unbound to only send traffic out via the WG interface. It did not work, it still used my ISP DNS servers. It would not even use 1.1.1.1 which was the only DNS I set in General Settings.

I have both the boxes you mention unchecked under Settings: General.

I am wondering if this situation is because of the differences between Wireguard and OpenVPN, and perhaps the guide author did not fully test for DNS leaks. As I understand it, DNS traffic can use both TCP and UDP protocols, which is fine for OpenVPN. But Wireguard does not use TCP, only UDP. (https://www.wireguard.com/known-limitations/) Could this be causing the router to fall back to ISP DNS when nothing else works? I'm running short on new theories. As it stands, I do not believe this guide works as intended, unless I'm still not configuring something correctly.

I hope I made some simple error, and we can get to the bottom of this.

Edit: I realize your second question referred to removing the RFC1918 alias as Destination in the LAN firewall rule.  When I do that, the static client gets no DNS at all.

#5
Hi Greelan and Fingerlessgloves,

Thank you both so much for working on this Wireguard selective routing guide, and very glad it got added to official OPNSense documentation.

I have been banging my head trying to figure out why I am leaking my ISP DNS after implementing your guide exactly as suggested twice from a bone-stock OPNSense configuration.

How can we route DNS traffic through the VPN without leaking DNS when using your guide?  I took the following steps based on a redditor's suggestions, but nothing has worked so far:

QuoteOK, reverted to bone stock OPNsense, disabled IPV6, few minor tweaks, then spun up the guide.

Tried setting unbound to use WG interface only, it didn't work. It still used ISP DNS (even ignored DNS settings from System -> Settings -> General).

Then I tried setting it to forwarding mode and specifying VPN-provided DNS in System -> Settings -> General, this didn't work. Static clients got no DNS at all.

I then theorized that the firewall alias (and thus rule) in step 8 contained networks which include the DNS servers my VPN provider has specified for use, so maybe the firewall was forcing that traffic to NOT use the WG gateway I created. So I removed those networks from the firewall. Still didn't work, but I'm tired and maybe I needed to flush DNS or something, I don't know.

This has me stumped. Surely other people are using this official Wireguard selective routing guide and not leaking DNS?

Lastly, when I traceroute from a static client, it actually routes through the Wireguard VPN DNS, and VPN tunnel. But when I fire up Firefox, dnsleaktest.com clearly shows my ISP DNS and IP, which I literally put nowhere in any setting.

Thanks for any help you can provide, I'd like to make the guide and documentation improved for the benefit of others if we can figure this out.