LDAP auth intermittent for SSL VPN - slow to connect if it does

[dirvin]

This is on a FortiGate-3000D running v5.4.6. This configuration hasn't been changed in four months or more.

We've had problem with SSL VPN connections being authenticated in the past week, but it's very sporadic.

In the RAS-VPN context, I have several User Groups created. It looks to be 11 of the groups. I'm suspecting some organic growth in the AD group size is causing the issue. As after spreadsheeting the users, it's down to three groups that are having issues. Of those, two of the AD group have 260 users, and the other has 80 users.

We are using a standard LDAP server configuration

Name: LDAP_server_1

ServerIP: x.x.x.x

Server Port: 389

Common Name Identifier: sAMAccountName

Distinguished Name: dc=corp,dc=example,dc=com

Bind Type: Regular

User DN: CN=fortinet_ldap,CN=Users,DC=corp,DC=example,DC=com

Password: xxxxx

Secure Connection: Off

Pushing the Test button results in Successful, and as I said, it's been working for quite some time.

The User Groups are configured with the LDAP_server_1 as a member.

LDAP_server_1 - CN=VPN-Users,OU=SecurityGroups,DC=corp,DC=example,DC=com

At the other side, on the LDAP_server_1, is really the DUO proxy server which is querying the real LDAP side, and using DUO as secondary auth.

As a test, I can change the IP in LDAP_server_1 and point directly to the real LDAP server, disabling DUO and the results do not change.

When a user is having issues, they would get the DUO push, and then after acknowledging, the connect would either timeout, or show a client err (in fact, different client errors). A work-around was moving the user to an alternate VPN group in AD, and then moving them back, which worked only some of the time.

As for the Client side, we are seeing this mainly on Windows, but in the spreadsheet I have it shows Windows 7, Windows 10, OS X 10.13, and OS X 10.14. The actual client versions are 5.4.3, 6.0.2, and 6.0.3 on Windows, and 6.0.2 and 6.0.3 on OS X

The last piece is that when we find a user that cannot connect with the FortiClient, we start troubleshooting with them trying on the web portal, which has worked 100% of the time. The last information seemed to contradict our initial theory that it's LDAP query taking too long, and more on the Fortigate side AFTER auth, possibly having an issue applying a policy to the tunnel being created?

Thanks in advance,

Dean

[FirewallNoob]

By chance, are users entering proper case for their usernames in the fortigate? Using LDAP, it's designed to match case.

Say for example user is John Smith and the Fortigate VPN user is configured as JSmith...

VPN user enters: jsmith

..it will fail.

VPN user enters: JSmith (matching the fgt) it works.