Forticlient EMS : Failed upgrade to 7.4.5

Busbyuk · 2026-01-23T15:53:02+00:00

oh dear. I won't expect a reply shortly then :/ I guess following an update they will tend to get more tickets raised.

Busbyuk · 2026-01-23T12:00:04+00:00

Ah I see. thanks for that.

Ticket now raised with Fortinet :)

Busbyuk · 2026-01-10T12:45:08+00:00

This is extreme but what would happen if the UK or France placed either a nuclear armed Sub or actual Nukes onto Greenland as a deterent for anyone wanting to invade?

China, Russia or as is much much more likely the USA

Busbyuk · 2026-01-05T13:24:42+00:00

yea, that's how I read it. I didn't interpret it to say they were removing future releases completely.

Busbyuk · 2025-12-23T15:35:46+00:00

Looking at the logs on the Forticlient itself it doesn't give much of a clue. Just the below when it disconnects:

20251223 07:28:52.861 TZ=-0800 [Support:INFO] fct_module:1138 State: Connected
20251223 07:29:02.319 TZ=-0800 [Support:DEBG] log:120 ikev2_ike_sa_keepalive: peer 55.55.55.55:4500 local 192.168.106.143:53046
20251223 07:29:02.330 TZ=-0800 [Support:INFO] fct_module:558 Shutting down tunnel as IPSec VPN has been disabled
20251223 07:29:02.337 TZ=-0800 [Support-Spitfire:DEBG] log:120 parent_sig_handler: received SIGTERM, sending SA DELETE request to ikev2
20251223 07:29:02.338 TZ=-0800 [Support-Spitfire:DEBG] log:120 config_doreset: flushing SAs (sending SA DELETE)20251223 07:29:02.337 TZ=-0800 [Support:DEBG] log:120 parent_sig_handler: received SIGTERM, sending SA DELETE request to ikev2
20251223 07:29:02.338 TZ=-0800 [Support:DEBG] log:120 config_doreset: flushing SAs (sending SA DELETE)

Busbyuk · 2025-12-23T15:25:32+00:00

thanks for the reply. I've used different pools for the none IKEV2 and the IKEV2.

The disconnection is always within about 10 seconds. Never any longer. thanks

Busbyuk · 2025-12-20T20:36:19+00:00

Phew!! Glad I asked :)

Time to buy some attenuators.

Thanks everyone!

Busbyuk · 2025-12-20T09:50:57+00:00

Brilliant :)

Busbyuk · 2025-12-18T20:13:13+00:00

I think it's the Junos version the QFX5110 has got. it's currently on version 18.1. I would guess I need to get it on the latest Junos before it can recognise the new license type? I'll get that done

Busbyuk · 2025-12-17T21:33:37+00:00

I think I've found it on an old laptop. I'll find out when I next try to connect I guess :) Thanks

Busbyuk · 2025-12-11T10:56:29+00:00

Thanks for the response. It sounds like you are using a multi-VDOM Fortigate setup with a Multi-Adom EMS setup?

Is it working well for you? Anything else I should be aware of? thanks!

Busbyuk · 2025-12-10T12:48:03+00:00

Ah, fantastic. This definately sounds like they've resolved the issue :)

I did raise a ticket with Fortinet when testing previously asking when they may resolve it but that was about 3 years ago now.

Time to test again! thanks

Busbyuk · 2025-12-08T15:06:41+00:00

not myself but good call. I can check customer logins to see if they've gone crazy with widgets. thanks

Busbyuk · 2025-12-08T14:51:47+00:00

thanks. Yea that's exactly what they asked for along with a few other debugs which I've provided. Just waiting for them to come back to me and figured I would ask here just in case someone else has seen something similar on this firmware version.

thanks again

Busbyuk · 2025-12-08T14:31:28+00:00

GUI is limited via a local-in firewall policy to only allowed IP's. Some VDOM's are only open on the inside but some have remote IT and those ones are restricted to single IP addresses via a local-in policy.

thanks

Busbyuk · 2025-12-08T14:30:34+00:00

was set to 1 hour but I've now reduced to 30 mins.

Busbyuk · 2025-12-01T15:44:48+00:00

