FortiGate Active-Passive High Availability Lab with Cisco Nexus 9000 vPC – Full Configuration Guide
Home › Config & Troubleshoot › FortiGate HA Lab
Last Updated: June 2025 | Fortinet | ⏱ 12-min read
Building a FortiGate High Availability (HA) lab that mirrors enterprise production architecture is one of the most valuable hands-on exercises a network security engineer can undertake. This project demonstrates exactly that — a fully redundant, enterprise-grade topology using two FortiGate VM64-KVM firewalls in Active-Passive HA mode, backed by two Cisco Nexus 9000 switches running Virtual Port Channel (vPC) for fully redundant Layer 2 backlinks. Every device has a real configuration; every design decision has an enterprise justification.
This article walks through the complete setup — from topology design and Nexus 9000 vPC configuration, through FortiGate initial access, VLAN interface provisioning, firewall policy creation, and finally HA cluster formation and verification. All CLI configurations are taken directly from the live lab.
Table of Contents
- Lab Topology & Design Overview
- Cisco Nexus 9000 vPC Configuration
- LAN Internal Switch Configuration
- FortiGate Initial Setup & Management Access
- FortiGate VLAN Interface Configuration
- Firewall Policies for VLAN 100 & 110
- FortiGate HA Active-Passive Configuration
- HA Cluster Verification & Failover
- Conclusion & Key Takeaways
1. Lab Topology & Design Overview
The lab topology is deliberately designed to eliminate every single point of failure between the firewall layer and the switching layer — a critical requirement for any production data center or enterprise edge deployment.
| Device | Role | Mgmt IP | Platform |
|---|---|---|---|
| FW-1 | FortiGate Primary (Active) | 192.168.79.100/24 | FortiGate VM64-KVM |
| FW-2 | FortiGate Secondary (Passive) | 192.168.79.110/24 | FortiGate VM64-KVM |
| N9K-1 | Primary Switch (vPC Domain 1) | 192.168.1.1/24 | Cisco Nexus 9000 |
| N9K-2 | Secondary Switch (vPC Domain 1) | 192.168.1.2/24 | Cisco Nexus 9000 |
| LAN Switch | Internal access switch (VLAN 100 & 110) | — | Cisco IOS 15.2 |
Key design decisions in this topology:
- Each FortiGate connects to both N9K-1 and N9K-2 via separate port-channels (Po100 and Po110), providing dual-homed uplinks that survive a complete switch failure.
- The Nexus pair uses vPC (Virtual Port Channel) so that both switches appear as a single logical switch to the FortiGates — eliminating Spanning Tree blocking and maximizing bandwidth.
- FortiGate HA heartbeat runs over two dedicated ports (HA-1 on port2, HA-2 on port3) for heartbeat redundancy.
- Two VLANs (100 and 110) segment internal users: VLAN 100 (Linux-PC) uses 192.168.100.0/24; VLAN 110 (Win-PC) uses 192.168.110.0/24.
2. Cisco Nexus 9000 vPC Configuration
Virtual Port Channel (vPC) allows two Nexus switches to present a single Port Channel to downstream devices, eliminating STP blocked ports and providing both link-level and device-level redundancy simultaneously. Both N9K-1 and N9K-2 run NX-OS 9.3(1) and are in the same vPC domain.
N9K-1 (Primary) — Key Configuration
N9K-1 is assigned vPC role priority 20 (lower = preferred primary). The peer-keepalive uses the management VRF between 192.168.1.1 and 192.168.1.2.
feature lacp feature vpc vpc domain 1 role priority 20 peer-keepalive destination 192.168.1.2 source 192.168.1.1 ! vPC Peer-Link (Po1) — E1/1 + E1/2 interface port-channel1 switchport mode trunk switchport trunk allowed vlan 100,110 spanning-tree port type network vpc peer-link ! Po100 — uplink to FW-1 port4 interface port-channel100 switchport mode trunk switchport trunk allowed vlan 100,110 vpc 100 ! Po110 — uplink to FW-1 port5 interface port-channel110 switchport mode trunk switchport trunk allowed vlan 100,110 vpc 110 ! Po10 — downlink to LAN internal switch interface port-channel10 switchport mode trunk switchport trunk allowed vlan 100,110 vpc 10 ! Member interfaces interface Ethernet1/1 switchport mode trunk switchport trunk allowed vlan 100,110 spanning-tree port type network channel-group 1 mode active ! peer-link interface Ethernet1/4 switchport mode trunk switchport trunk allowed vlan 100,110 channel-group 100 mode active ! to FW-1 interface Ethernet1/5 switchport mode trunk switchport trunk allowed vlan 100,110 channel-group 110 mode active ! to FW-2 interface Ethernet1/3 switchport mode trunk switchport trunk allowed vlan 100,110 channel-group 10 mode active ! to LAN switch interface mgmt0 vrf member management ip address 192.168.1.1/24
N9K-2 (Secondary) — Key Differences
N9K-2 has role priority 30 (higher number = secondary) and mirrors the vPC configuration with reversed peer-keepalive source/destination addresses.
vpc domain 1 role priority 30 peer-keepalive destination 192.168.1.1 source 192.168.1.2 ! Interface assignments mirror N9K-1 ! E1/4 → channel-group 110 (to FW-1 port5 cross-link) ! E1/5 → channel-group 100 (to FW-2 port4) interface Ethernet1/4 channel-group 110 mode active interface Ethernet1/5 channel-group 100 mode active interface mgmt0 vrf member management ip address 192.168.1.2/24
⚠ vPC Design Note: Notice the cross-connect pattern — FW-1's port4 goes to N9K-1's E1/4 (Po100) AND N9K-2's E1/5 (Po100). FW-1's port5 goes to N9K-1's E1/5 (Po110) AND N9K-2's E1/4 (Po110). This cross-connect ensures that a single switch failure does not take down either port-channel to the firewall.
3. LAN Internal Switch Configuration
The LAN switch (Cisco IOS 15.2) connects the end-user devices and trunks up to the N9K pair via Po10. It assigns access ports per VLAN for the Linux-PC (VLAN 100) and Win-PC (VLAN 110).
! Trunk uplink to N9K vPC pair (Po10) interface Port-channel10 switchport trunk allowed vlan 100,110 switchport trunk encapsulation dot1q switchport mode trunk interface GigabitEthernet0/0 switchport trunk allowed vlan 100,110 switchport trunk encapsulation dot1q switchport mode trunk channel-protocol lacp channel-group 10 mode active interface GigabitEthernet0/1 switchport trunk allowed vlan 100,110 switchport trunk encapsulation dot1q switchport mode trunk channel-protocol lacp channel-group 10 mode active ! Access port: Linux-PC → VLAN 100 interface GigabitEthernet0/2 switchport access vlan 100 switchport mode access ! Access port: Win-PC → VLAN 110 interface GigabitEthernet0/3 switchport access vlan 110 switchport mode access
4. FortiGate Initial Setup & Management Access
Both FortiGate VM64-KVM instances require initial console setup before GUI access is possible. After the first login, FortiOS forces an immediate password change. Once the new password is set, the management interface is configured via CLI.
FW-1 — Management Interface (port6 → 192.168.79.100/24)
FortiGate-VM64-KVM # config system interface FortiGate-VM64-KVM (interface) # edit port6 FortiGate-VM64-KVM (port6) # set ip 192.168.79.100/24 FortiGate-VM64-KVM (port6) # set allowaccess https http ssh ping FortiGate-VM64-KVM (port6) # end
FW-2 — Management Interface (port6 → 192.168.79.110/24)
FortiGate-VM64-KVM # config system interface FortiGate-VM64-KVM (interface) # edit port6 FortiGate-VM64-KVM (port6) # set ip 192.168.79.110/24 FortiGate-VM64-KVM (port6) # set allowaccess https http ssh ping FortiGate-VM64-KVM (port6) # end
After these commands, both firewalls are reachable via HTTPS at their respective management IPs. All remaining configuration is performed through the FortiGate web GUI on the Primary unit — the HA cluster will automatically synchronize every setting to the Secondary after cluster formation.
5. FortiGate VLAN Interface Configuration
Two VLAN sub-interfaces are created on the FortiGate's AGG-IN aggregate interface (which represents the bonded port-channel toward the Nexus switches). These VLAN interfaces serve as the Layer 3 default gateways for each user segment and carry the VLAN tags defined on the Nexus switches.
VLAN-100 Interface
Name: VLAN-100
Type: VLAN (802.1Q)
Parent: AGG-IN
VLAN ID: 100
IP/Mask: 192.168.100.254/24
Role: LAN (default gateway for Linux-PC)
VLAN-110 Interface
Name: VLAN-110
Type: VLAN (802.1Q)
Parent: AGG-IN
VLAN ID: 110
IP/Mask: 192.168.110.254/24
Role: LAN (default gateway for Win-PC)
Both interfaces are created via Network → Interfaces → New Interface in the FortiGate GUI. The "Create address object matching subnet" toggle is enabled for each, which automatically generates a corresponding address object (e.g., "VLAN-100 address") that can be immediately referenced in firewall policies without manual address creation.
6. Firewall Policies for VLAN 100 & 110
Two firewall policies are created to allow outbound internet access from each VLAN. Both policies use NAT with the outgoing WAN interface address, enabling both user segments to share the single public IP on port1 (WAN) without additional IP pool configuration.
| Parameter | VLAN100-Policy | VLAN110-Policy |
|---|---|---|
| Incoming Interface | VLAN-100 | VLAN-110 |
| Outgoing Interface | WAN (port1) | WAN (port1) |
| Source / Destination | all / all | all / all |
| Service | ALL | ALL |
| Action | ACCEPT | ACCEPT |
| NAT | Enabled (outgoing interface address) | Enabled (outgoing interface address) |
| Inspection Mode | Flow-based | Flow-based |
Important: These policies are intentionally broad for a lab environment. In production, the source should be restricted to the specific subnet (e.g., VLAN-100 address object), destination should be scoped where possible, and Security Profiles (AV, Web Filter, Application Control, IPS) should be attached to each policy to enable full NGFW inspection on all outbound traffic.
7. FortiGate HA Active-Passive Configuration
FortiGate HA is configured via System → HA on each firewall independently. The two units discover each other through the heartbeat interfaces and negotiate roles based on device priority — higher priority wins the Primary role.
FW-1 (Primary) HA Settings
FW-2 (Secondary) HA Settings
HA Design Explanation
- Two heartbeat interfaces (port2 and port3) are used for heartbeat redundancy. If the primary heartbeat (HA-1/port2) fails, the secondary heartbeat (HA-2/port3) keeps the cluster operational and prevents a split-brain condition.
- Monitor interface (WAN port1) triggers a failover if the Primary loses connectivity on this interface — even if the firewall itself is still running.
- Group name and password must match exactly on both units — they are used to authenticate cluster membership and prevent rogue units from joining.
- Active-Passive mode means only FW-1 passes production traffic; FW-2 sits in standby, receives full configuration sync, and takes over within seconds if FW-1 fails.
8. HA Cluster Verification & Failover
After applying HA configuration on both units, the FortiGate cluster forms automatically within 30–60 seconds. The HA monitor page at System → HA confirms the cluster status. Both units in this lab show Synchronized status — confirming that configuration, routing tables, and session tables are being replicated correctly.
| Status | Priority | Hostname | Role | Sessions |
|---|---|---|---|---|
| ✔ Synchronized | 128 | Primary | Primary (Active) | 21 sessions, 170 kbps |
| ✔ Synchronized | 100 | Secondary | Secondary (Standby) | 1 session, 37 kbps |
Failover Test: The project also verified HA failover by shutting down the primary firewall. The HA monitor page (accessed via the same VIP — 192.168.79.100) shows FW-2 (hostname: Secondary, priority 100) taking the Primary role automatically, with FW-1 dropping to Secondary once restored. This is confirmed in the second HA monitor screenshot where the unit with priority 100 (FW-2) is listed first with the Primary role and 19 minutes of uptime.
Verification Commands (CLI): Run get system ha status from the FortiGate CLI to see the full HA cluster state, including heartbeat interface status, sync state, and the reason for the last failover event. This is invaluable for troubleshooting HA formation issues.
9. Conclusion & Key Takeaways
This home lab project demonstrates a production-grade approach to FortiGate high availability — combining the firewall-level redundancy of Active-Passive HA with the switch-level redundancy of Cisco Nexus 9000 vPC. The result is a topology with no single point of failure between the firewall and the switching fabric: either firewall can fail, or either switch can fail, and traffic continues without interruption.
The skills practiced in this lab — Nexus vPC design and configuration, FortiGate VLAN sub-interface creation, NAT firewall policy construction, and HA cluster formation and verification — map directly to enterprise deployment scenarios and are highly relevant for Fortinet NSE, Cisco CCNP/CCIE Data Center, and network engineering roles.
Key Takeaways
- vPC eliminates STP blocking and allows both uplinks from each FortiGate to actively carry traffic simultaneously
- Cross-connect the port-channels — each FW port should connect to both N9K-1 and N9K-2 to survive a full switch failure
- FortiGate HA requires matching Group Name and Password on both units — a mismatch prevents cluster formation entirely
- Device priority determines role — higher value = Primary. FW-1 at 128 beats FW-2 at 100
- Two heartbeat interfaces (HA-1 and HA-2) prevent split-brain — never run HA with a single heartbeat link in production
- Monitor interface (WAN) triggers failover if the Primary loses its uplink, even if the firewall hardware is healthy
- Failover is automatic — verified in lab with the Secondary taking Primary role and all sessions continuing via the synchronized session table
Tags
