Intermittent connection issue with FortiClient on Mac - Azure AD SSO Integration - Error -1001
I'm experiencing a peculiar issue with our FortiClient VPN on Mac systems and I was hoping to get some guidance or suggestions from this community.
We have integrated Azure AD SSO with our Fortigates within our organization. The problem we're facing is quite aleatory. Mac users, when trying to connect, occasionally receive an error message stating: "Network error. Cannot connect to VPN server". The strange thing is that after several connection attempts, they are eventually able to connect. I've tried a number of troubleshooting steps, but the problem persists:
I've tried reinstalling the FortiClient and clearing the configuration cache, but neither seems to have any effect.
We're using the latest FortiClient version, 7.0.8. We also tested with previous versions, but faced other issues related to known bugs with SAML SSO.
If I set the public IP address instead the FQDN as the remote gateway, it connects at the first try.
The client side network is fine, I tested this by myself and could connect to other VPNs from other vendors without any issue.
There is no AV active with mac users.
Accessing the VPN web portal via a web browser also works without any issues.
Below is the fortitray.log with details (I removed sensitive data):
After analyzing the session, it appears that there is no subsequent message following the last occurrence of "samld_send_common_reply ." In a successful connection, however, I would typically expect to receive "__samld_sp_login_resp " along with the corresponding SP Login Response Message Body.
Hi all, I went deeper in the troubleshooting and found out that this happens also in notebooks with Windows and it looks like there is some extrange behaviour with the DNS resolution from the FortiClient app itself.
We have a load balancer that resolves vpnssl.corp.com with two IPs, and there is a sticky connection rule to resolve the same IP depending the source IP address
Tests performed from macOS 13.4.1 and Windows 10:
I started with a "flushdns" before conducting the tests.
When performing a DNS query from the command line interface to vpnssl.corp.com, it provides us with the IPs 666.666.666.666 (primary) and 777.777.777.777 (secondary).
The Wireshark capture begins.
I open FortiClient and initiate the VPN connection. In Wireshark, I observe that the traffic is directed to 666.666.666.666 for SAML login. Once both the credentials and the token are accepted, the traffic is redirected to 777.777.777.777.
The 777.777.777.777 FGT send a RST message, I assume this happens because all the login went to the other host.
I also tried the FortiClient v7.2.0 but with the same result
FortiClient performs a single DNS query at the start of the connection, where it receives the two IPs of vpnssl.corp.com.
FortiClient manages to validate the credentials but then, for some reason, it attempts to establish the connection against the secondary node.
I identified in the wireshark capture that FortiClient makes the decision to route the traffic to the secondary node without performing a new DNS query. This leads me to believe that it might be storing both IPs in the application's code and, by mistake, uses the secondary one at some point.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.