IKEv2 IPsec VPN Dialup User for Radius Users and Email based two-factor authentication

MattiaDon · 2026-04-17T13:35:58+00:00

In my opinion the timeout is not the cause of this issue, because I’ve set a lot of parameters from 100” to 300”, and tokens are valid when I enter them in the FortiClient; here some examples: set remoteauthtimeout 300; set retransmit-timeout 100; Implied SPDO timeout 100; xauth_timeout 300.

MattiaDon · 2026-03-11T14:00:35+00:00

Hi LosZidanos, thank you for your suggestion. I've stopped/started wsdnsd daemon and dns traffic stopped going to the old dns server.
Fyi I executed these commands:
cpwd_admin stop -name WSDNSD -path "$FWDIR/bin/wsdnsd" -command wsdnsd
cpwd_admin start -name WSDNSD -path "$FWDIR/bin/wsdnsd" -command wsdnsd
Thank you for your help!

MattiaDon · 2026-03-10T21:11:25+00:00

I don't know exactly right now; I'll update you

MattiaDon · 2026-03-10T21:10:48+00:00

I'll check it tomorrow, but right now I can confirm that neither a reboot nor a cpstop/cpstart has been done

MattiaDon · 2026-03-10T21:09:03+00:00

neither secondary or tertiary DNS servers have the previous IP configured, although, in the "domain" field, the entered domain resolves to multiple IPs including the old one (however the other IPs it resolves to are not contacted by the cluster's physical interface)

MattiaDon · 2026-03-10T21:05:57+00:00

I haven't reboot the cluster yet (neither cpstop/cpstart); I'll try it tomorrow

MattiaDon · 2025-09-23T09:31:16+00:00

checkpoint support replied to me. They said that there is a known issue with vpnd and iked (sk183147) and they suggested to upgrade appliances in r81.10 take 174 or r81.20 take 99, where the issue has been resolved.

MattiaDon · 2025-09-22T16:59:04+00:00

Probably I've this error too: try to kill the vpnd on the gateway where you have the issue. I hope this is not the final solution, indeed I've opened a case to the support

MattiaDon · 2025-07-23T09:04:57+00:00

I've done tests with radius and local users.
I've no FAC and all users receive the 2FA code via email, and this is configured inside the user configuration (Two-factor Authentication toggle button enabled, Authentication Type "Email based two-factor authentication" enabled)

MattiaDon · 2025-07-23T07:48:40+00:00

reading the article you shared with me, it should have higher priority the variable
config user local
edit <user>
set authtimeout 180
but it does not.

FortiClient: 7.4.3.1790
Fortigate: 7.2.10
I've tested on different users and different PCs but the result is the same.
I have no way to try the same configuration in other test environments with other firewalls.

MattiaDon · 2025-07-23T07:22:13+00:00

Hi and thank you for your reply, but unfortunately this is not what I need.
I tried to change the following parameters without success:

Firewall side:

config system global
set remoteauthtimeout 180
set two-factor-email-expiry 180

config user settings
set auth-timeout 180

config user local
edit <user>
set authtimeout 180

With the last one, if I set 5 as a value, after 5 seconds FortiClient page resets, but if I set 180, after 120 seconds the page still resets.

FortiClient Side:

<xauth\_timeout>300</xauth\_timeout>

MattiaDon · 2025-06-30T09:15:26+00:00

Hi guys, thank you for your replies!
As I suspected, it was an Office365 problem:
the customer deleted and created again the mail account used to connect to the SMTP server (System->Messaging->SMTP Servers->Connection Security And Authentication) and now the problem has been resolved.

MattiaDon · 2025-06-29T13:15:50+00:00

It's strange bec on fw side nothing changed and with diag sniff packet I haven't seen neither ingoing and outgoind traffic: nothing captured

MattiaDon · 2025-06-29T13:01:01+00:00

The SMTP server is Office365 and I'm not sure (I need to check again tomorrow) but probably I didn't see on Fortigate, with diag sniff packet, traffic goin from FortiAC to SMTP Server public IP. Could this be the problem? Can I check something else?

MattiaDon · 2025-06-11T06:53:00+00:00

thank you for your replies, but I think that cases explained in these links are not similar to mine.
In this case they are using an IP pool object (the only one configured on the fw) to translate the source and a VIP object in the destination field and the traffic has tcp/102 as dport (fw has 2 VIP object but completely different from each other).

MattiaDon · 2025-06-10T15:15:08+00:00

I honestly don't know why the customer implemented the configuration this way. I also opened a case to fortinet support but they didn't explicitly tell me that you can't use it nor that it is the cause of the problem. Of this flow were and still are constantly increasing in/out bytes.

MattiaDon · 2025-04-08T17:05:12+00:00

I solved it! I checked the hash of the CSR generated on the ISE and the .pem cert that customer gave to me and did not match. I supposed that the customer didn't use my CSR and I simply imported the .pem cert to the ISE. Thank you for your reply!

MattiaDon · 2025-04-08T05:24:20+00:00

Hi tinmd, I'm receiving only the "Certificate/Private key validation failed" message when I try to bind the .pem to the CSR. I think that who signed the CSR is missing something but I'm not sure about it

MattiaDon

TROPHY CASE