@JKnott Thanks a lot for your replies. Like an idiot, I had not noticed that the server on my lan was not running when I started to try to access the http service. In pfsense it appears to need a xxx.yyy domain rather than xxx in my DNS resolver setings so another mistake I made was to omit yyy in my later tests where I was trying to see exactly how that domain needed to be represented. In any case, with pfsense 2.4.5, I can now go to host overrides in DNS resolver, set the name of my server thus 'thiservername' and point it to a LAN address adding xxx.yyy in the parent domain entry and all is well. Additionally in /etc/hosts it shows up as 192.68.abc.def thiservername.

That put me in the right direction! Thank you gentlemen.

@toriol Yeah, it doesn't reply to ping. [image: 1697434736380-0c4419d0-db03-4d96-9633-76b4afc14044-image.png] If the resulting message contains "Updated" then you're good, no need to match more then that. I'm using freedns.afraid.org myself for other service : backup DNS servers for my host names. Never used their dynamic host name services before. I've created a host name : "just-a-test.chickenkiller.com". I thought the GUI 'afraid' password was needed, but it was the token. I found the token here : [image: 1697435692657-a39234e4-b4db-48e1-814c-9ae8a5a07979-image.png] It's mentioned in the script several times. So, no 'user' neither 'password'. From bottom to top : 2023-10-16 07:47:59.425777+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _update() ending. 2023-10-16 07:47:59.425682+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _checkStatus() ending. 2023-10-16 07:47:59.425577+02:00 php-fpm 65511 /services_dyndns_edit.php: phpDynDNS (just-a-test.chickenkiller.com): (Success) No Change In IP Address 2023-10-16 07:47:59.425125+02:00 php-fpm 65511 /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wanfreedns'just-a-test.chickenkiller.com'1.cache: 82.127.26.111 2023-10-16 07:47:59.422062+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): 82.127.26.111 extracted from Check IP Service 2023-10-16 07:47:58.521987+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _checkIP() starting. 2023-10-16 07:47:58.521864+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _checkStatus() starting. 2023-10-16 07:47:58.521814+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Data: ERROR: Address 82.127.26.111 has not changed. 2023-10-16 07:47:58.521797+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: 2023-10-16 07:47:58.521782+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: 2023-10-16 07:47:58.521767+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: X-Cache: MISS 2023-10-16 07:47:58.521740+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Expires: Mon, 26 Jul 1997 05:00:00 GMT 2023-10-16 07:47:58.521725+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Pragma: no-cache 2023-10-16 07:47:58.521710+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Cache-Control: post-check=0, pre-check=0 2023-10-16 07:47:58.521696+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Cache-Control: no-store, no-cache, must-revalidate 2023-10-16 07:47:58.521680+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Vary: Accept-Encoding 2023-10-16 07:47:58.521665+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Connection: keep-alive 2023-10-16 07:47:58.521650+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Transfer-Encoding: chunked 2023-10-16 07:47:58.521635+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Content-Type: text/plain;charset=UTF-8 2023-10-16 07:47:58.521620+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Date: Mon, 16 Oct 2023 05:47:41 GMT 2023-10-16 07:47:58.521603+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: Server: nginx 2023-10-16 07:47:58.521564+02:00 php-fpm 65511 /services_dyndns_edit.php: Response Header: HTTP/1.1 200 OK 2023-10-16 07:47:57.708502+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _update() starting. 2023-10-16 07:47:57.708472+02:00 php-fpm 65511 /services_dyndns_edit.php: DynDns (just-a-test.chickenkiller.com): Dynamic Dns: cacheIP != wan_ip. Updating. Cached IP: 0.0.0.0 WAN IP: 82.127.26.111 Initial update. 2023-10-16 07:47:57.708434+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic Dns (just-a-test.chickenkiller.com): Current WAN IP: 82.127.26.111 No Cached IP found. 2023-10-16 07:47:57.708183+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): 82.127.26.111 extracted from Check IP Service 2023-10-16 07:47:56.161143+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _checkIP() starting. 2023-10-16 07:47:56.161116+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _detectChange() starting. 2023-10-16 07:47:56.160937+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS (just-a-test.chickenkiller.com): running get_failover_interface for wan. found ix3 2023-10-16 07:47:56.160875+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): 82.127.26.111 extracted from Check IP Service 2023-10-16 07:47:54.728922+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS freedns (just-a-test.chickenkiller.com): _checkIP() starting. 2023-10-16 07:47:54.727893+02:00 php-fpm 65511 /services_dyndns_edit.php: Dynamic DNS: updatedns() starting I had of course a soft error, as my IPv4 didn't change, it was already set to the correct IP addresses. You agree, nothing changed @ freedns ?!

@Bob-Dig said in Disabling DNS Rebinding Checks does alter domain overrides: you want DNSSEC to be disabled for that, right? Not necessarily.. If where you are forwarding does actually do dnssec then no you wouldn't want to disable it.

Easy solution : I could say : @publictoiletbowl said in DHCP Lease 504 GW Time-out: 23.01-RELEASE (amd64) Upgrade, and take advantage of the corrected issues ? More serious : this issue is known, and not a pfSense error. It can happen when DNS settings are changed, and/or set wrong. The web page that you see when visiting [image: 1697188598768-612c7298-6c92-41df-853d-6443de5b2a51-image.png] uses a dns calls to retrieve DNS host names which normally wind up calling 127.0.0.1 or pfSense itself. Unbound picks up the request, and does its thing. Your issue is : this doesn't work anymore for you. So every DNS call (for every lease you have) will time out after xx seconds. Eventually, the web server, nginx, bails out as it took to long for PHP to build the page. So : tells us what your DNS settings are - and we'll guide you from there.

