external 2FA for ftgt ssl vpn

[alsoft]

Hi,

we are sw company, and have own security product (authentication server). It can work like radius + otp (and many others methods) so I try to integrate OTP to ftgt. It works (with free ssl vpn client). But after I try use 2FA online method, with push notification. And here I have problem. Forticlient send AD user name and correct password, mobile app recieve notification, but FortClient instantly shows OTP dialog. With no reason, I not send more validation req. -- UPDATE ---

This is because I have second functional radius server with MS365 MFA on it. And fortigate from unknown reason switch to this, second server, almost instantly after password send. When I change IP of second radius to nonsense, everything works.
Fortios have only 2 parameters I know, timeout in radius definition, and global, remoteauthtimeout. Both set to 120s and not helping.
This seems now like some error in fortigate logic, so I create ticket on it, sorry for this post, I believe in time of writing that this can be free forticlient problem...

Anyone any hint?

[AEK · Accepted solution]

I don't think this is a bug on FortiClient.

This is because FGT sends authentication request to all possible authentication servers at the same time. That's why you receive OTP request from your MS365 auth server.

This tech tip explains the authentication process.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...

The document also explains how to ensure the correct authentication server is used.

Hope it helps.

[alsoft]

Yea! Realms really do this trick, nice. Thx for help.

[Debbie_FTNT]

Hey alsoft,

to expand a bit on my Technical Tip and AEK's comment:

- FortiGate will send authentication requests to any possible server

- If you have user groups associated with each RADIUS server in your SSLVPN policies (any policy with ssl.root as source interface), then both RADIUS servers will be checked

- FortiGate will go with the one that replies first

- In your case

-> the RADIUS with push notification will appear to not reply for several seconds (while push is triggered and accepted)

-> the other RADIUS sends back an Access-Challenge

-> FortiGate goes with the RADIUS server that responded first, and so prompts for a token code

As outlined in the KB, you will need to ensure that authentication requests ONLY go to the RADIUS with push notification in some way, for example by using SSLVPN realms.

Let us know if you have questions :)

Cheers,

Debbie

[AEK]

Thanks for the clarification Debbie.

And what would be the best solution for dialup IPsec with RADIUS users?

[Debbie_FTNT]

Hey AEK,

with IPSec the user group (and thus authentication server) is associated with the IPSec configuration directly, and authentication happens based on those, not based on policies.

FortiGate will only authenticate to the group(s) and servers defined in that particular tunnel configuration when an IPSec client tries to connect.

So, if a single IPSec tunnel links back to multiple authentication servers, I would suggest splitting that into multiple tunnels to achieve a similar effect to SSLVPN realms.

Cheers,

Debbie

[AEK]

I missed to mention that but in fact in my IPsec config the authusrgrp is unset because users must be in different groups, since I use RADIUS groups as source in my firewall rules.

[Debbie_FTNT]

Hey AEK,

ok, if authusrgrp is not set, then FortiGate behaves a bit differently.

If I remember correctly, this method (no authusrgrp set in IPsec config) only works with local users (those users can then be of type LDAP/RADIUS/Password/...), and FortiGate would have the username from the IPSec connection request.

You should have to set authusrgrp for authentication via a user group with LDAP or RADIUS server outright (instead of local users of type LDAP/RADIUS).

I am a bit rusty with IPSec VPN however, so I'm not entirely sure I got all details straight.

Cheers,

Deborah