ISP Uplink through FortiSwitch

I know why but you need to wait somebody else to provide you the best option for you. Only I can think of is don't use FortiLink but make those FSWs standalone.

The reason is all VLANs you create on FGT-managed FSWs have to come over FortiLink interface (automatic. You can see them in GUI interface page). And, those VLANs on the FortiLink don't have L2 connections to the same VLAN ID you have on other FGT ports like WAN1, in your case.

I want to know the answer from FTNT staff as well. I was thinking to do the same for our customers but I need to wait for an answer.

Toshi

Update: Toshi called me out, indicating this solution does not satisfy the OP since it uses two FortiLinks and requires extra switches, which was what I was trying to avoid when I originally posted the OP 2 years ago. Every argument against doing this was specific to running ISP links over FortiLink, and the guide I'm referencing below seems to end that argument. This is what I am trying to clarify, so AI's like ChatGPT don't tell people "it's not supported, configure your switches as standalone"

I got into an argument with ChatGPT this week, because I recalled reading about this exact setup and asked it to find the guide. It kept telling me this is not a recommended configuration and to do it differently, so I asked it to point me to the Fortinet published articles that state this is not a recommended setup, and it became clear this very thread is one it was citing. 

For anyone that comes across this forum post, this is a supported configuration, the section pasted below comes from the FortiSwitch 7.4.2 FortiLink Guide.  Granted, they're showing a second FortiLink, but the overall concept remains. 

I am seeing issues with this topology for lower end switches where MCLAG is not a supported feature and LACP is used to create the agg. Is it reasonable to recommend standalone switches when the MCLAG feature is not available? Our experience has been poor ARP and MAC relearning after failover or ISP related events. By passing to the switches is always an immediate fix, but given enough time or stack reboot, things come back. 

Toshi is essentially right, and this thread mostly lands in the right place, but everyone talks past the actual mechanism, the OP wins a point he shouldn't, and the 2026 reply from sckripts is the most valuable thing in the whole thread. Let me lay it out cleanly.

The root cause is concrete, not a vibe. On a FortiLink-managed FortiSwitch, every VLAN you define on the switch is automatically trunked back to the FortiGate over the FortiLink. So in the OP's design, VLAN 100 (the ISP transit) is mapped to the ISP port and to the port cabled to physical WAN1, but it is also, automatically, present on the FortiLink uplink to the same FortiGate. The FortiGate is now L2-reachable on VLAN 100 by two paths: the FortiLink trunk and the physical WAN1 cable. The FortiGate doesn't bridge them so there's no loop, but the FortiSwitch's MAC table now sees the FortiGate's MAC on VLAN 100 arriving from two ports, and it flaps or resolves to the wrong one. When the ISP CPE ARPs for the gateway, the reply gets delivered toward the FortiLink instead of out the port to WAN1, and the ISP "can't talk" to the WAN. It's brand-specific because it depends on how aggressively the particular CPE does ARP / gratuitous ARP, which decides whether the flap manifests. "Putting the Aruba back fixes it" because a standalone Aruba does not auto-extend that VLAN back to the FortiGate over a managed uplink, so there's only one L2 path and no ambiguity.

The OP's "it's supported per the 7.4.2 guide" is half right, and Toshi's correction stands. Carrying WAN over FortiLink-managed switches is documented, but the guide topology is two separate FortiLinks with two separate FortiSwitch clusters, one for WAN and one for LAN. The OP is running one FortiLink and one cluster carrying both. Those are different designs, and the difference is exactly the thing that causes the failure. The OP cited a real document for a topology he isn't running.

The colleague's "why trust FortiLink VLANs for LAN but not WAN" argument is a category error, and it's worth saying so plainly. The objection to this design was never about trust or security. Internal user VLANs don't break because they aren't simultaneously hairpinned back out a physical FortiGate port carrying the same VLAN, and they aren't exposed to an external CPE's ARP quirks. So "we trust it for sensitive internal segmentation" is irrelevant to the failure mode. The OP is right that a blanket "WAN over FortiLink is unsupported" is too crude, but he's drawing the wrong conclusion from it.

sckripts' 2026 reply is the key practical rule and confirms the mechanism. Without MCLAG, the FortiSwitch pair is joined to the HA cluster via plain LACP, and there's no inter-switch MAC sync. So when the FortiGate HA virtual MAC moves on failover, or the ISP bounces, MAC and ARP relearning across the managed pair is unreliable, which is exactly the "poor ARP/MAC relearning, bypass fixes it immediately, recurs after time or reboot" pattern he describes. The answer to his question is yes: on switches without MCLAG, terminating WAN through the FortiLink-managed pair is fragile, and standalone or bypass is the reasonable call. With MCLAG-capable switches and MCLAG actually configured, the virtual-MAC move is handled and the relearn is clean. The LACP-without-MCLAG arrangement is the worst of both worlds.

Practical recommendation, ranked, and accounting for the OP's real constraint:

1. When port count allows, terminate the ISP directly on the FortiGate physical WAN ports and keep it off the managed switch entirely. Cleanest, no hairpin, no MAC ambiguity.
2. If you must switch the WAN and you have MCLAG-capable FortiSwitches, configure MCLAG properly. That removes the relearning problem sckripts is hitting.
3. If you want it on the managed fabric without a physical WAN port, terminate the WAN subnet on the FortiLink VLAN interface (the SVI), as the OP did at site 1. One L2 path, no ambiguity.
4. The guide's two-FortiLink / separate-cluster model is the officially blessed managed-switch way, but as Toshi says, nobody wants dedicated switches just for ISP termination, so it's rarely practical.

For the specific site with hundreds of IPsec tunnels and policies bound to physical wan1: don't re-home to a VLAN interface, that migration is the trap. Instead take that one WAN circuit off the FortiLink-managed switch path, either straight into wan1 or through a dumb/standalone switch for the handoff, and leave wan1 and every tunnel and policy binding untouched. You solve the L2 problem without touching the config that scares you.