I’m needing to setup a remote access VPN for a couple of users. I’ve avoided the SSL VPN due to the vulnerabilities that keep coming up. If I use EntraID SSO, would this mitigate a lot of the vulnerabilities? Or should I just stick to IPsec dialup and have the user put in a PSK? It’s only one user at the moment and a few others may need it in the future, so logging on and setting it up with a PSK isn’t too bad, but SSO is just a bit more streamlined…
You may find IPSEC is blocked on some public networks like hotels other places your remote users may be trying to work from.
Ipsec remote access vpn supports saml with entra id in latest fortios releases, I prefer to use entra id for authentication as this is more user friendly.
In the worst case scenario I would fall back to using any mechanism providing me mfa.
That being said, if your remote access is limited to providing tcp based application I would revert to using ztna.
Ipsec tends to be blocked by most of the public Internet providers, therefore if you can carefully manage you can implement ssl vpn as well.
If you’re running 7.2.7+ and forticlient 7.2.4+ you can run ipsec mfa vpn using saml and entra.
IPSec is better performance, but it’s a PITA to get MFA working on it (unless you consider the PSK a second factor). SSLVPN is more convenient, works well with MFA (including SAML), but performance isn’t as good as IPSec.
Sslvpn is better for end users/clients.
There are guides on how to harden your ssl vpn config, like using a loopback interface or really disabling Web mode and so on.
In addition to what was mentioned here you can run IPsec over TCP in newer versions now, which might aleviate some connection problems:
Very stupid question here, any one here ditched these complicated vpn set-up and use services like tailscale? Or wire guard in general.
Remap IPsec to 443? 
Could you configure a VIP to listen on another port number?
Configure a VIP to listen for 443 and translate it to 500 → forwarding it to the desired listening interface? Except now you’re working with IPsec at the software level instead of the NPU.
Man that would piss off hackers trying to figure out why SSL attempts at that port wont respond.
Using radius (nps) and azure MFA in a hybrid environment is just as easy as getting MFA to work with sslvpn. Point the xauth to that group and call it a day.
Also SSLVPN industry wide has had a lot of vulnerability problems so I’d more likely to need regular patching.
Huh. Been doing MFA with radius for years without issue on IPsec.
I like it. I’ll look for those guides. I was reviewing this document and it looks like it could be a good way to stay away from SSL VPN while keeping it simple for end users.
I tried this on a dialup tunnel and the option wasn’t available to me. Not sure if it’s for site to site only. I saw some 7.6 things mentioning IPSEC over TCP so it might have been added in that upcoming release
after reading this, it is even better than running on TCP, you can choose the port!
so i would move mine from 4500 to say 443, so things like cloudflair’s DNS proxy service would work with IPSec. right now, their proxy service does not support IPSec unless you use their enterprise levels if you need to bypass something like CGNAT
Gl with windows clients, iirc you can’t change the port (unless that had changed)
Why go that complex? Fortios ipsec implementation now supports running it in custom port. So u can set anything other than 500. Moreover we can run ipsec to listen to tcp instead of udp.
Yeah, with RADIUS and push notifications, it works. Configuring a RADIUS server (FAC or otherwise) for “a couple of users” is a lot of work, though. Especially if you’re configuring Microsoft NPS and Entra ID. Getting anything to work properly with Entra ID is an exercise in patience and frustration.
As of right now, though, you cannot use FortiToken on the Gate with IPSec, while you can with SSLVPN.