Oh then if they're simple websites, this is very doable.Have you made sure your SitesToVPn rule is above your rule that allows traffic to the internet?Also you need to make sure the Outbound NAT rule is there.
Yes, pTables does have IP resolved for FQDN I had set
OK, 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.
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.
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).
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!