Executive Summary

FGCP is the default answer whenever someone says “FortiGate high availability,” and for a matched active-passive or active-active pair it is almost always the right answer. But FGCP only works between two FortiGates of the same model running synchronized configs. The moment you need first-hop redundancy between a FortiGate and a Cisco or Juniper router, between two FortiGates that intentionally run different configs (different VDOMs, different policies, a staged migration), or between boxes that simply cannot form an HA cluster, FGCP is off the table. That is the gap VRRP fills.

This guide covers configuring the Virtual Router Redundancy Protocol (RFC 3768 / RFC 5798) on FortiGate as a standards-based, vendor-neutral alternative to FGCP for default-gateway redundancy. It walks through a two-FortiGate lab, but everything here applies just as well to a FortiGate paired with a third-party router. The objective is a working VRRP domain with fast, predictable failover, plus the handful of FortiGate-specific options (virtual MAC, VRRP groups, VRRP proxy ARP) that do not exist in a textbook VRRP writeup.

Target audience: network and security engineers who are already comfortable with FGCP HA and FortiOS CLI basics, and who need first-hop redundancy in a scenario FGCP cannot cover.

Scope: FortiOS 7.0 through 7.6/8.0. IPv4 VRRP (VRRPv2/v3) is the primary focus, with IPv6 (VRRPv3 over vrrp6) covered as a condensed step since the config structure mirrors IPv4 closely. One version-specific detail matters throughout this guide: FortiOS 7.6.0 changed the VRRP advertisement interval from whole seconds (1 to 255) to milliseconds (250 to 255000). Every CLI example below uses the post-7.6 millisecond syntax and calls out the pre-7.6 equivalent inline.

Prerequisites & Architecture

Assumed knowledge: FortiOS CLI conventions (config / edit / set / next / end), basic IPv4 subnetting, and enough routing background to know what a default gateway does. Familiarity with FGCP HA is helpful context but not required.

Environment and lab requirements:

• Two FortiGates (or one FortiGate and one third-party VRRP-capable router) with interfaces on the same Layer 2 broadcast domain. VRRP hellos are multicast to 224.0.0.18 over IP protocol 112, and that multicast does not route between segments, so both routers must sit on the same VLAN or switch.
• FortiOS 7.4 or 7.6+ recommended. If you are running anything older than 7.6.0, adjust the adv-interval examples to whole seconds as noted.
• VRRP can only be configured on physical or VLAN interfaces. It cannot be configured on a hardware-switch interface (multiple physical ports bridged into one virtual switch port).
• CLI or SSH access. There is no GUI page for VRRP on FortiGate. Every official Fortinet example, from FortiOS 6.0 through the current 8.0 documentation, is CLI-only, and a Fortinet KB article states this outright. Network > Interfaces will let you assign an IP to the interface, but the VRRP instance itself is CLI territory. Plan your maintenance windows and change tickets accordingly.

Addressing plan for this guide (using 10.0.0.0/16 for internal segments and 198.18.0.0/15 to represent upstream/transit addresses, per house convention):

FGT-EDGE-A and FGT-EDGE-B are two independent FortiGates, each with its own WAN uplink and its own configuration. They are not an FGCP cluster. Downstream hosts on the LAN and DMZ segments will use the virtual IPs (10.20.30.1 and 10.20.40.1) as their default gateway, never the physical interface IPs.

Step-by-Step Implementation Workflow

Step 1: Confirm Interface Eligibility and Plan the VRRP Domain

Goal: pick an interface type VRRP actually supports, and settle on a VRID and virtual IP before touching the CLI.

Action: Confirm port10 on both FortiGates is a physical or VLAN interface (not a hardware switch member). Pick a VRID between 1 and 255 that is unique within this broadcast domain (VRID does not need to be globally unique across your network, only within the segment where the VRRP hellos are exchanged). Pick a virtual IP inside the same subnet as the interfaces’ physical IPs. Do not reuse the virtual IP as either box’s physical address.

diagnose hardware deviceinfo nic port10

Look for the interface type in the output; a hardware-switch member will show up differently than a standalone physical or VLAN interface. If port10 is currently part of a hardware switch, break it out before continuing.

Step 2: Configure VRRP on the Primary FortiGate

