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

Before you run this

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.

• Privileges: you need an administrator account on the firewall with commit rights — a superuser, or a device/vsys admin role that permits editing the security rulebase and committing. A read-only admin cannot complete this.
• Test first: read every field before you commit. If you have a lab firewall or a VM (PA-VM), build and commit the rule there first. On production, scope the rule as tightly as you can (specific source, destination, application) rather than any, and put it in the right position — order matters.
• This changes live enforcement. The change is not destructive to data, but it is immediately effective on traffic once committed, and a bad rule can lock you out of the management interface and break user connectivity at the same time.
• Keep an out-of-band path open. Have a console connection (serial or the management-port console) available in a separate window before you start, so a wrong rule on the data plane doesn't leave you with no way back in.
• Back up the running config BEFORE you touch anything. In the GUI: Device > Setup > Operations, then Save named configuration snapshot (and Export a copy off-box). This snapshot is your rollback.
• Do it in a maintenance window.
• Rollback path: PAN-OS uses a candidate/running config model. Before you commit, you can discard everything with Config > Revert Changes (GUI) or revert config (CLI) — nothing has taken effect yet. After you commit, revert by loading the snapshot you saved above (Device > Setup > Operations > Load named configuration snapshot) and committing again, or simply delete/disable the rule and commit. PAN-OS does not have a Junos-style timed auto-rollback, so your saved snapshot is the safety net.

I assume a single standalone firewall, one virtual system (vsys1), zones already defined (e.g. trust and untrust), and any address or service objects already created or that you'll use built-ins.

What the rule will say

For the worked example I'll allow internal clients to browse the web outbound:

• Name: Allow-Trust-to-Internet-Web
• From zone: trust → To zone: untrust
• Source: 10.0.0.0/24 (replace with your client subnet or address object)
• Destination: any
• Application: web-browsing, ssl, dns
• Service: application-default
• Action: allow, with logging at session end

Substitute your own zone names, subnet, and applications. Everything in angle brackets or that obviously names your network is a placeholder.

The GUI procedure (the normal path on PAN-OS)

1. Log in to the web interface and go to Policies > Security.
2. Click Add at the bottom. The rule dialog opens.
3. General tab: set Name to Allow-Trust-to-Internet-Web. Add a Description. Leave Rule Type as universal unless you specifically need intrazone/interzone.
4. Source tab: under Source Zone click Add and choose trust. Under Source Address click Add and enter your subnet/object (10.0.0.0/24). Leave Source User/Device as any unless you use User-ID.
5. Destination tab: Destination Zone → untrust. Leave Destination Address as any (or scope it).
6. Application tab: click Add and add web-browsing, ssl, and dns. Naming the App-IDs is the whole point of a next-gen firewall — avoid leaving this any.
7. Service/URL Category tab: leave Service as application-default (this ties each app to its standard ports). Leave URL Category as any unless you're filtering here.
8. Actions tab: set Action to Allow. Tick Log at Session End. If you have a Log Forwarding profile, select it under Log Forwarding. Attach Security Profiles (Antivirus, Anti-Spyware, etc.) under Profile Setting if you use them.
9. Click OK.
10. Back in the rulebase, check the rule's position. Rules evaluate top-to-bottom, first match wins. Drag it above any broader deny that would shadow it, and below any tighter rule that must win first.
11. Click Commit (top right), review the change, and commit.

The CLI procedure

If you prefer the CLI, SSH in and enter configure mode. These set commands build the same rule:

configure
set rulebase security rules "Allow-Trust-to-Internet-Web" from trust
set rulebase security rules "Allow-Trust-to-Internet-Web" to untrust
set rulebase security rules "Allow-Trust-to-Internet-Web" source 10.0.0.0/24
set rulebase security rules "Allow-Trust-to-Internet-Web" destination any
set rulebase security rules "Allow-Trust-to-Internet-Web" application [ web-browsing ssl dns ]
set rulebase security rules "Allow-Trust-to-Internet-Web" service application-default
set rulebase security rules "Allow-Trust-to-Internet-Web" source-user any
set rulebase security rules "Allow-Trust-to-Internet-Web" action allow
set rulebase security rules "Allow-Trust-to-Internet-Web" log-end yes

Position the rule explicitly rather than leaving it at the bottom. To place it before an existing rule:

# Move this rule directly above an existing rule named "Deny-All"
move rulebase security rules "Allow-Trust-to-Internet-Web" before "Deny-All"

Review the candidate change before you commit:

# Show what you're about to commit
show config diff
commit

If you decide against it before committing, discard the candidate config:

revert config

For attaching a Security Profile group or individual profiles, the keyword is profile-setting. I won't spell out every profile keyword from memory — confirm the exact syntax for profile-setting group versus profile-setting profiles ... in the PAN-OS CLI reference ("Security Policy" / "profile-setting" in the PAN-OS 11.x CLI Quick Start / configuration reference on the Palo Alto Networks docs site) before typing it into production.

Verify it worked

Predictive test — do this before real traffic if you can. PAN-OS can tell you which rule a given flow would match, without sending a packet:

test security-policy-match from trust to untrust source 10.0.0.5 destination 8.8.8.8 destination-port 443 protocol 6 application ssl

The output names the matching rule and its action. If it doesn't name your new rule, your position or match criteria are wrong.

Confirm the rule is in the running config:

show running security-policy

Check real traffic after commit:

• GUI: Monitor > Traffic — filter on the source/destination and confirm sessions show allow and the rule name in the Rule column.
• GUI: Policies > Security — enable the Hit Count columns (or hover the rule) to confirm the counter is incrementing.
• CLI, live sessions matching the rule:

show session all filter source 10.0.0.5 destination 8.8.8.8

Undo / roll back

If the rule is wrong, you have three clean options, in increasing bluntness:

• Disable it (keeps it for later): GUI, select the rule and click Disable; or CLI set rulebase security rules "Allow-Trust-to-Internet-Web" disabled yes, then commit.
• Delete it: GUI, select and Delete; or CLI:

configure
delete rulebase security rules "Allow-Trust-to-Internet-Web"
commit

• Full revert to the state before you started: Device > Setup > Operations > Load named configuration snapshot, choose the snapshot you saved in the safety note, then Commit. This restores the whole config, so only reach for it if targeted deletion isn't enough.

Whichever you choose, the change is only real after the commit — and your out-of-band console is there in case that commit is the one that surprises you.