My story on FortiEMS & FortiClient

My customer’s main VPN system uses SSLVPN with FortiClient. There are around 1.5k simultaneous users on a daily bases and everything works flawlessly. The FortiGate is a 600E so it packs more than enough in order to deal with all the users.

As for features we don’t use a ton, FortiClient only has the VPN module activated (some with FSSO as well), in the SSLVPN configuration the only a bit uncommon thing is that we perform a Certificate pre-authentication.

It all started with version 6.0 three years ago now all FG, FortiEMS & FortiClient are on 6.4, latest firmware/app version. Now we are looking to upgrade to 7.0 and use SAML authentication with AzureAD.

The SSLVPN solution got us through the COVID crisis and got heavily used and is still heavily used right now as the company policies towards home working evolved as well.

My customer has some 24/7 activities and overall the SLA have been outstanding for this service. Outages on the VPN service happened but they were unrelated to the FortiGate / FortiClient / FortiEMS.

This is so far a success story for my customer !

On the other side, I’m quite unhappy with the product (FortiEMS & FortiClient) and this is the other side of the story:

My first rant is that FortiEMS is now needed. Before FortiEMS (version 6.0) I happily used the free version of FortiClient as we only needed SSLVPN. I knew it came with no support and I was quite happy with how I was able to generate the msi with the SSLVPN configuration imbedded inside. It was a very cost effective VPN solution with minimal effort.

I had to convince my customer that starting from 6.2 they had to pay for FortiEMS, which, gave them more features and access to support for FortiClients problems, that were previously dealt internally.

No features were needed as they already had other products for antivirus/malware, web filtering and so on. Partly because, those features were not even wanted to begin with, my customer only needed a VPN solution. Partly because of large organization segregations of responsibilities: the network team had to provide a VPN solution and nothing more, not an antivirus,antimalware one, and the other teams weren’t keen to try out a product that was pushed forward from the network team… In the end, FortiEMS is only used to generate msi packages…

My second rant is about the support with FortiClient issues. Now that there is a license for FortiClients/FortiEMS I’m able to create cases. Oh boy what a bad experience so far. Fortinet’s support, is in my opinion quite descent compared to other brands I know of. But when dealing with FortiClients… that’s another story.

I would consider the support on FortiClient cases to be the worst experience I had with Fortinet’s support.

> Issue with certificate pre-auth after upgrading Win 10 1909 to 21h2 > just figure it out yourself: 4 cases, 2 of them still open, 1 of them has a “bug fixing” status but I suppose it is that way because I demanded escalation too many times and thus, they just gave up and put that into some random bug. In the end, it seems to be related to the TPM chip on certain devices with FortiClient not being able to get the private key of the certificate with Microsoft TPM crypto provider…

>>> I agree that this case is not directly related to FortiClient but it infuriates me that clues were only partially provided and to get those I had to insist multiple times and ask escalations.

>>> Some of our endpoints are still in version 1909 of windows because of this case and have therefore a retired end of support version of windows since beginning of this month.

>>> Leads us in accelerating our move to SAML authentication and get rid of certificate pre-auth (BTW, the two of them do not work together, you need to configure another vdom if you wish to have them side by side, it’s a technical limitation, no rant/sarcasm here)

> Issue with the save password feature ? Also, figure out yourself. Case still on bug fixing after more than 6 months with no updates.

>>> The “€” sign corrupts the encrypted saved password and is unable.

>>> How professional it is to need to explain to end users not to use the € sign in their passwords ?

> Issue with FortiClient not being able to establish the tunnel with SAML authentication after the authentication was correctly made ? Figure this out yourself. After some tests it appears that version 7.0 works, 6.4 not in our configuration. Don’t know why and the only answer I got from the support is: workaround provided (by myself that is) and just upgrade to 7.0.

>>> Leads us to the decision to upgrade to version 7.0 and thus next case :stuck_out_tongue:

> Issue upgrading FortiEMS 6.4.7 to 7.0.4 does not upgrade the syntax of the profiles correctly leading to unusable profiles and installers ? This time the provided support was good ! Fun fact: there is a known bug with upgrading 6.4.7 to 6.4.8, after telling us this, the supports asks us to try upgrading to 6.4.8 then 7.0.4, ok…

So, on the surface, FortiClient VPN solution is a huge success ! In the shadows I really struggle with it. I wanted to share my frustration and see if I was alone or not.

This has been a pretty common theme from a lot of people posting. I’m surprised Fortinet hasn’t addressed this although I guess if they had a fully functional SSLVPN client on it’s own then EMS would be a hard sell. It sucks to now that even with the “supported” FortiClient version the support isn’t at the level it should be.

I’ve switched most of the clients I work with from Cisco ASA/Firepower over to Fortinet and absolutely no regrets from a firewall perspective. But so far I’ve been reluctant to move to Fortinet for SSLVPN due to the EMS requirement.

- I want a fully supported SSLVPN client, connect before login capability and maybe dynamic host checks, ability to manage/push Forticlient updates. Honestly i could almost live with the free FortiClientVPN without those other features for some clients if it just didn’t have that free version banner warning.
- I don’t need another endpoint management system to take care of, Web Filtering, Vulnerability checks, AV, ZTNA, etc.

The only answer I’ve found is that you need to deploy EMS. Although yes you don’t need to fully license the features you don’t need.

One other question I haven’t figured out. Correct me if I’m wrong but even if you have EMS and want a vendor to use the FortiClient (not the web portal) they must consume a license and be registered with your EMS. Or use the free FortiClientVPN with free version warning banner. How can either of these options be the correct solution?

I agree, it’s functional but compared to something like global protect it’s hot garbage. Forti get really salty when you point this out to them too.

Stupid things like in SSL settings the authentication rules table is ordered but the actual order is controlled by the order the firewall policies appear.

If you have SAML auth enabled you need to have HTTPS in one of the sslvpn firewall policies or the SAML SP won’t trigger.

Still can’t use VIPs in policies if web mode is enabled for the referenced group.

EMS needing to run on a windows machine, it’s not that fancy software it really should be containerized and be a management extension in something like FortiManager.

Edit: not directly related but ran into it recently, the vdom limit for saml users is 10, why? As an mssp migrating forticlient off of legacy radius auth this is just annoying.

Okay, I read all this, and I don’t understand why, if you were using FortiClientVPN, and didn’t care about the support, that you felt you needed FortiEMS.

Because there is still FortiClientVPN for later versions.

Are you talking about the need to get past the 10-user restriction?

I can echo many of your frustrations. The latest gaff was I had to remove the uninstall password on the policy just to upgrade clients from 6.4.7 to 6.4.8 (don’t ask why we had to upgrade to 6.4.8 so soon after rolling out 6.4.7 or get me started on the rollout of secure EMS communication). Every release is like a box of chocolates, you never know which one has the poop-filling.

So— We recently moved to using Forticlient 7 and SAML with no problems, and no need to upgrade to EMS or whatever garb they’re pushing on you. Granted you don’t get the fancy installer with profiles included, but there are ways to get around all that.

I’m a reseller/one man band consultant and most of my customers have most of the common forti products.

What i have found odd is how most customers love ems/client with next to no issues but I have 2 or 3 which seem to run into issues/bugs all the time.

One in particular has a problem every time he does an upgrade and keeps rolling back to 6.4.2 or something.

The one which has him most worried is when he enabled usb blocking and excluded hid devices but apparently it blocked all keyboards and mice.

I can’t replicate most of the problems they seem to have so considering a reinstall.

I personally have found it to just get better and better over the years.

I don’t have as many frustrations as you but I’m pretty annoyed by the EMS requirements as well. All I need it for is the “login with Windows” feature, and to get that, I have to dedicate resources to an additional VM. It’s another box to patch and manage, another Windows license consumed, all so I can have a single feature.

On top of that, Fortinet wants EMS exposed to the Internet? Fuck that.