Goal: bring FGT-EDGE-A up as the VRRP primary for VRID 10 with the highest priority in the domain.

Action: Add a config vrrp block under the LAN interface. vrip is the floating address, priority decides who wins the election (higher wins), and preempt lets a higher-priority router reclaim primary status once it comes back online.

config system interface
    edit "port10"
        set ip 10.20.30.2 255.255.255.0
        config vrrp
            edit 10
                set vrip 10.20.30.1
                set priority 255
                set adv-interval 1000
                set preempt enable
            next
        end
    next
end

set adv-interval 1000 sends a hello every 1000 milliseconds (1 second), matching the pre-7.6 default of set adv-interval 1. On FortiOS releases before 7.6.0, use set adv-interval 1 instead; the field simply will not accept a value above 255 on those builds.

Step 3: Configure VRRP on the Backup FortiGate

Goal: bring FGT-EDGE-B up as the backup for the same VRID and virtual IP, with a lower priority.

Action: Mirror Step 2 on FGT-EDGE-B, keeping vrip and the VRID identical (these are the two values the protocol actually negotiates on) while giving the box a lower priority.

config system interface
    edit "port10"
        set ip 10.20.30.3 255.255.255.0
        config vrrp
            edit 10
                set vrip 10.20.30.1
                set priority 100
                set adv-interval 1000
                set preempt enable
            next
        end
    next
end

With preempt enabled on both sides, FGT-EDGE-A will always reclaim primary status when it is healthy and reachable, since 255 beats 100. If you want the backup to keep serving traffic after a planned failback until you are ready to switch it back manually, set preempt disable on both boxes instead.

Step 4: Point Downstream Hosts at the Virtual IP

Goal: make the redundancy actually useful by having the LAN use the floating address, not either physical interface, as its gateway.

Action: Update DHCP scope options and any statically addressed hosts on the 10.20.30.0/24 segment to use 10.20.30.1 as the default gateway. If FortiGate is also the DHCP server for this segment, set the default gateway option explicitly rather than letting it default to the interface IP.

config system dhcp server
    edit 1
        set default-gateway 10.20.30.1
        set netmask 255.255.255.0
        set interface "port10"
        config ip-range
            edit 1
                set start-ip 10.20.30.100
                set end-ip 10.20.30.200
            next
        end
    next
end

GUI Verification: Network > DHCP Server, confirm the Default Gateway field shows 10.20.30.1 on both FortiGates if each is independently serving DHCP for its own scope, or on whichever box owns the scope in your design.

Step 5: Enable the VRRP Virtual MAC

Goal: make failover invisible to downstream switches and hosts by having both routers answer for the same MAC address, not just the same IP.

Action: By default, vrrp-virtual-mac is disabled and each FortiGate answers ARP for the virtual IP using its own physical interface MAC. When the primary fails over, the new primary has to send gratuitous ARP with its own MAC and hope every downstream switch updates its CAM table and every host refreshes its ARP cache before the old entry times out. Enabling the RFC-standard virtual MAC (00-00-5E-00-01-{VRID} for VRRPv2/IPv4) means both routers already share the same MAC address for the virtual IP, so failover only requires a CAM table update via gratuitous ARP, not a full ARP cache refresh on every host.

config system interface
    edit "port10"
        set vrrp-virtual-mac enable
    next
end

Set this identically on both FGT-EDGE-A and FGT-EDGE-B. For VRID 10 this produces the virtual MAC 00-00-5e-00-01-0a (0a is hex for 10).

GUI Verification: none, see Step 1. Confirm with get router info vrrp after Step 2 or 3, covered in Verification & Validation below.

Step 6: Track Upstream Reachability with vrdst and vrdst-priority

Goal: make the primary step down when it loses its own upstream path, even though the LAN-side VRRP segment itself is still perfectly healthy.

Action: VRRP by itself only detects a dead peer or a dead LAN-side link. It has no idea whether FGT-EDGE-A’s WAN uplink is still working. vrdst tells the primary to actively monitor one or two remote destinations; vrdst-priority is the priority the primary will announce if none of those destinations are reachable, letting the backup take over even though the primary is technically still alive on the LAN segment.