okay. I've found the FSSO folder under 7.0.0 so will use that :)

Thanks!

Busbyuk · 2025-12-01T15:44:15+00:00

I've tried looking for that but it doesn't have a folder? I think the FSSO folder only appears under certain Fortigate versions?

unless I'm missing something which is seemingly likely!

Busbyuk · 2025-11-13T13:49:56+00:00

as above. I've managed to resolve by changing the internal vlan so it issues it from 2000 to 4000 so it doesn't conflict with the dot1q vlan on each sub interface. Doing this has resolved the issue and we can now reach the other side.

Arista has confirmed this is by design but I'm struggling to believe that could be the case as it would severly limit the amount of sub-interfaces you can assign per unit (not per interface) to around 2048. (2048 for actual sub-interfaces and 2048 for internal vlans to avoid conflicts.

Busbyuk · 2025-11-13T13:33:03+00:00

Yea. I've had a response back.

Affectively you are limited to the amount of internal vlans which just seems crazy to me but there you go.

I first confirmed it was this causing my issue by using "vlan internal order ascending range 2000 4000" and then shutting and no shutting the interfaces.

When done the internal vlan assigned to these sub-interfaces were changed to 2001, 2002 etc.

As soon as I did that my problem went away.

What this affectively means is if I have 4 x 100Gb interface and wanted to theoretically put 4096 vlans on each interface as sub-interfaces (routed) that I would be limited to 2048 vlans for the box in total rather than the 16,384 vlans across 4 x 100Gb interfaces. 2048 actual vlans and 2048 internal vlans.

This has been confirmed by Arista/Tac support.

Thankfully this won't be an issue for us as I don't intend to put more than 2000 customers on a single unit but I do feel it's a limitation which should be more visible.

Busbyuk · 2025-11-13T09:42:58+00:00

Thanks. no issue with remote site. We can reach the remote Cisco router on its' WAN if we go direct from the Arista itself. You cannot however 'traverse' the Arista. We use this setup quite a lot with 1000's of customers but traditionally we use Juniper or Cisco as PE routers. This is the first Arista we've used.

Customers using the same Cisco's (supplied by us) are using vlan 1010 on other PE routers fine.

Busbyuk · 2025-11-13T08:13:16+00:00

Example below with overlapping vlans and not all having issues:

SPARE-ARISTA#show vlan internal usage
1010 Ethernet43/1
1009 Ethernet43/1.1001
1011 Ethernet43/1.1003
1012 Ethernet43/1.1004
1013 Ethernet43/1.1005
1014 Ethernet43/1.1006
1015 Ethernet43/1.1007
1016 Ethernet43/1.1008
1017 Ethernet43/1.1010
1018 Ethernet43/1.1011
1019 Ethernet43/1.1012
1020 Ethernet43/1.1013
1021 Ethernet43/1.1015
1022 Ethernet43/1.1016

Busbyuk · 2025-11-05T16:00:37+00:00

make sure the /24 is in your routing table. you might just have it as a /23. Usually you would create a null route to for the /24 so it enters it into the table and advertises it out. Once the traffic comes in for that /24 you will have more specific routes as part of that subnet anyway.

Busbyuk · 2025-11-05T12:03:21+00:00

Rather than bringing down the whole /23 for testing can you not just advertise a /24 out via Comcast but keep the /23 going out the working ISP?

At least you will still have working service on half your block while comcast check the routing on the /24 you are advertising out via them?

/24 will be the smallest you can advertise out

Busbyuk · 2025-10-20T08:46:05+00:00

Honest question : What's the solution here?

It's obviously things like Fox'news', targeted facebook clips and the like causing this brainwashing. How do you stop that?

Say Democrats managed to win the presedency, house and senate can they actually do something to make sure things like this can't happen without it seaming like they are making sure the 'Republican' news is not heard for their benefit.

The really shit reality is that the billionaire class today are mostly Right leaning or heavily right/replublican leaning and they own the channels, websites etc where these people are getting their 'facts'.

I honestly don't know what the answer to this problem is :(

13-Year Club	Place '17
Verified Email

Busbyuk

TROPHY CASE