Technical Tip: The impact of 'set configuration-sync local' on the Security Fabric

[skrymi]

Description	This article describes the impacts on the Security Fabric Topology when 'set configuration-sync' is set to local.
Scope	FortiGate, FortiAnalyzer, and FortiManager.
Solution	In a network topology with a centralized FortiGate (root FortiGate) and downstream FortiGates (all devices are managed by FortiManager), a logging icon showing all is by design when Security Fabric is enabled. If needed to centralize logging management through FortiManager, there is a setting to achieve it: config system csf     set configuration-sync local end Below are the impacts on Security Fabric devices when 'set configuration-sync local' is configured on the downstream device: All traffic going through FortiGate firewall policy will be logged regardless if logging is enabled or not in policy configuration. The policies will reflect the logging changes that are pushed from FortiManager.  The connection between downstream FortiGate, FortiAnalyzer and FortiManager will remain established and the downstream FortiGate can be managed by FortiManager. The synchronized Fabric objects are kept as locally created objects on downstream FortiGate. On FortiAnalyzer, the logs from the downstream device will continue to be saved. On the downstream FortiGate: On the FortiAnalyzer, the connection is UP, and the logs are stored: On the FortiManager device, the device is UP and still can be managed by FortiManager: Note: If this option 'configuration-sync' is not configured as 'local' on all downstream FortiGate, those Fabric Objects synchronized from the root FortiGate won't be modified. In certain scenarios that the downstream non-root FortiGate receives the synchronized objects while the FortiManager is not aware of this change. In that case, FortiManager will attempt to delete these synchronized objects when pushing configuration to the FortiGate but will not be successful. The error will be as follows: ------- Start to retry -------- chewbacca-kvm62 $ config firewall address chewbacca-kvm62 (address) $ delete "192.168.10.10/32" Cannot delete fabric object in non-root Security Fabric member. command_cli_delete:6944 delete table entry 192.168.10.10/32 unset oper error ret=-160 Command fail. Return code -160 chewbacca-kvm62 (address) $ end ---> generating verification report ( firewall address ) delete "192.168.10.10/32" <--- done generating verification report install failed This is actually the conflict between the Security Fabric synchronization and FortiManager as both attempt to push changes to non-root FortiGates. To avoid this scenario, it is necessary to configure 'configuration-sync' as 'local' while let the FortiManager manage the synchronization of all objects among all FortiGates in the same ADOM.