Skip to main content
Mikelar
Mikelar
New Member
August 27, 2015
Question

Intermittent SSLVPN / RADIUS issues

  • August 27, 2015
  • 2 replies
  • 16710 views

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.

    2 replies

    Huey
    Huey
    New Member
    September 9, 2015

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

    Mikelar
    MikelarAuthor
    New Member
    September 29, 2015

    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
    Huey
    New Member
    September 29, 2015

    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/multiple-but-not-all-vpn-clients-failing-in-windows-8-and-81?forum=w8itpronetworking

     

    For me, re-install did the trick. 

    emnoc
    emnoc
    New Member
    September 29, 2015

    "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
    MikelarAuthor
    New Member
    September 30, 2015

    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.

    Terms & ConditionsAccessibility statement