Update: Had another look this morning, and the error is gone. I rebooted because of something else yesterday evening, and that seems to have done it. I thought that only works for Windows. Strange.

Waited a day and it fixed itself. I had booted into another operating system via USB. Then booted up and DHCP worked as expected. I cannot explain it but am relieved it works. Graham

This helped saved me a bit of time. Thanks for following up your own post and publishing the solution. Graham

I do get the same results. Did a DNS Lookup on www.cnn.com    (<–-- never used to be here and my pfSense has been running for only 1 day now and my browser cache is clean.  

^ valid point, its possible its pfsense going directly to 8.8.8.8 vs using unbound via loopback. But doesn't make sense why pfsense would be trying to go to the dnsleak fqdn site, which would be the only way the dnsleak site would know that dns queries are leaking.

Well you could edit the advanced dhcp stuff on your wan, you could override the lease time so it shorter and will try and renew faster and expire sooner if not renewed.  Lots of features here that could help.  On the wan interface, click the dhcp advanced and then read the help linked too for what might help in faster renewal, I would think the superseding of the lease time you could set to say 2 hours vs 2 days.  All that should happen is your renew more often, and fails then you should do a new discover when expired at most 2 hours. Such issues with connections to a remote site is why out of band access is such big plus with remote sites.  Be it you have a user hotspot off their phone data connection and remote their machine to access pfsense from the lan side or put in a dedicated out of band connection is up to you vs having to actually go onsite.  A secondary connection be it used for failover/loadbalance or just out of band access is good thing to have for any site really.

Client responses can be the reason, check your DHCP logs for a failed client and one that worked and see if you can spot the differences. Been a long time since I looked but Dish Network boxes and Sonos gear were both giving my system fits. Blurry memory say one had no client name provided while the other reused the same client name on each system. Static assignments are what worked here so they may be your answer too.

If I had to guess dhcp did not restart when you added your interface, so when it tried to start again it already saw listening on 67 Did you just try stopping dhcpd and restarting.  It listens on all IPs [2.3.2-RELEASE][root@pfSense.local.lan]/root: sockstat -L | grep :67 dhcpd    dhcpd      8498  16 udp4  *:67                  : [2.3.2-RELEASE][root@pfSense.local.lan]/root: You can then verify your on your interface via [2.3.2-RELEASE][root@pfSense.local.lan]/root: ps axww | grep dhcpd 8498  -  Ss      0:29.39 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid em1 em2 em3 em2_vlan200 em2_vlan100 em2_vlan300 em2_vlan500 so you can see mine is listening on multiple vlan inerfaces.

Just to report the same issue on 2.3.2-RELEASE (amd64). I have dual wan configuration, and I've used DNS Forwarder until few days ago, when I moved my DNS to unbound. DNS Forwarder was working fine all the time. Today, I had some problems with both WAN connections, and few hours later I've realized that hosts behind the pfSense do not resolve. After restarting unbound service, everything works fine.

Navigate to System > Package Manager, Available Packages tab Install the System Patches package Navigate to System > Patches Click + Add New Patch Enter the Description: Chrome Bug Workaround Enter the URL/Commit ID: 83469e50681bf1ab0388e5cb756d5198b7f705f4 Click Save Click Fetch Click Apply

Yes because Unbound can't otherwise update the host entries to make them available for resolving. It's a common UNIX methodology for services to reload configuration files on SIGHUP and ignore changes otherwise.

I know exactly how it is.. I am on the road for work myself.  Let me know when you get back.  I am curious to what is going on that is for sure.

BTW your rule is completely pointless that you created.  Pfsense has nothing to do with traffic on the lan..

I see your point about the route – I'll try that. =)

@Grogorio: ok it's working again this morning so I tried a couple more commands on a client connected directly (actually via gateway router with IP 192.168.20.1) and via pfSense: nm-tool | grep DNS direct connection client output: DNS:  192.168.20.1 pfSense client output: DNS:  8.8.4.4 DNS:  103.244.30.142 DNS:  8.8.8.8 dig www.google.com direct connection client output: SERVER: 127.0.1.1#53(127.0.1.1) pfSense client output: SERVER: 127.0.1.1#53(127.0.1.1) pfSense shell output: dig command not found Gateway router (192.168.20.1) is getting DNS dynamically from the ISP. There is an option to set DNS but the fields on the admin form are disabled. There will be no gateway router where the box will be finally deployed (pfSense box will be the gateway router). Sooo, what does it all mean? I am no networking guru as you can probably tell. I tend to agree it was probably an ISP hiccup and it's probably now a case of continue to monitor the situation, unless somebody has further diagnostic suggestions. (I don't want to change client DNS settings as my goal is to deploy this pfSense box in a semi-public area using captive portal, so will have no control over client settings.) Dear Grogorio, I had a problem like you. My client use dns google 8.8.8.8 not resolve domain name when connect direct to pfsense. But when It used dns server of domain AD resolve domain name is ok. Can you show me step by step? Thanks for help.

That will send everything for 8.8.8.8 out that specific interface. It is probably the result of network clients being hard-set to use that for DNS. I don't think there's anything you can do besides: 1. Not use it as a monitoring IP address 2. Block DNS queries to that address from that LAN. 3. Forward DNS queries to that address to your preferred DNS.

Anyone – ??