Skip to main content
brandonziots
brandonziots
Explorer
February 16, 2026
Question

NAC Policy devices clearing out multiple times per day

  • February 16, 2026
  • 5 replies
  • 736 views

Hello all. Looking for anybody who has run into this issue and may be able to provide guidance.

We have a pair of FGT 70Gs running 7.4.9 connected to a stack of 148F FSWs running 7.2.5. This is our standard stack and we run it at dozens of sites.

We have NAC enabled via the built in managed FSW setting (not FortiNAC). We add devices via NAC policies individually and via wildcard filters such as Vendor name and device type (Example: IP Phone). Our switchports are configured in NAC mode and based on the device that plugs in, the dynamic VLAN will assign to what's configured in the NAC policy.

Anywhere from a couple to a few times a day, users with devices plugged into these NAC-mode switchports say their devices are doing network hard down, and then coming back up moments to minutes later. I checked logs and am seeing that the entire NAC MAC address cache appears to be deleted out and then added back, all at once but separated by short periods of time. This aligns exactly with when the issue was reported/experienced. Please see attached logs and configurations for reference.

Logs:

image (3).png

image (1).png

 

 NAC Config:

config user nac-policy
    edit "Cisco Phones"
        set type "IP Phone"
        set switch-fortilink "fortilink"
        set switch-mac-policy "Cisco Phones"
    next
end
 
config switch-controller mac-policy
    edit "Cisco Phones"
        set fortilink "fortilink"
        set vlan "Voice"
    next
end



I did also see this tip out there that may be related: https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Resolving-port-flapping-issues-when/ta-p/367000

image (4).png

 I haven't yet been able to determine why the NAC devices are being cleared out and re-added but it appears that the above fix couple help keep them while the root cause happens (STP event, flapping ports, etc?).

Any help is appreciated!

5 replies

Stephen_G
Moderator
Stephen_G
Moderator
February 19, 2026

Hello brandonziots,

 

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. 

 

If anybody else has any info or advice, please feel free to contribute!

Regards,
Stephen_G - Fortinet Community Team
Stephen_G
Moderator
Stephen_G
Moderator
February 23, 2026

Hello,

 

We are still looking for an answer to your question.

 

We will come back to you ASAP. If anyone else has any ideas in the meantime, please feel free to contribute!

Stephen_G - Fortinet Community Team
AEK
SuperUser
AEK
SuperUser
February 25, 2026

Hi Brandon

I couldn't find such known issues in FortiOS/FortiSwitch release notes.

Also I don't have a clear solution for your issue, but first thing I'd do in such situation is to update my devices to the recommended versions while ensuring that the compatibility matrix is ​​respected, at lease to minimize the probability that the issue is related to firmware bug.

I such case I'd try update FortiOS to 7.4.11 and FortiSwitch to 7.4.10.

AEK
brandonziots
brandonziotsAuthor
Explorer
March 11, 2026

Quick update here in case anybody is experiencing similar issues:
- Working with TAC we found a setting set inactive-timer <X> within config switch-controller fortilink. Raising this from the default 15 minutes to 60 minutes resolved our issue at 4/5 sites.

Regarding the single site that did not resolve:

- The issue is still occurring at least once a day.

- We did an upgrade on the FortiGate to 7.4.11. We have switch updates planned during our next maintenance window but unfortunately cannot spare the downtime until then.

- At this point the only thing that appears to align with the timing of the MAC Cache clears are wad and ipsmonitor flapping around the same interval, seen in the crash logs. Unfortunately TAC has not been able to determine if this is a cause or effect.
- I'm continuing to double the fortilink inactive timer (currently at 8 hours) but have yet to see this act as a permanent solution for this site.

- Still working with TAC on this but we're getting to the point of them gathering diagnostics and additional info to submit a case to the development team. 

I will provide another update as soon as we have a concrete solution.

Divil
Divil
New Member
March 23, 2026

Hi Brandon,

we suffer of same issue with same symptoms. Ticket with TAC has been created, but they unfortunately close it with conclusion there is no compatible topology (all FortiOS versions) with NAC policies.
https://docs.fortinet.com/document/fortiswitch/7.6.5/fortilink-guide/801182
Limitations:
The following limitations apply to FortiSwitch islands operating in FortiLink mode over a layer-3 network:
FortiSwitch NAC is not supported.
Our customer topology is Fortilink L3, but it was working on FortiOS 7.2.13 and FortiSwitchOS 7.6.4 and previous versions with no problem.
Unfortunately after upgrade to 7.4.11 we started suffer of same problem with same symptoms like you have. FortiSwitchOS is
version 7.6.6 so it is R version in compatibility matrix chart.
https://docs.fortinet.com/document/fortiswitch/7.6.6/fortilink-compatibility
We tried adjust switch-controller parameters, but it didn`t help to solve this issue:
switch-controller fortilink-settings
set inactive-timer 15 -> 480
link-down-flush enable -> disable

Our environment is 2x100F FGT and 4x148F FSW
Did you reach of some progress with TAC please?
I`m affraid, there is some kind o of change in FortiOS 7.4.x which has impact of this.

 

I will appreciate any answer.
Thank you!

Divil
Divil
New Member
May 7, 2026

We finaly resolved the issue.
There was a connection with periodic crashing of WAD process indeed as brandonziots mentioned in previous post.
The WAD process is engaged in FortiLink NAC mechanism and there was in configuration auto-script from the past which periodicly kills WAD process on previous version of FortiOS, because of high CPU consuption after some period of time.

config system auto-script
edit "restart_wad"
set interval 600
set repeat 0
set start auto
set script "diag test app wad 99"
next

Abacustech
Abacustech
New Member
April 9, 2026

Not sure if this will help anyone but these work-arounds worked for me, since trying the match-type-override option above did not work.

 

I have the same issue that cropped up only after upgrading from Fortigate 7.4.9 to 7.4.11. I am running On-board NAC on the fortigate. 

 

Fortigate 7.4.11/Fortiswitch 7.6.4/On-board NAC

Same NAC issue as posted caused port flapping but it would go on for up to 30 minutes on some ports. First few days it was only about a dozen same ports, then by day 8 it was all active NAC ports voice and computer, but only NAC ports. Always occurred all at once on multiple ports on multiple switches (always same switches but not all switches) about every 4-5 hours. It never effected printers that had individual NAC entries for MAC address matching, only grouping type policies. It effected forticlients that used EMS tags to onboard, and also effected devices like phones that did not use EMS but used Hardware Vendor matching only to onboard. Our onboarding starts in the onboarding VLAN then moves to a different VLAN upon match.

I tried TWO different/separate changes to two different NAC policies to see which would fix it and to my surprise, BOTH fixed the issue separately. 

 

FIRST SCENARIO OPTION:

  • On my Forticlient NAC policy that uses EMS tags to match the policy, I only changed the "Bounce Port" to disabled. That's it. It worked right away. Not one more issue. This will slow down the onboarding but not by much. You can expect up to 2 minutes to complete, but it's usually less than a minute.

 

SECOND SCENARIO OPTION:

  • We relay our DHCP to one of the AD servers. I wasn't sure if there was something there that may be triggering it as I recall reading something about it previously. So I wanted to take that out of the picture. So with the Voice NAC policy devices (do not use EMS for this policy at all), I moved the VLAN DHCP from Relaying to a separate server, to running DHCP directly on the Fortigate VLAN interface. All issues stopped on these devices as well immediately.

It's been several days and I haven't experienced any more issues with this particular problem.

Terms & ConditionsAccessibility statement