@johnpoz said in DHCP LEASES some mac address that are not allowed is shown in the dhcp leases: You you only allow known devices to connection - what is the point of captive portal then? It boils down to "what is my concept of networking", and then "yours", and then, after some extrapolation, you'll find a lot of so called definitions of one and the same thing out there. pfSense might even be at fault here, as it might induce this impression that every possible collection of selected options and settings can create a workable or useful solution for someone I guess we'll reach that point in the future : invent something (whatever), and some one else has already tried it. This forum has already a nice collection of them.

@aloisiobilck the problem is you cloned it and the client ID being sent to the dhcp server is the same.. If netplan would use mac vs client ID, you would of never seen the issue. Or if netplan would use duplicate IP detection, ie arp probe before using an ip offered by a dhcpd you wouldn't of seen the issue. This has been a known issue for some time if you google duplicate IP vm clone, etc. After I re-invented the wheel it seems by looking at the captures and what exactly what was going on. I started running into lots of threads about cloned vms and duplicated IP.. Solution given was either my yaml edit or the machine id change.. The dhcp server is not to blame - because the identifier sent matches an IP already given out, so sure it would send that back - hey guy I know you, here is the IP you had last time, etc. Why go to client ID vs mac - not sure why netplan using that.. Why no arp probe for duplicate detection, not sure - but detection can slow down acquisition of IP from dhcp.. Depending on your vm software and how your creating your copy/new/clone vm - there can be ways you can setup in that vm software to generate different machine id when the vm is created. I can not really think of anything could do on pfsense in preventing such a scenario.. Per the client ID sent, it was the same box - so yeah going to send the same IP.. Now maybe there is something in the dhcpd software that could check.. Hey wait this client ID is the same but the mac is different. But off the top I am not aware of any dhcpd that has such an option. Then again haven't looked too hard for such an option.. I do remember way back in the day when disk duplication was new, and cloning disks for windows.. Would need to generate a new guid in windows after you deployed the new disk.. Or all kinds of weird stuff could happen. I don't recall ever seeing duplicate IP issues from dhcp.. But that was using mac, and windows machine send out the arp probe for duplicate detection, etc. But other odd stuff with the AD, and permissions etc would come up if you didn't generate the new guid. If I recall mind you this like 30 years ago or something that when we would join the clone disks to the AD it would generate new guid. But if you cloned a machine that was already in the domain, you had all kinds of problems.. But again that was many many years ago.. So bit hazy on all the details.

@johnpoz said in Local (LAN) domain confusion: did you set unbound to register your reservation? Oh... had not done that. Now it works without host override! Thanks!

@Gertjan I could understand the "home.arpa" addition, if it would happen in every case, but it does not happen always. Unbound does not restart that often, and I do not have DHCP Registration checked. I changed the DNS Forwarding ON on the resolver, and this seems to have helped. At least so far. I will try to get more verbose unbound logs when I have a chance.

Check if interface is Enable on PFSENSE > INTERFACES > vlan_interface > Enabla interface

@netgateuser39384 It depends, for some interfaces I use the external approach. For others I use unbound because of DNSBL with pfBlocker and other local DNS stuff. But even those I finally route them with DoT via a VPN to a privacy focused DNS provider.

@theuken said in DHCP Server running, but not doing anything: interface while running Wireshark Wireshark on the client is pretty useless in such a situation - client could be sending it all day long, doesn't mean pfsense ever saw it. You need to do a packet capture on pfsense under the diag menu as @Gertjan shows in his post, feel free to run wireshark on the client at the same time to validate the client actually sent it.. But if pfsense interface where dhcpd is listening never sees a discover, then its never going to send an offer.. By the way you don't need both ports.. 67 or 68 is going to be involved in any dhcp - so you just need 1 of those ports.

I just learned. . . Squid can be forced to lock down to a specified dns dns_nameservers "PI-hole dns ip address" http://www.squid-cache.org/Doc/config/dns_nameservers/

@netboy wouldn't bookmark just be easier??? if you goal is typing it out in your address bar, just set a tag or keyword.

@ASGR71 putting a block rule to 53 just below the rule you allow 53 to pfsense IP would be a valid solution if you want to block clients on that network from talking to any normal dns on the internet. If you are having issues with clients using dns other than pfsense. While that rule would block normal dns, it doesn't prevent clients from using doh (dns over https) or dot (dns over tls).. while dot should be easy to prevent since the standard part is 853.. And clients don't normally use dot. A forwarder would use dot to forward to some other resolver via tls. Blocking clients from using their own dns to circumvent local dns has become an uphill battle.. Browsers deciding to use doh on their own without explicit opt-in by the user is a problem. Blocking doh is becoming a challenge. Since it uses standard 443 port of https traffic - which is pretty much everything on the internet these days. Blocking this has come down to using lists of known doh servers and blocking the IPs.. Which can turn into a wack-a-mole game.. But if you just want to prevent some client talking to say 8.8.8.8 or quad9 or 1.1.1.1 on 53, etc.. then yeah that 2nd rule accomplishes that.