@johnpoz

Hope you didn't take my post the wrong way

Oh not at all!

I see nothing wrong with your post bringing attention to a possible issue people could run into.

Yeah, there's nothing more frustrating than seeing a comment on a discussion thread involving a problem you're experiencing that simply says "Disregard, I fixed it" or "resolved", but no further details 🙄 so I generally try to share the details about problems I've run into, especially when I see others experiencing the same thing. It makes the Internet a better place!

For example the option 43 is odd to me since I wouldn't think that option would ever be on a dhcp scope that users machines are on, that sort of option would exist on your infrastructure network, why would windows machine ever even be on it.. Other than maybe some admin laptop or something now and then. Sure that would and could exist on some smb network maybe, but then again that dhcp server really shouldn't hand it out unless the dhcp client actually ask for it. So its just weird that could actually cause an issue with whatever they did with windows..

So the reason #43 made it into this discussion is due to the top comment on page #2 of the Microsoft answers thread I posted earlier. I'm mostly in agreement that #43 has no business on a client access network. I say mostly because only Siths deal in absolutes. 🤣

As to an always on vpn - I worked for a very large msp for many years with many customers and never ran across such a setup. My previous gig was a fortune 100 company and we were not setup like that. You could enable or disable the vpn on your laptop. And while my current gig isn't a huge company - we again are not setup like that, you enable your vpn when you want. We do have multiple DCs and locations across the globe that you can connect to via vpn. But systems are not set to auto login to the vpn, and sure doesn't limit you to which one you connect too, etc.

Yeah, I mean... it's definitely not common, but it's perfect for our environment.

I could see such a setup having its own set of problems, maybe advantages but having a hard time of thinking of any off the top of my head ;) Other than a setup where your users don't have to think at all - it should just work and the laptop should have access to company resources all the time. But sure it could lead to odd routing at times. If the user was on a company site would seem odd that their machine should connect to the company vpn unless they were say on a locations guest wifi network or something.

The main issue we've seen is inefficient routing, which is solved by telling our endpoints "When you're at an office, use the office's gateway as your route to the various datacenters instead of your AAVPN" ... because again, when all traffic destined for one of our datacenters traverses the AAVPN, that's not efficient when you've got a perfectly good (and shorter) path to the datacenter if your traffic goes through the VTI insead. Unfortunately I can't post a diagram because I don't have a sufficiently sanitized one; if I have some time I'll post one because I think using option 249 to resolve this is actually an underrated, elegant solution to the problem.

Not saying they are not correct sort of setups that shouldn't work, etc. Just seem like one offs to me

Yeah, I mean... The option exists for the very reason we're using it 😸 . And isn't that part of the beauty of what we do? That most of the time, someone found themselves in the exact same situation and created a solution that was good enough to become part of the protocol/spec/RFC/whatever, in turn, ensuring future humans in the same situation already have a path forward? And conversely, if you find yourself in a situation that nobody else has ever encountered, then either your approach to the problem you're trying to solve is incorrect or you've been presented with the opportunity to be that person who creates a solution that becomes a standard. We all stand on the shoulders of giants.

with some 30+ years in the business is all..

I've been in the industry since '98 so I'm not far behind ya. 😉

So yeah it is curious what MS might have done - but I could see maybe these 2 scenarios got overlooked somehow??

Well, text is the wrong type for this particular DHCP option, so I'm inclined to believe that whatever change they made fixed or tightened up something in their OS that worked but wasn't technically correct (which, as we all know, is the best kind of correct).

I have not been in that space for many moons, but next time talking to one our server/client guys that are responsible for the deployment of OS to the users devices and they run the dhcp servers etc.. I will ask them if they have seen any of this. Or if they are even thinking of pushing 24h2 any time soon ;)

It might be worth the conversation. ¯\_(ツ)_/¯

The other thing that is curious is to me, other than some smaller smb is why would this sort of problem with 24h2 not be caught in testing before the update is pushed to user machines, etc.

Ya know, that's not an uncommon question -- in fact, you can always find some population of users asking it once a month, right after every Patch Tuesday. I've admin'd Windows for a long time and I can't recall a time when routine updates were so reliably broken. In this case however, I'm not pointing the finger because obviously the problem was on my end, but I can point to several incredibly frustrating situations that have occurred over the last few years that weren't.

I will for sure have to look into it a bit, just because I am a curious sort of guy ;) Thanks for posting the info.

Of course, enjoy your evening, and happy holidays to you and yours!

@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.

