IPSec Dial-up - Saml Auth Cache - Unable to Connect

[AZFortinetMember335]

I may have to edit the Subject once I have a better idea of what is going on. We successfully configured our IPSec Dial-up tunnel last week and we were able to successfully login and get assigned IP addresses. Now today I tried to login and I put in my Entra credentials, and it says it successfully logged me in but nothing happens. I just see the VPN Name and the Disconnect button. No metrics or my assigned IP address like before. I verified that I did not get assigned an IP address and the tunnel is not showing up. My coworker proceeds to sign-in and it works just fine.

I ran the debugger and compared my connection to his and I found only one difference between our logins. After we get the response back from Entra his logs show the following:
    __saml_auth_cache_push-New auth cache entry is created, user='{randomNumbersSet01}', saml_user='{username}', expires=1756916400, SAML_server='{SamlServerName}'

Now mine is a little different:

    __saml_auth_cache_push-Update '{randomNumbersSet02}', SAML_server='{SamlServerName}'

Mine hangs there at this point where his logs continue with communicating with a RADIUS server and performing EAP processes.

So I'm wondering based on my log that something thinks I'm still connected and because it thinks I am it doesn't continue with the EAP process and just hangs. If that is the case how do I go out getting out of this state? I already tried rebooting the laptop but that didn't work. I didn't see anything in the enterprise application that has 'connections' to disconnect. 

Any help would be appreciated.

[tbarua]

Hi, 

You can check if the user gets authenticated by running this command: 'diagnose firewall auth list' in  FortiGate if the user group is being mapped in Ipsec policy. Please run those command to check more details about user authentication process:

diag debug reset

diag debug console timestamp enable

diag debug app fnbamd -1

diag debug app ike -1

diag debug app samld -1

diagnose vpn ike log filter rem-addr4 x.x.x.x     >public ip

diag debug enable

Please check these kbs for more details:
A guide to Dial-Up IPSec VPN Authenticati... - Fortinet Community

Dialup IPsec VPN user-info not displaying... - Fortinet Community

[AZFortinetMember335 · Accepted solution]

I ran those commands and it looks like maybe my user ID is not being passed correctly to the EAP. 

Broken EAP debug:

•  __saml_auth_cache_push-New auth cache entry is created, user='{randomNumbersSet02}', saml_user='{username}', expires=1756916400, SAML_server='{SamlServerName}'
• ike 0:IPSEC-Dialup:1403: FCT EAP 2FA extension vendor ID received
  
• handle_req-Rcvd auth_cert req id=201541, len=2089, opt=0
• __cert_auth_ctx_init-req_id=201541, opt=0
• __cert_chg_st- 'Init'

Working EAP debug:

• __saml_auth_cache_push-New auth cache entry is created, user='{randomNumbersSet01}', saml_user='{username}', expires=1756916400, SAML_server='{SamlServerName}'
• ike 0:IPSEC-Dialup:1392: FCT EAP 2FA extension vendor ID received
• handle_req-Rcvd auth req 1142587109492 for {randomNumbersSet01} in {UserGroupName} opt=00000000 prot=7 svc=9
• __compose_group_list_from_req-Group '{UserGroupName}', type 1create_auth_session-Session created for req id 1142587109492
  

There should be no difference between these two accounts other than the user name.

I also noticed for some reason it was looking for certificates on the broken EAP. I went to another laptop to use Forticlient to verify it wasn't a laptop issue (it wasn't). I noticed a new entry in our Password Manager. Found out that the PSK was changed to a stronger password but I was not informed. So the end result was that the PSK was incorrect. Which is why it was looking for the certificates. Too bad that wasn't shown more obviously but if you are using SAML with PSK and see a lookup for certs after the above lines check the PSK password.