Skip to main content
sj3fk3
sj3fk3
Visitor III
February 26, 2026
Solved

Fortigate HA Failover issue with clients connected to vlan with intra-vlan-blocking enabled

  • February 26, 2026
  • 4 replies
  • 265 views

The issue:

Clients connected to a vlan with Block intra-VLAN enabled can't reach the FortiGate for around 2 minutes and 30 seconds after failover. Clients connected to a vlan with no Block intra-VLAN enabled do not have this issue.


All switches are managed by the Fortigate.


Topology:

2 X Fortigate 601F in HA A/P

2 X Core switches FortiSwitch 1024E in MCLAG

2 X FSR-216F-POE connected in a ring to the MCLAG switches. So, the first switch connects to the first 1024E switch and the second connects to the second 1024E switch with a link between the two FSR-216F-POE switches. (We can't change this because of the physical fibers)


I have tested with two clients connected to the same switch. Client A connected to port 1 on a vlan with intra-vlan blocking enabled, and Client B connected to port 2 on a vlan with intra-vlan blocking disabled.


Client A was having issues after the failover and could not reach the Fortigate for around 2 minutes and 30 seconds. Client B does not have any problems. It looses one ping after failover and works fine.


I have a support case open now for around 3 months. I still have no solution or information to work with.

Can somebody help me here?


Support confirmed all physical cabling and MCLAG configuration is all completely fine. No spanning-tree issues or anything.

 

FortiGates are running 7.4.9 and FortiSwitches are running 7.6.4

Best answer by sj3fk3

Tested in 8.0.0 and is now resolved. 

Resolved bug id: 

1269523

Traffic loss occurs when the secondary FortiGate is rebooted in HA A/P mode

4 replies

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 2, 2026

Hello sj3fk3, 

 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 3, 2026

Hello,

 

We are still looking for an answer to your question.

 

We will come back to you ASAP.

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 4, 2026

Hello again sj3fk3,

 

I found this answer, can you tell us if it helps, please?

 

Issue Analysis

The issue you're experiencing seems to be related to the configuration of intra-VLAN traffic blocking on your FortiGate and FortiSwitch setup. When intra-VLAN traffic blocking is enabled, all traffic between devices in the same VLAN is forced to route through the FortiGate, which allows for security inspection and policy enforcement. However, this can introduce delays during failover scenarios, as the FortiGate needs to re-establish connections and apply policies.

 

Possible Causes

  1. Failover Delay: The delay in reaching the FortiGate after failover could be due to the time it takes for the FortiGate to re-establish the routing and firewall policies for intra-VLAN traffic.

  2. Proxy ARP Configuration: If proxy ARP is not configured correctly, it might cause delays in traffic routing during failover.

  3. Firewall Policy Configuration: Ensure that the firewall policies are correctly configured to allow traffic between the same VLAN interfaces.

  4. Switch Configuration: Although support confirmed the MCLAG and physical cabling are fine, ensure that the FortiSwitch configuration aligns with the FortiGate settings, especially regarding VLAN and intra-VLAN traffic settings.

 

Recommendations

  1. Review Proxy ARP Settings: Ensure that proxy ARP is configured correctly for the VLANs with intra-VLAN blocking enabled. This can help in faster resolution of ARP requests during failover.

  2. Check Firewall Policies: Verify that the firewall policies on the FortiGate are correctly set up to allow traffic between the same VLAN interfaces. This includes ensuring that the policies are active and correctly prioritized.

  3. Monitor Failover Process: Use logging and monitoring tools to observe the failover process and identify any specific delays or errors that occur when the failover happens.

  4. Firmware Updates: Ensure that both FortiGate and FortiSwitch are running the latest stable firmware versions. Sometimes, upgrading to a newer version can resolve known issues.

  5. Consult Release Notes: Check the release notes for FortiOS 7.4.9 and FortiSwitch 7.6.4 for any known issues or fixes related to HA failover and intra-VLAN traffic blocking.

 

Follow-ups and Clarification Questions

  • Proxy ARP Configuration: Have you verified the proxy ARP settings for the VLANs with intra-VLAN blocking enabled?
  • Firewall Policy Details: Can you provide details on the firewall policies configured for the VLANs with intra-VLAN blocking?
  • Monitoring Tools: Are you using any specific tools to monitor the failover process and identify delays?
  • Firmware Version Confirmation: Can you confirm if there are any available updates beyond FortiOS 7.4.9 and FortiSwitch 7.6.4 that might address this issue?

If these steps do not resolve the issue, it may be beneficial to continue working with Fortinet support to further investigate the problem.

Jean-Philippe - Fortinet Community Team
sj3fk3
sj3fk3Author
Visitor III
March 27, 2026

Hi Jean-Philippe_P,

 

After taking captures and doing some port mirroring I found out that the secondary fortigate is sending out an ARP annoucement before it's rebooting.

 

I showed the issue to Bill Hoang from Fortinet over a remote session and he was able to reproduce the issue in the lab. The Engineering team found out the root cause and they are working now on a fix. the recommended workaround is to increase the value of hb‑lost‑threshold to around 30. (Default is 6)

After the workaround I don't see the ARP annoucements anymore and my failover is now working a lot better. Only taking around 7 seconds because the treshold is increased. But this is expected. They are still working on the final fix. 

I did not received any more information if this is only applicable to the 601F FortiGate or also other models. I'm also not sure which versions are impacted. But at least 7.4.7, 7.4.8, 7.4.9, 7.4.11 and 7.6.6 which I'm running now. 


I don't have any bug id yet.

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 27, 2026

Hello again!

 

I found that answer for you:

 

 

Issue Summary

You have identified an issue where the secondary FortiGate is sending out an ARP announcement before rebooting, which affects failover performance. This issue was confirmed by Fortinet's Bill Hoang, and the engineering team is working on a fix.

 

Workaround

The recommended workaround is to increase the hb-lost-threshold value to around 30 (default is 6). This adjustment has improved failover performance, reducing the time to approximately 7 seconds, which is expected due to the increased threshold.

 

Impacted Versions

You mentioned that the issue affects at least the following FortiOS versions:

  • 7.4.7
  • 7.4.8
  • 7.4.9
  • 7.4.11
  • 7.6.6

 

Uncertainties

  • Model Specificity: It is unclear if this issue is specific to the FortiGate 601F model or if it affects other models as well.
  • Bug ID: No bug ID has been provided yet for tracking this issue.

 

Follow-Up and Clarification Questions

  1. Model Specificity: Have you received any updates on whether this issue affects models other than the FortiGate 601F?
  2. Further Updates: Are there any additional updates or timelines provided by Fortinet regarding the final fix for this issue?

If you have further questions or need additional assistance, please feel free to ask.

Jean-Philippe - Fortinet Community Team
sj3fk3
sj3fk3AuthorAnswer
Visitor III
May 12, 2026

Tested in 8.0.0 and is now resolved. 

Resolved bug id: 

1269523

Traffic loss occurs when the secondary FortiGate is rebooted in HA A/P mode
Terms & ConditionsAccessibility statement