How to Secure Cisco AnyConnect, Fortinet, and Palo Alto VPNs with RADIUS MFA

VPN is the first thing attackers test when they're trying to get inside a network. Not because VPN is technically weak — it's not — but because it's the front door, it's usually internet-facing, and in most organizations it asks for exactly one thing: a username and a password.

That's the problem. The credential stuffing tooling available today can process millions of username/password pairs against a VPN endpoint in hours. Phishing campaigns specifically harvest VPN credentials because they're the most direct path to a network-level foothold. And when an attacker does get in through VPN, they arrive with a legitimate-looking session — no exploit traffic, no unusual ports, nothing that signature-based detection catches.

The answer isn't a better password policy. It's a second factor that the attacker can't obtain from a breach dump or a phishing page. This article walks through how RADIUS MFA actually works in the three VPN environments that come up most often in enterprise networks: Cisco AnyConnect, Fortinet FortiGate, and Palo Alto GlobalProtect.

How RADIUS MFA Works with VPNs: The Authentication Flow

Before getting into vendor specifics, the architecture is worth understanding, because it's identical across all three platforms.

Your VPN gateway — the ASA, the FortiGate, or the GlobalProtect gateway — is configured to use RADIUS for authentication. That hasn't changed. What changes is where the RADIUS request goes: instead of pointing directly at Active Directory or your existing NPS server, the gateway points at a RADIUS MFA proxy.

The flow looks like this:

User enters credentials in VPN client

↓

VPN gateway sends Access-Request to RADIUS MFA proxy (UDP 1812)

↓

Proxy validates password against AD / LDAP

↓ [password correct]

Proxy sends Access-Challenge back to gateway: "Enter your OTP"

↓

VPN client displays secondary prompt to user

↓

User enters TOTP code from authenticator app or hardware token

↓

Gateway sends second Access-Request with OTP

↓

Proxy validates OTP

↓

Access-Accept returned to gateway → session established

Two things worth noting here. First, the VPN gateway doesn't "know" about MFA — it's just doing standard RADIUS challenge/response, which every modern VPN platform supports. Second, if your VPN client doesn't handle Access-Challenge well (some older configurations don't), there's a fallback: password concatenation, where the user types their password and TOTP code together in a single field, like MyPassword123456. The proxy parses out the last N digits as the OTP. Less clean UX, but it works with any RADIUS client without exception.

Cisco AnyConnect + RADIUS MFA

Cisco AnyConnect is the most common enterprise VPN client, running on either an ASA (Adaptive Security Appliance) or an FTD (Firepower Threat Defense) device. Both support RADIUS natively and handle Access-Challenge correctly, which means the full interactive OTP flow works without workarounds.

AAA Server Configuration on ASA

On the ASA side, RADIUS MFA configuration lives in the AAA server group settings. You're creating a new AAA server group that points to the Protectimus RADIUS proxy instead of (or in addition to) your existing RADIUS/NPS server.

Key parameters to configure:

• Server IP: the IP address of your Protectimus RADIUS proxy
• Authentication port: UDP 1812
• Shared secret: must match what you configured on the Protectimus side
• Retry interval: 10–15 seconds (MFA challenges need slightly more time than a simple password check)
• Server type: RADIUS with password management enabled if you need to handle AD password expiry through the VPN client
  

In ASDM: Configuration → Remote Access VPN → AAA/Local Users → AAA Server Groups → Add. Create a new group, add the Protectimus server, set the timeout to at least 60 seconds (users need time to check their phone and enter the code).

On FTD, the same configuration sits under Objects → Object Management → RADIUS Server Group in FMC, or under AAA settings in FDM for smaller deployments.

Connection Profile and Tunnel Group

The tunnel group (connection profile) needs to reference the new AAA server group. Under Configuration → Remote Access VPN → Network (Client) Access → AnyConnect Connection Profiles, edit the relevant profile and set the authentication server group to your new Protectimus RADIUS group.

One practical consideration: if you're running multiple connection profiles (separate profiles for employees vs contractors, or for split-tunneling vs full-tunnel), you can apply RADIUS MFA to specific profiles only. This lets you roll out MFA to a pilot group before enforcing it universally. The VPN RADIUS MFA integration guide covers the full ASA and FTD configuration path with step-by-step CLI and ASDM instructions.

Authentication Policies

For environments using Cisco ISE alongside ASA, the authentication flow can go: ASA → ISE → Protectimus RADIUS proxy → AD. ISE handles authorization policies; Protectimus handles the MFA layer. The proxy fits into the chain without ISE needing any awareness of MFA — it sees the final Accept or Reject and applies its policies accordingly.

Fortinet FortiGate + RADIUS MFA

FortiGate's SSL VPN is the other VPN platform that shows up constantly in mid-market enterprise environments. The RADIUS configuration is straightforward; the nuance is in how FortiGate handles the OTP prompt depending on the authentication flow.

RADIUS Server Config on FortiGate

In the FortiGate web UI: User & Authentication → RADIUS Servers → Create New.

Parameters:

• Name: anything descriptive (e.g., Protectimus-MFA)
• Primary server IP: Protectimus RADIUS proxy address
• Primary server secret: shared secret (min 16 characters recommended)
• Authentication method: select MS-CHAPv2 or PAP depending on your setup — PAP is required if you're using password concatenation mode; MS-CHAPv2 works with standard challenge/response
• Include in every user group: leave unchecked unless you want it applied universally at this stage

