Switching from FortiClient VPN to Windows 10 native?

Hi All

We are an msp who supply/support FortiGates to a number of clients. Only a few use licenced FortiClients with EMS and the benefits of support/Vulnerability scanning and the extra features that the full blown client provides.

For many others it’s the free/unsupported FortiClient VPN only client that’s in use. This is relatively easy to deploy/configure but becomes problematic when updates are required to plug security holes.

As any upgrade requires a removal/reboot/reinstall it’s pain when we’re talking about hundreds of endpoints. In addition, there are some recommendations (for sensible reasons) to use the native OS client that would dispense with these problems.

https://www.ncsc.gov.uk/collection/mobile-device-guidance/virtual-private-networks

Integrated vs third-party VPN clients

Most operating systems have a built-in VPN client available which can either be configured on the device or managed remotely. Integrated clients are normally free to use, work reliably, and are updated automatically, but can also be relatively limited in functionality. For example, there’s often no ability to configure routing rules, exceptions, or split tunnelling.

We recommend using the native client where possible, and our platform specific guidance provides configuration details. However, a range of commercially available third-party VPN clients exists.

Using a third-party VPN client increases the risk that operating system integration will be poor, and that consequently, some data may be sent outside the VPN. It also increases the number of software packages that need to be kept up to date, adding to the likelihood that some out-of-date software will be in use.

Has anyone switched from using the Forticlient VPN Only client to Windows 10 Native (IPSEC not SSL)?

Any issues/problems encountered by those who use the Windows native client?

Question for you… for the relatively inexpensive cost of EMS clients, as an MSP why are you not buying, hosting, and making it part of your services, to standardize everyone on FortiClient? Honestly, it’s like $10:year per machine… worth it to you just in saved labour. Even if they don’t use the protection services and it’s just a management platform for VPN client, Mobility Agent for FSSO, and a.Fabric agent to send Tags to FortiGate for your ZeroTrust…

Step up your game, and your life will become easier. If your clients aren’t willing to pay an extra $1/mo per machine, you don’t want them as clients - they’re too cheap to bother keeping.

W10 native IPsec needs admin rights to establish a connection, so I would say that’s a big NO if you’re considering it for regular users.

My reply is irrelevant to this topic but anyway here I goes…

I use Win 10 native SSL VPN to Fortigate and have never had any issues. I really enjoy not having the monkey forticrap on my pc

We use a mix of FortiClient VPN and the inbuilt Windows VPN (specifically SSTP VPN).

If you have the infrastructure to support SSTP VPNs (namely a server to run the MS RRAS role, and one to run the NPS role), DMZ etc, it’s hard to look past given that it’s baked right in to Windows, and it uses port 443 meaning it’s guaranteed to work from almost anywhere. Also, you can leverage MS Always On VPN if required.

One obvious upside to using the forticlient is that the VPN is on the ‘gate which means you don’t need other infrastructure.

Edit - just read that you are an MSP. So are we, and this is why we have several solutions. Our smaller clients are typically using FortiClient VPN, but larger ones where they have significant infrastructure are often on inbuilt Windows VPN.

Still dealing with Meraki devices, I support a number of users that use the W10 VPN and it works just fine. I’m not concerned about the L2TP/IPsec mix aspect of it (which is all Meraki will support). I find the connection itself to be very reliable.

Setup is very easy. I create an “allusers” VPN profile with a single PowerShell command, and drop a desktop shortcut that says “Connect VPN” that invokes “rasphone -d ” to connect. While users can connect it from the system tray network icon, there has been a bug that seems to pop itself up with random W10 updates where VPN’s will sometimes fail to connect when using that method. I train users to always using the “login with network” option but if they don’t do that, they are trained to click the “Connect VPN” shortcut.

