Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
k4tamai
New Contributor II

Forticlient IPSEC w/ SAML stuck in connecting

Hi Guys.

 

I have starved my own knowledge and googlefu so i hope someone in here can help me.

We are transitioning from SSLVPN to IPSEC VPN and want to keep using our SAML setup.

 

When trying to connect to the IPSEC VPN tunnel i get prompted with my SAML prompt, enter my credentials, log in and the client then hangs in "Connecting".

In my debug i see the SAML request being processed and completes as it should but i see no IKE debug prompts.
Nothing appears in my VPN log either. 
The only thing i can see is in my Forticlient, where i get an error regarding power which i reckon is not related to this.

 

When connecting to the SSLVPN (same public IP, different ports ofc.) i go straight through and connect with no issues.

 

Does anyone have any idea why i am stuck in "Connected" when my SAML request is processed?

Kind Regards

EDIT:
We have tested with Forticlient versions 7.2.4, 7.2.5 and 7.4.0 and with different vendors of net adapters and from different locations.

1 Solution
k4tamai
New Contributor II

Hi Qim!

Thank you for reminding me of this post.

I meant to return with an update, but forgot it.

 

Yes! We did solve the issue!

 

So, in my case, i saw that samld processed the request correctly but an error in fnbamd with no data on ike debug.

 

What we found out was, on the Azure enterprise application, all the groups that the user belongs to were pushed after successful authentication. The samld was able to retrieve them but the eap_proxy was unable to handle this large amount of groups - This was diagnosed by running the command "diagnose debug application eap_proxy"

 

We resolved the issue by going to the enterprise application and changing the settings on the group claim from (Which groups associated with the user should be returned in the claim?) from "Security Groups" to "Groups assigned to the application".

 

Hope this helps you with changing to IPSEC with SAML authentication and thank you for reminding me of this support ticket.

 

Kind Regards.

 

Commands used to diagnose issue:

diagnose debug application samld -1 - Used to diagnose the processing of the SAML claim to confirm that SAMLD processes the request properly and receives the desired groups from claims.

 

diagnose debug application fnbamd -1 - This was used to diagnose the authentication process where we found out that the fortigate auth daemon processed the authentication request but reported an error that there was no group match despite saml reporting a group match.

 

diagnose debug application eap_proxy -1 - Was used to diagnose the IKEv2 / RADIUS data procesed by fortigate(someone correct me if i am way off). This command showed that the group buffer was full, indicating that the amount of groups parsed from saml to eap_proxy / fnbamd was incomplete, which led us to change the group claim on the enterprise application to only parse groups assigned application instead of all groups the user is a member of.

View solution in original post

12 REPLIES 12
k4tamai
New Contributor II

I have come closer with doing more debugging.

SAMLD debugging shows correct authentication.

AUTHD debugging shows correct SAML auth ID.

However, FNBAMD debugging below i see that my user is validated and that my group is matched and hereafter the VPN disconnects on my machine but is stuck on "Connecting".

However in the end of the log it says that group matching is failed. 

 

I am at a complet loss and unsure how to further troubleshoot this issue as, in my eyes, my user is validated but then... Not validate?

 

@Debbie_FTNT @rahulkaushik-22 @FortiArt @tpatel  - Giving you all a tag since you're involved in this support thread already - Sorry if this is an inconvenience.

 

 

