hi all
I am studying the difference between using IPsec VPN and SSL VPN in FortiClient after watching the administration-guide.
Description explains that the generation of IPsec VPN in the FortiClient allows access to the Internet using a dial-up connection via POTS or ISDN telephone lines.
There is no difference between SSL VPN and IPsec VPN from the perspective of a regular PC, but is it really a function used because of the phone?
Unfortunately, I looked up the guide and googled it, but I didn’t understand it. Please ask me if the purpose of setting this up is really because of the phone and whether the difference from SSL VPN exists except for technical theory.
Thank you
Reference
https://docs.fortinet.com/document/fortigate/7.0.3/administration-guide/190553/remote-access
It really doesn’t have to do with phones at all. They’re just different protocols for accomplishing a similar task.
Fortinet’s IPSec VPN is standards based and uses the IKEv1/IKEv2 protocol. It can be used with a generic IPSec VPN client such as the one built into Windows or iOS. Under the hood it uses two different UDP ports, one for control messages and one to transmit the data. It offers a wide range of configurable encryption ciphers for you to tune security or match what a client can handle.
Fortinet SSL VPN is a proprietary VPN protocol from Fortinet. It is a very similar scheme to TLS or SSL encryption you use to visit websites, like there’s a RSA certificate exchange to confirm identity of the server followed by a symmetric crypto cipher for the data. It only works with the FortiClient applications as it is proprietary to Fortinet. Note that it’s not the same thing as OpenVPN which is also a SSL VPN but a different protocol. Under the hood it uses a single TCP or UDP port. In fact when it uses a single TCP port, it is often indistinguishable from the traffic pattern of viewing a HTTPS website.
Long story short, IPSec VPN tends to be faster and can be used with a variety of native clients. SSL VPN is better for traversing firewalls and double NATS since it’s just a single port, but the overall performance is worse.
A couple additional thoughts not yet mentioned…IPSEC VPN typically ends up using UDP port 4500 (which is IPSEC in NAT-T mode) while SSL VPN uses TCP port 443 and if possible may try to negotiate DTLS on UDP port 443. You have to have DTLS enabled for it to negotiate using UDP 443. I *believe* still FortiClient does not support DTLS on MacOS in which case the only UDP-based tunneling mechanism would be IPSEC.
The reason this is important is you will get better throughput with UDP based tunneling for two reasons:
- Less overhead
- TCP sessions tunneled inside TCP sessions are less resilient to packetloss and can cause TCP Meltdown. If you get a packet drop on standard TCP SSLVPN you now have your inner-tunnel session trying to re-request the missing packet AND the outer tunnel session doing the same. In unreliable networks with intermittent loss such as wireless this can cause odd issues and TCP Meltdown. Also TCP based sessions are less resilient because the underlying OS network stack will kill the session when it thinks it should rather than the client application using it’s own decision process so packetloss = renegotiation rather than retry.
I’ll add, that SSL VPN tends to make configuration easier, and more “coffee shop/hotel” friendly if you stick to port 443 - since many hotels and coffee shops only allow common ports (53, 80, 443). So if you have a highly mobile workforce it might be beneficial to use this.
I used to prefer IPSEC because the performance is much better, and the security is generally a little better too. But availability for the reasons above has me using SSL VPN a lot more.
Due to this there’s a trade-off. On the one hand you have TCP SSLVPN which is more likely to be allowed out through any firewall and guest network you encounter in the wild. On the other hand you have the more reliable protocols like IPSEC or DTLS. You can do SSLVPN and have it negotiate DTLS if available, which is a good option, but I believe it’s still not an option on MacOS. For this reason I like having IPSEC VPN as an available option. Some orgs may configure both in the client and let users flip to the other in case of trouble or settle to only use SSLVPN with DTLS negotiation and let their support teams help users with issues reconfigure to IPSEC on a per user support basis
Indeed! If you can place your SSL VPN on a common port that uses SSL (HTTPS, IMAPS), it’s surprising how many public WiFi filters will fail to catch it. Not foolproof, I’ve definitely seen the more expensive Nomadix/GoGo WiFi hotspots be able to detect this.
In the end I find that most workforces demand to have both. SSL VPN is great for those who have restrictive connectivity, but IPSec tends to be in-kernel or even hardware accelerated. On mobile devices that can make a huge difference in battery life.