After creating the RADIUS server, add it to a User Group: User & Authentication → User Groups → Create New, set Type to Firewall, add the RADIUS server as a remote group member.

SSL VPN Authentication

Under VPN → SSL-VPN Settings → Authentication/Portal Mapping, assign the user group with RADIUS MFA to the appropriate SSL VPN portal. Users in that group hitting the SSL VPN login page will authenticate against the RADIUS proxy, which triggers the OTP challenge.

FortiGate's web-mode SSL VPN (browser-based) handles the Access-Challenge cleanly — users see a second field asking for a verification code after their password is accepted. Tunnel-mode with the FortiClient app also handles challenge/response, though the UX differs slightly by FortiClient version.

User Group and SSL VPN Auth Specifics

One gotcha with FortiGate: the RADIUS server timeout default is 5 seconds. For MFA where users need to retrieve a TOTP code, this is too short. Increase it to 60 seconds under the RADIUS server configuration (nas-ip, timeout field in CLI):

config user radius

edit "Protectimus-MFA"

set timeout 60

next

end

Without this change, users who take more than 5 seconds to enter their OTP will see authentication failures that look like server errors, not timeout issues — a frustrating troubleshooting experience.

Palo Alto GlobalProtect + RADIUS MFA

GlobalProtect has a slightly different architecture from the other two. Authentication for GlobalProtect passes through an Authentication Profile, which references a RADIUS server profile. The MFA layer fits in at the Authentication Profile level.

Authentication Profile Setup

In Panorama or the local firewall web UI: Device → Authentication Profile → Add.

• Type: RADIUS
• Server Profile: create a new RADIUS Server Profile under Device → Server Profiles → RADIUS
  • Server address: Protectimus RADIUS proxy IP
  • Port: 1812
  • Secret: shared secret
  • Timeout: 60 seconds (same reasoning as FortiGate)
  • Retries: 3
    

Under the Authentication Profile, set the allowed list to the appropriate user group or leave it open during testing.

RADIUS Server Profile and MFA Scenario

GlobalProtect Gateway and Portal both have authentication settings that reference an Authentication Profile. Assign the Protectimus-backed profile to the Gateway authentication (which handles actual tunnel authentication) rather than just the Portal (which handles pre-login). Most MFA enforcement should happen at the Gateway level.

GlobalProtect's handling of RADIUS Access-Challenge is solid in current GP versions (5.x and later). The client displays a "Additional Authentication Required" prompt where the user enters their OTP. For environments running older GP clients that don't display the challenge prompt cleanly, password concatenation mode works as an alternative — configure the expected OTP length in Protectimus (typically 6 digits) and instruct users to append their TOTP code to their password.

Protectimus RADIUS Server Component for Palo Alto

The Protectimus RADIUS server component handles the proxy role for all three platforms with the same configuration on the Protectimus side. You add each VPN gateway as a RADIUS client with its IP and shared secret, configure the upstream AD/LDAP connection once, and the same setup serves Cisco, Fortinet, and Palo Alto simultaneously. User enrollment is also shared — a user who enrolls their TOTP token for Palo Alto GlobalProtect is automatically covered for AnyConnect and FortiGate through the same account.

Common Pitfalls and How to Avoid Them

After working through RADIUS MFA integrations across different environments, the failure modes cluster around a few consistent issues.

OTP timeout on VPN. Already mentioned for FortiGate and Palo Alto, but it applies to Cisco too. The default RADIUS timeout on many VPN devices is 5–10 seconds — designed for instant password validation, not for a human retrieving a time-based code. Set it to 60 seconds across the board. Users who work fast will still get through in 5 seconds; users who need to unlock their phone won't see spurious errors.

Fallback policy during MFA outage. What happens if the Protectimus RADIUS proxy goes offline? If you've configured no fallback, every VPN user is locked out until the proxy comes back. The right answer is HA (primary + secondary RADIUS server configured on the VPN gateway), not a bypass policy. A bypass that allows password-only auth "during outages" is an attack surface; any adversary who can take down the proxy — or simply wait for an unplanned outage — can remove the second factor.

Testing MFA bypass scenarios. Before you go live, test what happens when someone deliberately tries to skip the second factor. Attempt to send an Access-Request without responding to the Access-Challenge. Attempt concatenation mode with an incorrect OTP appended. Verify that Access-Reject comes back in every bypass attempt, not Access-Accept.

HA failover behavior. When the primary RADIUS server goes down and the gateway fails over to the secondary, users shouldn't be required to re-enroll their tokens. Verify that your secondary Protectimus instance shares enrollment data with the primary before you treat HA as "configured."

The full configuration path — from initial proxy setup through HA testing and bypass verification — is covered in the RADIUS multi-factor authentication for FortiGate and other VPN gateways deployment guide.

Conclusion

RADIUS MFA for VPN isn't complicated once you understand the proxy model. Your VPN gateway doesn't change how it talks RADIUS — it just talks to a different server. That server validates the password upstream and enforces the second factor before returning an Accept. The VPN platform is irrelevant to that logic; Cisco, Fortinet, and Palo Alto all use the same RADIUS protocol in the same way.

The configuration differences between the three platforms are real but shallow: timeouts, authentication method selection (PAP vs MS-CHAPv2), where in the UI the RADIUS server gets assigned. Once you've done one, the others take minutes.

What matters is getting it deployed. Every day a VPN endpoint accepts password-only authentication is a day that a credential from last year's breach dump could be the key to your network.