Palo Alto GlobalProtect 2FA over RADIUS, without a separate RADIUS server

Palo Alto Networks firewalls can send GlobalProtect VPN logins to a RADIUS server. That is all the Notakey auth-proxy needs: it sits in the RADIUS path and only lets a login through once the user has approved it on their phone.

The usual objection is the RADIUS server itself. Many teams do not run one, and building FreeRADIUS or Microsoft NPS just to add a second factor is a project of its own. This guide uses the RADIUS plugin that ships with the Notakey on-premise appliance instead, so the appliance is the whole back end: proxy, RADIUS and phone approval in one place.

We have not lab-tested a Palo Alto firewall ourselves. The Palo Alto settings below come from Palo Alto’s documentation, with links. The firewall talks to the auth-proxy over standard RADIUS, the same way the VPN concentrators in our other guides do.

How it fits together

GlobalProtect app ──▶ Palo Alto portal/gateway ──RADIUS──▶ Notakey auth-proxy ──RADIUS──▶ RADIUS plugin
                                                                  │
                                                                  └──▶ approval request ──▶ user's phone

The user connects with GlobalProtect and enters a username and password.
The firewall sends a RADIUS request to the auth-proxy on the appliance.
The proxy passes the password check to the RADIUS plugin. A wrong password is rejected straight away.
If the password is accepted, the proxy sends an approval request to the user’s phone and holds the RADIUS exchange open while the user decides, 30 seconds by default.
Approve, and the firewall gets Access-Accept. Deny or no answer, and the login is rejected.

What the plugin changes about the password

There is a trade-off to weigh before you choose the plugin. The plugin does not check the user’s directory password. It accepts either one global password shared by everyone, or a short list of per-user passwords kept in the plugin’s configuration (RADIUS service plugin).

In practice that means the phone approval is what protects the login: the request goes to the phone enrolled for that username, and the person holding it sees what they are approving. With the global password, the password step is a shared gate rather than a second secret per user.

If your policy or auditor expects the directory password as one of the two factors, point the auth-proxy at a RADIUS server that checks Active Directory, such as Microsoft NPS, instead of the plugin. Everything on the Palo Alto side of this guide stays the same; only the proxy’s downstream address and secret change, as described in our VPN 2FA with RADIUS guide.

Step 1 — Create the VPN application in Notakey

In the Notakey dashboard, create an application (service) for the VPN, onboard the users’ phones, and copy the application’s Access ID.

The username the user types in GlobalProtect must reach the proxy exactly as it was onboarded in Notakey. Keep that in mind in step 4, where Palo Alto can add or strip a domain.

Step 2 — Start the RADIUS plugin on the appliance

On the appliance CLI, set the plugin image, replace the default secret and password, and start it. Do not leave the defaults in place: they are published in our documentation.

ntk cfg setc :plugins.radius.image "notakey/radius-all:latest"
ntk cfg setc :plugins.radius.env.SECRET "<long-random-secret>"
ntk cfg setc :plugins.radius.env.PASSWORD "<global-password>"
ntk plugins update
ntk plugins start

PASSWORD is the global password users type in GlobalProtect. To give specific users their own password instead, add USER1/PASSW1, USER2/PASSW2 and so on; the full list of options is in the plugin article.

Step 3 — Point the auth-proxy at the plugin

The proxy finds the plugin by its container name, radius. Use the same secret on both sides, as the plugin article describes; the firewall will use it too.

ntk cfg set :ap.vpn_port_in "1812"
ntk cfg set :ap.vpn_radius_address "radius"
ntk cfg set :ap.vpn_secret_in "<long-random-secret>"
ntk cfg set :ap.vpn_secret_out "<long-random-secret>"
ntk cfg set :ap.vpn_access_id "<access-id-from-step-1>"
ntk cfg set :ap.vpn_message_ttl "30"
ntk cfg set :ap.message_title "VPN login"
ntk cfg set :ap.message_description "Allow {0} to connect to the VPN?"
ntk ap start

vpn_message_ttl is how long the user has to approve. {0} in the description is replaced with the username. The proxy listens for RADIUS on UDP port 1812; the firewall must be able to reach the appliance on that port.