config system interface
    edit "port10"
        config vrrp
            edit 10
                set vrdst 198.18.30.1 198.18.30.2
                set vrdst-priority 10
            next
        end
    next
end

With two vrdst addresses configured, VRRP only reports a failure once both are unreachable, not just one. vrdst-priority 10 means that if FGT-EDGE-A loses its WAN path entirely, it starts advertising a priority of 10 instead of 255, and FGT-EDGE-B (priority 100) takes over as primary. As a best practice, point vrdst at addresses reachable only through the WAN uplink, such as the ISP’s next-hop gateway, not at anything on the local LAN segment.

Step 7: Synchronize Multiple VRRP Domains with vrgrp

Goal: make the LAN and DMZ segments fail over together, so a WAN outage on FGT-EDGE-A does not leave it as primary on the DMZ while it has already stepped down on the LAN.

Action: Each interface running its own config vrrp block is its own independent VRRP domain, and VRRP can only track health within its own domain. If FGT-EDGE-A has separate VRRP instances on port10 (LAN, VRID 10) and port11 (DMZ, VRID 20), a WAN failure detected via vrdst on the LAN instance has no effect on the DMZ instance by default; you would end up with a split brain where FGT-EDGE-A is backup on the LAN and still primary on the DMZ. vrgrp links VRRP instances on the same chassis into one group so that if any member steps down, all members with the same vrgrp value step down together.

config system interface
    edit "port10"
        config vrrp
            edit 10
                set vrgrp 100
            next
        end
    next
    edit "port11"
        set ip 10.20.40.2 255.255.255.0
        config vrrp
            edit 20
                set vrip 10.20.40.1
                set priority 255
                set vrgrp 100
            next
        end
    next
end

Repeat the same vrgrp 100 assignment on both VRID 10 and VRID 20 on FGT-EDGE-B as well. The vrgrp value itself is purely local bookkeeping. It never appears on the wire and does not need to match anything on the peer FortiGate; it only has to be consistent across the instances on the same box that you want to move together.

Step 8: Fail Over Firewall VIPs and IP Pools with VRRP Proxy ARP

Goal: make sure any firewall VIPs or IP pool ranges configured on the VRRP-enabled interface follow the current primary automatically, without carving out a separate VRID for every extra address.

Action: config proxy-arp nested under a VRRP instance (not the same as the standalone config system proxy-arp table) maps additional single IPs or IP ranges to that instance’s virtual MAC. After a failover, the new primary answers ARP for those addresses too, so any DNAT VIPs or SNAT IP pool ranges riding on this interface move with the group automatically.

config system interface
    edit "port10"
        set vrrp-virtual-mac enable
        config vrrp
            edit 10
                config proxy-arp
                    edit 1
                        set ip 10.20.30.100-10.20.30.150
                    next
                    edit 2
                        set ip 10.20.30.200
                    next
                end
            next
        end
    next
end

The address or range configured here should match whatever VIPs or IP pool ranges you have already defined for this interface elsewhere in the firewall policy. vrrp-virtual-mac must be enabled for this to work, since the whole point is mapping these extra addresses onto the shared virtual MAC.

Step 9: Mirror the Configuration for IPv6 (VRRPv3 over vrrp6)

Goal: run the equivalent dual-stack setup for an IPv6 segment sharing the same LAN.

Action: IPv6 VRRP lives under config ipv6 on the interface, using vrrp6 instead of vrrp, vrip6 instead of vrip, and a separate vrrp-virtual-mac6 switch plus a link-local address for the virtual router. The rest of the option set (priority, adv-interval, preempt, vrdst6, ignore-default-route) works the same way as its IPv4 counterpart.

config system interface
    edit "port10"
        config ipv6
            set vrrp-virtual-mac6 enable
            set vrip6_link_local fe80::10:20:30:1
            config vrrp6
                edit 10
                    set vrip6 2001:db8:20:30::1
                    set priority 255
                    set vrdst6 2001:db8:198:18::1
                next
            end
        end
    next
end

The IPv6 virtual MAC scheme uses a different OUI suffix than IPv4: 00-00-5E-00-02-{VRID} for VRRPv3/IPv6, versus 00-00-5E-00-01-{VRID} for VRRPv2/IPv4. vrdst-priority for vrrp6 is only available starting in FortiOS 7.6.x; on earlier releases you do not have the IPv6 equivalent of Step 6’s graceful priority drop.

