Adding FortiGate to FortiManager: A Technical Investigation into Centralized Firewall Management
.
Step-by-step guide to adding FortiGate devices to FortiManager for centralized policy control and configuration management.
Prerequisites and Foundation
Network and Access Requirements
Successful integration begins with verified connectivity. FortiManager communicates with managed FortiGate units over TCP port 541, a dedicated channel for configuration synchronization and policy distribution. Administrators must confirm bidirectional reachability between the management platform and each firewall endpoint, accounting for intermediate routing, NAT translations, or security policies that might interrupt the handshake. Both NAT-mode and transparent-mode FortiGate deployments are supported, though interface mapping considerations differ during policy import.
Device Registration Essentials
Before management enrollment, FortiGate units require registration through the vendor's support portal. This step activates access to threat intelligence feeds—antivirus signatures, IPS definitions, and firmware updates—that FortiManager subsequently distributes. Unregistered devices may join the management console but will operate with diminished protective capabilities, creating a potential gap in organizational security posture.
The Two-Way Configuration Process
FortiGate-Side Preparation
Configuration initiates on the firewall itself. Through the web-based manager, administrators navigate to System > Admin > Settings, input the FortiManager IP address, and submit a registration request. The FortiManager serial identifier then appears in the trusted management table. For CLI-driven environments, the equivalent sequence uses config system central-management followed by set fmg <ip_address>. An optional registration password adds a layer of authentication, requiring matching credentials on both endpoints before trust is established.
Encryption preferences can be tuned via CLI using set enc-algorithm, with options for default (high and medium cipher suites), high (AES-256 and equivalent), or low (legacy 56/64-bit algorithms). Security-conscious deployments should retain the default or explicitly select high-strength ciphers to protect management traffic from interception.
FortiManager Discovery and Enrollment
On the management platform, enrollment proceeds through Device Manager > Device & Groups. The Add Device wizard offers a Discover mode that scans for unmanaged FortiGate units advertising their availability. Administrators supply credentials and confirm device identity before the unit appears in the inventory. Alternative manual entry methods exist for air-gapped or highly restricted environments where discovery protocols cannot traverse network boundaries.
Synchronization and Policy Management
Configuration Retrieval Mechanics
After enrollment, FortiManager does not automatically assume the device's running configuration. Administrators must explicitly retrieve the configuration through the device dashboard's Configuration and Installation Status widget. Selecting Revision History > Retrieve Config pulls the active policy set, interface definitions, and object database into the management repository. Discrepancies between the device and repository generate a new revision entry, preserving an auditable change trail.
Policy Import and Ongoing Governance
The Import Policy wizard finalizes synchronization by mapping interfaces, ingesting policy rules, and reconciling address objects. A critical operational constraint: default or per-device interface mappings must exist before installation proceeds. Post-import, all policy modifications should originate from FortiManager's Policy & Objects module. Direct edits on the FortiGate unit desynchronize the management state, necessitating a full re-import to restore consistency—a workflow disruption that undermines the centralization benefit.
Security Considerations and Encryption
Management channel integrity warrants deliberate attention. While SSL/TLS encryption is configurable, the default cipher suite selection balances compatibility with contemporary security standards. Organizations subject to compliance frameworks should validate that selected algorithms meet regulatory requirements. Additionally, the optional registration password functions as a pre-shared key; its compromise could permit unauthorized management enrollment. Rotation policies and restricted administrative access on both endpoints mitigate this risk.
Frequently Asked Questions
What network port must be open for FortiGate to communicate with FortiManager?
TCP port 541 must permit bidirectional traffic between the FortiGate unit and the FortiManager appliance. Firewalls or ACLs blocking this port will prevent registration, configuration retrieval, and policy installation.
Can I manage a FortiGate that was configured locally before adding it to FortiManager?
Yes. The Import Policy wizard ingests the existing configuration, including interface mappings and security policies. However, after import, all subsequent changes should be made through FortiManager to maintain synchronization.
What happens if I modify a policy directly on the FortiGate after it is managed?
Direct modifications create a configuration drift. FortiManager will not automatically detect these changes. To restore alignment, administrators must retrieve the updated configuration and re-import policies, which may overwrite manual edits or require manual reconciliation.
Is a registration password required for enrollment?
No, but it is recommended for environments requiring additional authentication. When enabled, the same password must be configured on both the FortiGate and FortiManager before the trust relationship is established.
Do all FortiGate models support management by FortiManager?
Most FortiGate hardware and virtual appliances support FortiManager integration, but feature availability and scale limits depend on the FortiManager license tier and the FortiGate model. Consult compatibility matrices before deployment planning.