We are looking at upgrading our firewall, migrating over from a Sonicwall that’s end of life. We are eyeing up the FortiGate 300e.
I’m told there’s an optional vpn client, or we could go with the Windows 10 built in.
With Sonicwall we’ve always used a client. It’s pretty simple, allows us to configure the client to auto launch with Windows and auto connect. You can have a desktop shortcut. We are small enough of a company that we typically just manually configure for each user. Users are still presented with a login box, and on the back end, we have it configured were their profile must be part of a specific security group, which gives me one additional layer of security, even if it’s fairly minor.
I’m looking for some advice on which route to take with the FortiGate. The Windows 10 would be simpler for us as we could configure and push out via Group Policy. The client we would still probably manually configure. I do hear that people have had some issues with the Windows 10. Stability, reliability, etc. I’d rather do more work now, for a better experience for my users. As I understand it, there’s no speed difference. Many of my users are not super technically inclined, so a simple enough solution is also important.
I’ve been trying to do some searching around, and haven’t come up on anything direct, so I hoped I could just ask here quickly.
I would highly suggest going with the FortiClient and use sslvpn. It’s incredibly easy to configure on both ends. As stated, IPSEC may have performance advantages, but is sometimes blocked which leads to the user being stuck without any ability to connect. With the windows 10 client, it has very limited configuration options, is limited to IPSEC and I find it very hard to troubleshoot. There is very little information it gives you about failed connections, though I’m not a desktop engineer so there might be more logs somewhere I haven’t found.
I’ve never used the Windows VPN Client, but I’d assume it’s likely using IPsec VPN.
IPsec will support vastly more users and throughput than SSL VPN but will have slightly more complex configurations.
The FortiClient VPN application supports both IPsec and SSL, and I believe you can still build custom deployable MSI’s that are pre-configured and even branded, but you might need a couple guys at Fortinet (usually SE and someone he knows) to get you sponsored into FNDN for the configurator.
Also keep in mind that it’s much more likely for a hotel/restaurant/public hotspot to block IPsec then it is for them to block SSL (as long as you’re using 443 for the SSL VPN).
Go the FortiClient route, and I really suggest you look into FortiClient EMS and Telemetry licenses. You get 10 of both for free so that you can trial it.
FortiClient isn’t just a VPN client, it’s an endpoint security suite in it’s own regard. You can disable the features you don’t need.
The FortiClient EMS server can push out VPN configurations to endpoints under it’s control.
We’re using the FortiClient for VPN only, and it works like a charm. Our firewall is connected to Active Directory, so users can authenticate to the VPN using their domain credentials. FortiGate 80C (older model).
If you do choose the Fortigate/Forticlient, just consider the use of split tunnelling. We’ve had some issues with this, where 3rd party suppliers have tried to access addresses we list on our dmz, which caused them to route down the tunnel and not get anywhere.
To remedy it, create SSL routed groups, essentially defining the subnets in which are available across the tunnel which are injected into the end users PCs routing table. Which prevents the “availability” or subnets that are not available to that user on the HQ side.
For example, if you list Google on your DMZ that address to the end user appears down the tunnel, if there’s no rules setup for them to access, they’ll not ever make it to Google. The idea of split tunnelling is if that address is not specified on the DMZ, use the local machine’s internet breakout.
Just something to consider.
Update: our problem was related to local addresses, the third party’s proxy server was an address we also had, so when they established VPN connection their proxy was inaccessible.
Forticlient has so much security goodness in it that it’d be almost tragic to *not* use it. It’s not just a VPN client, it can enforce policies and act as an antivirus too.
Do note that it’s easier on Macs to use the built-in IPSec. Same with iPhones.
Oh wait. Unless you disabled it on your clients you are. Connect sslvpn over IPv4 and all Ipv6 traffic bypasses the VPN. Connect sslvpn over IPv6 and IPv4 traffic bypasses the VPN.
And we can’t seem to get Fortinet to understand why this is bad. The state of IPv6 support and the craptastic response from suppport is a big reason why we’re regretting investing in fortigate devices and why we’re warning others to stay away.
The issues they highlight with ports being blocked for IPSec are real and do happen - we rolled it out and had to roll it back cos of the uproar of connectivity issues our users had. SSL works for the most part flawlessly plus you get host checking, but it’s down to your requirements really.
Check the data sheets for ssl vpn vs IPSec connection numbers.
Is there a guide somewhere on mass-deployment of Forticlient via SCCM? We’re going to roll it out only for the VPN portion… would be great to remove the noise for end-users and reduce support calls.
I see what you are saying now. Seems like they are still coming up with updated docs for 6.0. 6.0 obviously has less docs than 5.X.
I also wonder why some routers manage to drop ipsec nat traversal packets. They should just forward those packets as normal UDP packets.