Just in case anyone else is interested, I found pfsensible, seems to work well.

@Gertjan said in VPN Killing DNS.: @panzerscope said in VPN Killing DNS.: My question is, how do I stop my VPN instance from killing my DNS ? Not Pu**VPN but the other one : read this. A story about how VPN totally destroys DNS ... That was a really good read, thanks for pointing that out. I am now testing a new config as mentioned in that thread as per the below screenshot. [image: 1712485359882-2d216e8d-2f4e-42a5-843a-f6c1b7ff00ad-image.png] Fingers crossed that will work. DNS has been ok now for 24 hours. Will report back if it passes a week. Thanks all.

@jdlucena I would try 2.7.2 first…

@bmeeks I will try and replace the cable monitor it. Thank you for the reply.

@Jeremy11one said in DNS stopped working due to route from OpenVPN client: I noticed that, when my OpenVPN Client connects, it automatically creates an unwanted route that redirects my pfSense's primary DNS server (1.1.1.1) to the OpenVPN interface's IP address (10.10.110.185). I assume this is intended to prevent DNS leaks. But it somehow prevents any of my LAN hosts (or pfSense itself) from pinging 1.1.1.1 or resolving anything. I never had this problem until a few weeks ago, around the time I updated to pfSense 2.5.2. When it occurs now, I have to remove the route via "route delete 1.1.1.1," then go to DNS Resolver, then click Save and Apply Settings. Problems: Disabling the OpenVPN Client does not automatically remove the DNS route it automatically added. Seems like it should. If a gateway is specified for each DNS server in System > General, pfSense creates routes for them. OpenVPN Client overwrites the route for the first DNS server to apparently force it through the VPN, but when OpenVPN Client is disabled, it does not revert that route back to the correct gateway IP. The route is left pointing to an obsolete IP address. Rebooting pfSense while the OpenVPN Client is disabled removes the route, but DNS Resolver still does not work until I click "Save" then "Apply Settings." I don't know what "Save" and "Apply Settings" fixes behind the scenes, but it probably shouldn't work like that. Checking the boxes on the OpenVPN Client page for "Don't pull routes" and "Don't add/remove routes" does not seem to have any effect. Upon connecting to the VPN server, the pfSense VPN Client still automatically creates the routes for the DNS server and the VPN subnet. How can I prevent my pfSense OpenVPN Client from breaking my DNS Resolver? I understand this is an older topic, but I have been experiencing the same issue. I am now testing a revised OpenVPN client config with the following options enabled to see if it will stop the behaviour. [image: 1712081202015-c2ece863-59aa-4f5c-b7ff-caa1568feee3-image.png] Will report back whether it helps or not. if anyone else has any other suggestion, they are definitely welcome!

@McMurphy said in Resolver works but not nslookup on PC: Not my choice. I inherited it. Well change it.. .local is mdns.. Trying to use it as your normal domain in actual dns can be problematic. The domain of choice currently is home.arpa, .internal is soon to be approved from my understanding... So you could use like mydomain.internal, or just home.arpa or mydomain.home.arpa

Argh! I wasted a lot of time on this one before finding the solution. The problem is similar to yours... I'm using the latest version of pfsense... I have a pfsense on site #1 whose domain is home.arpa. I have another pfsense on site #2 whose domain is s2.home.arpa. IOf course, I want pfsense from site #2 to send DNS queries for home.arpa to the pfsense on site #1. No matter the request sent, I got an "NXDOMAIN" with nobody.invalid in the AUTHORITY section. I discovered that this is normal behavior for "unbound" (the DNS resolver). The solution is to indicate that the "home.arpa" domain should be set to nodefault... as indicated in the /usr/local/etc/unbound/unbound.conf file. However, I discovered that modifying this file won't help because pfsense does not use it. I was finally able to succeed by performing the following procedure, in DNS Resolver/General Settings... 1- Display the customs options and add the following 2 lines (do a copy/paste to make sure it's OK)... server: local-zone: "home.arpa." nodefault 2- In the "Domain Overrides" section, specify the pfsense IP address of site #1 as the DNS server for the "home.arpa" domain 3- Restart the DNS resolver (or reboot pfsense)) In my case, omitting step #2 (Domain Overrides) prevents the solution from working even if, in the pfsense on site #2, the pfsense IP address in site #1 is indicated in "General settings" and "DNS query forwarding" is activated. You can see the result in /var/unbound/unbound.conf Hope it helps !

@McMurphy maybe its being redirected upstream? There are currently multiple threads about on how nord is intercepting dns traffic.. If you want to know if your override is working.. Sniff your traffic.. A domain override can be used on just a resolver as well. Also keep in mind using the diagnostic lookup window isn't a good choice for this sort of test, because depending on how you have it setup, pfsense would fallback to or could just ask what is in its dns settings. Here.. I setup domain override for openvpn.com You can see when I ask unbound for it from a client on my network - it tries to ask 1.2.3.4 via sniff on the wan interface. [image: 1711803179164-settings1.jpg] You can see from your response there - it asked loopback, got no answer, but then asked 8.8.8.8 directly.. This is pfsense asking, not what unbound did via its settings.. You would prob need to set this to do not use external.. [image: 1711803033316-ignore.jpg]

@McMurphy said in Force DNS over OVPN: Question: How can ensure all LAN devices only use the private DNS? Whatever this is, put it in the DNS-field of the DHCP-Server on that LAN. Don't use pfSense Resolver for that LAN.

@johnpoz OK, looks like I have it fixed. I reread your post above and added domain specific override to the resolver and it now works. What is interesting to note is that if I removed the Resolver's disable rebind custom command it still works.

@McMurphy I found this, probably not what you are looking for. But if you are using CloudConnexa as your VPN provider, then I thing you need to change your NAT rule. Try to remove the destination address. https://openvpn.net/cloud-docs/tutorials/configuration-tutorials/connectors/routers/tutorial--configure-a-pfsense-router-to-connect-to-cloudconnexa.html

@rjcab does the dig +trace work now?

As soon as you post you work it out - turns out you need the record to exist first, before pfSense can then update it. Shouldn't need to be that way but it's working now.

@Unscathed7897 if you have been using example.com a long time internally.. From a users point of view, might be better to get a new domain example.net for external use - for your vpn connections or any other stuff you might host externally or need to resolve public for.. This might be less of a learning curve for users, and for sure less to change on your network if you have been using example.com for any length of time ;)

@johnpoz Thanks for your help that worked!

@Gertjan @johnpoz Here is my working config using the Forwarder. Please let me know if a better outcome can be achieved using the Resolver. [image: 1711488210240-27.03.2024_07.32.00_rec.png] [image: 1711488218336-27.03.2024_08.21.59_rec.png] Unless a better outcome can be suggested my original setup is optimal.

@Antibiotic Looks like Domain Overrides option in DNS resolver did this trick))))

Hello, anyone?