Shore Up
A locked office door with a single remote worker outside holding a numbered key card, a guard inside checking it against a list before opening an inner gate to the building's corridors.
Security

Configure GlobalProtect Remote Access VPN on Palo Alto

Ketan Aagja6 min read
No ratings yet

Before you run this

This guide configures a GlobalProtect remote-access (SSL/TLS) VPN on a single Palo Alto firewall: remote users authenticate to a portal, download a client config, and connect through a gateway that drops them into an internal zone with an assigned IP. It is a set of GUI changes plus a commit — there is no shell script here, because on PAN-OS the correct path is the web interface, not a CLI hack.

  • Privileges: you need a firewall administrator account with superuser (or a role that can edit Network, Objects, Policies, Device, and commit). All work is in the web UI at https://<firewall-mgmt-ip>.
  • This changes production forwarding. You will create a new tunnel interface, a new zone, an IP pool, and security policy rules. A wrong security or NAT rule can expose internal networks or break existing traffic, and a bad interface/zone change can cut sessions.
  • Keep a separate way in. Have a console cable or out-of-band management session open the whole time. If you lock yourself out of the web UI over the data plane, you will need it.
  • Back up first. Go to Device > Setup > Operations and Save named configuration snapshot (and Export named configuration snapshot to your workstation). PAN-OS has no timed auto-rollback like commit-confirmed on other platforms, so your rollback is manual: Device > Setup > Operations > Load named configuration snapshot (or Load configuration version) then commit. To discard uncommitted edits, use Config > Revert Changes.
  • Do this in a maintenance window, and if you have a lab or spare VM-Series, build it there first. Read every value before you commit — a commit is atomic and applies everything at once.

Assumptions: PAN-OS 11.1, a single firewall (hardware or VM-Series), one external-facing gateway, local database authentication to keep the example self-contained, and a trust/internal zone that already exists. I note where LDAP/RADIUS/SAML would slot in. A note on licensing: a basic single-gateway VPN like this works without a GlobalProtect subscription; the subscription is required for HIP checks, multiple gateways, clientless VPN, and the mobile app.

1. Download a GlobalProtect app package

The firewall must host at least one client version. Go to Device > GlobalProtect Client, Check Now, then Download and Activate a version. Without an activated package the portal has nothing to hand out.

2. Create the tunnel interface and VPN zone

Network > Interfaces > Tunnel > Add. Create tunnel.1. Assign it to your Virtual Router and to a new zone you create here (call it vpn). Leave it with no IPv4 address — GlobalProtect assigns client addresses from a pool, not from the tunnel interface.

Confirm the new zone exists under Network > Zones (vpn, type Layer3).

3. Certificates and the SSL/TLS Service Profile

Clients must trust the portal/gateway certificate. The clean way is a publicly signed server certificate whose CN/SAN matches the FQDN users will type (e.g. vpn.example.com). For a lab you can self-sign:

  • Device > Certificate Management > Certificates > Generate. First generate a root CA (tick Certificate Authority), then generate a server certificate signed by that CA, with Common Name = your VPN FQDN and a matching SAN (Hostname). Self-signed means clients see a trust warning unless you push the root CA to them.
  • Device > Certificate Management > SSL/TLS Service Profile > Add. Name it (e.g. gp-ssl-profile), select the server certificate, and set Min Version TLSv1.2.

If you are not certain how the SAN or CA-signing fields behave in your build, stop and check the Palo Alto document "GlobalProtect Administrator's Guide — Deploy Server Certificates to the GlobalProtect Components" rather than guessing.

4. Authentication profile

Device > Local User Database > Users — add a test user, e.g. gp-test.

Device > Authentication Profile > Add — name it gp-auth, set Type = Local Database, and on the Advanced tab add the users/groups allowed to authenticate (add your test user; all is acceptable for a first test). For a real deployment set Type = LDAP or RADIUS (or SAML) and reference the matching server profile under Device > Server Profiles — the field layout differs per type, so follow the auth-profile section of the admin guide for the type you pick.

5. Create the Gateway

Network > GlobalProtect > Gateways > Add.

  • General: name gp-gateway, Interface = your external data interface (e.g. ethernet1/1), IP Address Type IPv4, and the external IP.
  • Authentication: SSL/TLS Service Profile = gp-ssl-profile. Under Client Authentication > Add, set Authentication Profile = gp-auth.
  • Agent > Tunnel Settings: tick Tunnel Mode, Tunnel Interface = tunnel.1.
  • Agent > Client Settings > Add: under IP Pools, set a pool not overlapping any internal subnet, e.g. 10.99.99.0/24. Under Split Tunnel > Include, list the internal subnets clients should reach (e.g. 10.0.0.0/8); leaving Include empty tunnels everything. Set DNS under Network Services if internal name resolution is needed.

