| Description |
This article describes how to configure and troubleshoot issues with zero touch provisioning of a standalone FortiGate. |
| Scope | FortiManager. |
| Solution |
Configure the Name, Serial Number, and device model settings (these have been configured in the above example). A provisioning template and other settings can be provided where necessary.
A pre-shared key option can also be used instead of the FortiGate Serial Number. In the following example, the Serial Number has been added:
Once the FortiGate device model has been added, the FortiGate appears under the list of managed devices with a grey icon.
ADOM Configuration will be automatically pushed, so make sure the FortiGate is not in production yet as will get impacted by the ADOM configuration.
Ensure the FortiGate admin password is updated under the device database.
'Right-click' on the FortiGate model recently added, select Edit, enter the admin password and select OK.
Then, select the FortiGate model and select Administrator -> Admin, select the Local User type, enter the admin password (twice) and select 'OK'. 
Each of these methods has its specifics (not explained in this article), but the end result is the same. A FortiManager IP/FQDN and Serial Number must be added to the FortiGate configuration.
Note: The FortiManager Serial Number must be configured in the FortiGate to authenticate the incoming FortiGate's FortiManager management request in all of the ZTP scenarios.
In the example below, a batch mode script is used on FortiGate to configure the central management settings and the serial number, because the serial number cannot be set in normal CLI mode.
exe batch start config system central-management set type fortimanager set fmg x.x.x.x <----- IP address or FQDN of the FortiManager. set serial "FMG-Serial-Number" <----- If the Serial Number is not set, the FortiGate will be unable to authenticate the FortiManager request. end
exe batch end
Ensure the FortiGate can connect to the FortiManager address on port TCP/541.
On FortiGate, run the following CLI commands:
Exe ping < FortiManager Management ip >
Exe telnet < FortiManager Management ip > 541
Before running the Batch script or another deployment method is used, run the CLI commands shown below.
On FortiManager:
diag debug service sys 255 diag debug application depmanager 255 diag debug enable diag fwmanager fwm-log diag debug application fgfmsd 255
On FortiGate:
diagnose debug cli 8 diag debug application fgfmd 255 diag debug enable
Example of debug traces when the auto-link and config push to device operation fails:
checkin_sched: check in configuration __checkin_handler: new rev=1 ==INST CONF==>install done state, finish! ==INST CONF==>install and save finished status=FAILED Release token oid=160, pid=867.0x26d81b6c. Response: { "id": 1, "result": [{ "status": { "code": 0, "message": "OK"}, "url": "acquire\/dvm\/token"}]} __sched_inst_save_queue,565: cur_inst=1, max_inst=480. destroy_service.59:mark sconn 0x268bb3c0 done. destroy_service.59:mark sconn 0x268bb3c0 done. Destroy sconn 0x268bb3c0, connSize=0.
Under system settings -> Task Monitor, the two operations have a 'failed' status. To view more details about the error(s), select the task - in this case, 'Push config to device'.
Under Device Manager, the configuration shows a 'Conflict' status:
In most cases, the details from the errors when the provisioning task is finished will provide sufficient information to solve the problem:
Start installing FortiGate-VM64-KVM $ config system interface FortiGate-VM64-KVM (interface) $ delete "port10" Physical interfaces cannot be deleted. command_cli_delete:6711 delete table entry port10 unset oper error ret=-3 Command fail. Return code -3 FortiGate-VM64-KVM (interface) $ delete "port9" Physical interfaces cannot be deleted. command_cli_delete:6711 delete table entry port9 unset oper error ret=-3 Command fail. Return code -3 …………. Port 8, 7………………………..
FortiGate-VM64-KVM (interface) $ end FortiGate-VM64-KVM $ config system global FortiGate-VM64-KVM (global) $ set hostname "FGVM01TMxxxxxx" FortiGate-VM64-KVM (global) $ set alias "FortiGate-VM64" FortiGate-VM64-KVM (global) $ end FGVM01TM22-----9 $ config system admin FGVM01TM22-----9 (admin) $ edit "admin" FGVM01TM22-----9 (admin) $ unset password incomplete command in the end Command fail. Return code -160
Issues may occur during the deployment of the FortiGate configuration.
Most failures are caused by a password difference with the device model and/or because the device model does not contain the same number of ports as the real FortiGate.
By default, FortiManager tries to flush the delta configuration and warns it is not possible to install this configuration on the FortiGate. The configuration status of the newly added FortiGate then displays as 'Conflict' (as shown in the previous image, which demonstrated illustration issues with the admin password and the number of interfaces).
To get rid of the interface issue (manually creating a physical interface is not possible via the device database GUI), it is necessary to create and apply a script on the device database.
The following is a script example that can be used to work around this issue:
Below, each of the missing interfaces has been correctly created by the script:
After success, the batch script can be run again on the FortiGate side to trigger the auto-link and push configuration to device tasks.
This includes, for example, FortiGate’s Serial Number and IP address information, which are retrieved and validated by FortiManager.
Below is an example of auto-link output debug:
Request: { "client": "dmserver:867", "id": 111, "method": "exec", "params": [{ "data": { "device": 160, "force": 0}, "url": "start\/tunnel"}], "root": "fgfm"} Start probe_dev.start_tunnel ... Response: { "id": 111, "result": [{ "data": { "assigned_ip": "169.254.0.2", "branch_pt": 1157, "build": 1157, "managed_serial": "FMG-VMTMxxxxxxx", "platform_str": "FortiGate-VM64-KVM", "serialno": "FGVM01TMxxxxxxx", "version": 700}, "status": { "code": 0, "message": "ok"}, "url": "start\/tunnel"}]}
Go to FortiManager and notice two tasks have been created.
If a provisioning template was used when creating the device model and after the configuration is pushed to FortiGate, access FortiGate and verify that the configuration set in the provisioning template is correctly deployed and displayed in FortiGate GUI/CLI.
A 'Success' state of the auto-link and configuration push tasks means the ZTP operation is successful.
Finally, go to Device Manager and confirm if the configuration status is 'Synchronized'.
In the case of a deployment failure, send the install log to support:
To view it, select View Install Log and Install Log.
Related articles: Technical Tip: ZTP basic configuration and troubleshooting for a HA FortiGate cluster Auto-link setting is exposed to control configuration installation during ZTP 7.4.1 Zero-touch and low-touch provisioning Perform installation to apply Jinja template configurations to branches |
