FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Raghu_Kumar
Staff
Staff
Article Id 220883
Description

This article describes steps to troubleshoot VRRP split brain, where both primary node and secondary node shows as 'Primary'. Given the VRRP configuration on both sides of the FortiGates are legitimate.

Scope FortiGate, all firmware
Solution

In normal working condition the secondary receives keep alive messages from the primary and it takes the master role when it stops receiving keep alive messages from the previous master.

 

VRRP split brain scenario, where both primary node and secondary node shows as up 'Primary' happens when there’s a communication problem happens between the two peers.

 

Following is an example case scenario of this problem:

 

JSY-ESP-VG-FG01(primary) 172.28.10.252---------VRRP------ 172.28.10.253 (Secondary)VG-LFO-FG01

 

Raghu_Kumar_0-1660568292053.png

 

Raghu_Kumar_1-1660568315212.png

 

Secondary node will stay as primary unless it receives announcement from primary node with a higher priority.

 

So, to see if proper communication is established on both sides, user must see if the multicast IP address of the other is seen by running the following sniffer on both FortiGates.

 

# diag sniffer packet any 'proto 112' 4 0 l

 

Primary FortiGate

 

Raghu_Kumar_2-1660568370613.png

 

Secondary FortiGate

 

Raghu_Kumar_3-1660568407613.png

 

In both outputs, primary and secondary is communicating with Multicast address in the first packet.

 

In such case first check the configuration part on both sides. Read more in VRRP failover - FortiGate 6.0.0 handbook.

 

Primary FortiGate:

 

Raghu_Kumar_4-1660568449750.png

 

Primary FortiGate:

 

Raghu_Kumar_5-1660568483622.png

 

In this case both the capture and configurations look fine.

 

Even so, the secondary FortiGate (172.28.10.253) shows up as 'Primary'.

 

Raghu_Kumar_6-1660568524290.png

 

In these cases, there are high chances that 'Local in' policy is in place set to 'deny' action, as shown below.

 

config firewall local-in-policy

    edit 7

      set uuid c20af8ea-fd36-51ec-d21e-65dc42ed530d

      set intf "any"

      set srcaddr "all" <----- Set to deny all access.

      set dstaddr "all"

      set service "ALL"

      set schedule "always"

    next

  end

 

'all' also includes multicast address.

 

If this Local in policy is a requirement for remote management, etc

 

Create a service for VRRP as shown below,

 

Raghu_Kumar_7-1660568578687.png

 

Once it is created the issue will be resolved and the secondary will show as secondary moving forward.

 

Note:

 

Local in policy needs a check only when VRRP on both sides of FortiGates are configured properly.