I have a site I am going to swap out a Meraki to a FortiGate and they current use the Windows 10 VPN client (L2TP over IPSec w/PSK) to connect to the Meraki with most users doing full tunnel, and a few doing split tunnel. The VPN client auth’s against a domain and they are accessing SMB shares over the VPN.
Would anything useful be gained by switching users to the FortiClient VPN-only (free option) vs. having them continue to use the native client in Windows?
I would go for ikev2/ipsec with native Windows 10 Client. Keeping the free Fortigate Client up to date can be a challenging tasks. It depends how many remote workers are there and also how tight Are there security rules within the company.
Forticlient has been giving us headaches mostly where as all of out Windows Native VPN IKEv2 Implementations have been running perfectly up until now.
Actually your losing some functionality when you go for FortiClient free version. Pre Logon VPN to name one.
Theres some stuff thats pretty neat when using FCT with SSLVPN but in my opinion its nothing that would makeup for the stability issues we’re seeing using it.
We have over 1000+ users with the forticlient free. Only issue we face (besides users locking their account) seems to stem around when forticlient has a fit with the NIC drivers. We get at least 2-3 tickets a week with a user and the NIC issue. If the users are mobile and travel (hotels, vendors office, cafe), then the SSL-VPN seems to work better. Many locations have IPSEC blocked for their networks.
I agree. If you do not have a need, why add another layer of complexity?
Didn’t think about, Pre-Logon VPN, that alone is a deal breaker compared to the Windows native client.
After looking at license costs for FortiClient VPN/ZTNA with FortiClient Cloud, that would be viable from a cost perspective to have Pre-Logon option, and would give me web filter at the endpoint, which would be an extra value add, but I am not liking the idea of introducing more support headaches from FortiClient if the Windows client would be just as reliable as it has been with the Meraki.
saml 2fa. As far as I know if you want to use saml based auth you must use forticlient.
We are mostly a mac shop and have scripted updating forticlient vpn via mdm. I think there’s a intune script somewhere on how to update it on windows.
Since you added the licensing into the mix: Also remember you will need an additional windows based server to run FortiClient EMS (the management component) if you want to use the licensed features.
Without EMS you can’t use the full featured FortiClient.
Also a dealbreaker for me. Another system that needs maintenance, support and expertise in windows server mgmt to be run securely.
If I were to go to a licensed option I would plan to go with the cloud hosted EMS (FortiClient Cloud), although there is existing server in place that could easily host an on-prem EMS, so either option is available. I’m not sure there is really going to be any benefit to go with paid client though.
Ah k. The price premium for cloud kind of scared me off of it.
As far as I can tell you wouldn’t gain much from EMS if you didn’t want to leverage ZTNA.
I know this is old, but to be clear: pre-logon VPN works with the free Forticlient at least up to 6.0.10.0297 which includes Always Up, Save Logon and AutoConnect, and is stable with Windows 11.
We use it across the company.
With all the critical CVEs FortiClient had in the past I wouldn’t recommend using 6.0.10 in any way. If you want anything like that still but dont want to pay for FortiClientEMS try OpenConnect VPN client. or GitHub - adrienverge/openfortivpn: Client for PPP+TLS VPN tunnel services
We’ve been using Fortinet and Forticlient for over 20 years and have not once had an issue with a Forticlient vulnerability whatsoever. FortiOS 6.0.10 - sure, but not the Forticlient itself.
With that said, anybody using SSLVPN is under a FAR greater threat than any Forticlient vulnerability, 50000x over. In fact, it’s even disabled by default now. Vendors just can’t secure it.
I would challenge anyone to exploit any of our users on 6.0.10.247 Forticlient without local access to the device and do something harmful to the device, OS or anything it’s connected to. There are FAR greater threats out there that actually have a chance of happening than someone exploiting a VPN client from 10 years ago. Oh, you can get it to delete a file the user can’t normally with local access to the actual device…bfd, you’re already sitting there, the entire device is compromised now. If you have that level of access, that’s the least of anyone’s concern.
Just because a CVE exists doesn’t mean you’re going to see it in the wild, most of these are found during audits, code reviews and challenges for bounty at university campuses. There are CVEs to care about and ones to say ok thanks for the heads up - *anything* pertaining to Forticlient itself is an “ok thanks, i know you now want me to upgrade again or go ZTNA. Got it”.
If you go the Forticlient CVE route, you’re going to have to check for and stay on the very latest, every single day. Entire generations of Forticlient have these vulnerabilities, but you never hear of anyone being compromised.
Strange, no?
I get what you’re saying, but of all the attack vectors on a Windows device, Forticlient would be the absolute last one anyone would care about. They’d be better off leaving it alone and trying to pass ransomware over the VPN it’s connected to than screwing with the Forticlient itself.
Here’s a list. Let me know which one we should care about, and why:
https://www.fortiguard.com/psirt?filter=1&product=FortiClientWindows&version=6.0.10&severity=4
Sorry, don’t mean to sound combative, but after being in this field for so long, it’s something that irks me when people upgrade just because a vendor says so and don’t fully understand why. This has long been a revenue-generation move in the tech sector, and with something so trivial as a VPN client, a lot of time and resources can be wasted on something that has no practical reason to be messed with. In fact, it can be argued all you’re doing is introducing more bugs that have yet to be discovered. I like my CVEs known, and thus don’t need to worry about a 0-day in a new release that’s been rushed out and tested like crap by some disgruntled intern who just looks for crashes and gives the green light to push if it doesnt. 
If thats the way you approach vulnerabilities on your managed devices you have much more to worry about than just the vulnerabilities.
Any vulnerability no matter how critical it seems on its own could potentially become a part of a sophisticated kill chain.
Also inside jobs are a thing.
But you do you.
That’s the thing - I manage vulnerabilities by the vulnerabilities themselves, you don’t patch everything just to patch. Well you can, but I would highly recommend against it. You patch what you are truly and functionally vulnerable against first and foremost.
Do you patch a home routers firmware because it fixes a vulnerability in a module you don’t even use, and isn’t active? Do you risk the update not breaking something else? I literally have a Netgear Nighthawk that I can’t login to because it’s web server didn’t restart properly after an update it didn’t need that my brother ran.
These things happen. Patching to patch is a fools errand, in my experience.
My methodology is quite successful as I have a 100% production uptime to report after over 25 years of running IT…not just working in IT, being in charge for 25 years.
I am extremely comfortable in the “threat” of being down, or compromised.
Backups aren’t the key - recovery is the key, and we do that *daily*. And its not through lack of trying - we block over 30,000 direct firewall hack attempts every single day, with about the same number of emails blocked.
I find a multi-faceted perimeter approach is far more successful than worrying about specific targets and software versions used on endpoints. Again, if you’re there on the machine already messing around with a Forticlient, the game is over.
We purposely send out ransomware payloads to our users. We purposely try to spear-phish their emails. We test and train for this stuff as a company.
We’re a public financial company, I am held to higher standards than most can possibly imagine, and we are audited *quarterly* by both internal AND external auditors. Every change is a process. It’s documented. It’s tested. *They’re also vetted for viability i.e. “why are we doing this in the first place?”*
There have been too many IT guys that came through here that are scared of their own shadows…too many to count. The fear of vulnerabilities equates to a fear of the repercussions of the vulnerabilities themselves, which normally manifests in one way: the inability to effectively restore or recover from any given threat. They can’t handle the pressure, talk a big game “yeah, I know esxi, ran a cluster, etc…” ok so I corrupt a VM and watch him squirm while he tries to recover it (with an also purposely corrupted backup) and they’re dead in the water. I hold my guys to a standard so high, more have left than stayed, and the ones who have stayed are the very best alive, I’d bet anything on that.
Sure, we rely on vendors like Fortinet to do their jobs, but they aren’t flawless. Support is sketchy (especially after US-hours), and their devices are quite complicated if you’re not literally trained to administer them, by them. Their IDS/UTM is great, but SSLVPN being deprecated despite them pushing it for decades tells you all you need to know. Talk about vulnerabilities, actually being exploited. I don’t like not having Fortigate expertise onsite, but I do trust the experts in the field who are experts and freelance, knowing support isn’t the greatest at times. Other times, you get a real pro at Fortinet. Unfortunately, it’s too hit-and-miss for my liking…and I can only imagine how the devs are. When the general consensus is to NOT upgrade after a Fortinet release, even for up to a year or more, that’s a problem.
Why would anyone want to run on that code unless you’re looking for specific features? They are *going* to break something, and it’s probably something you need.
For a *Forticlient*, this is a non-issue.
FortiOS is a different story.
Inside-jobs are a non-issue also (unless I’m the one doing it), we are protected from that as well.
Being audited by people who know what they’re doing lay waste to the mentality most IT people have with regards to this stuff.
We teach VMWare, Dell, MS support agents how to fix their own stuff. We were up when Azure, Google, META and AWS was down. Crowdstrike? Ransomware? Hello world, it’s us again, still up and ready for business…
We can pay for licensed Forticlients…but *why*? For the same vulnerabilities that affect the new versions as the old? Nah, it’s better to mitigate the device itself and it’s exposure than trust some vendors developer to code their shit properly - seen too many examples to the contrary. Hell, like I said, SSLVPN isn’t even secure and businesses have been using that as the defacto standard for so long, I wouldn’t listen to anybody running SSLVPN talking to me about security.
I generally don’t trust devs anymore, “they don’t code like they used to” is what I usually think based on what I see, and it’s only getting worse with AI “helping” half-assed devs write code they themselves don’t understand, but push out anyway.
Too much focus on pushing out updates, new features, products and piss-poor QA is what I see, mostly. Very rarely do I see focus on stability, core-functionality, optimization. Apps these days are kludged together to just get the income and they’ll “patch it later” to bring a product they actually released which should have still been in Beta, if not even Alpha. No thanks, I’ll stay back a while while your code is tested more thoroughly in production. MS updates? Those get applied one month after release, mostly. There is a very strong public testing program for those. We patch all the time, but there better be a good reason to do so.
But either way, yeah, I’ll do me all day long.