One difference from other VPNs: with GlobalProtect, do not expect the user’s IP address on the approval card. The auth-proxy reads the client address from the standard RADIUS attribute for it, Calling-Station-Id. GlobalProtect does not put the client’s IP there; it sends it only in Palo Alto’s own vendor-specific attribute (SecureAuth’s note on this behaviour). Write the description so the card still tells the user what they are approving: the service and the username.

Step 4 — Configure the Palo Alto firewall

Palo Alto’s guide Set Up RADIUS or TACACS+ Authentication covers the general steps. These are the settings that matter for a phone approval.

RADIUS server profile (Device → Server Profiles → RADIUS) (field reference):

Server: the appliance’s address, port 1812, and the secret from step 3.
Timeout: the default is 3 seconds, which is enough for a password check and nowhere near enough for a person to find their phone. The allowed range is 1–120 seconds, and Palo Alto’s own note for multi-factor setups is to give users enough time to respond. Set it comfortably above the proxy’s 30-second window, for example 60.
Retries: the default is 3. With a long timeout, 1 is enough. If the firewall does resend a request, the auth-proxy recognises it and ignores it, so the user does not get a second approval.
Authentication Protocol: choose PAP. The default, PEAP-MSCHAPv2, wraps the login in an encrypted tunnel and, by default, hides the user’s identity in the outer request. The proxy needs to read the username to know whose phone to ask. PAP is the option Palo Alto lists for a RADIUS server that does not use EAP or CHAP. With PAP, RADIUS sends the username in clear text and hides only the password, using the shared secret (RFC 2865). Keep the firewall-to-appliance link on a trusted network and the secret long and random.

Authentication profile (Device → Authentication Profile):

Type: RADIUS, with the server profile above.
Username Modifier: %USERINPUT% passes the username unchanged. If you set a User Domain, Palo Alto prepends or appends it, or strips a domain the user typed. Whatever the result is, it must match the username onboarded in Notakey.
Allow List (Advanced tab): the list is empty by default, which blocks everyone. Add the users or groups who should connect, or all.

Portal and gateway: add the authentication profile to the client authentication settings of the GlobalProtect portal and gateway, then commit.

Step 5 — Avoid two approvals per connection

A GlobalProtect connection authenticates twice: once to the portal and once to the gateway. With RADIUS on both, the user gets two approval requests for one connection, which is exactly the kind of noise that teaches people to approve without reading.

Palo Alto’s authentication override cookies solve this (portal authentication settings). The portal issues an encrypted cookie after the first successful login, and the gateway accepts it instead of asking again:

On the portal, enable Generate cookie for authentication override.
On the gateway, enable Accept cookie for authentication override.
Use the same certificate on the portal and the gateway to encrypt and decrypt the cookie.
Choose the cookie lifetime deliberately. While the cookie is valid, the user is not asked again, so a long lifetime means fewer approvals and also less protection if the laptop is stolen.

Test it

Connect with GlobalProtect. After the password, the approval request arrives on the phone with the title and description you set in step 3. Approve, and the tunnel comes up. Then try once more and deny: the connection must fail.

If logins fail even when you approve quickly, check the timeouts first:

the RADIUS server profile timeout on the firewall, which must be longer than the proxy’s 30 seconds;
GlobalProtect’s own connection timeout. Administrators on Palo Alto’s community forum report raising it for multi-factor logins (community thread). If approvals late in the window fail but quick ones work, this is the likely cause; raise that timeout, or shorten vpn_message_ttl.

What this does not cover

Relayed phishing logins. A phone approval stops a stolen or guessed password from being enough on its own. It does not stop an attacker who relays a real login through a fake page in real time; only site-bound methods such as FIDO keys do that. We explain the difference in our post on MFA fatigue and relay attacks.
The firewall’s own exposure. Why a password-only VPN or management login is a problem, and what else to fix first, is in our FortiBleed post. The lessons apply to any vendor’s firewall.

Try the live demo to approve a login from your own phone in about two minutes, or request a demo and we will help you plan a GlobalProtect pilot.