6. Create the Portal

Network > GlobalProtect > Portals > Add.

  • General: name gp-portal, Interface = ethernet1/1, and the same external IP.
  • Authentication: SSL/TLS Service Profile = gp-ssl-profile; add a Client Authentication entry with Authentication Profile = gp-auth.
  • Agent > Add (a client config): on External > External Gateways > Add, give the gateway a name, Address = your VPN FQDN or external IP, and tick a priority/manual option. On Trusted Root CA, add your root CA and tick Install in Local Root Certificate Store so the client trusts the server cert.

7. Security policy (and NAT if full-tunnel)

Policies > Security > Add — allow traffic from zone vpn to trust for the applications/services your users need. Keep it least-privilege; do not paste an any/any rule into production.

If you are not split-tunnelling and clients must reach the internet through the firewall, add a source NAT: Policies > NAT > Add, source zone vpn, destination zone untrust, source translation to the untrust interface IP. Confirm the pool subnet is what you translate.

8. Commit

Click Commit (top right), review the change summary, and commit. Watch the job complete.

Verify it worked

  • On the firewall: Network > GlobalProtect > Gateways — the gateway should show green/up after the first connection. Under Monitor > Logs > GlobalProtect you will see portal and gateway auth events; under Monitor > Logs > Traffic you will see tunnelled sessions from the vpn zone.
  • CLI check (read-only):
show global-protect-gateway current-user
show global-protect-gateway statistics

These list connected users and gateway session counts. Run them in the CLI (SSH or console) — they only display state, they change nothing.

  • From a client: install the GlobalProtect app, enter the portal FQDN, sign in as gp-test. The client should receive an address from 10.99.99.0/24 and reach the internal subnets you included.

Undo / rollback

  • Uncommitted mistakes: Config > Revert Changes discards edits before you commit.
  • After a bad commit: Device > Setup > Operations > Load named configuration snapshot (or Load configuration version), pick the snapshot you saved in step 0, then commit.
  • To remove GlobalProtect cleanly: delete the Portal, Gateway, the vpn-to-trust security rule, any NAT rule, tunnel.1, and the vpn zone — in that order — then commit. Deleting the zone before the rules that reference it will fail the commit validation, which is the firewall protecting you.

For anything you are unsure of — a field label, a certificate option, an auth-profile setting — the authoritative reference is the Palo Alto Networks GlobalProtect Administrator's Guide for PAN-OS 11.1 on the vendor's TechDocs site. Prefer reading it over guessing a value into a production commit.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.

Related guides

Security

Set Up a Site-to-Site IPsec VPN on a Palo Alto Firewall

This guide builds a route-based site-to-site IPsec VPN on a Palo Alto firewall: an encrypted tunnel between your firewall and a remote peer so two private subnets can talk over the public internet. You configure it entirely as candidate configuration in the web GUI and make it live with a Commit .

7 min read
Security

Set Up Active-Passive HA on a Palo Alto Firewall Pair

This guide pairs two identical Palo Alto firewalls into an active-passive HA cluster : one firewall passes all traffic while the other sits in sync and takes over if the active one fails, reboots, or loses a monitored link. It does not load-balance — the passive box carries no production traffic until failover.

6 min read
Security

Configure Source and Destination NAT on a Palo Alto Firewall

This guide creates two NAT policies on a Palo Alto firewall: a source NAT rule so hosts on your inside zone reach the internet behind the firewall's public interface address (hide-NAT / PAT), and a destination NAT rule that forwards an inbound public IP and port to an internal server (a port forward). Both change how traffic is translated and, paired with the security rules they require, change what traffic is allowed . A wrong NAT or a missing/overbroad security rule can expose an internal host or break outbound connectivity for a whole zone.

7 min read
Security

Create Security Policy Rules on a Palo Alto Firewall (PAN-OS 11.x)

This guide adds a Security policy rule to a Palo Alto Networks firewall running PAN-OS 11.x , managed locally (not from Panorama). A Security rule decides which sessions between zones are allowed or denied, in top-down order. Adding, reordering, or misscoping a rule changes what traffic passes the firewall the moment you commit , so a mistake here can either open a hole or cut production traffic — including your own management session.

7 min read