@DavidIr Hi @marcosm any joy looking at the dump files?

I have implemented the changes in https://forum.netgate.com/post/1199521 for now in the hope this will restart the DHCP service when it fails, but would love to understand what's going on and help solve the potentially wider issue.

Thank you

@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..

I see this is still ongoing. I found a workaround via watchdog service. The script does a cleanup before attempting to restart the sevice

list itemmake sure you install the watchdog service in pfsense.

list Add the kea dhcp 4 service.

Shell into pfsense and change to /usr/local/etc/rc.d

list Create a backup of kea service script. cp kea kea.old

list edit the kea file and replace contents with script below

#!/bin/sh # PROVIDE: kea # REQUIRE: NETWORK netif routing # KEYWORD: shutdown . /etc/rc.subr name=kea desc="Kea DHCP Server" rcvar=kea_enable load_rc_config $name kea_enable=${kea_enable:-"NO"} command="/usr/local/sbin/keactrl" required_files="/usr/local/etc/${name}/keactrl.conf" # Add cleanup function cleanup_kea() { # Clean up stale lock files rm -f /tmp/kea4-ctrl-socket.lock # Kill any zombie processes pkill -9 kea-dhcp4 # Wait for processes to die sleep 2 } # Modify start command to include cleanup start_cmd() { cleanup_kea ${command} start logger -t kea-watchdog "Kea DHCP4 started with cleanup" } # Modify stop command to include cleanup stop_cmd() { ${command} stop cleanup_kea logger -t kea-watchdog "Kea DHCP4 stopped with cleanup" } status_cmd="$command status" reload_cmd="$command reload" extra_commands="reload" run_rc_command "$1"

Watchdog should auto restart the service

I see this is still ongoing. I found a workaround via watchdog service. The script does a cleanup before attempting to restart the sevice

list itemmake sure you install the watchdog service in pfsense.

list Add the kea dhcp 4 service.

Shell into pfsense and change to /usr/local/etc/rc.d

list Create a backup of kea service script. cp kea kea.old

list edit the kea file and replace contents with script below

#!/bin/sh # PROVIDE: kea # REQUIRE: NETWORK netif routing # KEYWORD: shutdown . /etc/rc.subr name=kea desc="Kea DHCP Server" rcvar=kea_enable load_rc_config $name kea_enable=${kea_enable:-"NO"} command="/usr/local/sbin/keactrl" required_files="/usr/local/etc/${name}/keactrl.conf" # Add cleanup function cleanup_kea() { # Clean up stale lock files rm -f /tmp/kea4-ctrl-socket.lock # Kill any zombie processes pkill -9 kea-dhcp4 # Wait for processes to die sleep 2 } # Modify start command to include cleanup start_cmd() { cleanup_kea ${command} start logger -t kea-watchdog "Kea DHCP4 started with cleanup" } # Modify stop command to include cleanup stop_cmd() { ${command} stop cleanup_kea logger -t kea-watchdog "Kea DHCP4 stopped with cleanup" } status_cmd="$command status" reload_cmd="$command reload" extra_commands="reload" run_rc_command "$1"

Watchdog should auto restart the service

@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,

@guardian said in [SOLVED] Setting up Cloudflare Dynamic DNS without using Global API Key:

Zone Resources fill in the domain name to be used (mydomain.co

Thank you! I just needed to set this up and all the other tutorials say you need a global key!

Okay, I figured it out. When I stopped Kea via the web GUI, there was still a Kea process listening on UDP 67:

sockstat -l | grep :67

So I killed the rouge Kea:

kill -9 XXXX

Then restarted Kea via the web GUI. Now the binding errors are gone, and my reservations are being honored.

Super weird issue, no idea how I ended up with two running instances of Kea.

@SkyBladeMP said in KEA DHCP Settings Tab missing:

Never thought that the CE would lag so far behind.

Netgate Releases pfSense Plus Software Version 23.09.1 and pfSense CE Software Version 2.7.2

For the new, unknown bugs, having the real sensation that your firewall is bleeding edge technology and some new gadgets, get Plus.
It's maybe better, but that's just a point of view.
The real issue is : 2.7.2 is to 'good' so there is less rush to get out a new version 😊

@DavcoreTech
Do better.
Remove these :
0fdd6781-839f-43d6-86db-e0e98803376a-image.png

or, at least, renegotiate a better contract with Google, as facebook pays more for your private DNS request as Google.
Me, IMHO, I give none of it to nobody. Why would I ?