Fortigate and Bitlocker Network Unlock

[Robin_Svanberg]

Hi,

have an issue with Bitlocker Network Unlock and a Fortigate.

We have configured DHCP relays to both the DHCP server and WDS where the Bitlocker Network Unlock role is installed and can see that traffic to both relays work fine.

But when the client sends the actual Bitlocker boot request the packet isn´t being forwarded by the Fortigate. We can see the broadcast but nothing happens to it :( The packet looks OK so not really sure why it isn´t forwarded.

Anyone running Bitlocker Network Unlock and Fortigates or have any idea why the packets aren´t being forwarded? 

BR Robin

[Hultis]

Hello,

I have the same problem. Have you solved it?

[Robin_Svanberg]

Hultis wrote:

Hello,

I have the same problem. Have you solved it?

We haven´t solved the root cause but did a workaround with a multicast policy which only forwards broadcasts for port 67-68 UDP to be proceed with the Bitlocker Network Unlock POC. 

config system interface edit "Clients" set broadcast-forward enable next end

config firewall multicast-policy edit 1 set srcintf "Clients" set dstintf "Servers" set srcaddr "all" set dstaddr "broadcast" set protocol 17 set start-port 67 set end-port 68 next end

[ndDallasDan]

I have the exact same issue, I've been struggling with it now for what seems like forever.  I was planning on testing your suggestion actually before I found it.  I did implement that change, however what I've found is that the traffic does indeed appear on the correct network when I sniff the interface on the fortigate (which it wasn't doing before) but when I take a packet capture on the server it isn't seeing JUST the BOOTP packet (even though it appears to being forwarded from the FGT packet capture dump on the firewall).  

Used in conjunction with the dhcp-relay on the interface what appears to happen is that DHCP packets are being rebroadcast in the correct (server) network, but the microsoft DHCP server is completely ignoring them and only responding to the fortigate ip-helper-fixed (via the dhcp-relay agent) packets--those packets are being 'fixed' by the FortiGate with a relay-ip address.

Were you successfully able to get your WDS server to 'see' the incoming bitlocker BOOTP packet with this method?  FWIW I checked the windows firewall rules and added an appropriate rule for ports 67-68 on the WDS server...no dice.

It seems like the easiest solution would be for the FGT to 'fix' these packets like it does for the other DHCP packets; I'm on 5.6.7 and I can confirm it still doesn't do so.  Did you ever get this to work, either through the broadcast forwarding or through another novel method?

[cardonaje]

Hello,

Has anyone managed to get this to work?

In our setup we have a WDS server that replies to bitlocker requests for network unlocks and we would like to use this central server in another site that's behind an ipsec vpn.

Is that possible?

[ndDallasDan]

As you can see the original poster never wrote back how they were successful--I did test a multicast broadcast policy as they suggest but it had no effect (yes the packet landed in the right network but it was unusable by the server hosting WDS without being fixed up with a relay-agent-IP by a helper).  After testing that, I abandoned multicast forwarding, and here's what I can tell you in general:

After doing a number of packet captures and then debugging the dhcp relay daemon, I finally opened a support case with FortiNET support.  

Basically after a week and multiple interactions, they said that the DHCP relay daemon will NOT fix-and-forward BOOTP type packets (which is the nature of the BitLocker packet), here is the excerpt from the support ticket--

"I have found this is a known issue for the DHCP relay. We currently have no workaround. There is a submitted request to support it in the DHCP relay. There is no ETA at this time. We only have support for the BOOTP protocol in DHCP server configuration at the moment. The related NFR request number is 0537876, should you want to follow up on progress."

   In other words, the DHCP relay daemon sees the packet, and doesn't 'do' anything to it (i.e. doesn't fix-and-forward).  It's troubling because numerous other platforms (Cisco and Juniper I confirmed) *do* handle BOOTP as fix-and-forward via helpers, just not FortiGate...so unless you are willing to setup WDS on the network local to your clients, or setup a local 3rd part DHCP relay daemon on that network and not use the FortiGate DHCP Relay Daemon, it appears we are SoL.  I had to abandon this effort; waste of at least 15 hours of setup and testing.  Hope this saves you some of that pain.

Overall it appears that Microsoft is not pushing BitLocker Network Unlock anymore...the Microsoft setup document is piss-poor and was obviously written by marketing people as it's scant on actual detail for setting up the WDS server other than just some very basic steps.  From what I've read, folks are using the powershell script to reboot machines without requiring the bitlocker PIN when required for maintenance...unfortunately that kind of sucks for WSUS/Microsoft Updates without a lot of extra work.

[cardonaje]

Thank you for the reply, we have the same experience unfortunately.

We may try an other solution, as we would really like to have that working on other sites :(

I'm looking at dhcp-helper on a linux box.