Verification & Validation

Confirm the VRRP state on each box with the built-in diagnostic command:

get router info vrrp

Expected output on the primary once everything is up:

Interface: port10, primary IP address: 10.20.30.2
UseVMAC: 1, SoftSW: 0, BrPortIdx: 0, PromiscCount: 0
VRID: 10
vrip: 10.20.30.1, priority: 255, state: MASTER
adv_interval: 1000, preempt: 1, start_time: 3
vrdst: 198.18.30.1 198.18.30.2

The backup should show the same VRID and virtual IP with state: BACKUP and its own lower priority. UseVMAC: 1 confirms the virtual MAC from Step 5 is active. For the IPv6 side, run get router info6 vrrp and look for the equivalent vrip, state, and vrmac fields.

Confirm the virtual MAC is actually what downstream devices see by checking the ARP entry for the virtual IP from a host or switch on the segment:

get arp | grep 10.20.30.1

You should see 00:00:5e:00:01:0a (VRID 10 in hex) as the MAC, not either FortiGate’s real interface MAC.

Watch the protocol on the wire directly with the built-in sniffer, useful when you suspect hellos are not making it across a switch:

diagnose sniffer packet port10 'ip proto 112' 4

Finally, test an actual failover. Disable the VRRP instance on the primary (or physically pull its LAN link) and confirm the backup takes over within roughly three times the advertisement interval, which is how long a backup waits before assuming the primary is gone:

config system interface
    edit "port10"
        config vrrp
            edit 10
                set status disable
            next
        end
    next
end

Re-run get router info vrrp on the backup and confirm state: MASTER. Re-enable the instance on the original primary afterward and, with preempt enable, watch it reclaim primary status.

Troubleshooting & Gotchas

The 7.6.0 adv-interval unit change breaks copy-pasted configs across mixed firmware. A config snippet written for a pre-7.6.0 box uses set adv-interval 1 (one second). Paste that same line onto a 7.6.0+ box and it is still valid syntax, since 1 is a legal millisecond value now, but it means something completely different: a hello every 1 millisecond instead of every second, which will hammer the CPU and flood the segment. Always double-check the target FortiOS version before reusing an old VRRP config, and set the value explicitly (1000 for a 1-second interval) rather than trusting muscle memory.

VRRP needs a shared Layer 2 segment, and a local-in policy or upstream ACL can silently eat it. VRRP hellos are multicast to 224.0.0.18 over IP protocol 112. If the two routers are on different VLANs bridged through something that filters unrecognized IP protocols, or if a local-in policy on the FortiGate itself blocks protocol 112 from the peer’s address, the backup will never see a hello and will eventually declare itself primary too, giving you two active masters answering ARP for the same IP. Confirm reachability with the sniffer command from the Verification section before assuming the VRRP config itself is wrong.

Spanning Tree can delay hellos enough to trigger a false failover. Fortinet’s own documentation calls this out directly: some switches with STP enabled delay forwarding VRRP advertisement packets during topology changes or port state transitions, and a backup router can decide the primary is gone even though nothing actually failed. If you see intermittent, unexplained failovers with no corresponding link or config event, check whether the switch ports facing both FortiGates have PortFast (or the equivalent edge-port setting) enabled, and consider extending start-time beyond the default of 3 seconds as a buffer.

vrgrp only synchronizes domains on the same chassis, it is not a peer-to-peer setting. It is easy to assume vrgrp needs to match between FGT-EDGE-A and FGT-EDGE-B the way VRID does, since both are small integers set inside a config vrrp block. It does not. vrgrp never goes out on the wire; it is a purely local instruction telling one FortiGate “if any VRRP instance sharing this group number steps down, step all of them down together.” Each box manages its own grouping independently.

There is no GUI, so configuration drift is invisible until you go looking for it. Because every VRRP setting lives only in the CLI, a change made by another engineer during an incident will not show up anywhere in Network > Interfaces. Bake show system interface <name> into your regular config audits for any interface running VRRP, the same way you would already audit static routes or firewall policies.