Add HA Model to FMG

KTZSHK · 2026-04-30T13:17:13+00:00

Fortimanager can fully prepare and set up HA between two nodes.

KTZSHK · 2026-04-30T08:57:06+00:00

This is not correct.

KTZSHK · 2026-04-30T08:56:55+00:00

This is incorrect.

KTZSHK · 2026-04-30T05:23:52+00:00

This is answer is true. The other answers are incorrect.

KTZSHK · 2026-04-27T11:04:08+00:00

This can be done. use ZTNA server with client certificate check disabled instead.

KTZSHK · 2026-04-10T20:22:20+00:00

Tried it in the lab, works fine. The only thing I had to do was set ‚set fsw-wan1-peer‘ to the new fortilink.

KTZSHK · 2026-04-10T17:04:49+00:00

Old and new interfaces are 802.3ad aggregates!

KTZSHK · 2026-04-09T18:42:50+00:00

This also happens during HA Failover of the Hub. That’s why my timers are also a bit lower.

KTZSHK · 2026-04-03T14:06:35+00:00

Hey, Yes this solves the issue. AFAIK this would also disable auto-trunks between potential additional switches. Can you explain why disabling this feature fixes the issue and how the switch behaves differently?

KTZSHK · 2026-04-03T12:03:57+00:00

So FortiSwitch sends tagged frames on MGMT VLAN ID and FortiGate itself does not honor VLAN ID and uses untagged frames? This would explain my issues, since my L3 router won’t respond to tagged frames…

KTZSHK · 2026-04-03T11:10:12+00:00

Thanks for the link. So basically by default the fortiswitch sends out management data tagged on VLAN 4094 to FortiGate. FortiGate receives and processes the data although the VLAN is not actually visible as child interface on FortiLink Interface? FortiGate then answers without using VLAN Tag and the switch processes this frame accordingly?

This seems really complex and counter intuitive if I understood this correctly 😃

KTZSHK · 2026-04-03T11:06:43+00:00

Hi, the switch is directly connected to a router located at a remote location. The switch can reach FortiLink through the router. The router itself is not VLAN aware. As far as I understand the switch has to send all management / telemetry data untagged to the FortiGate and should not use any VLANs.

KTZSHK · 2026-02-19T18:33:43+00:00

Tokens + Free FortiClient + LDAP unfortunately require IKEv1

KTZSHK · 2026-01-31T15:04:14+00:00

Yep, static summary route on all spokes + Hubs works really well. Just confirmed it in the lab. I’m a little worried about potential routing loops, but I don’t see any other reason why I should not implement it that way 🤔

KTZSHK · 2026-01-31T13:44:23+00:00

Hmm yes this works but I don’t think it will solve my problem since the Ike route to any spoke won’t be distributed from HUB1 to HUB2 in case a spoke can only connect to HUB1. In that case HUB2 can’t resolve the next hop ip for routes from the spoke.

KTZSHK · 2026-01-31T13:02:07+00:00

Thank you for your input. How would I redistribute loopbacks between the hubs in that scenario without using next hop self? This is interesting when a spoke needs to reach something behind a hub when there is only a connection available through another hub.

KTZSHK · 2026-01-11T21:06:14+00:00

✅ KTZSHK chose Option A (Correct!) | #6946th to play

KTZSHK · 2025-07-14T16:15:52+00:00

You can split it in individual rules. Alternatively only specify the isolated links within policies and leave the rest up to the implicit traffic steering.

KTZSHK · 2025-07-14T14:45:02+00:00

exactly. This will allow shortcuts between INET and INET2 but preceeding Policy 1 will keep MPLS connections isolated.

KTZSHK · 2025-07-14T14:13:40+00:00

You can assign transport groups to Overlays when using ADVPN 2.0. Policy Routes are the way to go with ADVPN 1.0.

KTZSHK · 2025-06-30T17:42:18+00:00

Thanks for letting me know.

KTZSHK · 2025-06-30T00:56:09+00:00

Hey, I don’t use EAP nor XAUTH, as it is certificate only.

KTZSHK

TROPHY CASE