Accessing Secondary FortiGate HA Units via CLI: Methods, Commands, and Operational Realities
.
Master CLI access to secondary FortiGate HA firewalls: execute ha manage syntax, reserved management interfaces, cluster indexing, and field-tested procedures.
The Hidden Access Layer in FortiGate High Availability Clusters
High-availability firewall deployments promise seamless failover, yet operational demands occasionally require direct engagement with the passive unit. Network engineers confronting this scenario discover that FortiGate's HA architecture deliberately obscures individual node access—a design choice favoring cluster-wide consistency over granular control. This investigation reconstructs the verified pathways to secondary-unit CLI access, separating documented procedures from field adaptations.
Primary Pathway: The execute ha manage Command Sequence
Command Syntax Evolution and Index Resolution
FortiOS version boundaries dictate command structure. On firmware 6.2.1 and later, administrators must specify both the target cluster index and a valid username:
execute ha manage <index-ID> <admin-username> Earlier releases accepted only the index identifier, prompting separately for credentials. The cluster index—critical for targeting the correct node—derives from two diagnostic commands. Executing get system ha status returns a detailed topology report where each unit's serial number pairs with its operating cluster index. Alternatively, execute ha manage ? produces a concise peer listing:
<id> please input peer box index. <1> Subsidiary unit FGVMxxxxyyyyy Index assignment typically follows convention: 0 denotes the primary unit, 1 the secondary. Verification remains essential, as topology changes can alter these assignments.
Authentication Flow and Session Navigation
Upon issuing the manage command, the CLI presents a password prompt scoped to the target unit's local credential store. Successful authentication drops the administrator directly into the secondary unit's executive context. Navigation back to the primary requires only the exit command. System logs record these transitions using link-local addresses: primary units communicate via 169.254.0.1, secondaries via 169.254.0.2, unless Layer 3 unicast routing is explicitly enabled in the HA configuration.
Alternative Architecture: Reserved Management Interfaces
Independent Access Through Dedicated Ports
When operational requirements demand persistent, direct connectivity to each cluster member—such as independent SNMP polling or out-of-band diagnostics—the reserved management interface feature provides a structural solution. This approach configures a physical port exclusively for management traffic, bypassing the cluster's synchronized interface state.
Implementation requires parallel configuration on both units. On the primary firewall, administrators designate a physical interface (for example, port15) with management-specific attributes:
config system interface edit "port15" set dedicated-to management set ip 10.10.10.140 255.255.255.0 set allowaccess ping https ssh http next end The HA configuration then binds this interface to a dedicated management routing instance:
config system ha config ha-mgmt-interfaces edit 1 set interface "port15" set gateway 10.10.10.1 next end end Asynchronous Configuration Requirements
Critical to this method: management interface settings do not synchronize between cluster members. The secondary unit requires manual configuration with a distinct IP address within the same subnet. Administrators must also ensure matching gateway definitions and consistent HA group parameters. This architectural choice preserves cluster integrity while enabling independent node access—a tradeoff demanding disciplined change management.
Platform Constraints and Access Limitations
GUI Access Variability Across Hardware Tiers
Web-based management of secondary units remains inconsistently available. Entry-level and midrange FortiGate models (60D through 90D series) generally restrict GUI access to the active cluster member. Higher-end chassis platforms (6000 series and above) occasionally support direct secondary access through port-specific HTTPS endpoints, such as https://<cluster-ip>:44320, where the final digit identifies the target cluster member.
Models featuring dedicated management ports (typically 100D and above) offer the most reliable path to independent GUI access, provided the reserved management interface configuration is correctly implemented. Administrators should verify hardware capabilities against firmware release notes before designing access workflows around GUI availability.
Diagnostic Visibility Without Direct Access
When direct secondary access proves impractical, FortiOS provides limited observational channels. The HA statistics widget—accessible via Dashboard > Administrators > Show active administrator sessions—displays resource utilization metrics for both cluster members. System logs capturing authentication events from link-local addresses (169.254.0.1/0.2) confirm successful cross-node management sessions executed via the ha manage command sequence.
Frequently Asked Questions
What happens if the secondary unit's admin password differs from the primary?
The execute ha manage command authenticates against the target unit's local credential store. Password synchronization is not automatic; administrators must ensure credential consistency across cluster members or maintain accurate records of unit-specific credentials.
Can I execute configuration changes on the secondary unit while it remains in the HA cluster?
Technical access does not imply operational advisability. Configuration changes made directly to the passive unit risk desynchronization and cluster instability. Fortinet's design philosophy treats the cluster as a single logical entity; modifications should originate from the primary unit to maintain configuration integrity.
Why do some commands show different behavior across FortiOS versions?
FortiOS 6.2.1 introduced explicit username specification in the execute ha manage syntax to strengthen authentication auditing. Administrators managing heterogeneous firmware environments should consult version-specific documentation and test command sequences in non-production contexts before deployment.
Is the reserved management interface method compatible with Active-Active HA modes?
Yes. The reserved management interface operates independently of HA operational mode (Active-Passive or Active-Active). However, traffic distribution policies in Active-Active deployments may influence which unit processes management requests, requiring careful interface and routing design to ensure predictable access patterns.