MAC Address Passthrough Issues with DHCP

Posted by CrestronwithTechron@reddit | sysadmin | View on Reddit | 23 comments

Hi, we are experiencing issues with the MAC address pass-through option set on "Integrated NIC 1 MAC Address". In our infrastructure, we have a DHCP server which releases an IP address to every MAC address declared in the specific IPv4 reservation. Due to security constraints, we cannot put the docking station MAC address into the DHCP server. So, our Senior SysAdmin decided that enabling the pass-through option to use only the MAC address of the integrated Intel NIC. Here is the behavior we are experiencing. 1. I switch on the laptop connected to the docking station, (for the record it is a WD19DCS) and the laptop gets a valid IP address, as expected. 2. I unplug the docking and move to an office; the I plug the network cable into the laptop. The laptop gets a valid IP address, as expected. 3. After, I come back into my office, and I connect again the laptop to my docking station. The laptop is not able to get a valid IP address in any way (I get an APIPA address, 169.254.x.x) When checking the log of the DHCP server, I have seen that it releases the IP but for some reasons the laptop did not get it. The only way to solve is to reboot the machine. This is very frustrating for our end users, as you can imagine. Anyone got any ideas or suggestions? Is this something that can be remedied on Windows itself?

Reply to Post

23 Comments

[-]

OddInstruction20@reddit

curious, would restarting the windows dhcp client service help?

[-]

mac_due@reddit

Hey, I have the same problem in our company. Is there any news from Microsoft yet?

[-]

kheldorn@reddit

