Description
This article describes the process of performing zero touch provisioning (ZTP) by using DHCP options to direct a FortiGate towards FortiManager management. This allows administrators to deploy low/no-configuration FortiGates to the field and have them automatically connect to FortiManager and retrieve a full configuration (in addition to ongoing management control).
Scope
FortiGate, FortiManager, DHCP.
Solution
Zero Touch Provisioning (ZTP) is a method for deploying low- or no-configuration FortiGates to remote environments and having them automatically connect to a management platform (e.g., FortiGate Cloud or FortiManager) to receive further configuration and ongoing management. There are several methods available for ZTP/LTP of FortiGates, which can be found in the following link, though this article will focus specifically on the FortiManager/DHCP-based method: Zero-touch and low-touch provisioning
This feature can only be used when the FortiGate boots up after a factory reset, as it is meant to be used with zero additional configuration (i.e., an 'out-of-the-box' experience). This method works well for FortiGates that cannot access the Internet (those in closed environments that cannot access FortiCloud/FortiDeploy servers).
This method relies on a local DHCP server with Options 240 and 241 configured. These are IANA Reserved options, and in this case Fortinet utilises these options to inform the FortiGate as to where the FortiManager is located:
- DHCP Option 240 advertises an IP address used to reach FortiManager. This is configured using the DHCP IP format.
- DHCP Option 241 advertises an FQDN that can be used to reach FortiManager. This is configured using the DHCP string format, When transmitted on the wire, the string will be converted into a series of hexadecimal characters.
- For example, 'fortimanager.example.com' would translate to '666F7274696D616E616765722E6578616D706C652E636F6D' when viewed in a packet capture.
- Some DHCP servers may only serve Options 240 and 241 to clients that actively request them via DHCP Option 55 (Parameter Request List), whereas others (such as the FortiGate DHCP server) may serve the option to all clients.
- Both options may be used together, but it is generally suggested to use one option or the other since the FortiGate will add an entry under config system central-management for each option received.
Factory-fresh FortiGates are configured to generally configured to use DHCP for the first interface (e.g., wan1), and they will automatically request the above DHCP options. Once the FortiGate has received Options 240 and/or 241, it will make an outbound connection to the FortiManager to establish a management tunnel. On the FortiManager, the administrator can authorize this FortiGate and deploy a full configuration to the FortiGate via this management tunnel.
To prevent spoofing, the FortiGate will no longer accept a different FortiManager IP/FQDN received from DHCP after the initial ZTP setup.
Configuring the DHCP Server to serve Option 240/241
The following is an example configuration for adding DHCP Option 240 and 241 to a FortiGate acting as a DHCP server:
config system dhcp server
edit 1
set dns-service default
set default-gateway 172.16.200.254
set netmask 255.255.255.0
set interface 'internal'
config ip-range
edit 1
set start-ip 172.16.200.201
set end-ip 172.16.200.209
next
end
set timezone-option default
config options
edit 1
set code 240
set type ip
set ip '172.18.60.115' <--- Example IP for FortiManager
next
edit 2
set code 241
set type string
set value 'fortimanager.example.com' <--- This FQDN is automatically converted to hexadecimal in DHCP packets.
next
end
next
end
For Windows DHCP servers, DHCP Options 240 and 241 are not configured by default. Administrators must add these as new Predefined Options to the Windows DHCP server, then they may be assigned as Scope Options within the DHCP scope. This can generally be done in the DHCP MMC by right-clicking IPv4 (or IPv6) and selecting Set Predefined Options..., then adding two new options to the list:
Like the FortiGate, Option 240 on Windows DHCP Server accepts an IP address format ('172.18.60.115') and Option 240 accepts a standard string of characters ('fortimanager.example.com').
Verifying the results
On the FortiGate, the command diagnose fdsm fmg-auto-discovery-status will show the status of the FortiGate and what has been obtained via DHCP for ZTP. The following output was taken immediately after the FortiGate has booted following a factory-reset ( config-touched=0 indicates that there have been no configuration changes from default yet):
FortiGate # diagnose fdsm fmg-auto-discovery-status
dhcp: fmg-ip=0.0.0.0, fmg-domain-name='', config-touched=0
After a DHCP lease has been obtained, the same command will show any received FortiManager IP/FQDNs (config-touched=1 and the source being /bin/dhcpd). Additionally the FortiGate configuration under config system central-management now reflects the FortiManager IP and FQDN (only if both DHCP options are received, otherwise only one entry is shown):
FortiGate # diagnose fdsm fmg-auto-discovery-status
dhcp: fmg-ip=172.18.60.115, fmg-domain-name='fortimanager.example.com', config-touched=1(/bin/dhcpcd)
FortiGate # show system central-management
config system central-management
set type fortimanager
set fmg '172.18.60.115' 'fortimanager.example.com'
end
Once config-touched changes from 0 to 1, the FortiGate will no longer accept new FortiManager IPs/FQDNs via the DHCP Options (until a factory-reset is performed using execute factoryreset). The following output is expected when re-running diagnose fdsm fmg-auto-discovery-status, even when another DHCP server has offered Option 240/241 with a different IP/FQDN:
FortiGate # diagnose fdsm fmg-auto-discovery-status
dhcp: fmg-ip=0.0.0.0, fmg-domain-name='', config-touched=1(/bin/dhcpcd) <--- no IP/domain accepted since config-touched=1
FortiGate # show system central-management
config system central-management
set type fortimanager
set fmg '172.18.60.115' 'fortimanager.example.com' <--- FortiManager address remains unchanged, preventing attackers from unexpectedly overriding the configuration towards a different destination
end
Related Article:
Technical Tip: ZTP basic configuration and troubleshooting for a standalone FortiGate
