Docs

Appearance

Panorama Day-to-Day Operations ​

Overview ​

This guide covers the practical mechanics of operating Panorama — how to log in, navigate the GUI, add or modify a rule, and commit changes. It assumes you've already read Firewall Change Request Procedure and have an approved change record before making any modifications.

For Panorama disk sizing, PAN-OS upgrades, and log forwarding configuration see Panorama Operations. For firewall architecture and zone design see Palo Alto Firewall Overview.

Rory is the only person authorized to commit changes to Panorama. If you need a change made, file a ticket per the change procedure and Rory implements it.

Accessing Panorama ​

Which Panorama ​

EnvironmentAccess MethodNotes
AWS DR (operational)Twingate → private IP in vpc-aws-transitPrimary Panorama — manages AWS DR firewall
DDE (rebuilt)Twingate → DDE private IPFirewall reconnection pending
Azure PRODNot yet deployedPhase 2, June/July 2026

The Panorama management IP and admin credentials are in Keeper → "Panorama — [Environment]".

Logging In ​

  1. Connect Twingate (if not already connected) — Panorama is on a private IP, not internet-accessible
  2. Open the Panorama IP in a browser: https://<panorama-ip>
  3. Accept the self-signed cert warning (Panorama uses its own cert on the management interface)
  4. Log in with the admin credentials from Keeper
  5. You land on the Dashboard tab showing device health, log rates, and connected firewalls

Confirming Connected Firewalls ​

Check that managed firewalls are connected:

  • Panorama tab → Managed Devices → Summary
  • Each firewall should show Connected status and a green icon
  • If a firewall shows Disconnected, it may have rebooted or the management tunnel is down

Panorama GUI Layout ​

The top navigation bar has five main tabs:

TabWhat's Here
DashboardHealth overview, log rates, connected devices
MonitorLog viewer — traffic, threat, system, config
ObjectsAddress objects, service objects, application groups
PoliciesSecurity rules, NAT rules, decryption rules
PanoramaDevice groups, template stacks, managed devices, commits

The Device Group and Template dropdowns at the top filter which managed firewall's config you're viewing/editing. Always confirm you're in the correct device group before making changes.

Checking Firewall Logs ​

