BitLocker Network Unlock Fails Across Remote Subnets

Hello,

For BitLocker Network Unlock to function correctly across routed subnets, the DHCP Option 43 payload must be formatted exactly as the WDS server expects. The WDS role hosting the Network Unlock key protectors requires a vendor-specific option with the Microsoft-defined sub-option code 0x01, followed by the IP address of the WDS server in hexadecimal. If the payload is malformed, the WDS server rejects the unlock request, which is what you’re seeing in your packet captures.

The correct format is:

01 <length> <WDS server IP in hex>

For example, if your WDS server is 192.168.10.5, the IP in hex is C0 A8 0A 05. The Option 43 payload should therefore be:

01 04 C0 A8 0A 05

Here, 01 is the sub-option code for Network Unlock, 04 is the length (since an IPv4 address is 4 bytes), and the rest is the IP address. If you have multiple WDS servers, you can concatenate multiple sub-options, each beginning with 01 and its own length and IP.

On Windows DHCP, you configure this under the scope options. In the DHCP MMC, go to Scope Options, add Option 43, and enter the hex string exactly as above. On Cisco IOS or other routers acting as DHCP relay, you must ensure the Option 43 payload is passed unchanged to the client. If you’re relaying DHCP across subnets, confirm that the relay agent isn’t stripping or rewriting vendor-specific options.

Once the Option 43 payload is correctly formatted and delivered, the BitLocker Network Unlock client will be able to locate the WDS server, retrieve the key protector, and unlock automatically during PXE boot, even across routed subnets.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.