Intermittent SSLVPN / RADIUS issues

[Mikelar]

I'm hoping for a bit of advice from the experts, as I'm fairly stuck with an SSL VPN issue. I'm running a 100D on 5.2.2 with SSL VPN authenticating via a Windows RADIUS server.

Symptoms:

User will connect either via the SSL web portal or SSL client, client will reach ~90% completion then give error -12. User tries again maybe 2 or 3 times, then will authenticate successfully.

VPN logs during these connection attempts will show several entries with 'SSL new connection', but with the user as 'N/A'. There is also usually another entry with 'SSL user failed to login', with the username showing correctly.

Up until now I've had a great deal of difficulty replicating this issue. Not all users are affected, and the ones that are seem to resolve the issue with 2-3 re-tries. This means that by the time the issue is reported from the Helpdesk, it's tough to setup the proper debugs. I've recently found a user that will consistently get 'SSL user failed to login'. I'm not entirely sure if this is the same issue, but it seems related, so I'm hoping I can get some assistance now that I can produce some debug logs.

Debug from Failed User:

2015-08-27 12:38:01 [97:root:10239]sslvpn_authenticate_user:168 authenticate user: [USERNAME_A]

2015-08-27 12:38:01 [97:root:10239]sslvpn_authenticate_user:175 create fam state
2015-08-27 12:38:01 [97:root:10239]fam_auth_send_req:514 with server blacklist:
2015-08-27 12:38:01 [97:root:10239]fam_auth_send_req_internal:414 fnbam_auth return: 4
2015-08-27 12:38:10 [97:root:10239]fam_auth_send_req:514 with server blacklist: #RADIUS_SERVER
2015-08-27 12:38:10 [97:root:10239]fam_auth_send_req:600 task finished with 5
2015-08-27 12:38:10 [97:root:10239]rmt_logincheck.c:250 user[USERNAME_A],auth_type=1 failed [sslvpn_login_unknown_user]

Debug from Successful User:

2015-08-27 14:03:01 [99:root:10245]sslvpn_authenticate_user:168 authenticate user: [USERNAME_B]
2015-08-27 14:03:01 [99:root:10245]sslvpn_authenticate_user:175 create fam state
2015-08-27 14:03:01 [99:root:10245]fam_auth_send_req:514 with server blacklist: 
2015-08-27 14:03:01 [99:root:10245]fam_auth_send_req_internal:414 fnbam_auth return: 4
2015-08-27 14:03:06 [99:root:10245]Auth successful for group SSL_VPN_Group
2015-08-27 14:03:06 [99:root:10245]fam_do_cb:463 fnbamd return auth success.
2015-08-27 14:03:06 [99:root:10245]SSL VPN login matched rule (1).

Note the line "514 with server blacklist" with the return "414 fnbam_auth return: 4". This is reflected in the RADIUS logs from both user connections, with the RADIUS Reason Code 66 = IAS_INVALID_AUTH_TYPE. The difference being that on the second request the RADIUS logs show a return a "Packet Type 2 = Access-Accept" for the successful user, and a "Packet Type 3 = Access-Reject" on the failed user.

The only other major discrepancy I could find is the RADIUS logs reporting the failed user's OU as "domain\username", where as it should be in "domain\container1\container2\username". The two accounts looks identical in AD from what I can see, which is why I'm leaning more towards a configuration issue/bug on the Fortigate.

I'm stumped. Any suggestions on what to try next are welcome. I'm happy to post any further debugs or logs that might help.

Cheers.

[Huey]

Did you evere get resolution to this?  I am seeing something similar.  What debug did you use?

[Mikelar]

Huey wrote:

Did you evere get resolution to this?  I am seeing something similar.  What debug did you use?

Unfortunately not. We had a major issue that took out our firewall recently, and after reloading the exact config to a new model running 5.2.3, the same issues are occurring.

Debug commands used are below:

diag debug app sslvpn -1

diag deb app authd -1

We'll likely move to an MSP hosted VPN in future, so I don't think I'll be spending too much more time on this. I'll be looking to update to 5.2.5 when it's released, hopefully with a bug fix addressing the issue.

[Huey]

Mikelar wrote:

Huey wrote:

Did you evere get resolution to this?  I am seeing something similar.  What debug did you use?

Unfortunately not. We had a major issue that took out our firewall recently, and after reloading the exact config to a new model running 5.2.3, the same issues are occurring.

Debug commands used are below:

diag debug app sslvpn -1

diag deb app authd -1

We'll likely move to an MSP hosted VPN in future, so I don't think I'll be spending too much more time on this. I'll be looking to update to 5.2.5 when it's released, hopefully with a bug fix addressing the issue.

I solved the issue I was having with the 98% issue.  Turns out it is a Microsoft bug.  Heres a link that discusses it.  https://social.technet.microsoft.com/Forums/sharepoint/en-US/133a2d5e-5156-4300-996e-dc53fbe8bcad/mu...

For me, re-install did the trick. 

[Mikelar]

I solved the issue I was having with the 98% issue.  Turns out it is a Microsoft bug.  Heres a link that discusses it.  https://social.technet.microsoft.com/Forums/sharepoint/en-US/133a2d5e-5156-4300-996e-dc53fbe8bcad/mu...

For me, re-install did the trick. 

Thanks for the link, glad to see some kind of evidence that it may not be my config. This actually fits, as one of the user machines that was experiencing this issue could connect without issue under the admin account, but would consistently fail under the user account (using same domain credentials connecting to VPN).

I'll give this a shot when I get some more time for testing.

Cheers.

[emnoc]

"Packet Type 2 = Access-Accept" for the successful user, and a "Packet Type 3 = Access-Reject" on the failed user.

That's normal and actually good since it's message seen from the RADIUS server. The Access-Reject could be sent due to;

 multi-logins active for the same user

 bad username

 bad password

 account disabled

 etc....

Have you query logs on the radius-server or does your radius server allow you to run in a debug mode, to get a look at the user packet flow for authentication directly?

Alternatively can you  test the radius  account locally on the radius server using something like a "radtest" or "radcheck"

Three, to rule out the radius server, if you apply the account locally, does the SSLVPN authenticate 100% of the time.

if the problem is intermittent, I would suspect the RADIUS server(s), How many radius servers do you have? And  What methods of authentication are enabled ( PAP CHAP EAP msCHAP etc....)

[Mikelar]

emnoc wrote:

"Packet Type 2 = Access-Accept" for the successful user, and a "Packet Type 3 = Access-Reject" on the failed user.

That's normal and actually good since it's message seen from the RADIUS server. The Access-Reject could be sent due to;

 multi-logins active for the same user

 bad username

 bad password

 account disabled

 etc....

Have you query logs on the radius-server or does your radius server allow you to run in a debug mode, to get a look at the user packet flow for authentication directly?

Alternatively can you  test the radius  account locally on the radius server using something like a "radtest" or "radcheck"

Three, to rule out the radius server, if you apply the account locally, does the SSLVPN authenticate 100% of the time.

if the problem is intermittent, I would suspect the RADIUS server(s), How many radius servers do you have? And  What methods of authentication are enabled ( PAP CHAP EAP msCHAP etc....)

Thanks for the info, I thought the logs looked fairly normal, this issue has been very tough to track. I've got a few other things to try from other replies, but if this fails I'll test with local accounts and try to confirm the issue only occurs with RADIUS authentication.