Bitlocker Network Unlock in SDA Environment

[barryjm]

Hello all,

My organization was testing Bitlocker Network Unlock in our SDA environment and was running into issues. I was curious if anyone else has setup network unlock in their SDA environment. I'm pretty sure the reason we are having issues is because the BOOTP request from the client is not getting tagged with option 82. I can see the BOOTP reply from the WDS server to the client but it never reaches the client which is making me think it is arriving on the border node and not going any further since option 82 is not being inserted in the BOOTP packet and it is using the SVI IP of the edge node which also exists on the border node. The DHCP packets are getting option 82 just not the BOOTP packets. If anyone has managed to get network unlock to work, were there any configurations you had to do other than setting the IP helper addresses and setting the port in low-impact mode with a pre-auth ACL?

[Andrii Oliinyk]

Hej
i've just got the hint that The core of the problem is that BitLocker Network Unlock's third packet is a BOOTP request that lacks DHCP Option 53 resulting in edge node doesnt insert option 82 into it. but it would be damn cruel if it's true.

[barryjm]

Yeah that's what I'm thinking too but wasn't 100% sure so I was curious if anyone else has gotten it to work in their environment. We did also open a case with TAC as well and are giving them the pcaps we have taken so we hopefully get a confirmation if that is the issue or not.

[Andrii Oliinyk]

please keep tread updated & good luck in resolving the issue

[Kris Pellens]

Can you provide the SR number of the TAC case you have opened?

[barryjm]

Unfortunately I cannot since the case contains information that our customer has determined to be sensitive. I will keep this thread updated with any results or determinations that we get back from Cisco or Microsoft though.

[Cristian Matei]

Hi,

    @barryjm Can you try enabling, at port level, in the path between client and BOOTP server, ip dhcp snooping trust ? See if it works?

Thanks,

Cristian.

[Andrii Oliinyk]

this is enabled by default on EN's user-facing VLANs. Having it somewhere on the routed way beyond Site's BN, honestly, makes few sense from my pov.

[Cristian Matei]

Hi,

  @Andrii Oliinyk Why so? I meant, if not clear, on the layer 2 path, up until the DHCP Relay.

Thanks,

Cristian.

[Andrii Oliinyk]

bc since DHCP DISCOVER reached out to EN's AnycastGW with L2-switching & where "ip dhcp snooping" is natively configured to insert information option where else apart of EN configuration can u see "ip dhcp snooping vlan USER-VLAN" applicable?

[Cristian Matei]

Hi,

  @Andrii Oliinyk The problem is with the BOOTP process, right, not with DHCP. Enabling the layer 2 path as DHCP snooping trusted, maybe there's not gonna be an intent to insert OPTION 82 which is not supported for BOOTP (this is the problem we're trying to solve per my understanding).

Thanks,

Cristian.

[Andrii Oliinyk]

problem is exactly in EN doesnt insert opt 82 in the BOOTP request packet during dhcp snooping while it does it for regular DHCP packet. this is what BU & developers must resolve, not community.

[Cristian Matei]

Hi,

 @Andrii Oliinyk Yes, I've misunderstood where the problem lies.

Thanks,

Cristian.

[barryjm]

Yeah from the packet captures we can see that the normal DHCP traffic 0.0.0.0 -> 255.255.255.255 hits the SVI of the edge node which has the helper address so the switch now sends the packet to the helper address with the source IP as the SVI IP and also where the switch will input option 82 into the packet. The DHCP process continues and assigns the client the IP address x.x.x.x. After the client has an IP it sends out the BOOTP request which is x.x.x.x -> 255.255.255.255 also with udp port 67. The broadcast hits the SVI of the edge node again and forwards it with the helper address once again which gets rid of the client IP of x.x.x.x and replaces it with the SVI IP address but does not insert option 82 this time so when the return traffic comes back to the fabric at the border node it hits the IP of the LISP interface on the border node and since there is no option 82 in the original BOOTP request, the packet does not get routed further. We suspect it does not insert option 82 into the BOOTP request since it does not contain option 53 like the DHCP request does, since the client already has been assigned an IP address by this point, although that has not been confirmed to be the case yet. Cisco is currently reviewing the information we have sent them and our customer has also opened a ticket with Microsoft.

[Cristian Matei]

Hi,

 @barryjm If you figure it with TAC, would be great to present if there's a WA that can be done on Cisco side.

  Meanwhile, not sure if the following could work / override the built-in SDA requirements, however I would give it a try. Either globally disable the verification of Option 82 being inserted in BOOTP Reply via command no ip dhcp relay information check (this would affect all SVI's), either do it at the SVI level via command ip dhcp relay information check-reply none.

Thanks,

Cristian.