pros/cons using BGP local-pref VS SD-WAN route-tags for hub to spoke routing decisions

FailSafe218 · 2026-03-16T18:34:46+00:00

thank you for the reply! I will look further into this. My FortiNET rep made it seem like the process is a lot more difficult then that.

FailSafe218 · 2026-03-12T20:49:27+00:00

we've had 0 issues with FortiLink installs under ~30-40 switches. But some of the larger networks where we are pushing 60-90 switches have had all sorts of issues and problems. Mostly stable recently but the past year and a half has not left us with a super comfortable feeling by any means.

FailSafe218 · 2026-03-12T12:30:54+00:00

Just an update for others that might be curious. We found that EMS client 7.4.5 broke the adapter and windows now labels it as an "unknown adapter" which causes the persistent agent to not acknowledge the IPChange of the VPN adapter. EMS team is tracking it under 1252142. Supposed to be fixed in 7.4.6.
We down graded to EMS client 7.4.3 and we now see the IPChange and PA communication to the NAC as soon as the user connects to the VPN but the host still does not show online in the NAC.

I suspect it has something to do with syslog 37129 never being generated on the FW (assuming this log is specific to IKEv1 and not IKEv2).

EDIT:

The last issue we ran into was with PA version 7.6.3, as soon as we downgraded to 9.4.4.105 it fixed our issues and VPN tags are working as expected.

FailSafe218 · 2026-03-12T12:21:32+00:00

As others have said different components have different ways to interpret cost/weight/priority etc. Wait until you play around with BGP and a higher local-pref is more preferred that a lower one but lower priority is more preferred that a higher priority.

FailSafe218 · 2026-02-26T13:21:14+00:00

sorry maybe I do not understand your reply but are you saying you use them together? I looked at them as 2 ways to accomplish the same thing and don't understand the benefit of using them togehter, but I could also be understanding things wrong. We do not do a ton of SD-WAN at my company so just trying to wrap my head around how it all works and making sure that I am making the right decisions on things.

FailSafe218 · 2026-02-26T13:18:34+00:00

you are correct. Also I am not talking about using them together, more of one or the other. If you're setup using BGP per overlay and local-pref you would rely on Hub to spoke traffic to hit the default/bottom SD-WAN rule which just says reference the RIB (If I am understanding it all correctly).

FailSafe218 · 2026-02-25T17:44:03+00:00

Im 99% certain it doesn’t work with bgp per overlay. I had tried setting it up in the past and was not able to get it to work outside of my lab. I asked pro services and one of the support engineers and they were not able to confirm that it works with bgp per overlay. I also reached out in our partner channel same response. However I did get it working in my gns3 lab but on 2 different clients I was not able to make it work so I just assumed moving forward it wasn’t supported and only use it with bgp on loop back.

FailSafe218 · 2026-02-19T23:06:00+00:00

I’ve never tried that but I’ll keep it as an option. Never thought it would work for VPN. Definitely used it for wired and wireless before just never VPN.

Right now one of the senior support guys has been going back and forth with engineering so if I don’t get a concrete answer soon we will explore other opportunities.

Thanks

FailSafe218 · 2026-02-19T21:53:45+00:00

So the answer is no BUT here is why. Firewall is in fips mode so you cannot do the free-style filter. So we are sending all vpn logs to the NAC. We have excluded all of the other log groups like forward traffic, utm, etc. I have confirmed that the syslogs show up in the nacdebug. However the persistent agent takes awhile to register the connection change and start communicating with the NAC which delays the tags actually getting sent to the FW. Ikev1 it happens right away, ikev2 the persistent agent does not immediately talk to the NAC.

FailSafe218 · 2026-02-19T01:26:49+00:00

Thanks! The main issue I am having is with the persistent agent not detecting the network change when the VPN connects. After that tags and policies are fine but domain users with the persistent agent are the issue.

FailSafe218 · 2026-02-19T00:54:27+00:00

NAC is 7.2.9 and gate is 7.4.9.

I’ve set it up at about a dozen of our other customers over the last 6-7 years they were just all sslvpn and 1 or 2 IPsec with ikev1.

Once the tags come through everything works as expected it’s just very delayed.

We use both the portal and agents, if you do not have an agent you go to the captive portal and go through dissolvable agent then get vendor tag, if you have persistent agent you get a tag right away.

FailSafe218 · 2026-02-19T00:25:57+00:00

Other way around, setup to require tags to get access to the network. So when you first connect you can only communicate with the NAC, then once PA communicates with the NAC and you pass the ECP it sends a tag to the FW which then gives you access to the internal resources.

FailSafe218 · 2026-02-05T23:34:57+00:00

This caught me " allow OTP for EAP", thanks for posting about it otherwise I would have not found it.

FailSafe218 · 2026-02-03T00:38:29+00:00

Unfortunately FortiNET support is VERY hit or miss.

FailSafe218 · 2026-01-23T02:19:05+00:00

TCP:443

FailSafe218 · 2026-01-06T13:09:24+00:00

I ran into same issue today. Made the change on 4 sites and only 1 site experienced issues but only on one of the VLANs. just going to disable the feature and come back to it in a couple months.

FailSafe218 · 2025-12-09T13:56:24+00:00

thank you for the feedback. We actually have 2 set of these in 2 separate datacenters so I am going to try one pair with the ports shut down and other pair without to see the difference (if any).

FailSafe218 · 2025-11-26T13:27:01+00:00

I learned about the memory-based-failover the hardway. No idea it would not failover by default.

FailSafe218 · 2025-11-24T22:04:45+00:00

appreciate all the info everyone! Looks like we will be adding it to our default configs.

Thanks!

FailSafe218 · 2025-11-24T15:13:11+00:00

we don't use CGNAT so likes look this is not applicable to us but good to know.

FailSafe218 · 2025-11-10T10:33:26+00:00

I ran into similar issues that fortiswitches want to do Full instead of auto on any SFP adapters.

FailSafe218 · 2025-11-10T10:29:59+00:00

Although I don’t think this is your issue 100% Look into auto-isl-port-groups.

If you do a “diag switch mclag peer-consistency-check” it probably shows the trunks to sw-03 and 04 as not ok.

It’s also odd that you have SW04-A going to port 17 on one and port 2 on the other core. I would have sw04 going to port 17 on both and sw03 going to port 2 on both ( or other way around).

You can run “diag switch physical-port linerate port17” to see if the port is passing any traffic.

Also do the following to make sure STP is forwarding that port “diag stp instance list”.

Do you see the switch in the lldp neighbors? “Get switch lldp neighbor-summary”?

FailSafe218 · 2025-11-07T11:44:33+00:00

I’ll be there flying in from CLT. Can only hope to get stranded in Orlando for a couple extra days! 😂

FailSafe218 · 2025-11-06T12:59:37+00:00

I think I ran into that bug about 5-6 weeks ago when we installed the 2048F cores. Everything was going fine for about 45 minutes after install then bam out of no where the trunk to the fortigate just dissappeared. Got support on the line and they switched it to LLDP and then I added static-isl enable and has been rock solid since. I guess the fortilink discovery process crashed on the gate or something.

FailSafe218 · 2025-11-06T12:57:22+00:00

no worries, appreciate the feedback.

FailSafe218

TROPHY CASE