- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Labels:
-
FortiClient
-
IPsec
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Sir, Can you please run IKE debug with remote gateway address as public ip address of client machine.
diag vpn ike log-filter rem-addr4 x.x.x.x instead of x.x.x.x please write public IP.
diag debug app ike -1
diag debug enable ---> to enable debug
diag debug enable -> disable debug.
Can you please provide us log.
Created on 09-10-2024 01:03 AM Edited on 09-10-2024 01:06 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Patel.
Thank you for your response.
As mentioned in my post we do not receive any output from IKE debug.
I do however see the traffic coming with a diag sniffer.
In this case X.X.X.X is our firewall and Y.Y.Y.Y is my external host.
We pass the SAML Authentication and the connection the client is then stuck in "Connecting" after the 3 IKE packets.
See sniffer output below.
Kind Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Patel.
A bit more sniffer output, alongside with what i see in the IKE debug.
//Sniffer
HHHH-FW01 (CSMG) # diagnose vpn ike log-filter src-addr4 y.y.y.y
HHHH-FW01 (CSMG) # diagnose debug application ike -1
Debug messages will be on for 9 minutes.
HHHH-FW01 (CSMG) # diagnose debug enable
HHHH-FW01 (CSMG) # ike change cfg 1 interface 0 router 0 certs 0
ike config update start
ike ike_embryonic_conn_limit = 20000
ike ikecrypt DH multi-process disabled
ike config update done
ike 1: cache rebuild done
ike 2: cache rebuild done
ike 4: cache rebuild done
ike 5: cache rebuild done
ike 6: cache rebuild done
ike 7: cache rebuild done
ike 8: cache rebuild done
ike 9: cache rebuild done
ike 10: cache rebuild done
ike 12: cache rebuild done
ike 14: cache rebuild done
ike 15: cache rebuild done
ike 17: cache rebuild done
ike 35: cache rebuild done
ike 18: cache rebuild done
ike 20: cache rebuild done
ike 21: cache rebuild done
ike 23: cache rebuild done
ike 24: cache rebuild done
ike 25: cache rebuild done
ike 27: cache rebuild done
ike 28: cache rebuild done
ike 29: cache rebuild done
ike 30: cache rebuild done
ike 31: cache rebuild done
ike 33: cache rebuild done
ike 19: cache rebuild done
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you using Window 10 or Windows 11. Please check this article:
Things you need to confirm:
1- Confirm the config sys global > set remoteauthtimeout has high value
2-Force NAT-T on the dialup ipsec vpn and re-test the issue
3-Disable any security software and Windows defender
4-Try other PC with different OS and re-test
As above the debug output will help in finding the root cause.
Hope this help
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Art.
Thank you for your response.
NAT-T is forced and remote auth is set to max for this test scenario.
A clean PC with no Defender has been used to test as well as an Ubuntu and Mac client.
As mentioned in Patels post, we do not receive any IKE debug output despite our client exchanging packets during the SAML authentication and 3 IKE packets being sent.
Kind Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @k4tamai
Do you have multiple dialup IPsec tunnels on the firewall if yes then use peerid to specify the relevant tunnel with the help of aggressive mode?
Refer to the article: https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-Peer-IDs-to-select-an-IPSec-dia... for more details.
Regards,
Rahul Kaushik
Created on 09-10-2024 01:08 AM Edited on 09-10-2024 01:17 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rahul.
Thank you for your response.
This is the only dialup IPsec in this VDOM.
We have tried using IKEv1 with agressive mode as well as IKEv2 to no avail.
Kind Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey k4tamai,
you could try disabling IPSec offloading, if you have a hardware model:
https://docs.fortinet.com/document/fortigate/7.4.4/hardware-acceleration/636026
That might be why you're not seeing any IKE debug?
Aside from that, double-check that you have the correct IPSec configuration to ensure that the FortiClient reaches FortiGate; usually if there is no IKE debug at all, I would assume some kind of connectivity issue, like IKE being blocked on an ISP level (though you did mention you observed some IKE packets, correct?)
Cheers,
Debbie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Debbie.
Thank you for your response.
I have tried disabling NPU offloading with the same result as earlier.
As you can see from my log the Firewall and the client exchanges IKE packets (x.x.x.x being firewall and y.y.y.y being client) - IKE debug output remains empty.
Kind Regards.