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
Description

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

Scope FortiGate, all firmware
Solution

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

 

VRRP split brain scenario, where both master node and slave node shows as up 'Master' 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(Master) 172.28.10.252---------VRRP------ 172.28.10.253 (Slave)VG-LFO-FG01

 

Raghu_Kumar_0-1660568292053.png

 

Raghu_Kumar_1-1660568315212.png

 

Slave node will stay as master unless it receives announcement from master 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, Master and Slave is communicating with Multicast address In the first packet.

 

In such case first check the configuration part on both sides as per the following document.

 

https://docs.fortinet.com/document/fortigate/6.0.0/handbook/826177/vrrp-failover

 

Master

 

Raghu_Kumar_4-1660568449750.png

 

Slave

 

Raghu_Kumar_5-1660568483622.png

 

In this case both the capture and configuration look’s fine.

 

But still, Slave FortiGate (172.28.10.253) shows up as ‘Master’

 

Raghu_Kumar_6-1660568524290.png

 

In such exceptional case, there are high chances that 'Local in' policy is in place set to 'deny' action as in this case 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 Slave moving forward.

 

Note:

 

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

Contributors