Alright team, I'm coming to you with a bit of a story and a request for your collective wisdom. 😅 We just rolled out FortiGate firewalls across three retail locations and our small HQ, aiming to get better visibility, segmentation (think PCI compliance for those POS systems!), and a solid VPN mesh.
On paper, it was perfect! In practice... we hit a few snags that I wish we'd anticipated. Sharing here so you can learn from our "experience."
**What we planned:**
* HQ (100F) as the hub, three stores (each 60F) as spokes.
* SD-WAN for dynamic path selection (MPLS + broadband at each site).
* Separate VLANs for registers, guest WiFi, back-office, and security cameras.
* Full mesh IPsec VPNs between all sites.
**Where things got... interesting:**
* **The "seamless" mesh VPN** was our first headache. Getting the spoke-to-spoke tunnels to form reliably took way more manual config than expected. We had to carefully manage the phase 1 and phase 2 proposals. A template would have been a lifesaver here!
* **SD-WAN + VoIP = weird jitter.** Performance SLAs looked good, but our store phones had intermittent issues. Turns out, the default traffic shaping and SD-WAN health-check sensitivity needed fine-tuning for those tiny, constant UDP packets. We learned to create a dedicated SD-WAN rule for VoIP, steering it primarily over MPLS.
* **A firmware surprise.** We standardized on one version for the rollout, but a critical bug fix for an IPsec issue we encountered was only in a later version. We had to scramble to update post-deployment, which wasn't in the change window. Lesson: check the release notes for your *specific* features *right* before go-live.
* **The "set" vs "config" confusion.** Our team was used to another vendor's CLI. The FortiGate's dual configuration modes (set commands within `config` sections) tripped us up a few times in early scripts. Not a deal-breaker, but a pacing issue.
It's all running smoothly now, but the deployment phase was more of a scramble than our agile retrospectives prefer! Has anyone else navigated a similar multi-site retail setup? I'd love to compare notes on your health metrics for monitoring these distributed boxes and any templates you swear by for consistent site-by-site deployment.
🌻 fiona
null
Oh, the mesh VPN setup is a classic. I've been there. The advertised "auto-mesh" features often need a very specific configuration handshake to work without manual babysitting.
For the SD-WAN and VoIP jitter, did you check if the performance SLA probes were using the same DSCP markings as your voice traffic? The default "best-effort" probes can show a clean path, while your EF-marked voice packets take a different, congested route. Setting up explicit SLA targets for your VoIP VLAN might be needed.
The traffic shaping defaults are definitely not voice-friendly. You usually need to create a specific shaping policy that prioritizes your voice VLAN and guarantees minimum bandwidth.
Keep automating!
You're spot on about the DSCP mismatch for probes. We saw the same thing with our call center traffic. The default "HTTP" SLA target doesn't honor EF, so the SD-WAN algorithm picks a path based on latency for best-effort traffic, not voice.
One more layer: even with correct DSCP on the probes, you might need to adjust the `diffservcode` field in the SD-WAN performance SLA configuration itself. It's easy to miss. If that's not set, the FortiGate won't mark the outgoing probe packets correctly, and your ISP might still route them differently.
The automatic VPN mesh can be a significant time sink if you don't pre-stage the spoke configurations identically. A subtle difference, like a mismatched IKE version or dead peer detection setting on just one spoke, will break the full mesh topology.
Your point about explicit SLA targets for VoIP is crucial. The default traffic shaping profile also applies a hard cap that can starve voice traffic if not adjusted. You need to create a guaranteed-bandwidth shaper, reference it in a policy for the voice VLAN, and then ensure that same policy is ordered above any general internet traffic rules.
null
Absolutely, those subtle differences in the spoke configs can completely derail a mesh setup. I learned this the hard way too, when a single spoke had a slightly different IPsec proposal order, inherited from a previous test config. The hub would connect, but that one spoke couldn't talk to any of the others, breaking the whole mesh.
Your reminder about policy order for the shaping rule is so important. It's easy to create that perfect guaranteed-bandwidth shaper, apply it to your voice policy, then watch it do nothing because a catch-all policy for guest Wi-Fi is sitting above it and eating all the bandwidth first. A quick reorder in the policy list is often the fix.
hannah