The biggest downsides of the native VPN client for me are:

  • Cannot control split tunneling from the head end - Must add rules via PowerShell on the client for split tunnel networks
  • If you want users to have a VPN connection before logging into windows, they have to click the “logon with network” icon in the bottom right corner of the W10 login screen, which will connect the VPN first then pass-through those creds to Windows to complete the Windows login (assuming they are all the same creds). More often than not, users completely ignore this and just login to Windows normally and now you have to be concerned with what GPO’s aren’t running because you cannot contact a DC as part of the login process.

All I know is that split-tunneling on Windows VPN is a pain in the dick. If the home user happens to be on the same subnet as the office (we’ve all seen it), good luck. You’re going to have to put routes in the commandline and they will eventually break.

Don’t do it. It’s not full IPSec, it’s a mix of L2TP and IPSEC, feels cludgy and user experience is suboptimal.

The challenge for me has always been lack of full IPSec support under Windows. MacOS is fine as it comes with a ‘Cisco’ IPSec client. It’s not clear if you’re planning to use IPSec or SSL?

Your issue seems to arise when deploying upgrades for free Forticlient. Have you considered using an application deployment software for that? Maybe SCCM or Chocolatey?

I have been administering FortiClient VPNs and later FortiClient EMS for a long time now. FortiClient isn’t high quality software and needs a lot of testing/debugging with each new version. This wastes a lot of labor and time is money so that’s a black mark against the product IMO. Also, if you want to manage a lot of remote FortiClient installs you need to expose the EMS server to the Internet (at least FortiClient management port 8013). If you expose the install port most remote installs can be accomplished too. A small percentage (like LTE users) will crash and burn and you’ll need a remote access solution to get FortiClient fixed.

Being tired of all this I decided to experiment with the Windows 10 Enterprise device-tunnel Always-On IKE v2 vpn with FortiGates. You could as easily use a user-based connection instead with Win 10 Pro machines. Using certs this works quite well, but logging isn’t very good on the FortiGate. I can see what machine is connected live, but that info isn’t there in the logs for some reason. Split-vpn features are great, with the ability to control dns queries, proxy settings, and app-specific routing. Unfortunately the Windows 10 VPN seems fragile. I was able to come up with a fix script for the issues, but still a fair amount of labor to maintain the VPN.

Given the importance of VPNs for our business units we have decided to switch everyone to NetMotion Mobility. It’s tried and true for our law enforcement users and just works. The reporting is great, and I’m looking forward to our upgrade to version 12 that is going to double the reporting capabilities with lots of diagnostics data.

I’m going to keep the FortiClient around and use it as a backup VPN solution, but I’m not going to miss supporting it day in and out. I deploy new versions of FortiClient with SCCM/MECM since it doesn’t end up with broken clients as often as deploying with EMS. The EMS install for upgrades is just plain dumb unless your EMS server is connected to the Internet.

why not try use turbo vpn for your pc it’s good for gaming and streaming and all the vpn features are great maybe it’ll solve your problem.

Good morning,

I am interested to: does it is necessary to have the VPN Client installed to show in Windows 10 VPN the related profile?

I don’t believe this is true. Got proof?

What is that native Win10 SSL VPN client you speak of?

<on_connect>

Put that in your EMS profile XML config under VPN to correct that issue. I’m literally getting ready to do this next week.

Win10 can also do pure IKEv2 IPsec, with EAP to auth the user. Thought it can be tricky to get up.

Sorry - have edited post to remove a typo. We are/and will be using IPSec VPN’s.

Hi interested to: does it is necessary to have the vpn client installed to show in windows 10 vpn the related profile, I’m dad.

there’s nothing that I can show you to prove it, but I’m sure you’ll find multiple topics on this subject if you google it.

A couple of years ago we set up a few Windows VMs on Azure with specific services and applications to be used by our users. Our initial goal was to provide them with P2S IPsec access through the W10 native client. Everything worked perfect on our sysadmin test labs, but as soon as the first endpoints were configured, UACs started popping up asking for admin creds… so after googling this behavior, we found multiple references to this specific restriction, so that was the end of the road. We ended up moving the more expensive gateway tier which allowed access through OpenVPN.

I haven’t delved into this subject for a while, but I suppose this restriction still exists.