Pairing a FortiGate and FortiSwitch the Right Way, Part 1: Get the Firmware Right First

8 June 2026 FortinetFortiSwitchHomelabPython

I’ve got a FortiGate 70G and a FortiSwitch 124F sat on the bench in the home lab, and the plan was simple: rack them, cable the switch into the FortiGate over FortiLink, and have one pane of glass to manage both. It hasn’t gone that way yet. This is the first of a short series where I document the process we should have followed — based on what’s actually broken for us so far — before going back, factory-resetting both boxes, and running it properly on camera, so to speak.

This first part is entirely about groundwork: getting both devices onto compatible firmware, and making sure the two services that quietly underpin everything else — NTP and DNS — are solid before a single FortiLink cable goes in. Skipping this step is, with hindsight, exactly where our first attempt went wrong.

FortiLink isn’t just a cable and a checkbox. The FortiGate manages the FortiSwitch’s configuration, pushes firmware to it, and builds a CAPWAP tunnel to keep tabs on its state. All of that depends on the two devices agreeing on protocol versions, certificate validity, and — as I learned the hard way — having their clocks within spitting distance of each other. None of that is forgiving of a mismatched or ancient firmware build on either side.

Fortinet’s own guidance is blunt about this: don’t free-climb between major versions. Use the Upgrade Path Tool on the support portal, plug in your model, current version, and target, and it returns the shortest QA-tested path between the two — every hop validated, in order, no skipping. Each step in that chain has been through Fortinet’s own regression testing; jumping straight from, say, 7.0.x to 7.6.x on a FortiGate is asking for a bricked config parser or a failed boot.

Target: FortiOS / FortiSwitchOS 7.6.6 on both

We settled on 7.6.6 across the board — it’s the current GA branch for both product lines at time of writing, and Fortinet’s hard requirement that all Security Fabric members run the same major.minor when Security Fabric is enabled makes “match the versions” the path of least resistance long-term anyway.

FGT-70G-HUB # get system status
Version: FortiGate-70G v7.6.6,build3652,260127 (GA.M)

S124FNTF25001025 # get system status
Version: FortiSwitch-124F v7.6.6,build1137,251212 (GA)

That’s where both units sit now — but getting there looked very different for each box.

The FortiGate 70G: multiple hops, not one

The 70G didn’t ship anywhere near 7.6.6, and FortiOS upgrades are not a “download the latest and go” affair. The Upgrade Path Tool returned a multi-hop chain — several intermediate builds, each one a full upgrade-reboot-verify cycle before moving to the next. That’s the process to actually budget time for: this is an evening’s work, not a five-minute job, and every hop is a chance to discover that your config has something the new build doesn’t like.

The non-negotiables before each hop:

  • Back up the configuration and the license file. Not just the running config — the full backup, encrypted if you’ve got VPN PSKs or certificates in there.
  • Read that specific hop’s release notes, not just the target version’s. “Changes in default behaviour” sections matter — more on why in Part 2, where one specific behavioural change between 7.6.0 and 7.6.1 turns out to be the whole story.
  • Confirm the build before moving on. get system status after every reboot; don’t queue up the next image until the current one has settled and the unit is stable.

The FortiSwitch 124F: one hop, but don’t get complacent

The 124F’s path was simpler on paper — FortiSwitchOS 7.6.6 supports upgrading directly from 7.2.4 and later, so it’s a single hop rather than a chain. (The multi-step “go via 6.4.12 first” requirement that catches out some older FS-4xxE switches doesn’t apply here; that’s a 6.0.x/6.2.x-specific trap.)

“One hop” doesn’t mean “no thinking required,” though. A FortiSwitch that’s going to be FortiLink-managed can have its firmware pushed by the FortiGate once it’s adopted — which is part of why getting the FortiGate’s version right first matters. If the FortiGate doesn’t carry (or can’t fetch) a compatible FortiSwitch image, authorization can stall with the switch parked indefinitely in an unauthorized or “image download pending” state. Doing the FortiSwitch upgrade to a known-good, matching-major build before the FortiLink handshake removes that variable entirely — which is exactly the order we got wrong the first time around (more in Part 2).

The bit that actually bit us: NTP and DNS, before any of this

Here’s the part I’d skipped past mentally, filing it under “I’ll sort that out later” — and it’s the single biggest reason our pairing attempt stalled. Both devices need working time sync and name resolution before you start, not after.

Why it matters more than it looks like it should:

  • Certificate and licence validation is time-sensitive. FortiGuard checks, and the certificates FortiLink uses to build its management tunnel, both depend on the system clock being right. A FortiGate with a wildly wrong clock can fail FortiGuard contract checks and refuse to do things that look unrelated to time entirely.
  • FortiLink’s CAPWAP tunnel needs synced clocks on both ends. If the FortiSwitch’s clock has drifted from the FortiGate’s, the management tunnel either won’t establish or will silently drop, and the switch will sit there showing Offline in the GUI even while traffic keeps flowing through it untouched (which is its own kind of confusing — the switch works, it just won’t manage).
  • NTP often resolves by hostname, which means DNS has to actually work. If your NTP server is configured as an FQDN (Fortinet’s own pool addresses, or an internal server name) and the FortiGate’s DNS resolution is flaky — wrong forwarders, no route to the resolver, whatever — the clock silently fails to sync and you won’t get an obvious error pointing at DNS. You’ll get a switch that won’t come online and a “synced: yes” status that’s quietly lying to you.

The fix, done properly, before touching FortiLink:

  1. Confirm the FortiGate can resolve external names cleanly — execute ping <ntp-fqdn> or a quick diagnose test against your resolvers. Don’t assume; check.
  2. Configure NTP explicitly (don’t rely on defaults), verify with get system ntp status / diagnose sys ntp status, and confirm the offset is small and staying small, not just synced once and drifting.
  3. Make sure there’s an outbound firewall policy that actually permits NTP (UDP/123) from the FortiGate — and, once FortiLink is up, from the FortiLink subnet too. A default-deny policy on a fresh FortiGate will silently eat NTP traffic and you’ll be debugging a “switch offline” symptom that’s actually a one-line policy gap three layers down.
  4. Do the same sanity check on the FortiSwitch once it’s reachable — show system ntp / get system status — rather than assuming it inherits good time from the FortiGate automatically. (It mostly will, once FortiLink’s NTP relay is configured correctly — which is its own small configuration step I’ll cover properly in Part 2.)

What’s next

With both devices on 7.6.6 and NTP/DNS solid and verified — before the FortiLink cable goes in — Part 2 covers the actual pairing process: building the FortiLink interface, what auto-discovery ports do for you versus manual config, the authorization handshake, and the specific way ours went sideways (a default that changed under our feet between 7.6.0 and 7.6.1, plus the NTP gap above compounding it). I’ll also lay out the exact sequence I’m going to run when we factory-reset both units and go again — properly, this time, in the right order.