Integrations · Palo Alto GlobalProtect

Palo Alto GlobalProtect 2FA over RADIUS with phone approval

For teams running GlobalProtect on a Palo Alto Networks firewall who want every VPN login approved on the user’s phone, without building a RADIUS server first. The Notakey appliance can be the whole back end: proxy, RADIUS and phone approval in one place.

How it connects

The firewall sends RADIUS, the appliance does the rest

The GlobalProtect portal and gateway send the login to the Notakey auth-proxy over RADIUS. The proxy passes the password check to the downstream RADIUS server, and 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.

If you have no RADIUS server, the RADIUS plugin that ships with the Notakey on-premise appliance is the downstream server. It accepts one global password or a short list of per-user passwords kept in its configuration, so there is no RADIUS user database to build. If you already run Microsoft NPS or another directory-backed RADIUS server, point the proxy at that instead. Everything on the Palo Alto side stays the same; only the proxy’s downstream address and secret change.

The GlobalProtect app, the portal, the gateway and your users’ workflow are unchanged. They type a username and password as before and then tap Approve.

What to know before you start

  • We have not lab-tested a Palo Alto firewall ourselves. The Palo Alto settings come from Palo Alto’s documentation, linked from the guide; the firewall talks to the auth-proxy over standard RADIUS.
  • The RADIUS server profile timeout defaults to 3 seconds and accepts 1 to 120 seconds. It must be longer than the proxy’s 30-second approval window. If quick approvals work and late ones fail, GlobalProtect’s own connection timeout is the likely cause; raise it or shorten vpn_message_ttl.
  • Choose PAP, not the default PEAP-MSCHAPv2. The proxy needs to read the username to know whose phone to ask, and PEAP hides it by default. With PAP the username travels in clear text and only the password is hidden with the shared secret, so keep the firewall-to-appliance link on a trusted network and the secret long and random.
  • The RADIUS plugin does not check the user’s directory password. With the global password, the phone approval is what protects the login. If your policy or auditor expects the directory password as one of the two factors, point the proxy at a RADIUS server that checks Active Directory, such as Microsoft NPS.
  • Do not expect the user’s IP address on the approval card. GlobalProtect does not put the client IP in Calling-Station-Id, which is where the proxy reads it from. Write the approval description so the card still names the service and the username.
  • Without authentication override cookies the user gets two approvals per connection, one for the portal and one for the gateway. Choose the cookie lifetime deliberately: longer means fewer approvals and less protection if the laptop is stolen.
  • A phone approval 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.

From zero to the first approval

  1. 01

    Create the application and start the back end on the appliance

    Create a VPN application in the Notakey dashboard, onboard the phones and copy the Access ID. On the appliance CLI, start the RADIUS plugin with your own secret and password (never the published defaults), then point the auth-proxy at it with the Access ID and the approval message.

  2. 02

    Configure the RADIUS server profile and authentication profile

    On the firewall, add a RADIUS server profile for the appliance on port 1812 with the shared secret, set the timeout comfortably above 30 seconds (for example 60), retries to 1 and the authentication protocol to PAP. Create an authentication profile of type RADIUS, keep the username modifier at %USERINPUT% so it matches the name onboarded in Notakey, fill the allow list, and attach the profile to the portal and gateway.

  3. 03

    Enable authentication override and test

    Turn on cookie generation on the portal and cookie acceptance on the gateway, with the same certificate on both, so one connection gets one approval instead of two. Connect with GlobalProtect, approve the push, then connect again and deny; the second attempt must fail.

Frequently asked questions

Do I need a separate RADIUS server for GlobalProtect 2FA?
No. The RADIUS plugin on the Notakey on-premise appliance can be the downstream server, with one global password or a short per-user list. If the directory password must be one of the factors, point the proxy at Microsoft NPS or another directory-backed RADIUS server instead. The Palo Alto settings come from Palo Alto’s documentation; we have not lab-tested a Palo Alto firewall ourselves.
Which authentication protocol should the RADIUS server profile use?
PAP. The proxy needs to read the username to know whose phone to ask, and the default PEAP-MSCHAPv2 hides it. Keep the firewall-to-appliance link on a trusted network and the shared secret long and random.
Why does the user get two approvals per connection?
The portal and the gateway each authenticate. Enable authentication override cookies on the portal and the gateway, with the same certificate on both, so one connection means one approval.

Guides and documentation

Related products

← All integrations

See your first passwordless login this week

A 30-minute call with an engineer, not a sales deck. We’ll map your VPN, SSO or Windows setup to a working pilot.