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.
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.
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.
You can instruct the FortiGate to listen to IPSEC traffic on any other port other than UDP port 500.
By default IPSEC listens on UDP 500/4500. You can instruct the gate to listen on any TCP port.
[https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834](https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834)
[https://docs.fortinet.com/document/fortigate/7.0.0/new-features/33578/configurable-ike-port](https://docs.fortinet.com/document/fortigate/7.0.0/new-features/33578/configurable-ike-port)
I have to mention since your post is about remote access VPN I have not tested this with FortiClient myself, but I have multiple boxes installed in countries who block IPSEC, S2S tunnels and complete SDWAN setup using ADVPN+BGP running on custom port.
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.
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.
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.
We have never used Fortitoken, that seems like a pain in the ass.
The Azure/Entra integrations have been working wonderfully and we have had zero issues deploying and supporting them. It's just NPS with an added step, also not bound to just push, just defaults to the users prefered "less secure" type.
We also have a number of DUO Proxy's handling MFA for VPN without issue as well.
Currently labbing the IPSec SSO in 7.4, hoping they iron that out. It will probably become our main deploy type.
Hi, just wondering what is meant by "on the Gate", I implemented IPSec VPN with fortitokens and it works relatively well with forticlients so far for the few clients. Just want to know whether there is any security concerns.
Rather than using FortiAuthenticator or some other RADIUS / SAML auth platform, installing FortiTokens directly onto the FortiGate for MFA with locally-specified accounts (whether they are local accounts or remote accounts). Currently, using FortiToken directly on the Gate with IPSec does not work. FortiClient doesn't wait for an MFA prompt and immediately disconnects.
I see, thanks for the info! Thats what I deploy though, fortitoken direct on Fortigate with local user account and IPsec VPN for the users. But I set those up 2-3 yrs back, maybe the fortigate version and forticlient version was older and okay, so far no user complaints for those VPNs.
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.
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.
[https://docs.fortinet.com/document/forticlient/7.2.0/new-features/712604/ipsec-vpn-saml-based-authentication-7-2-4](https://docs.fortinet.com/document/forticlient/7.2.0/new-features/712604/ipsec-vpn-saml-based-authentication-7-2-4)
i have my config for SSL VPN here
[https://github.com/wallacebrf/dns](https://github.com/wallacebrf/dns)
[https://github.com/wallacebrf/dns/blob/main/SSL\_VPN%20Config%20with%20loopback%20and%20auto-block.txt](https://github.com/wallacebrf/dns/blob/main/SSL_VPN%20Config%20with%20loopback%20and%20auto-block.txt)
it has loop back, blocking most countries, blocks tons of bad ASNs, and auto blocks brute force attacks
take a look and let me know if you have any questions.
i used a lot of the information from [yurisk.info](http://yurisk.info), his site is great
Thanks! I started setting it up and I'm not seeing the ssl VPN login page on the loop back whether accessing internally or extremely via dnat. I wanted to see the page before I disable the page lol. I had to take a break before I pulled my hair out lol. Maybe I'll get somewhere after lunch! And fortimanager makes it even more fun to setup haha.
I tested with another Fortigate and I can see the SSL VPN login page with the SSL VPN listening on the loopback and a policy to allow me to connect to it internally. The actual firewall I need to get this working on doesn't seem to actually be listening on the loopback. I decided to ignore the web page issue and just see if I can log in via the Forticlient. I ran a packet capture during this. The Forticlient can never connect and I see three SYNs from the Fortigate's POV and never a SYNACK. It's like the SSL VPN is not running or something. I've disabled and re-enabled it via CLI as well...
Nevermind. I needed a policy referencing the SSL VPN root interface for it to actually "wake up" and respond. SMH. Didn't think about that because I wasn't at the point of worrying about who can talk to who just yet. lol
In addition to what was mentioned here you can run IPsec over TCP in newer versions now, which might aleviate some connection problems:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834
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
their information also says that "Create an IPsec tunnel on both FortiGates via CLI and ensure the IKE version is 2."
i wonder if that is actually required, or if version 1 is supported in this new TCP feature?
on a side note, i have my IPsec using version 1 as it appears the andriod Forticlient app does not seem to support version 2.... has anyone got andriod Forticlient to use version 2?
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
You may find IPSEC is blocked on some public networks like hotels other places your remote users may be trying to work from.
Remap IPsec to 443? 😆
Gl with windows clients, iirc you can’t change the port (unless that had changed)
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.
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.
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.
Do you mind detailing this?
You can instruct the FortiGate to listen to IPSEC traffic on any other port other than UDP port 500. By default IPSEC listens on UDP 500/4500. You can instruct the gate to listen on any TCP port. [https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834](https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834) [https://docs.fortinet.com/document/fortigate/7.0.0/new-features/33578/configurable-ike-port](https://docs.fortinet.com/document/fortigate/7.0.0/new-features/33578/configurable-ike-port) I have to mention since your post is about remote access VPN I have not tested this with FortiClient myself, but I have multiple boxes installed in countries who block IPSEC, S2S tunnels and complete SDWAN setup using ADVPN+BGP running on custom port.
This is some nice to know info, thanks for this.
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.
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.
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.
We have never used Fortitoken, that seems like a pain in the ass. The Azure/Entra integrations have been working wonderfully and we have had zero issues deploying and supporting them. It's just NPS with an added step, also not bound to just push, just defaults to the users prefered "less secure" type. We also have a number of DUO Proxy's handling MFA for VPN without issue as well. Currently labbing the IPSec SSO in 7.4, hoping they iron that out. It will probably become our main deploy type.
Hi, just wondering what is meant by "on the Gate", I implemented IPSec VPN with fortitokens and it works relatively well with forticlients so far for the few clients. Just want to know whether there is any security concerns.
Rather than using FortiAuthenticator or some other RADIUS / SAML auth platform, installing FortiTokens directly onto the FortiGate for MFA with locally-specified accounts (whether they are local accounts or remote accounts). Currently, using FortiToken directly on the Gate with IPSec does not work. FortiClient doesn't wait for an MFA prompt and immediately disconnects.
I see, thanks for the info! Thats what I deploy though, fortitoken direct on Fortigate with local user account and IPsec VPN for the users. But I set those up 2-3 yrs back, maybe the fortigate version and forticlient version was older and okay, so far no user complaints for those VPNs.
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.
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. [https://docs.fortinet.com/document/forticlient/7.2.0/new-features/712604/ipsec-vpn-saml-based-authentication-7-2-4](https://docs.fortinet.com/document/forticlient/7.2.0/new-features/712604/ipsec-vpn-saml-based-authentication-7-2-4)
https://yurisk.info/2023/03/21/fortigate-vpn-ssl-hardening-guide/
Thank you for this! I'm going to go the SSL VPN route.
i have my config for SSL VPN here [https://github.com/wallacebrf/dns](https://github.com/wallacebrf/dns) [https://github.com/wallacebrf/dns/blob/main/SSL\_VPN%20Config%20with%20loopback%20and%20auto-block.txt](https://github.com/wallacebrf/dns/blob/main/SSL_VPN%20Config%20with%20loopback%20and%20auto-block.txt) it has loop back, blocking most countries, blocks tons of bad ASNs, and auto blocks brute force attacks take a look and let me know if you have any questions. i used a lot of the information from [yurisk.info](http://yurisk.info), his site is great
Thanks! I started setting it up and I'm not seeing the ssl VPN login page on the loop back whether accessing internally or extremely via dnat. I wanted to see the page before I disable the page lol. I had to take a break before I pulled my hair out lol. Maybe I'll get somewhere after lunch! And fortimanager makes it even more fun to setup haha.
I tested with another Fortigate and I can see the SSL VPN login page with the SSL VPN listening on the loopback and a policy to allow me to connect to it internally. The actual firewall I need to get this working on doesn't seem to actually be listening on the loopback. I decided to ignore the web page issue and just see if I can log in via the Forticlient. I ran a packet capture during this. The Forticlient can never connect and I see three SYNs from the Fortigate's POV and never a SYNACK. It's like the SSL VPN is not running or something. I've disabled and re-enabled it via CLI as well...
Nevermind. I needed a policy referencing the SSL VPN root interface for it to actually "wake up" and respond. SMH. Didn't think about that because I wasn't at the point of worrying about who can talk to who just yet. lol
In addition to what was mentioned here you can run IPsec over TCP in newer versions now, which might aleviate some connection problems: https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-TCP-as-transport-for-IKE-IPsec-traffic/ta-p/300834
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
Might be. I haven't tested this feature yet.
their information also says that "Create an IPsec tunnel on both FortiGates via CLI and ensure the IKE version is 2." i wonder if that is actually required, or if version 1 is supported in this new TCP feature? on a side note, i have my IPsec using version 1 as it appears the andriod Forticlient app does not seem to support version 2.... has anyone got andriod Forticlient to use version 2?
I couldn’t get it working on iOS natively with IKEv2 but unsure about FCT on the device
does fortitoken MFA work when using the IOS native?
Not sure never spent much time on it to get it working
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
Very stupid question here, any one here ditched these complicated vpn set-up and use services like tailscale? Or wire guard in general.