We’ve hit a bug in FCT 6.4.7 where sleep disables the wifi NIC, restart resolves; total PITA but fixed in 7.0.3, only, it’s not fixed in 7.0.3, TAC didn’t mention that, our AM told us. The actual fix is pending in 7.0.6 and 6.4.9 (or is it? Lost faith at this point).

I know it’s a common theme here but Fortinets software is shocking, every release fixes a critical issue and introduces 2 more; can’t wait to migrate.

I rolled out a ~45,000-user Mobility-Agent/FAC deployment for a major customer to replace the poorly-scaling FSSO Collector Agent and only found out after the whole thing was done that the version of Forticlient I based it on was the last one to offer the MSI configuration tool. Now if we ever run into a vulnerability or bug that requires upgrading I’ll have to justify an EMS purchase just to generate a tiny fucking MSI with only the Mobility Agent. Our TAM and account manager have both heard my anger and frustration on that mind-bogglingly stupid requirement.

this is not how the licensing works.
I would recommend call TAC (not an online ticket) to investigate his issue.
FortiClient features are not removed just because FortiClient is unreachable for short durations.

Honestly i could almost live with the free FortiClientVPN without those other features for some clients if it just didn’t have that free version banner warning.

You mean the banner you have to accept after the install? You can disable that in the registry.

I agree on the Windows requirement. I live in Windows, but a Linux appliance like FAZ or FMG would be much nicer.

good to know about some of the FG config quirks, I didn’t know about them !

To be the devil’s advocate, I think FortiEMS kind of has to be installed on a Windows machine as it relies on DCE/RPC in order to push installations on the endpoints (if you use this feature). There are Linux and open source implementations but they might have chosen to go with Windows Server in order to avoid any unnecessary issues.

But I do agree, having an appliance based on FortiOS would be way better.

The way I read it, they heavily leveraged the MSI deployment functionality of pre 6.2 FCT. That functionality was removed and requires EMS.

Strangely enough there was talk about introducing a middle ground between the two. VPN-only client, support, and deployment tools. Nothing else. Surprised that didn’t end up panning out.

Only telemetry port (tcp8013) should be exposed to the big bad internet. Which does a license check, profile updates (ideal for changes so users don’t have to be in the office and ZTNA checks etc….nothing else needs to be exposed to the internet and you should always put EMS in a DMZ

Oh, and they say put the dam thing in dmz and then add another read only domain controller in there too . Ok , how about I just buy some nice Cisco Miraki and just call it a day since I don’t need to expose my network and spend another 5kbon servers and licenses to just have a supported vpn client that is not nearly as good as Cisco AnyConnect.
I would have replaced all of our Cisco boxes with Fortinet if it wasn’t because of this none sense of Forticlient.

It kinda ressembles a bug we often encountered in previous versions (6.0 & 6.2, mitigated/fixed since 6.4): On unexpected VPN shutdowns like putting your laptop to sleep or changing WiFi while the VPN is up the DNS overridden were left on the physical adapter while tunnel is down. This basically disabled the Internet connectivity since no DNS was reachable… It was also a challenge to get some support on this problem.

Funny thing is that now the behaviour changed: a third DNS is now inserted and this third DNS is the “local” DNS… It really feels like they couldn’t figure out a way to make sure it resets what’s overwritten and thus they just though of putting the third DNS in place… This way 90% of the time the big will remain unnoticed.

Wait , I hear that with EMS , yoi have to uninstall the Forticlient free before being able to install the EMS one . How would you do that on 4500 endpoints .
Since you manage so many devices , how is the Forticlient ssl vpn compare to Cisco AnyConnect?

No. I mean the message within FortiClient VPN when you have it open. I don’t believe there is an ability to disable this message in the registry. There is no reason why an end-user should see this message. They would never be getting support directly form Fortinet anyway. It makes sense having it in “About” page if they needed to have in the FortiClient VPN somewhere.

“Upgrade to the full version to access additional features and receive technical support.”