@johnpoz Yep -- definitely not a complaint. I enjoy learning it all. In all the examples I've seen, .local was used after the hostname. The use of mDNS was never mentioned so I assumed .local was part of the base DNS configuration. I started reading up on mDNS a few weeks ago -- I guess I haven't made it that far yet.

@Gertjan Its traffic analyzer

@ericnix once you enable forwarding in the Resolver settings, see https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html

Switching back to the deprecated ISC solved my problem. Thank you @johnpoz

@johnpoz Wow, you are awesome !!! Huge thanks! Worked!

No matter what I do I cannot get DNS to resolve over this new interface, which is strange because I have others with as far as I can see, exactly the same setup. Traffic is definitely going through the interface/Gateway, but DNS refuses to I have tried backup/restoring, and unbound forwarding mode + forwarder instead - All with the same result Any help appreciated

@SteveITS Disabling DNSSEC seemed to solve it, thank you

For troubleshooting I have pulled the IP address the host had previous out of the address pool range and rebooted it. It came back with a different address from the address pool range, instead of picking the one from the static lease that matches its MAC address. So strange!

For anyone that has the same question. A workaround I've found is the Arpwatch package. It has a Timestamp data that has the last seen time not only for DHPC clients, but also for hosts with static IPs which is amazing! It does the job perfectly but has the following cons: there is no convenient way to remove specific entries from the Arpwatch database; in order to find the last seen time of specific host from the DHCP lease table, I have to manually crosscheck the info from both services; sorting the database of Arpwatch is done by the letters of the days of the week, not by the date itself which is quite unusual and a bit silly. Regards!

@NickJH DNSSEC should be disabled if forwarding. See blue note here: https://quad9dns.github.io/documentation/Setup_Guides/Open-Source_Routers/pfSense_%28Encrypted%29/

Never mind and thanks for looking. I went through all the settings in the tl-wa901n and the "gateway" wasn't set to anyting. I set it to the address of the router and can connect by wifi now. What I don't understand about that is that I thought the gateway info was supplied to the clients by the DHCP server.

@SteveITS Thank you very much! Done.

@ahking19 There are 7 VLANS that I'd like to be use pihole, but I don't want to expose the pihole directly on every VLAN. Using the netgate as the the DHCP and DNS would just be easier. I don't care about the reporting of pihole.

@SteveITS said in Domain Override not working from workstations: after the upgrade I found I had to restart the DNS Resolver service Turns out, the first restart didn't completely fix it as random lookups for the AD domain were failing during the day. I enabled forwarding (and turned off DNSSEC accordingly) which restarted unbound, and after that it's been fine since yesterday afternoon. We usually forward to Quad9 but for some reason it wasn't enabled on this router. I suspect something started IPv6 DNS lookups going to pfSense but I'm not sure why it wasn't a problem in the prior few years, since that would be expected.

After switching from NordVPN to AirVPN the issue is gone. I had to disable monitoring the VPN interfaces because AirVPN seems not to like that. But besides that everything works now flawlessly. After talking to NordVPN they said that they are aware of that and working on that issue. But I don’t want to wait for them to work on that issue.

I resolved the issue by formatting it the following way: server: private-domain: "plex.direct" access-control-view: 192.168.30.16/32 blockYT access-control-view: 192.168.40.0/24 blockRBLX view: name:"blockYT" local-zone: "youtube.com" static view: name:"blockRBLX" local-zone: "rbxcdn.com" static local-zone: "roblox.com" static local-zone: "minecraftskins.com" static include: /var/unbound/pfb_dnsbl.*conf This configuration above was accepted without error. Reference: https://mitky.com/pfblockerng-pfsense-filter-specific-clients-computers-network/

@forumate There is a punch of nice tools to investigate network issues. Your Ubuntu machine might have dig on board, a tool to resolve host names. So you can run e.g. dig @1.1.1.1 google.com This tries to resolve 'google.com' using the DNS server 1.1.1.1, which is Cloudflare. Ensure that you have allowed any on pfSense on the LAN interface, where the VM is connected to. Here you can find a list of DNS Root Servers, which are used by the Resolver. You can also try one of these, however, they only resolve the TLD. But you get an idea if you can reach them. You can also run this command in pfSense. If your ISP really blocks DNS requests to any other servers, you will have no other option than use the ISP's DNS. You can also switch the Resolver into the forwarding mode to use the DNS servers given by DHCP or which you stated on the General settings page.