Selective Routing to VPN - DNS not working

[vMAC]

I'm hoping someone can help me. I set it up my pfsense box so that I can have selective routing (i.e. only certain devices use the VPN, others go out my ISP) https://forum.netgate.com/topic/120879/selective-routing-via-vpn-interface . The problem that I am having is that I'm having issues with my VPN and my provider and they have asked me to do a DNS leak test. This has shown that DNS is leaking.

I'm wondering if any one here can help me to configure my server so that all clients NOT connected to my VPN alias go out using pfBlockerNG. While all clients on the VPN alias and thus connected to the VPN use my providers VPN.

[Bob.Dig]

@vmac There are only two things you can do. Send every DNS request out through the VPN tunnel for everyone. Or better don't use pfSense as the DNS server for those (VPN-)Clients at all, use 8.8.8.8 for example and make sure, it goes through the tunnel like everything else which is external.

[vMAC]

@bob-dig thank you for responding. How do I set it up so that the DNS for the VPN is set to the ips my VPN gave me and route out through the tunnel? Do I change that on the OPENVPN client in pfsense or somewhere in the DNS resolver?

[viragomann]

@vmac
The easiest way to do this is forwarding DNS request from the certain clients to a public or even the providers DNS server.

I'm assuming you have created an alias for these clients and policy route their upstream traffic to the DNS server.
So add a NAT port forwarding rule like this:
interface: LAN or which the clients are connected to
protocol: TCP/UDP
source: the client alias
source port: any
destination: any
destination port: DNS(53)
redirect target: the providers DNS server or any other in the internet

So this NAT rule forwards any DNS requests to the redirect target. Since you have policy routed upstream traffic from these clients, the requests are routed to the VPN server and there are no more DNS leaks.

[vMAC]

@viragomann I am attempting to implement your rule and I received an error. Can you see what I might be missing?

FYI the NORDVPN interface is the interface that I use for my VPN devices. You stated LAN may be the interface but I don't want all my LAN devices using the NordVPN server, only the ones connected to NordVPN via the VPN_devices alias.

[vMAC]

I played around with it until I got it to take the new rule. Still no dice. I'm getting cloudflare and google on my dnsleak tests:

[viragomann]

@vmac
The source port must be any.

NORDVPN is the internal interface, where the devices are connected to?

Which error do you get?

Please show the policy routing and the outbound NAT rule.

[vMAC]

@viragomann Here is the error that I get when I try to put in this rule without setting NAT Reflection to Disable:

Here is my Outbound NAT:

Here is Policy Routing:

[vMAC]

sorry picture was too big.

Here is Policy:

[viragomann]

@vmac
A policy routing rule has a gateway stated.
And action "reject" also seems not be proper for a policy routing rule.

[NightlyShark]

@vmac Don't forget the system resolvers (System->General Setup->DNS)

[viragomann]

@nightlyshark said in Selective Routing to VPN - DNS not working:

@vmac Don't forget the system resolvers (System->General Setup->DNS)

This has nothing to do with the actual case here.
This setting is for pfSense itself only by default.

[NightlyShark]

@viragomann Because DNS queries come from the same IPv4 as the client queries due to NAT, if the FW itself is configured during install to query, say CloudFlare instead of itself, a DNS leak test will be positive. I mentioned it because it happened to me (NordVPN). Most VPNs specifically require you to forward all DNS to their DNS.

[viragomann]

@nightlyshark
We are trying here to redirect all DNS requests from devices which use the VPN to an outside DNS server (over the VPN). If this succeed, which is quite straight forward, the systems DNS settings do not have any impact on the concerned clients.

[NightlyShark]

@viragomann I thought so, too. Turns out, gremlins live everywhere. I too have split-horizon DNS, with VPN-only and no-VPN subnets. But, the key problem proved to be Unbound and what servers it forwarded to, or that in recursive mode, it could either query through VPN or WAN for all interfaces. That broke Netflix, Government sites, Banking...

Consider this, you block all QUICK (chrome and android), redirect all simple DNS per interface. Still cannot block DoH and DoT without an access list for destination IPs and even if you do, it just breaks everything for the DoH-T clients. Those clients end up querying either nobody at all and just refuse to connect (android), or the servers you specified in DHCP and Radvd which can be:

• either external ones (catch them with port forward)
• internal ones

In the last case, Unbound becomes a problem. You can't split-horizon it. I tried using DNS-Forwarder for the VPN interfaces (forward to VPN DNS) and Unbound for no-VPN clients. Damn thing still leaked. If I changed the system DNS the leaks stopped, but Netflix, Government, Banks broke. I ended up using BIND.

My point is, as an answer to the problem that was stated in the first post, the leaks only stop if you force PfSense to query the VPN DNS. I don't know why, it shouldn't, but it does.

[viragomann]

@nightlyshark
Again, all these have not even any impact if you redirect DNS requests, as I suggested.

You have group of devices, which you policy route to the VPN server.
AND you redirect any DNS requests from this group to a public DNS server. Due to the policy routing rule DNS requests are forced to the DNS server as well.
You can forward unencrypted DNS requests to where ever you want. If a client tries to request you local unbound on pfSense on say 10.0.0.1 and pfSense redirects it to 8.8.8.8 over the VPN, 8.8.8.8 is responding to the request (while it sees the VPN providers public IP), the respond come back from the VPN and pfSense traslates the source IP of 8.8.8.8 back into 10.0.0.1. So the client doesn't take any notice that the request was answered by another server.
And DNS leaks are resolved.

So when you redirect DNS requests, they never go to the local unbound.

DoH is forced to a public DNS server over the VPN anyway due to policy routeing.

DoT, if a public server is requested, can be forced over the VPN as well to prevent DNS leaks. But it cannot be redirected to any other server, even not to the local unbound, since you don't have a matching SSL certificate.

[NightlyShark]

@viragomann I didn't doubt you can forward DNS manually, I just said it is problematic. And that in my case with the dns leak, the solution to it was to change the system DNS, as per the instructions of the VPN provider. To remedy the leak and just the leak.

[viragomann]

@nightlyshark said in Selective Routing to VPN - DNS not working:

I didn't doubt you can forward DNS manually, I just said it is problematic.

Never seen an issue with that and cannot think of any.

And that in my case with the dns leak, the solution to it was to change the system DNS, as per the instructions of the VPN provider.

This would impact all local devices. But the TO wants only certain "VPN" devices to use the providers DNS to provide leaks and all others use the system settings.

[vMAC]

@viragomann Is this what you are speaking about?
LAN rules:

IOT rules:

Here is the full rule:

[viragomann]

@vmac
Yes. Now this tells me that "NORDVPN" is the interface, which you have assigned to the VPN client instance. Hence this is the wrong interface to do the port forwarding.

According to your shown rules, there are some devices in the LAN and some in IOT, which you forward to the VPN provider.
Now you have to create the suggested NAT port forwarding rules exactly on these two interface.
I.e., you need two port forwarding rules for DNS, one on LAN and another one on IOT.