Traffic Logs (What's Being Allowed/Denied) ​

  1. Monitor tab → Logs → Traffic
  2. Use the filter bar to narrow results:
    ( addr.src in 10.20.0.0/16 ) and ( app eq ssl )
(destport eq 443) and (action eq deny)
addr.dst eq 8.8.8.8
  3. Columns: Source/Destination IP, Application, Action, Rule Name, Bytes
  4. Click any row to expand full log detail

Threat Logs (IPS Alerts) ​

  1. Monitor tab → Logs → Threat
  2. Filter by severity: ( severity eq critical ) or ( severity eq high )
  3. Each row shows the threat name, CVSS score, attacker IP, victim IP, and the matching rule

System Logs (Firewall Events) ​

  1. Monitor tab → Logs → System
  2. Shows admin logins, config commits, license updates, HA events
  3. Filter: ( subtype eq auth ) to see authentication events

Config Logs (Change Audit) ​

  1. Monitor tab → Logs → Config
  2. Shows every change made to the config — who made it, what command, when
  3. This is the audit trail for firewall changes

Objects — Address and Service Management ​

Before creating a policy rule you usually need to create Address and Service objects.

Creating an Address Object ​

  1. Objects tab → Addresses → Add
  2. Fill in:
    • Name: descriptive, follow the convention host-<description> or net-<subnet>-<purpose> (e.g., host-secops-prod, net-identity-vnet)
    • Type: IP Netmask (most common), FQDN, or IP Range
    • Value: the IP/CIDR or hostname
    • Description: what this host/network is — required for audit purposes
  3. Click OK

Address objects live at the Shared level (visible to all device groups) or scoped to a specific device group. For Cirius, put shared objects at Shared unless they're environment-specific.

Creating an Address Group ​

  1. Objects tab → Address Groups → Add
  2. Name it (e.g., grp-identity-servers), type Static, then add member address objects
  3. Use groups in policy rules rather than individual IPs — makes future changes a single object edit rather than a rule edit

Creating a Service Object ​

Only needed if the service uses a non-standard port. For standard applications (HTTP=80, HTTPS=443) use application-default in the policy rule instead.

  1. Objects tab → Services → Add
  2. Name: svc-<protocol>-<port> (e.g., svc-tcp-8443)
  3. Protocol: TCP or UDP, destination port

Security Policy Rules ​

Viewing Existing Rules ​

  1. Policies tab → Security
  2. Select the Device Group from the top dropdown
  3. Rules are listed in order — Palo Alto evaluates them top-to-bottom, first match wins
  4. Rules shown in green are matched recently; grey rules may be unused (check before deleting)

Adding a New Security Rule ​

Only after an approved change record exists.

  1. Policies tab → Security → Add (or right-click an existing rule and choose "Clone" if the new rule is similar)
  2. General tab:
    • Name: <action>-<source-zone>-<dest-zone>-<description> (e.g., allow-trust-untrust-secops-443)
    • Description: why this rule exists + ticket/change record number
    • Rule Type: Universal (most cases)
  3. Source tab:
    • Source Zone: select the zone traffic originates from
    • Source Address: select address objects or groups (avoid "any" for specific rules)
  4. Destination tab:
    • Destination Zone: where the traffic is going
    • Destination Address: specific hosts/networks if possible
  5. Application tab:
    • Use App-ID whenever possible (e.g., ssl, web-browsing, ms-rdp)
    • If App-ID doesn't exist for the app, use any with a service object
  6. Service/URL Category tab:
    • If using App-ID: set to application-default
    • If not using App-ID: select the specific service object
  7. Actions tab:
    • Action: Allow or Deny
    • Security Profiles: attach default profile group (IPS + URL + DNS + file blocking)
    • Log at Session End: always enabled

Click OK. The rule is now in the candidate config but NOT committed.

Rule Ordering ​

New rules added via the GUI go to the bottom of the list. Drag to reorder before committing. Most-specific rules should be higher; catch-all deny rules stay at the bottom.

NAT Rules ​

NAT rules translate source or destination IPs. The most common case is source NAT (SNAT) for outbound internet traffic from internal hosts.

  1. Policies tab → NAT → Add
  2. General tab: Name and description
  3. Original Packet tab: Source/destination zone, source/destination address, destination port (pre-NAT)
  4. Translated Packet tab:
    • Source Address Translation: Dynamic IP and Port → Interface Address (for outbound SNAT)
    • Destination Address Translation: for DNAT (inbound port forwarding)

NAT rules are also evaluated top-to-bottom. Commit after adding.

Commit and Push Workflow ​

This is the most critical step. Changes in the GUI are in the "candidate config" — they are not live until committed and pushed.

Step 1 — Commit to Panorama ​

  1. Click Commit in the top-right corner
  2. Select Commit to Panorama
  3. Add a commit description: reference the change ticket and what changed
  4. Click Commit in the dialog
  5. Wait for the commit job to complete (bottom status bar shows progress)
  6. A successful commit saves the config to Panorama's local store — it is NOT yet on the firewalls

Step 2 — Push to Devices ​

  1. Click Commit → Push to Devices
  2. Select which device groups / firewalls to push to
    • For a production change: select all relevant firewalls
    • For a test of one firewall: select only that device
  3. Click Push
  4. Watch the push job status — each firewall shows its push result
  5. Green checkmark = successfully applied to the firewall

Verifying the Change is Live ​

After push:

  1. Monitor → Logs → Config on the target firewall — you should see the config change event
  2. Test the traffic path that should now be allowed (or denied)
  3. Check Monitor → Logs → Traffic and filter for the new rule name to confirm it's matching

If a Commit Fails ​

  • Check the job detail in the bottom status bar — Panorama shows the error
  • Common: referenced object doesn't exist, duplicate rule name, invalid zone reference
  • Fix the issue in the candidate config and retry the commit
  • Do not push if the commit failed — the device would receive an incomplete config

Emergency — Block an IP Immediately ​

During an active incident you may need to block an attacker IP without waiting for a change ticket.

  1. Objects tab → Addresses → Add — create host-block-<ip> with the attacker IP
  2. Policies tab → Security — add a deny rule at the TOP of the list:
    • Source: host-block-<ip>
    • Destination: any
    • Zone: untrust or the zone the attacker is in
    • Action: Deny
    • Log at Session Start: enabled (so you see it blocked immediately)
  3. Commit to Panorama → Push to Devices
  4. Document the change in SecOps within 24 hours per emergency change procedure

The deny rule stays in place until the incident is resolved and Rory reviews it.

Common Troubleshooting ​

Traffic That Should Be Allowed Is Being Denied ​

  1. Monitor → Logs → Traffic — find the denied session, note the Rule Name column
  2. The rule name tells you exactly which rule is blocking it
  3. Check that rule in Policies → Security — is the zone/address/application correct?
  4. Use Policies → Security → right-click rule → Test Policy Match to test what rule would match a given source/dest/app/port combination

Commit Succeeds But Traffic Behavior Doesn't Change ​

  • Panorama committed but the push might have failed — check Panorama → Push to Devices → Job Status
  • The firewall may be caching a session — new rules apply to new sessions only, not existing ones

Firewall Shows Disconnected in Panorama ​

  1. Check that the firewall VM is running (Azure Portal or AWS Console)
  2. SSH to Panorama and ping the firewall management IP
  3. On the firewall: show panorama-status — shows connectivity to Panorama
  4. Common fix: restart the management plane on the firewall: debug software restart process management-server
  5. If still disconnected, reboot the firewall as a last resort (coordinate with Rory — this drops all active sessions through that firewall)

Document History ​

DateChangeAuthor
May 2026Initial draft — Panorama login, GUI navigation, rule management, commit/push workflow, emergency block, troubleshooting.Rory

Internal use only — Cirius Group