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

chamilton_ccn

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!

johnpoz

@chamilton_ccn 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've been in the industry since '98 so I'm not far behind ya

I just say now 30+ because I am getting close to 40.. Uggh getting old and don't always want to admit it to myself.. But retirement is that light I can start to see at the end of the tunnel.

I got a few gray years as well where I wasn't actually in the IT dept, but was doing lots of IT work but it wasn't my official job.. But those gray years end in 92 when I officially moved over to the IT dept.. But if I think back, I redid a db for the security office while I was doing temp duty in the navy awaiting orders back in 85.. So yeah man its pushing 40.. If I recall it was on old Zenith system ;)

You have a great holiday as well..

Gertjan

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

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

Then same '43' that Unifi devices can use so they can find the controller IP ? See here.
I know, a DNS method can also be used.

If a DHCP server has this DHCP option, or any option actually, it will only add it in the lease if the DHCP client was asking for it.

Or Am I mistaken somewhere ?

johnpoz

@Gertjan yeah that is what is weird.. Hope I can find some RCA on the problem at some point because it makes no sense.

Why would having an option that shouldn't wouldn't even be handed to the client cause an issue?

Ah.. ok that makes more sense now - just did a sniff to verify - seems windows does ask for those

So if there was something different with how those are handed out be it text/string or whatever that the client expects - then yeah could cause an issue..

But if they are not there - then even when the client asks for them, they are not handed out - they couldn't be because there is no info to send.

So that makes sense then, but still think that those options really shouldn't even be available in your common network. I mean why would I use 43 to send out the location of some wifi controller on my user network where there are no AP that would need that. But 43 guess could be sending out more than that info - and AP would just use it to find controller. But 249 typically wouldn't be even set I wouldn't think - not unless you were doing something like what @chamilton_ccn is doing.

edit: I just duplicated the problem that could happen on my win10 box.. I put some gibberish in 249 and client didn't like what it was seeing.

So if client before took say when it was sent as text, but now expects it to be a string specifically - then yeah that could cause a problem.. Good troubleshooting @chamilton_ccn to track it down to that specific text/string issue with 249.. And guess that could be the same sort of case with 43

I have never looked into the details of 249, maybe its ok if that is text or string - but now the client wants it only one way with the 24h2 update..

chamilton_ccn

@johnpoz 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 just duplicated the problem that could happen on my win10 box.. I put some gibberish in 249 and client didn't like what it was seeing.

TL;DR: Pre-Windows 11 24H2, either text or string types will work; Post-Windows 11 24H2, only string works; text breaks DHCP. Invalid values (e.g., gibberish) will always cause trouble -- this has been the case as long as I can remember.

Gibberish (an incorrect value for option 249) will always break DHCP. I don't remember a time when this wasn't true .

So, instead of gibberish, try inputting this string and set the type to text:

18:AC:10:56:AC:10:56:01

That will push the following route via option 249:

172.16.86.0/24 -> 172.16.86.1

You don't have to use the route I provided above; feel free to generate any route you wish, just make sure the hex string is formatted correctly -- I use a tool for this.

On Windows 10, or anything prior to 24H2, having text as the type doesn't prevent the acquisition of an IP address via DHCP. So in order to reproduce the conditions I described in my initial post, the following must be true:

OS needs to be anything prior to Windows 11 24H2
The value for option 249 needs to be correct (see the aforementioned python-hexroute tool for an easy way to generate these strings.)
The type needs to be text

When you configure the route above via option 249, then release/renew, then run route print, you should see a route for 172.16.86.0/24 via the gateway 172.16.86.1 in the output. HOWEVER these exact conditions will prevent your computer from acquiring an IP address via DHCP on Windows 11 24H2. In that version, the type parameter needs to be string -- which, again, is technically the correct type for this option.

johnpoz

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

Gibberish (an incorrect value for option 249) will always break DHCP

That is one way to go about it sure.. But wouldn't it be better if there is some option that doesn't make sense to the client to just ignore it? Vs a hard fail and not get even an IP from dhcp, just ignore the option that might be gibberish to the client..

If string is what it should be per rfc, but it use to accept just text would of been nice for MS to put that in the release notes of the update ;)

Guess you can look at it couple different ways, might be harder to notice if just some option isn't working vs hard fail - for sure will notice and track down what is causing the failure.

If me soft fail would be better, better to have 1 thing not working vs for sure say taking down the whole network. What would you rather have client not using a specific route your handing out, or just every dhcp client on the network just dead and not even get an IP ;)

chamilton_ccn

@johnpoz

But wouldn't it be better if there is some option that doesn't make sense to the client to just ignore it? Vs a hard fail and not get even an IP from dhcp, just ignore the option that might be gibberish to the client..

I agree -- the fact that DHCP completely stops working in the event of an un-parsable value seems short-sighted.

If string is what it should be per rfc, but it use to accept just text would of been nice for MS to put that in the release notes of the update ;)

It literally would have spared me a few days of stress

If me soft fail would be better, better to have 1 thing not working vs for sure say taking down the whole network. What would you rather have client not using a specific route your handing out, or just every dhcp client on the network just dead and not even get an IP ;)

Again, 100% agreed!

chrcoluk

Thanks for sharing this info, I use option 43 to make sure Netbios is disabled, I came across how to do it a few months back randomly when working on some networking stuff, tried it, and it works great. For reference I am using String, so seems I am good for this update.

chamilton_ccn

@chrcoluk Sure thing!

johnpoz

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