@djtech2k what I do when I add a new device is just let it get dhcp - then set a reservation for outside the pool. I'm not sure why anyone set a static on a device other than devices that don't even support dhcp

You can change its ip without ever having to touch it, you could even change whole network ip space. You can change options again without having to touch it..

My dhcp scopes are small .100-120 for example - rest of the space I just use as reservation. And its easy enough to know what IP is next to use..

@CapitanBlack there is a Kea config file - /usr/local/etc/kea/kea-dhcp4.conf

My config is pretty basic so I haven't tried editing it and it may get overwritten but that is where I would look to test. At least until Netgate migrates/implements more of the Kea features.

@Gertjan my computer is using my pfsense DNS but not all is working well. Going to reinstall it anyway on a different device and start the config from scratch.

In case you need any additional info I am now on holiday until Jan 5th so will not see or be able to respond to any posts or requests for info until I return.

@chrcoluk said in PSA: If you are using DHCP options with Windows 11 and DHCP/networking ceased to function after upgrading to Windows 11 24H2 ...:

, I use option 43 to make sure Netbios is disabled

Ah - ok that use case seems like it would be more common on a user machine vlan..

It does in 24.11.

@datpif Actually just found watchdog starts a different service . so the simplest fix i found was to edit

/etc/inc/service-utils.inc

search for case 'kea-dhcp4':

and add

case 'kea-dhcp4': exec("rm -f /tmp/kea4-ctrl-socket.lock");

Did you manage to resolve this? I've recently encountered the same problem, and this seems to be the only thing I can find mentioning it. Keen to know if there's an easy fix before I reinvent the wheel.

@Gertjan

Thanks Gertjan,

I tried it, and it did get rid of that process. I still had the "FAIL" message come back on the same regular basis all on its own though, with varying PIDs. When I finally found an opportunity to reboot pfsense though (30 mins ago) it went away completely though :-)

So yes, probably some ghost.

Thanks again!

Alex

@Gertjan Thanks, good idea. I will try increasing the log level. Unfortunately pfblockerNG-devel did not solve the issue.

@swemattias
The error above doesn't come from HAproxy, rather from Cloudflare. So I don't think, that the hostname resolves properly to your IP.
Seems you're using the Cloudflare proxy service.

@whosmatt said in pfSense KEA DHCP problems after reassigning interface:

@mcury I'm not sure that's the same issue. I've actually added and removed members from my lagg many times without DHCP being affected. My issue arises when I assign an interface to a different NIC and then back to the original NIC, which just happens to be a tagged interface with a lagg as the parent. I'm not sure the lagg is relevant.

hmmmm 🤔
I think that the ticket issue is related to yours but I got it wrong, the problem was not adding or removing members from the LAG.
See, previously I had some VLANs, and the issue happened after I moved them to the LAG interface.
At the same time I added a member and that confused me.

So, I really think we have the same issue and I got it wrong when I reported.
This explains why Netgate team couldn't replicate it..

Edit: It happened three times, guess what ?
I have three VLANs..

@TgWaKu
I run DHCP off my Cisco layer 3 switch not pfsense. I recommend only 1 DHCP server per local network. Otherwise, you need to limit the scopes.

@lassesj said in openvpn client cannot resolve pfsense dns entries:

I have an idea on how to solve this.

Use your keyboard ?
Normally, you should not be able to use a host name like 'file-server' to reach this device, even it's on your own LAN.
The correct way is : fileserver.yournetwork.tld which is the full device location.

Like this :

C:\Users\Gauche>ping -4 dvr.bhf.tld Envoi d’une requête 'ping' sur dvr.bhf.tld [192.168.1.8] avec 32 octets de données : Réponse de 192.168.1.8 : octets=32 temps=9 ms TTL=64 Réponse de 192.168.1.8 : octets=32 temps=2 ms TTL=64 Réponse de 192.168.1.8 : octets=32 temps=3 ms TTL=64 Réponse de 192.168.1.8 : octets=32 temps=4 ms TTL=64

True, Windows spoiled us a bit by adding a local network domain to the host name.

So, start being less lazy ^^, and always use the fill host name with domain name and your done ^^

@lassesj said in openvpn client cannot resolve pfsense dns entries:

Or is there anther, better way to do this?

You mean :

2284e0f5-7703-44c1-9e0d-a927ce5da562-image.png

? 😊

@Bob-Dig said in DHCPv6 server - Deny Unknown Clients ignored?:

Ops sry, I am using Kea on 24.11.

Hmm, I didn't see the edit. That may be the important point. On ISC I have tried again and what I see is weird:

If I have it set to allow only known from this interface, and enter an incorrect DUID, no leases happen (during the time I had it running, a while).

If I have it set the same but enter the correct DUID, the lease happens but a route isn't set up. Other leases to other routers DO incorrectly happen and routes may or may not be set up (comparing the leases page to the routes page).

Now the last part might well be because it was running for an hour or so and not just a half hour but it seems like the other routers should have pulled leases at some point along the way. I have no control over those routers though.

@FollyDude-0

I also issued an

ipconfig /release

followed by a

ipconfig /renew

on my clients after the reboot, just to speed things along and make sure its working. I feel like my clients are also holding on to bogus leases from the old DHCP server, just incase this helps.

@patient0 Hi, thank you, kia should be listening on all LAN interfaces (and VIP's) it seems to run for a short time then stop, moving back ICS seems to have fixed the issue.

I don't understand why irtwould run and then stop,