Going nuts with DNS over OpenVPN
-
@dma_pf said in Going nuts with DNS over OpenVPN:
Are your routing your DNS requests out through your VPN provider in the DNS Resolver settings ( Services/DNS Resolver/General Settings) like this?
It's set to ALL.
-
@gelcom When you do an "extended" dns leak test in this site what are the results? https://www.dnsleaktest.com
-
Do you control the server end of these tunnels?
If not they are almost certainly pushing a default route to connecting clients and it you don't reject it the pfSense default route will be changed.Never use 'any' as the source in Outbound NAT rules if you can possibly avoid it (and you can). It can catch unexpected traffic, like traffic from the firewall itself.
You shouldn't have outbound NAT rules on the internal interfaces.
Consider using a different DNS serer locally. By using 1.1.1.1 everywhere you are creating routing conflicts and making it far more difficult to diagnose the issues.
You want clients on those interfaces to use only 1.1.1.1 for DNS and to route those queries over VPN.Disabling gateway monitoring action will not prevent traffic leaking to WAN if VPN goes down and the gateway disappears entirely.
In Sys > Adv > Misc set 'Skip rules when gateway is down'.
That way if the gateway goes down there will be no pass rules and traffic will simply be blocked.Steve
-
@dma_pf said in Going nuts with DNS over OpenVPN:
When you do an "extended" dns leak test in this site what are the results? https://www.dnsleaktest.com
Kindly note "São Paulo, Brazil" is local pf and not remote VPN.
-
Can we see a screenshot of the firewall rules on
Interface_VMs_through_A. Assuming that is where you're testing from.Steve
-
@stephenw10 said in Going nuts with DNS over OpenVPN:
Do you control the server end of these tunnels?
If not they are almost certainly pushing a default route to connecting clients and it you don't reject it the pfSense default route will be changed.Yes, I do. OpenVPN server is a VM on my Oracle Cloud.
Pls note my openvpn server.conf:
port 1194 proto udp dev tun user nobody group nogroup persist-key persist-tun keepalive 10 120 topology subnet server XX.XXX.XXX.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "dhcp-option DNS 1.1.1.1" dh none ecdh-curve prime256v1 tls-crypt tls-crypt.key crl-verify crl.pem ca ca.crt cert server.crt key server.key auth SHA256 cipher AES-128-GCM ncp-ciphers AES-128-GCM tls-server tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 client-config-dir /etc/openvpn/ccd status /var/log/openvpn/status.log verb 3Never use 'any' as the source in Outbound NAT rules if you can possibly avoid it (and you can). It can catch unexpected traffic, like traffic from the firewall itself.
You shouldn't have outbound NAT rules on the internal interfaces.Ok! Corrected source to Interface_VMs_through_A subnet
Consider using a different DNS serer locally. By using 1.1.1.1 everywhere you are creating routing conflicts and making it far more difficult to diagnose the issues.
You want clients on those interfaces to use only 1.1.1.1 for DNS and to route those queries over VPN.Indeed. I changed local pfsense DNS servers to google (8.8.8.8 and 8.8.4.4) and I kept openVPN to Cloudfare (1.1.1.1).
With all these corrections problems persists:
When I run https://www.dnsleaktest.com on local machine it points correctly to google DNS and local location (São Paulo).
When I run the test on "Interface_VMs_through_A" machine it shows the same WAN address (incorrect) with Cloudfare DNS (correct).
Still leaking.
Can we see a screenshot of the firewall rules on Interface_VMs_through_A. Assuming that is where you're testing from.
Sure. Here we go
Please note I keep seeing logs in this interface pointing to 1.1.1.1 with a rule name I don't have: NEGATE_ROUTE: Negate policy routing for destination (10000001) .
Maybe this "hidden" rule is leaking my DNS?
kind regards
-
@gelcom said in Going nuts with DNS over OpenVPN:
NEGATE_ROUTE: Negate policy routing for destination (10000001) .
Ah, it's because you have or had set 1.1.1.1 as a DNS server for pfSense with a gateway and that adds a static route to it creating the conflict triggering the negate rules. If you reboot removing that route it will probably go away but to be sure (or to not reboot) go to Sys > Adv > Firewall&NAT and set 'Disable Negate rules'.
Steve
-
Actually, ironically, it's probably because you're pushing 1.1.1.1 as a DNS server from the OpenVPN server which means it is included in the VPN networks alias.
Disabling negate networks should prevent it anyway.Steve
-
@stephenw10 said in Going nuts with DNS over OpenVPN:
Ah, it's because you have or had set 1.1.1.1 as a DNS server for pfSense with a gateway and that adds a static route to it creating the conflict triggering the negate rules. If you reboot removing that route it will probably go away but to be sure (or to not reboot) go to Sys > Adv > Firewall&NAT and set 'Disable Negate rules'.
Rebooting pf did not the trick but checking Disable Negate rules did.
Now leakdns shows remote openvpn ip and remote location. GREAT!!!
Is this an expected behavior on pf?
With this option turned on should I expect any other changes on pfSense?
Isn't possible to remove that "hidden" static route instead of enabling this option?
kind regards
-
Check the routing table to see where 1.1.1.1 is added.
But it's probably because your servers are configured to pass is to the clients and your clients are NOT configured to reject routes.But in a setup like yours you should disable negate networks anyway since you are relying on policy routing for isolation.
Steve
-
@stephenw10 said in Going nuts with DNS over OpenVPN:
Check the routing table to see where 1.1.1.1 is added.
No entries for 1.1.1.1 ....
-
Might be used in an IPSec tunnel if you have any defined. It pretty much has to be a subnet used somewhere in a VPN config to hit that rule.
Steve
-
I don’t know. I don’t have any other vpns setup.
Anyway…
Thanks for the support.
@stephenw10: I owe you a beer!!! :-)
Problem is solved.
Kind regards
