The Packet Blog

To start, this is likely not the same level of complexity as a fully developed vendor solution, but in our case, we were dealing with one that was clearly not polished to the degree we required. Some of these steps helped us solve issues with utilizing Radius for VPN users…

Our goal is straightforward, we just need MFA enabled on our VPN setup using GlobalProtect, which is tied to LDAP for the first authentication step. The details of this are omitted and will be included in a different post. Unfortunately, while the initial phase of implementation went rather smoothly (See this post for setting up GlobalProtect 2FA), the end-user experience was severely stunted and resulted in a backlash of tickets. When users would connect, sometimes the MFA notifications wouldn’t send and other times they would send and then the connection would fail upon hitting accept. This triggered VPN client into thinking that the credentials were incorrect (since it sees the MFA request as part of the saved credentials), which prompted further tickets claiming that the username and password was not saved properly. In essence, the client couldn’t distinguish between a failure of authenticating the credentials (first step) and failing with the MFA method (second step).

After some persistent research, it seemed that the issue was either caused by misconfigured timeout parameters on either end, or something inherent to Freeradius (at least the way this vendor had it configured). Radius “Access-Challenges” seemed to be the way to go, to at least move from a push-notification model to TOTP and see if that would eliminate the issue with relying on a notification timeout.

I was able to somewhat simulate a 2FA environment by spinning up my own FreeRadius server and configuring NTLM_AUTH (MSCHAP) as the first authentication (first access-request), initiate an access-challenge (along with a session ‘state’ variable), then accept the session state with a pseudo OTP code. Next, I tested multiple users connecting to the Radius Server simultaneously. When using the access-challenge, it split off the authentication for the Active Directory credentials into the first request then allowed the user to finish authentication and finally receive an access-accept message once the VPN client returned the session variable along with the OTP.

This process did solve the problem that we are having with the Radius server being unable to process multiple requests at the same time by breaking up the different factors of authentication into two access-requests and only allowing the user to connect (send the access-accept) once they send the correct code for the second access-request.

• If you’re having issues with Radius MFA timeouts, try implementing native “access-challenges”. This will split up the the authentication (username/password + MFA TOTP/Push) into two phases which eliminates the issue of authentication timeouts.

To help visualize how this would help fix the issue:

[Session 1] User A sends an ACCESS-REQUEST and provides AD Credentials – match found, success

User A is given a state variable and asked to provide the OTP

ACCESS-CHALLENGE sent which presents the user with a text box and the “Reply-Message”

[Session 2] User B sends an ACCESS-REQUEST and provides AD Credentials – match found, success

User B is given a state variable and asked to provide the OTP

ACCESS-CHALLENGE sent which presents the user with a text box and the “Reply-Message”

[Session 3] User B connects using the state variable and correct OTP – proxied to MFA API, success

User B is sent an ACCESS-ACCEPT

[Session 4] User A connects using the state variable and correct OTP – proxied to MFA API, success

User B is sent an ACCESS-ACCEPT

Using push notifications, this was happening:

[Session 1] User A sends an ACCESS-REQUEST and provides AD Credentials – match found, success

The MFA service proxies the request through their API and pushes a notification to the users phone…

Session 1 remains open until the user completes the request or the session times out/fails.

[Session 2] User B sends an ACCESS-REQUEST and provided AD Credentials –

RADIUS SERVER is still waiting for Session 1 to complete before processing this request…

Global Protect client reaches timeout and the process fails.