Configure App-ID and URL Filtering on a Palo Alto Firewall

Before you run this

This guide walks through building a URL Filtering security profile and adding App-ID application matching to a security policy rule on a standalone Palo Alto firewall, then attaching the profile to that rule so web traffic is classified by category and applications are matched by App-ID rather than by port. The purpose is to move from port-based rules toward application- and category-aware enforcement.

This is a firewall configuration change, not a script. It requires an administrator account with a role that can edit security profiles, security policy, and commit — a superuser role is the simplest. Changes you make sit in the candidate configuration until you Commit, at which point they become live and affect production traffic immediately.

Because a badly scoped block can cut off legitimate applications (or your own management session):

• Keep a separate out-of-band path open — a console cable to the CONSOLE port, or a management session from an IP you have explicitly permitted — so a rule that blocks your traffic doesn't lock you out.
• Back up the running configuration before you touch anything (Step 1). PAN-OS lets you save and export a named snapshot, and lets you revert.
• Do this in a maintenance window, and if you can, build and test the profile on a lab or VM-Series appliance first. URL categories set to block change what users can reach the moment you commit.
• Rollback path: before commit you can Revert to running configuration to discard candidate changes; after commit you can Load configuration version to restore the snapshot you saved. Both are on the Device > Setup > Operations page. Neither is automatic — there is no timed auto-rollback on a standalone firewall, so verify quickly after you commit.

Nothing here is irreversibly destructive on its own, but a wrong block on a broad category is disruptive to production the instant it's live. Read each step before you commit.

Assumptions

I'm writing for PAN-OS 11.0 / 11.1 on a standalone PA-series or VM-Series firewall managed through its web GUI (not Panorama). App-ID is always on and needs no licence. URL Filtering requires an active PAN-DB / Advanced URL Filtering subscription — without it the category database won't populate. Menu paths and column names move between major PAN-OS versions, so if a screen doesn't match, check the PAN-OS Administrator's Guide for your exact version.

Placeholders like Corp-URL-Profile, Trust, Untrust, and example.com are yours to replace with your real object and zone names.

Step 1 — Back up the running config

Do this first, every time.

1. Go to Device > Setup > Operations.
2. Click Save named configuration snapshot, give it a dated name, and save.
3. Click Export named configuration snapshot and download the resulting XML to your workstation.

That XML is your restore point if the commit goes wrong.

Step 2 — Confirm the licence and PAN-DB connectivity

URL filtering does nothing useful without a live category database.

1. Device > Licenses — confirm the URL Filtering (PAN-DB / Advanced URL Filtering) subscription is present and not expired.
2. From the CLI, check the cloud connection:

show url-cloud status

You want to see a connected/authorised status. If it isn't connected, fix that before building rules — a profile with no working database won't categorise anything.

Step 3 — Build the URL Filtering profile

1. Go to Objects > Security Profiles > URL Filtering.
2. Click Add and name it, e.g. Corp-URL-Profile.
3. In the Categories list, each category has a Site Access action. The standard actions are:
   • allow — permit, no log entry for the URL.
   • alert — permit and log to the URL Filtering log. This is the safe default to start with.
   • block — deny and show the block page.
   • continue — show a page the user must click through to proceed.
   • override — require a password to proceed.
4. Start conservatively. Set the categories you're sure about (for example malware, phishing, command-and-control) to block, and set everything else to alert. Running everything at alert for a few days first shows you what your users actually browse before you start blocking.

Modern PAN-OS also exposes a User Credential Submission action per category (for credential-phishing prevention) and, with Advanced URL Filtering, inline ML options. Leave those at their defaults unless you've read up on them — don't enable features you haven't tested.

Click OK to save the profile into the candidate config.

Step 4 — Put App-ID into the security policy

App-ID classification happens automatically, but a rule only enforces by application if you list applications on it.

1. Go to Policies > Security and either edit an existing rule or Add a new one. I'll assume a rule allowing internal users out to the internet, from zone Trust to zone Untrust.
2. On the Application tab, click Add and select the applications you intend to allow — for example web-browsing, ssl, dns. If you add an application with dependencies, PAN-OS will prompt you to add the ones it needs; add them.
3. On the Service/URL Category tab, set Service to application-default. This ties the allowed applications to their standard ports and is the mainstream, safe choice — it's what makes App-ID matching meaningful rather than leaving the rule wide open on any service.
4. On the Actions tab, set Action to Allow.

A note on ordering and safety: don't convert a working port-based rule to App-ID in place and hope. Build the App-ID rule, place it, and watch the traffic logs. Applications that fall through can be caught by a lower, more permissive rule while you tune. Palo Alto's own Policy Optimizer helps with this migration if you have a lot of legacy port rules; that's a larger topic than this guide.

Step 5 — Attach the URL Filtering profile

Still on the rule's Actions tab:

1. Under Profile Setting, set Profile Type to Profiles.
2. In the URL Filtering dropdown, select Corp-URL-Profile.
3. Click OK.

The profile only takes effect on rules whose action is allow — you can't attach filtering to a deny rule, and there's no reason to.

Step 6 — Commit

Click Commit (top right), review the change summary, and commit. If you have console/OOB access ready, you're covered if something goes wrong.

Verifying it worked

Check what a URL categorises as (from the CLI):

test url example.com

This returns the category (or categories) PAN-OS assigns to that host, so you can confirm your block/alert decisions land where you expect. If your version's command differs, the PAN-OS Administrator's Guide documents the exact test url syntax.

Watch live traffic:

• Monitor > Logs > URL Filtering — you should see entries with the category and the action (alert, block, etc.) as users browse.
• Monitor > Logs > Traffic — confirm the Application column shows real App-IDs (e.g. web-browsing, ssl) hitting your rule, not incomplete or unknown-tcp everywhere, which would mean traffic isn't matching as intended.

Confirm the running policy from the CLI:

show running security-policy

Browse to a site in a category you set to block from a client behind the firewall — you should get the block page. That's your end-to-end proof.

Rolling back

• Before you commit: Device > Setup > Operations > Revert to running configuration discards the candidate changes entirely.
• After you commit: Device > Setup > Operations > Load configuration version lets you load a previous committed version; or Import named configuration snapshot and load the XML you exported in Step 1, then commit. To back out a single rule change without a full restore, edit the rule to remove the profile or the application, or set the affected URL categories back to alert, and commit again.

Verify after any rollback the same way you verified the change: logs, show running security-policy, and a real browse test.