It sure seems like there are an awful lot of vulnerabilities these days that come in through flaws in SSL VPNs, not just with Fortinet but many other vendors as well… I’ve always been leery of any exposed web interface with input boxes, since they can be a vector for injection attacks etc. I am playing around with it on my 40F at home, but I have a self-generated CA/cert PKI and I enforce requiring a client cert from my CA to connect, so i THINK that’s better than average, but I wanted to see other people’s opinions. Thanks.
In Sept 2021, the NSA/CISA recommended not using SSL/TLS VPNs (https://media.defense.gov/2021/Sep/28/2002863184/-1/-1/0/CSI\_SELECTING-HARDENING-REMOTE-ACCESS-VPNS-20210928.PDF)
“Avoid selecting non-standard VPN solutions, including a class of products
referred to as Secure Sockets Layer/Transport Layer Security (SSL/TLS) VPNs.
These products include custom, non-standard features to tunnel traffic via TLS.
Using custom or non-standard features creates additional risk exposure, even
when the TLS parameters used by the products are secure. NSA and CISA
recommend standardized Internet Key Exchange/Internet Protocol Security
(IKE/IPsec) VPNs that have been validated against standardized security
requirements for VPNs.”
That being said, I do like using SSL/TLS VPNs because they use the same port (TCP 443) that encrypted HTTPS traffic uses. Some network administrators may block the IKE/IPsec VPN ports (ESP 500 / UDP 4500) so your end users may not be able to use an IKE/IPsec VPN anywhere there is an Internet connection but usually an SSL/TLS VPN will get through.
The nice thing is that FortiOS supports both SSL VPN and IPsec VPN for remote access so you can choose the best solution for your scenario. Best of luck!
SSLVPN is the weak link in many vendor’s systems, including Fortinet. Stay on top of security updates and set sensible policy, never ‘allow All’ type stuff, use strict geofencing and tight control over UAs with access. We use FortiAuthenticator, and require a single-use cert to connect.
Cert auth would not make any difference for the unauthorized vulnerabilities that have been the last year. Makes the VPN itself more secure than username+password though.
I’ve configured loads of gates with SSL VPN. MFA is the way to go regardless. Use either SAML or radius with some form of MFA to confirm connections.
Don’t use standard ports. Security through obscurity.
The default settings like TLS handshake version need to be configured as well via the cli. If you’re not going to be working abroad then ensure that the portal is only accessible from the UK. You can do this by defining a UK region object and add that to your SSL VPN portal.
Also, enable the portals host checks to ensure the endpoint is secure.
There are always going to be issues with SSL VPN as all vendors have their own recipes and there is no industry standard unlike IPSec.
With anything IT, security is a must but we also need to ensure that it’s not to the point where you are disrupting productivity.
Having certs will also help in the authentication part.
In addition to all mentioned (MFA, Loopback Interface, …) I also usually set these parameters:
set dtls-min-proto-ver dtls1-2
set ssl-min-proto-ver tls-12
set ciphersuite TLS-AES-256-GCM-SHA384 TLS-CHACHA20-POLY1305-SHA256
Make sure your clients support these cipher suites. If they support TLS 1.3, you could also raise min TLS version.
I usually work in larger environments and we use SAML for authentication. The identity provider ensures device compliance, MFA, etc.
IPSEC brings more problems than it solves IMO (no modern MFA, connection problems in many environments like Hotspots, Mobile Internet acccess, DSlite, etc)
Requiring a client certificate already puts you ahead of what most people are doing but I’ll add that you also want to have your VPN service listen on a loopback interface to let you apply regular firewall policies with security profiles and restrict connections based on geographic location.
The issue with SSL VPNs is that every single vendor has their own way of executing their solution and no one follows an established standard.
As an idea it is generally ok, but the implementation and consequences around that cause issues.
The fact that the vpn by nature is exposed to the internet means it is a viable attack surface. It also should move from allowing subnets or IP addresses with static rules to more posture compliance dynamic access.
If possible, we always try get customers to move towards a private cloud type access. There are tons of them from various vendors and they remove the fact the remote access is exposed to the internet, and you just hope the vendor cloud is secure then.
Short answer yes if you keep your FortiGate patched and use MFA.
been with my org for almost 2 years now. one of our coworkers is off, they managed the vpn for the most part. we switched from ipsec tunnel to ssl vpn on our fortigates but we it was done (which i had just recently found out) they never put geo restrictions on it so IPs from everywhere were trying to attempt connections. i through up a restrict to just canada and now we only have seen our employee connections (which is not much anyway maybe 1 or 2 a day)
i hope to eventually get mac and mfa set up for it eventually if the boss’ approve it. our org is small so it is manageable.
Um add mfa to this list please. Absolute must have and definitely filter your sources to geolocations based on where your remote uses will be coming from.
We go as far as integrating with hr for out of the country users before we make exceptions
As opposed to popular belief, including myself up until recently, IPS has NO effect on local terminated connections.
Only L3/L4 objects are actually effective.
See Life of a packet
Wait how do you get emails? Via Gmail? You say home fortigate right? I have a 60E at home too and would like to try this email thing out. Have remote access VPN setup as well, and can you forward me/share the automation stitch configuration that you use for it? Thank you.
What’s the advantage of going to a loopback interface?
Any way of using Ip blocklist without loopback interface?
FortiOS supports both IPsec and SSL, and Forticlient for Windows does too. For other platforms, you’re stuck with SSL. SAML doesn’t work over IPsec on any platform, as far as I know. I’d love to be wrong about that.
The growing number of open Wifi networks i have seen that block IPsec is the reason i am looking into SSL. But i agree, i have been running fine for years with remote access IPsec. I do recall that Zyxel recently had a vulnerability in their IPsec stack, but Zyxel is utter trash.
Security through obscurity is a very, very weak technique.
I have to say i have been trying for many years to get a reliable connection with the builtin iPhone IPsec client. I’ve tried countless combinations of VPN firewalls & ISPs. It always disconnects if i’m not actively sending data over the connection, and always if i move around to different networks. It happens worse on mobile (so much for MOBIKE 
) so i pretty much just gave up trying to implement it iphone anywhere.
To be completely accurate, IPS can apply to local-in traffic. You just need to use an interface policy ( config firewall interface-policy ).
However that usually impacts performance fairly heavily. Use with caution.
With regards to the comment you replied to, IPS would still apply since traffic is first hitting a standard firewall policy as routed traffic, then being treated at local-in traffic.