@pfsense57352 I agree the wording could have been different. It is labeled as a feature preview in the release notes:
https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#kea-dhcp-server-feature-preview-now-available

@SteveITS -- thanks! I upgraded to 2.7.2 and disabled DNSSEC and everything is looking good so far. Much appreciated!! 😀

@Zosh-0 If you have DNS Resolver set to forward, uncheck DNSSEC. It can cause false failures if forwarding.

reference: https://docs.quad9.net/Setup_Guides/Open-Source_Routers/pfSense_%28Encrypted%29/#instructions

@viragomann
Thanks for that!
Been struggling with the Nord setup for days now - hadn’t used this system in a year
and after nords forced change of password and username - the vlan VPN stopped working - openvpn was connected but probably having a dns issue

Finally got it working - except for the correct dns server - like everyone else - I found the Nord support- not very supportive.

All I required is that the Nord VLAN to use the Nord DNS as set in the general settings (but any changes I made to fix it just stopped it working )
I just get Comcast dns responding Nord is ignored.
So nowhere near a solution
Thanks for the link

@morrisonken-a said in Netgate 6100 LAN switch config:

How then might I configure so that clients on either of the 4 LAN are visible to each other? Can a VLAN span all four ports?

The only way of doing that is to configure a bridge, which I don't recommend.

I would just connect a switch to one of the SG-6100 ports and set the vlans there.
SG-6100 would route between VLANs, such as a router on a stick topology.
You can set a LAGG group between the switch and the SG-6100 also.

@Antibiotic
No, I just use pfBlockerNG on pfSense with a view lists.

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.

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.

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.

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..

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?