[139] __saml_auth_cache_push-Hash bucket 252
[186] __saml_auth_cache_push-New auth cache entry is created, user='9BF44FB39C2E48FEA8D03FB7CEBC08E1', expires=1725978932, SAML_server='csmg-ipsec-saml', vfid=10
[1383] __fnbamd_rad_send-Sent radius req to server 'eap_proxy': fd=13, IP=127.0.0.1(127.0.0.1:1812) code=1 id=101 len=259 user="9BF44FB39C2E48FEA8D03FB7CEBC08E1" using EAP
[1283] send_radius_challenge_rsp-Timer of rad 'eap_proxy' is added
[1890] handle_req-Rcvd auth req 1922809002 for 9BF44FB39C2E48FEA8D03FB7CEBC08E1 in opt=00000000 prot=4
[473] __compose_group_list_from_req-Group 'sg-vpn-daily', type 1
[969] fnbamd_saml_auth_cache_lookup-Authneticating '9BF44FB39C2E48FEA8D03FB7CEBC08E1'.
[1003] fnbamd_saml_auth_cache_lookup-Authentication passed.
[234] __clear_one_entry-'9BF44FB39C2E48FEA8D03FB7CEBC08E1' is cleared.
[1931] handle_req-r=0
[1616] fnbam_user_auth_group_match-req id: 1922809002, server: csmg-ipsec-saml, local auth: 0, dn match: 0
[1585] __group_match-Group 'sg-vpn-daily' passed group matching
[1588] __group_match-Add matched group 'sg-vpn-daily'(2)
[1949] handle_req-Passed group matching
209] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 1922809002, len=5131
[47] handle_rad_timeout-rad 'eap_proxy' 127.0.0.1 timed out, resend request.
[1383] __fnbamd_rad_send-Sent radius req to server 'eap_proxy': fd=13, IP=127.0.0.1(127.0.0.1:1812) code=1 id=101 len=259 user="9BF44FB39C2E48FEA8D03FB7CEBC08E1" using EAP
[63] handle_rad_timeout-Timer of rad 'eap_proxy' is added
[1428] fnbamd_auth_handle_radius_result-Timer of rad 'eap_proxy' is deleted
[1863] fnbamd_radius_auth_validate_pkt-RADIUS resp code 11
fnbamd_dbg_hex_pnt[48] EAP msg from server (56)-01 D1 00 38 1A 03 D0 00 33 53 3D 38 35 43 41 32 42 33 30 39 31 44 30 37 33 38 34 33 39 36 46 45 38 37 46 37 41 45 41 38 37 41 41 35 31 35 36 43 39 39 38 20 4D 3D 4F 4B
[1454] fnbamd_auth_handle_radius_result-->Result for radius svr 'eap_proxy' 127.0.0.1(1) is 2
[209] fnbamd_comm_send_result-Sending result 2 (nid 0) for req 1922809001, len=2596
[1261] freeze_auth_session-
[2321] handle_req-Rcvd chal rsp for req 1922809001
[342] fnbamd_create_radius_socket-Opened radius socket 13
[342] fnbamd_create_radius_socket-Opened radius socket 14
[1454] fnbamd_radius_auth_send-Compose RADIUS request
fnbamd_dbg_hex_pnt[48] EAP msg from client (6)-02 D1 00 06 1A 03
[1383] __fnbamd_rad_send-Sent radius req to server 'eap_proxy': fd=13, IP=127.0.0.1(127.0.0.1:1812) code=1 id=102 len=174 user="9BF44FB39C2E48FEA8D03FB7CEBC08E1" using EAP
[1283] send_radius_challenge_rsp-Timer of rad 'eap_proxy' is added
[1428] fnbamd_auth_handle_radius_result-Timer of rad 'eap_proxy' is deleted
[1863] fnbamd_radius_auth_validate_pkt-RADIUS resp code 2
[362] extract_success_vsas-FORTINET attr, type 255, val csmg-ipsec-saml
[1723] __radius_decode_mppe_key-Key len after decode 16
[1723] __radius_decode_mppe_key-Key len after decode 16
fnbamd_dbg_hex_pnt[48] EAP msg from server (4)-03 D1 00 04
[1454] fnbamd_auth_handle_radius_result-->Result for radius svr 'eap_proxy' 127.0.0.1(1) is 0
[1479] fnbamd_auth_handle_radius_result-RADIUS auth succeeds with server 'csmg-ipsec-saml'
[1616] fnbam_user_auth_group_match-req id: 1922809001, server: csmg-ipsec-saml, local auth: 0, dn match: 0
[280] find_matched_usr_grps-Failed group matching

qim
New Contributor

Hello @k4tamai,

Did you manage to find a solution ?

I am facing the same issue with IPSEC SAML on a fortigate 80E running 7.2.4 and forticlient 7.4.0.1658.

 

 

k4tamai
New Contributor II

Hi Qim!

Thank you for reminding me of this post.

I meant to return with an update, but forgot it.

 

Yes! We did solve the issue!

 

So, in my case, i saw that samld processed the request correctly but an error in fnbamd with no data on ike debug.

 

What we found out was, on the Azure enterprise application, all the groups that the user belongs to were pushed after successful authentication. The samld was able to retrieve them but the eap_proxy was unable to handle this large amount of groups - This was diagnosed by running the command "diagnose debug application eap_proxy"

 

We resolved the issue by going to the enterprise application and changing the settings on the group claim from (Which groups associated with the user should be returned in the claim?) from "Security Groups" to "Groups assigned to the application".

 

Hope this helps you with changing to IPSEC with SAML authentication and thank you for reminding me of this support ticket.

 

Kind Regards.

 

Commands used to diagnose issue:

diagnose debug application samld -1 - Used to diagnose the processing of the SAML claim to confirm that SAMLD processes the request properly and receives the desired groups from claims.

 

diagnose debug application fnbamd -1 - This was used to diagnose the authentication process where we found out that the fortigate auth daemon processed the authentication request but reported an error that there was no group match despite saml reporting a group match.

 

diagnose debug application eap_proxy -1 - Was used to diagnose the IKEv2 / RADIUS data procesed by fortigate(someone correct me if i am way off). This command showed that the group buffer was full, indicating that the amount of groups parsed from saml to eap_proxy / fnbamd was incomplete, which led us to change the group claim on the enterprise application to only parse groups assigned application instead of all groups the user is a member of.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors