Finally got it! snort was blocking the check-IP service. Added the corresponding suppressions and all works fine again!

Ran fresh pcaps tonight, and after 2 minutes of pcap data there was no DHCP traffic going on onthe WAN interface. The 2 packets above are definitely from when I manually release/renew in the UI (got them in a separate capture tonight).

So basically pfSense doesn't seem to be respecting the DHCP renewal time, because the capture yesterday said renew time 14h, but I'm still here with an expired lease.

Today's DHCP renew said Lease 2 days, Renew 1 day, Rebinding 1 day 18 hours. But when I look in /var/db/dhclient.leases.mvneta2 it looks like the renew is more than 1 day out:

[2.4.5-RELEASE][admin@pfSense.localdomain]/root: date Sat Mar 20 17:09:34 PDT 2021 [2.4.5-RELEASE][admin@pfSense.localdomain]/root: less /var/db/dhclient.leases.mvneta2 lease { <snip> } lease { interface "mvneta2"; <snip> option dhcp-lease-time 172800; option dhcp-message-type 5; option dhcp-server-identifier 7.127.2.90; option dhcp-renewal-time 86400; option dhcp-rebinding-time 151200; renew 0 2021/3/21 23:53:46; rebind 1 2021/3/22 17:53:46; expire 1 2021/3/22 23:53:46; }

Is this intentional? Am I misunderstanding how DHCP renews are supposed to work? Or is pfSense just ignoring the values sent by the server and making up its own?

@nguser6947

Lease time is set by the server and the client renews around 1/2 or 2/3 through the lease time. Can you use Packet Capture or Wireshark to see what lease time the server is providing? If longer that 5 - 6 seconds, then there's a problem with the client. If the other device is not also renewing at 3 seconds, then the problem is likely with the client that is.

@gertjan Thanks... I've followed your instructions.. 12 hrs into the change, and there has not been issues with DNS. I will go to the location in sometime to check the unbound logs.

Thanks again for your help.

@cool_corona

Try this the next time :
Console access - or SSH.
Use option 15.
Pick the saved config that was known to be good.
Restore.
Reboot.
Done.

The last xx config backup can be found here : /cf/conf/backup/

Now we're getting somewhere :

@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:

Mar 18 12:39:52 dhcpleases 17571 Sending HUP signal to dns daemon(24774)

and

Mar 18 12:39:52 unbound 24774 [24774:0] notice: Restart of unbound 1.13.1.

Very handy, that time mark at the start, isn't it ?!

You actually posted yourself the answer to why this happens :

DNS Resolver sudden stop

Now, I guess I do not need to tell who 'dns daemon' is - right ? ;)
'dns daemon' can be unbound or dnsmasq, the forwarder. The dhcpleases processes doesn't mind, as it just send a HUP to the PID found in the 'dns daemon' PID file.

@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:

and I need to access them remotely by FQDN

Like using a NAT rule and such ? Using IPv4 ?
That means your are doing a lot of PAT (Port NAT). Which means : static IPs for all these devices on your LAN.

or adopt IPv6 .... and you still need to assign 'fixed' IP info to all these devices .... as accessing by host name from the outside implies porting local DNS info over to a public (your own, probably) DNS name server.
You don't want your name server zone info getting changed every xx seconds, that would be bad ... very bad.

@ramikilany said in DNS Resolver sudden stop and filterdns PID 48934:

200 IPs .... 400 device (I have mobiles and phones Network and IoT and more than 200 PC for a system)

Only static DHCP lease are needed for devices that need to be made accessed from elsewhere.
DHCP, as such, still works fine.
Do you need to connect TO a phone ? (is that possible ?)
Normally, stuff like file servers, printers, NAS's have (always) static DHCP leases.
Or plain static IP settings on their side - and entries - host overrides - on the DNS - unbound - side.
And then , yes, if you have 400 devices, you have to make 400 entries.

Btw : Un checking DNS registration actualy stops this process :

dhcpleases 17571 Sending HUP signal to dns daemon(24774)

which is probably killing your DNS.

@deadsoul said in After upgrade to 2.5.0 unbound crashing randomly:

@chrcoluk I tried what you suggested and it's being stable for the last 10 hours...
do you think it's a bug?

Thanks

No worries.

@gertjan Yeah, it's not working that way though. I've added an override but still getting the IP for the LAN segment. Even tried enabling the DHCP server with MAC address for the WAN interface and ticking the box for "Resolve DHCP first" but no luck. If there's not something obvious I missed I'll have to dig into the custom options for dnsmasq

UPDATE: You were right about the hostname config in General Setup. I looked at /etc/hosts and noticed the pfSense short name was in there, which is what I queried from a LAN host. I thought the domain and search settings on the host (/etc/resolv.conf) were supposed to tack on the domain portion when a short name was queried but I dunno now.. I changed the hostname as well as domain name in General Setup and added an override for the full hostname of the pfSense box and it's returning the override now. Thanks.

@whitetiger-it
Thank you, this resolve my issue.

@kom Thank you for you're replay.

@brian-1

Unfortunately I think this still ends up doing a 1:1 NAT in the box. It's limited to about 4K NAT table entries, which is inadequate if you have a lot of devices.

The problem is with 2.5 the RG bypass methods that people like me have used don't seem to work, so we will hang on 2.4.5 until things get sorted out.

@ccnewb Yep I'm also in the same boat
I"ve uninstalled PFblocker and made sure register in DNS when DHCP lease is not checked same deal