I didn’t get it… SSL VPN has been until not much longer ago the standard for providing remote access for clients. Even Fortinet TAC pushed some of my customers to stop using IPSec to grant access to users and adopt SSL-VPN instead. Now Fortinet is pushing against it, putting multiple warnings on FOS 7.4.x saying that it’s insecure, and recommending using ZTNA or IPSec and hiding SSL-VPN by default.
But if you stop to think, anything you use to grant remote access can be exploitable someday, including ZTNA or even IPSec. We just expect Fortinet to fix those exploits. We pay FortiCare for that! Nothing exposed to the public will be 100% secure forever.
We don’t have customers running production in 7.4.x yet, but for sure they will question us why they have such a security flaw in their environment and why we allowed it for so long to have such a security flaw if they keep those warnings when it became a Mature release. Not to mention customers using SAML auth that only works with SSL-VPN…
Is Fortinet abandoning SSL-VPN? Are those those fussy banners and warnings really necessary? Or they are just trying to push FortiClient ZTNA anyway?
ZTNA is not a magic bullet either. You still need to transport the traffic securely, which is fine if the traffic is HTTPS. For almost everything else, you are back to VPN, which is either IPSEC or SSL-VPN.
Until very recently (7.2.3?) the macOS FortiClient only supported outdated and insecure IPSEC, so you basically had no choice other than SSL-VPN if you wanted to support Macs.
Nowadays IPSEC with IKEv2 is a viable option. Unfortunately it does not work with SAML authentication. SAML is very popular these days.
SSL-VPN as a technology stack is a bit shit and vulnerable to a wet fart these days.
Those warnings are there for a reason (especially on web mode). If you look at the new features in 7.4 and 7.2 they’re adding a LOT of SSL functionality into IPSEC which suggests they want everyone off.
There is a reason why you keep seeing SSL-VPN vuln after vuln but rarely on IPSec. Yes, SSL VPN has been prominent but its time is near. Technology stack needs to keep evolving to a better standard. With enough time, IPSec will catch up with feature parity and is safer. ZTNA is another emerging solution. You dont have to use it and stay behind the curve.
SSL-VPN isn’t a standard protocol like IPSEC. Each firewall/vpn vendor has its own completely unique and proprietary SSL-VPN implementation. IPSEC on the other hand is a standard that anyone can audit and raise issues and you’re not exposing a webpage/Java/whatever to the public internet when using IPSEC.
SSL-VPN’s have been getting hammered with vulnerabilities for years now. Go look up Fortigate SSL-VPN vs IPSEC PSIRT advisories and you’ll see its VERY one sided. This also isn’t just Fortinets issue. ALL firewall vendors with SSL-VPN implementations are getting hit the same way.
lots of folks out there that deploy SSL without deploying it correctly…so its off by default and you can re-enable… not if you upgrade from an earlier version, you dont get the disable and warnings…only greenfield…
SSL is great, if used correctly, not so much if not
As you said - anything can have CVEs and any remote access solution needs patching. However, SSL VPN may be worse because after so many bugs, it is clearly due for a serious deep dive by the developers or even a re-write in a modern memory-safe programming language, and they would rather watch it die than fix it more proactively than playing whack-a-mole with each new exploit.
The root cause is SAML and economics. SAML is too awesome to be allowed, because it integrates with your existing MFA/2FA without FartiTokens.
The few monopolists that control the enterprise networking sector have basically agreed among themselves in an informal price/terms fixing unspoken agreement, that the ability to support remote users in a decently secure manner will at a minimum come with a per user price tag, and none of them will include it in their base appliances in a usable way, and you’ll be lucky to even have it not be an additional recurring subscription.
With SSL VPN, FartiTokens are the designated means of charging you per user. But it supports SAML, which is contrary to this, so they are intentionally neglecting fixing security bugs proactively in order to scare customers away from it & into paid per user solutions.
Also - desktops are cheaper than laptops and last a lot longer, and were a staple of any company on a budget. Web mode meant that you could let people WFH when needed via a personal device, with RDP in a browser. But putting a client on an untrusted device and using a tunnel where any malware on the device can talk directly to your network would be too dangerous.
Without web mode, you have to buy LAPTOPS for anyone who might ever need to WFH (or take a stupid risk and put clients on untrusted home devices). What do you know - another win for the big tech industry getting a bigger slice of small/medium business’s budget if “legacy” solutions that work well are neglected and destroyed!
TL;DR - SSL VPN is being neglected intentionally because it works too well for an included feature, and they want to replace it with things that extract more money from your business to meet the same basic needs & increase the proportion of every company’s operating budget that tech gobbles up.
SSL VPN has a major vulnerability every 6 months or so.
We’d move to IPSEC, but there’s no absolute timeout and getting an NFR submitted is proving difficult.
Not sure about abandoning, but definitely pushing other things. SSL vpn was fine to have connectivity through poorly configured hotspots (that wouldn’t allow anything else than https) for which FortiSASE (through Private Access) is the best solution (because Fortinet are the ones dealing with any vulnerability on the ssl vpn) and ssl vpn was also great to do « clientless vpn » (aka web mode) for which FortiPAM is the better go-to alternative.
ZTNA is perfect substitution for VPN. Works fully with TCP redirect and also have 2fa/saml option. I would give up any vpn solution and integrate ZTNA at 1st place as it reduce management cost and offload internet (vpn) traffic (significantly)
I think Fortinet is trying to push their SASE product too. I dunno if they will ever support SAML with Ipsec. But you can use RADIUS with Ipsec and I guess you could also use the Entra Id extension for NPS servers if you want to take advantage of Microsoft’s MFA or go the full Fortinet way with Fortiauthenticator and Fortitiken
You won’t. There is 0 possibility of Wireguard coming anywhere close to the performance of IPsec on a FortiGate. The SSL VPN feature is a different case.
Wireguard is an open source building block for a remote access solution, and like most open source solutions it’s half assed in that every single bit of configuration management is manual.
Fortinet would have to build a management platform on top of Wireguard for it to be usable.
Look at Netbird, Netmaker, or Tailscale for an example of what that would look like.
EDIT: I am not in a position to know, but I am pretty sure the only people asking for Wireguard are homelabbers and open source fanboys.
EDIT2: Wireguard isn’t going to happen because FortiOS on FortiGate appliances use “ancient” and “out of date” kernels for the hardware appliances.
Wireguard kernel modules do not exist for the kernel versions that most current shipping FortiGate hardware uses.
I imagine this is due to the integration of the NP6 (& variants) & NP7 (& variants) into the kernel networking stack.
You are asking that Fortinet do (yet more!) custom Linux kernel software development to backport Wireguard kernel modules to versions they do use, and make sure those backported kernel modules do not interfere with the NPU code.