Just wanted to let you know ... MS actually got back to me and they are in fact working on fixing the issue. I have instructions (that I can't share at this point) on how to test their fix once I'm back in the office on monday. Can only be a matter of (hopefully not so much) time until we actually get this fixed.

[-]

CrestronwithTechron@reddit (OP)

Yeah. Hope they get it fixed soon.

[-]

kheldorn@reddit

Ok ... I've spent the last 1.5 days installing my test notebook over and over again ... only to find out that apparently Windows 11 doesn't seem to support MAC Address PassThrough at all!? What OS are you seeing the issue on? Windows 10 or Windows 11? Here Windows 11 shows individual MAC addresses for the onboard and the USB-C network adapters, even with MAC Address PassThrough being enabled in the BIOS - on the same device that just an hour earlier showed the issue under Windows 10.

[-]

CrestronwithTechron@reddit (OP)

It’s on Windows 10. For Dells it has the Realtek adapter use the integrated NIC’s MAC address and both adapters show up under Network Adapters.

[-]

kheldorn@reddit

Any chance you can test a Windows 11 device and check if you can get MAC Address PassThrough to even work? All I'm getting is two distinct network adapters with individual MAC addresses as if MAC Address PassThrough had been disabled in the BIOS. Which it isn't...

[-]

CrestronwithTechron@reddit (OP)

Any updates from Microsoft on this issue? Will it make it into a Cumulative Update eventually?

[-]

kheldorn@reddit

Ah, sorry, yeah ... Good and not so good news. Good news: Microsoft acknowledged the issue and has been working on a fix. The fix is availble in the Windows 11 Canary version and can be enabled by a secret registry switch. They will include the fix without the need for the registry switch in a future Windows 11 cumulative update - but I've got no information on when that will be. The bad news: They won't backport the fix to Windows 10. Why? Well, "because". Apparently the Windows 10 product group thinks that a GUI change would be required to address the issue and give users an option to switch between the "legacy behaviour" and the new/fixed one. They didn't really have an answer for me when I asked why this decision only affects Win10 and not Win11 .. or why we'd need a "Bug on/off" toggle to switch between things being broken and how any sane person would expect the system to work. So, yeah ... You either upgrade to Win11 and wait a little while, or you'll have to live with the issue on Win10.

[-]

kheldorn@reddit

And if you are truly desperate to get this "fixed" under Win10 ... you could set up a scheduled task, triggered on the easily identifiable DHCP Client eventlog entries the issue produces and then simply use Powershell to restart the network adapter, which will release the stuck IP from the adapter and make things work again. I'm just not 100% sure what the chance of getting the system into a endless loop of restarting the network adapter is.

[-]

CrestronwithTechron@reddit (OP)

Unfortunately I cannot. We’re locked to using Windows 10.

[-]

SevaraB@reddit

Why the hell are you using a MAC allow list for “security” instead of 802.1x? If it’s a cost thing, PacketFence doesn’t cost anything other than time to set up…

[-]

CrestronwithTechron@reddit (OP)

Good question. The US Government.

[-]

SevaraB@reddit

SMH. It’s beyond easy to spoof a MAC address, especially when compared to a host key for EAP-TLS.

[-]

rian5678@reddit

HOW DARE YOU! I think you'll find it's illegal to modify a MAC address. Why on earth this was an actual thing that people thought, and even taught in training is really beyond me.

[-]

SevaraB@reddit

I'm really hoping this is sarcasm, but I'm not sure. So for anybody else who's not sure, major brand-name network OEMs don't make it easy to spoof a MAC, but a bunch of stuff that can be bought for <$50 on Amazon will happily let you run a WiFi repeater and hide behind a self-programmed MAC.

[-]

rian5678@reddit

Changing MAC is against the laws of allah

[-]

CrestronwithTechron@reddit (OP)

Yeah I don’t disagree. Gotta use what we’re given though. :/

[-]

kheldorn@reddit

Well well well, looks like I'm finally not alone anymore ... I assume your docking station and the network cable you plug directly into your laptop are on the same subnet? Because that is what I'm experiencing. See https://www.reddit.com/r/sysadmin/comments/14g60q3/weird_network_problem_with_lenovo_notebooks_and/ for some more details. Basically, the issue is this: Windows remembers the subnet on the internal network adapter, and when you connect any USB-C network adapter (either a dock or one of those short-cabled ones), Windows will not release the IP address from the internal adapter if the USB-C device receives the exact same IP address the internal network adapter had before. If you connect the USB-C adapter to any other subnet - it will work. If you connect the internal adapter to any other subnet and then the USB-C adapter to the original subnet - it will work. Because Windows will now remember the 2nd subnet for the internal adapter. I actually got a call open with Microsoft about this issue. But they refuse to fix it because ... well ... to quote them: "because MAC address pass-through was not part of the original DHCP specifications from 1993/1997". Your Windows client will actually log an entry in the DHCP client eventlog about this, as noted in the post linked above. And currently the only way to fix this issue is to forceably restart the internal network adapter to release the IP address from it. A simple "ipconfig /release" will not work, because there's no network cable attached to the internal adapter. Either that or disable the MAC address pass-through feature (or set it to secondary MAC). You mentioned your dock was a WD19DCS. What brand is your notebook? Our fleet is almost exclusively Lenovo, both for the notebooks and the docks. tl;dr: This is a Windows issue and Microsoft refuses to fix it, making excuses using a 30 years old RFC (while not actually understanding it, because in fact Windows is violating parts of it with this not working as anyone would expect.)

[-]

CrestronwithTechron@reddit (OP)

Is there anything more you can share?

[-]

kheldorn@reddit

I think I can share details from my call with Microsoft, as there's nothing really in it that should be secret. > [...] the "MAC address pass-through" feature of selected Lenovo USB based docking solutions can cause the Windows DHCP client to fail when switching LAN port to USB replicator adapter. This issue is reported on Windows 10 1809, 1903, 1909, 2004, 20H2, 21H1, 21H2, and 22H2. > > If the "MAC address pass-through" BIOS setting is enabled, and the user switches the LAN cable connection from [the built-in RJ45 to USB-C-Dock], the notebook gets an APIPA address, and the user is unable to work. The resulting APIPA address leaves the user in a non-working condition. > > The Microsoft-Windows-DhcpClient/Operational event log shows events ID 50068 and ID 50034. The error code 0x1392 maps to ERROR_OBJECT_ALREADY_EXISTS, which means that the object already exists. The final part of their response is the real kicker though: > Based on the original DHCP Design Spec, when you have a built-in NIC and a USB NIC, you have two separate NICs. Period. The "MAC address pass-through" is something that was thought up many years after the original DHCP spec. Therefore, the solution would be to turn it off. I had explained to them that turning it off is not an option for us, because we use the MAC address of the device for provisioning through SCCM and also for IP-reservations in DHCP. Having the notebooks show up with different IPs depending on what docking station the user is using would make stuff a lot harder ... Also, IF I understand rfc2131 from 1997 (and rfc1541 from 1993) correctly, then Windows is actually violating these rfcs ... Here's basically what I wrote them: > Section 3.1 “Client-server interaction - allocating a network address” in paragraph 5 says: > > > 5. The client receives the DHCPACK message with configuration parameters. The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. > > According to the error messages in the Windows Eventlog it is clear that Windows did detect that the address is already in use. Then why is Windows not sending a DHCPDECLINE message to the server to restart the configuration process? This seems like a violation to RFC 2131. > > > Section 3.2 “Client-server interaction - reusing a previously allocated network address” in paragraph 3 says: 3. […] If the client detects that the IP address in the DHCPACK message is already in use, the client MUST send a DHCPDECLINE message to the server and restarts the configuration process by requesting a new network address. > > Again, Windows appears to violate RFC 2131 by not sending a DHCPDECLINE message to the server despite detecting that the IP address is already in use. > > Sending a DHCPDECLINE would mark the address as “already in use” on the DHCP server and would restart the DHCPREQUEST process and should ultimately assign the device a new IP address. Obviously, a proper implementation of rfc2131 that would result in a DHCPDECLINE message and the assignment of a second IP address for the same MAC address would not be ideal ... End of story is that I now submitted a business impact report to them and they'll be adding it to their queue of things to fix. According to them it can take from months to year, if ever, to fix the issue...

[-]

CrestronwithTechron@reddit (OP)

Well it seems to affect more than just one client, maybe we’re just the more vocal ones. It’s been an issue for years so hopefully it gets fixed soon, my hope is that it’s fixed in 10 so we’re not forced to upgrade to 11.

[-]

CrestronwithTechron@reddit (OP)

Yep they’re all on the same subnet. Glad to see it’s not just a Dell issue. We’re almost exclusively Dell here.