Looking through the DHCP log I found the following error: /var/db/dhcpd.leases line 0: whitespace too long, buffer overflow. That file didn't exist, and through this link, I found that it was actually /var/dhcpd/var/db/dhcpd.leases instead. That file was a bit over 3MB, so I deleted it and restarted the service. Leases came pouring in from throughout the network. I'm not sure why all this started when trying to change my subnet, but next time I try I'll make sure I have more time to fix any issues that come up.

Instead of using overrides, an alternative is to add to the 'custom options' of dnsmasq (Forwarder). From the dnsmasq config example: # Add domains which you want to force to an IP address here. # The example below send any host in doubleclick.net to a local # webserver. #address=/doubleclick.net/127.0.0.1 Works well when there are disparate domain names that may not be part of your domain, and a blanket override is not suitable.

A reboot fixed both the pinging issue and the dns resolver issue. Not sure why.  I rebooted last night before I started the thread and it was not working after that reboot. By the time I rebooted I had disabled nearly all my packages and any questionable firewall rules testing after each one with no luck.  Rebooted with my fingers crossed and I was able to ping the loopback. I slowly re-enabled the fire wall rules testing between each one and rebooted after they were all re-enabled and things are still working as expected. I re-enabled the packages I was using one by one with a reboot and test between each one and things are still working as expected. Not really sure what the problem was?  Maybe just a config stuck in limbo?  I really am not sure.  The only other configuration I recall tinkering with while trying to debug this was rearranging some of the outbound NAT mappings. I wish I had an explanation for myself for what was messing this up.  I spent a few hours on troubleshooting and am regretful that a simple two minute reboot was the solution.  I guess my take away from this is to perform multiple reboots while troubleshooting. I am hoping the case is closed on this.  I will keep testing tonight and tomorrow to make sure I am still able to ping and resolve.

XMLRPC yes. Unbound sync - no. Should be easy to get coded if you need it, using some of the packages as example. E.g.: https://github.com/pfsense/FreeBSD-ports/blob/devel/www/pfSense-pkg-squid/files/usr/local/pkg/squid_sync.xml https://github.com/pfsense/FreeBSD-ports/blob/devel/www/pfSense-pkg-squid/files/usr/local/pkg/squid.inc#L2168

" I can continue to run DHCP from my pfsense box but maintain AD DNS entries based on DHCP leases." You Don't, or you let the client register with the dns SOA.. Why do you think you need to run dhcp on pfsense? When you have dhcp on your AD.. Makes zero sense to me.. "the rest of the devices on the network don't need any form of domain knowledge whatsoever. " Then WTF you pointing them at your AD dns for??  Only members of your AD need to point there.. Dude.. Why do you not just point your VMs to your AD, put them on their own segment so they can use their own dhcp.  Now you just create forwarders for the domains so that they can resolve each other. So you have host.pfsense.tld point to pfsense and get dhcp from pfsense, and you have host.ad-domain.tld get their dns and dhcp from AD..

" IP range 10.0.xx.x  to 10.0.xx.xxx" For gosh sake dude really.. Its rfc1918 space why are you wasting your time and ours when we need info to help you by trying to obfuscate this.. Its like I can not tell you I live on the planet earth because you might find where I live ;) ""Windows can't communicate with device/resource (Primary DNS)" " So is it your handing out dns via dhcp that is no longer working?  This seems more likely then dhcp not working.  What do you see in the dhcp server log?  Did you sniff on pfsense interface that dhcp server is listening on - do you see discover packets, and the dhcp server just ignores them?  Dhcp server is actually running?  Did you try restarting it - again what is in the logs?? If windows can talk talk to a dhcp server, it would give itself a APIPA address, ie something that starts with 169.254.x.x, so what does ipconfig /all show you on these windows machines that stop working?

That part I did do right …  ;) Thanks again for the help!!!

I will test waiting before click apply. But I think save just write to the pfsense config.xml file and Apply recreate dhcpd conf file and restart the daemon. I will test it later and try to understand how pfsense reconstruct the dhcp conf file and restart the service in the source files.

So that was the issue.  Because the vlan1 was assigned as an interface it had a dhcp server that was running a conflicting set of pools for the 192.168.0.x address range which there was already a DHCP server running for LAN_EM1_DBM (which is another interface). HUGE HUGE HUGE Props to Johnpoz for taking the time and working thru this with me. Thank you to doktornotor for trying to help me, even though we never really did reach a level of communication. I've said it before, and I'll say it again.  pfSense is a great product!  Just works and works well. Thanks for all the help everyone!

Thanks @johnpoz - so that means that the DHCP server uses the Global "Enable DNS Resolver" or "Enable DNS Forwarder" rather than the individual Interface selection within those services.  Thus, the only way to pass the System DNS servers to clients when running DNS Resolver (or Forwarder) is to manually specify them in the DHCP Server options for the interface that you don't want to use DNS Resolver (or Forwarder) on.

@dcol: There are three IP's used for good reasons due to three SMTP servers that are running on the same computer. They pass emails between them for different functionality. One handles attachments, one spam, and one IMAP/SMTP outbound. Yeah. That's what you normally do on localhost (127.0.0.1, [[::1]]). I.e., do AV filtering on a localhost: <someport>and spam filtering on localhost:<anotherport>. Why should you be opening those to the entire LAN (or even WAN) goes beyond me. There's no reason why anyone should be abusing those from inside LAN or from WAN. They are for mailserver use, nothing else. @dcol: All are encrypted and use https via the same URL Funny, I thought mailservers were using SMTP/IMAP/POP. Not HTTPS. Even if you were running webmail on the normal mailserver, you do not need any HTTP(S) for the rest. Huh.</anotherport></someport>

jimp, since bulk import was asked for quite often recently wouldn't that be a nice feature? Bulk import of a .csv file. Do you write the request?  ;)

Well that would all depend on the settings in the unbound.. That is not pfsense..  Contact unbound if you want specific features of their logging..