Palo Alto Security Policy Configuration with a Real-Life Example

Mastering Palo Alto security policy configuration is the foundational skill every network engineer must acquire when deploying PAN-OS firewalls. Unlike traditional stateful firewalls that rely strictly on source IP, destination IP, and port numbers, Palo Alto Networks firewalls use Application Identification (App-ID) and User-ID to enforce security at Layer 7. By default, PAN-OS enforces an implicit deny rule between different security zones, blocking all inter-zone traffic until you explicitly permit it.

In this technical tutorial, you will learn how to design, configure, verify, and troubleshoot security policies in PAN-OS. We will construct a real-life policy architecture that grants corporate network users secure, application-aware outbound access to web services and DNS, while preventing unauthorized or unsolicited inbound sessions from penetrating your internal network.

Real-Life Scenario

Consider an enterprise environment where the internal user segment resides on network subnet 192.168.10.0/24. The organization needs to establish an outbound internet policy that satisfies strict business and operational requirements:

• Secure Web Browsing: Internal corporate clients must access public web resources using encrypted HTTPS (App-ID: ssl) and standard HTTP (App-ID: web-browsing).
• Controlled Name Resolution: Clients must reach external DNS services (App-ID: dns) strictly targeting specified public DNS servers.
• Port Enforcement: Applications must strictly execute over their standardized default ports to prevent evasive applications from tunneling over non-standard ports.
• Inbound Blocking: All unsolicited traffic originating from the Internet toward internal subnets must be silently dropped or blocked.

Lab Topology

The network topology consists of a internal LAN zone, a single Palo Alto Networks firewall running PAN-OS, and an untrusted internet zone. All interfaces operate as Layer 3 interfaces.

+------------------------------------+
|   Corporate Clients (LAN)          |
|   Subnet: 192.168.10.0/24          |
|   Default Gateway: 192.168.10.1    |
+-----------------+------------------+
                  |
                  | Interface: ethernet1/2 (Zone: zone-trust)
                  v
+-----------------+------------------+
|    Palo Alto Networks Firewall     |
|   PAN-OS Next-Gen Firewall         |
+-----------------+------------------+
                  | Interface: ethernet1/1 (Zone: zone-untrust)
                  | Public Egress IP: 203.0.113.10
                  v
+-----------------+------------------+
|          Public Internet           |
|   External DNS: 198.51.100.53      |
+------------------------------------+

Example Addressing and Objects

To keep configurations modular, reusable, and easy to audit, always define network objects before building security rules. The following table details the baseline parameters for this configuration lab:

Note: The IP addresses 198.51.100.53 and 203.0.113.10 are standard RFC 5737 documentation addresses used for demonstration purposes. Adapt these values to match your specific production environment.

Prerequisites

Before implementing the Palo Alto security policy configuration, verify that the following underlying dependencies are fully operational on the firewall:

1. Interface Configuration: Layer 3 interfaces must be configured and assigned to their respective zones (ethernet1/2 in zone-trust, ethernet1/1 in zone-untrust).
2. Virtual Router Routing: A valid default route (0.0.0.0/0) pointing to the next-hop ISP router must exist on the Virtual Router, along with connected routes for internal subnets.
3. Outbound Source NAT Policy: An active Source NAT (Interface Address or Dynamic IP and Port) rule must exist to translate private 192.168.10.0/24 client IPs to the public interface IP (203.0.113.10) when egressing zone-untrust.
4. Content Updates: The App-ID database must be updated to the latest dynamic database version to ensure accurate signature identification.

Step-by-Step Palo Alto Security Policy Configuration

Follow these practical steps to configure the objects, application groups, and security rules inside the Web Interface (GUI).

Step 1: Create Address Objects

Define reusable address objects for the corporate subnet and the external DNS server.

1. Navigate to Objects > Addresses.
2. Click Add at the bottom of the window.
3. Configure the Corporate LAN Address Object:
   • Name: obj-net-corp-lan
   • Type: IP Netmask
   • Value: 192.168.10.0/24
4. Click OK.
5. Click Add again to configure the DNS Server Address Object:
   • Name: obj-srv-dns-primary
   • Type: IP Netmask
   • Value: 198.51.100.53/32
6. Click OK.

Step 2: Create an Application Group

Group related applications together to simplify rule management and streamline policy maintenance.

1. Navigate to Objects > Application Groups.
2. Click Add.
3. In the Name field, enter app-web-group.
4. Click Add in the Members section, then select ssl and web-browsing.
5. Click OK to save the group.

Step 3: Configure the Outbound DNS Security Policy Rule

Create a restricted policy allowing internal clients to reach the external DNS server using the dns application.

1. Navigate to Policies > Security.
2. Click Add at the bottom left to insert a new rule.
3. Under the General tab:
   • Name: Allow-Corp-Outbound-DNS
   • Rule Type: universal
4. Under the Source tab:
   • Source Zone: Click Add and select zone-trust.
   • Source Address: Select obj-net-corp-lan.
5. Under the Destination tab:
   • Destination Zone: Click Add and select zone-untrust.
   • Destination Address: Select obj-srv-dns-primary.
6. Under the Application tab:
   • Click Add and select dns.
7. Under the Service/URL Category tab:
   • Select application-default.
8. Under the Actions tab:
   • Action Setting: Allow
   • Log Options: Ensure Log at Session End is checked.
9. Click OK.

Step 4: Configure the Outbound Web Security Policy Rule

Create a policy allowing internal clients to browse web services over HTTP and HTTPS using App-ID.

1. Navigate to Policies > Security.
2. Click Add.
3. Under the General tab:
   • Name: Allow-Corp-Outbound-Web
   • Rule Type: universal
4. Under the Source tab:
   • Source Zone: Select zone-trust.
   • Source Address: Select obj-net-corp-lan.
5. Under the Destination tab:
   • Destination Zone: Select zone-untrust.
   • Destination Address: Select Any.
6. Under the Application tab:
   • Click Add Application Group (or Add) and select app-web-group.
7. Under the Service/URL Category tab:
   • Select application-default.
8. Under the Actions tab:
   • Action Setting: Allow
   • Log Options: Ensure Log at Session End is enabled.
9. Click OK.

Step 5: Commit changes

Configurations in PAN-OS are staged in candidate memory until committed to active memory.

1. Click Commit located in the upper-right corner of the web interface.
2. Review the change summary window.
3. Click Commit again to process and activate the rulebase.

CLI Configuration

For engineers managing firewalls via automation or terminal access, execute the following CLI commands to achieve the exact same operational state.

# Enter configuration mode
configure

# Create Address Objects
set address obj-net-corp-lan ip-netmask 192.168.10.0/24
set address obj-srv-dns-primary ip-netmask 198.51.100.53/32

# Create Application Group
set application-group app-web-group members [ ssl web-browsing ]

# Create Security Rule for DNS
set rulebase security rules Allow-Corp-Outbound-DNS from zone-trust source obj-net-corp-lan to zone-untrust destination obj-srv-dns-primary application dns service application-default action allow log-end yes

# Create Security Rule for Web Access
set rulebase security rules Allow-Corp-Outbound-Web from zone-trust source obj-net-corp-lan to zone-untrust destination any application app-web-group service application-default action allow log-end yes

# Commit changes to active running configuration
commit

Caution: Always double-check security rule order before running a commit in production. Rules evaluate top-down, and broader catch-all rules placed above specific rules can cause unintended access patterns.

How the Traffic Flows: Pre-NAT vs. Post-NAT Evaluation

Understanding packet processing logic inside PAN-OS is necessary to prevent severe configuration misstatements during security rule setup. When an outbound flow initiates from client 192.168.10.15 toward internet host 198.51.100.53, PAN-OS processes packets through distinct pipeline stages:

Ingress Packet 
[Src: 192.168.10.15, Dst: 198.51.100.53]
       |
       v
1. Interface & Zone Determination ---> Ingress: ethernet1/2 (zone-trust)
       |
       v
2. Route Lookup (Virtual Router)  ---> Egress: ethernet1/1 (zone-untrust)
       |
       v
3. NAT Policy Lookup              ---> Translates Src IP to 203.0.113.10
       |                               (Prepares state, DOES NOT apply yet)
       v
4. Security Policy Lookup         ---> EVALUATED HERE!
       |                               Source Zone: zone-trust
       |                               Source IP: 192.168.10.15 (PRE-NAT)
       |                               Destination Zone: zone-untrust (POST-NAT ZONE)
       |                               Destination IP: 198.51.100.53 (PRE-NAT IP)
       v
5. Session Creation               ---> State created; return traffic matches state table.

Key technical considerations regarding security policy evaluation:

• Source Address Evaluation: Security policies match the original Pre-NAT Source IP address (192.168.10.15), not the translated public address.
• Destination Address Evaluation: Security policies match the original Pre-NAT Destination IP address. (For outbound internet traffic, destination IP is unaltered, but this rule applies equally to inbound Destination NAT/DNAT).
• Destination Zone Determination: Security policies evaluate the Post-NAT Destination Zone. PAN-OS queries the routing table to determine which outgoing interface and zone the destination IP routes through.
• Stateful Return Traffic: Because PAN-OS is a stateful firewall, symmetric return traffic originating from internet servers is automatically matched against active entries in the session table. Return traffic does not require a corresponding inbound rule from zone-untrust to zone-trust. Unsolicited inbound sessions remain blocked by default.

Verification

To verify that the configuration functions as designed, use both GUI monitoring utilities and operational CLI diagnostic commands.

1. Monitor Live Traffic Logs (GUI)

Navigate to Monitor > Logs > Traffic. Generate web traffic from internal client machine 192.168.10.15. Apply the following search filter in the log bar:

( zone.src eq 'zone-trust' ) and ( addr.src in '192.168.10.0/24' )

Verify the generated traffic log entries display the expected results:

• Rule: Displays Allow-Corp-Outbound-Web or Allow-Corp-Outbound-DNS.
• Application: Displays identified applications such as ssl, web-browsing, or dns (rather than remaining on initial TCP signatures like not-applicable).
• Action: Displays allow.
• Session End Reason: Displays tcp-end, tcp-fin, or aging-out.

2. Active Session Inspection (CLI)

Execute operational diagnostic commands on the firewall CLI to inspect real-time active sessions established by internal hosts.

To view active sessions matching a specific client source address:

show session all filter source 192.168.10.15

To inspect granular state details for a specific session ID, execute:

show session id 12345

Examine the detailed session output to verify key fields:

Session           12345: 
        c2s flow: 192.168.10.15[49152] -> 198.51.100.53[443]
                  proto 6 main-state ACTIVE tracker-state ACTIVE
                  node 0 zone-src zone-trust zone-dst zone-untrust
        s2c flow: 198.51.100.53[443] -> 203.0.113.10[1024]
                  proto 6 main-state ACTIVE tracker-state ACTIVE
                  node 0 zone-src zone-untrust zone-dst zone-trust
        ...
        app               : ssl
        security-policy   : Allow-Corp-Outbound-Web
        action            : allow
        ...

3. Security Policy Match Simulator (CLI)

You can test policy logic statically without generating real user traffic using the built-in policy match engine:

test security-policy-match source 192.168.10.15 destination 198.51.100.53 protocol 17 port 53 application dns from zone-trust to zone-untrust

The CLI output will immediately display the exact security rule matching that specific parameter set.

Troubleshooting

When security rules block traffic unexpectedly or fail to identify applications correctly, follow this structured investigation matrix:

Symptom 1: Web browsing hangs or drops after initial TCP SYN

• Likely Cause: App-ID identification failure or missing dependent application. Initial TCP handshakes execute on standard ports, but once payload packets arrive, App-ID shifts from generic web-browsing or TCP port 80/443 to specific protocols (e.g., panos-web-interface or underlying protocol structures).
• Check: Look for traffic log entries showing Action: deny or Session End Reason: policy-deny immediately following an initial handshake.
• Fix: Ensure implicit dependencies are accounted for, or check if SSL decryption is required to accurately classify HTTPS payload applications.

Symptom 2: Traffic hits interzone-default implicit deny rule

• Likely Cause 1: Destination zone misconfiguration. Remember that security policy checks query the egress interface zone based on VR routing decisions. If routing points to a different zone than intended, the rule fails to match.
• Likely Cause 2: Service field set incorrectly. Using a fixed TCP/UDP port object instead of application-default when enforcing App-ID can cause drops if the application attempts to run over non-standard ports, or vice versa.
• Check: Run command show session all filter source 192.168.10.15 and look for dropped sessions. Check destination zone in log outputs.

Symptom 3: Applications fail when service is restricted to application-default

• Likely Cause: Standard enterprise infrastructure running services on non-standard ports (e.g., web interface on port 8443 instead of 443).
• Check: In Traffic Logs, inspect the destination port column. Compare the destination port against PAN-OS default app ports under Objects > Applications.
• Fix: Create a custom Service object matching the non-standard port (e.g., TCP-8443) and attach that service object explicitly to the rule instead of application-default.

Common Mistakes

Avoid these critical configuration mistakes frequently observed in production network environments:

• Using “Any” Service with App-ID: Setting the Service field to any in a security policy allows applications to run over non-standard or arbitrary ports. Always set the Service to application-default to enforce standard port utilization unless explicit business requirements state otherwise.
• Using Post-NAT IP Addresses in Security Policies: Configuring destination IP addresses using post-NAT translated public IPs instead of pre-NAT real addresses breaks policy matches. Always use pre-NAT IP addresses inside security policies.
• Ignoring Application Dependencies: Certain applications rely on secondary protocols to function (e.g., specific web applications requiring ssl, web-browsing, and ipsec-esp simultaneously). Check the Dependencies tab under Objects > Applications before deploying restrictive application lists.
• Incorrect Rule Order: Placing broad top-level rules (e.g., permissive rules with wide subnet masks) above tightly defined rules renders lower rules ineffective. Maintain strict rule ordering (Specific rules at the top, general rules at the bottom).

Production Considerations

When moving from a lab environment to a mission-critical enterprise production network, enhance your security policy architecture with these advanced practices:

1. Attach Security Profiles (Layer 7 Threat Prevention)

Creating an Allow rule with App-ID guarantees traffic classification, but it does not scan content for malicious payloads. Always attach a Security Profile Group to every permissive outbound rule. Profile groups should include:

• Antivirus: Blocks stream-based file downloads containing known malware signatures.
• Anti-Spyware: Blocks command-and-control (C2) domain lookups and spyware phone-home traffic.
• Vulnerability Protection: Prevents exploitation of client-side application vulnerabilities (buffer overflows, remote code execution).
• URL Filtering: Restricts web navigation by domain reputation and URL category lists (e.g., blocking malware, phishing, and adult domains).
• WildFire Analysis: Forwards unknown executable payloads to the WildFire cloud for real-time zero-day analysis.

2. SSL Decryption (Forward Proxy)

Over 90% of web traffic uses TLS encryption. Without SSL Decryption configured on the firewall, App-ID relies entirely on Server Name Indication (SNI) and certificate headers to identify applications. The firewall cannot inspect encrypted payload data for threats, viruses, or policy violations. Plan to deploy SSL Forward Proxy alongside your Palo Alto security policy configuration to gain complete application visibility and threat inspection.

3. Logging Best Practices

Ensure that Log at Session End (log-end) is enabled on custom security rules. Avoid enabling Log at Session Start unless required for specialized real-time session troubleshooting, as logging session starts doubles log storage consumption on log collectors and firewall storage partitions.

Summary

A structured Palo Alto security policy configuration forms the core defense line of your network architecture. By implementing application-aware policies instead of legacy port-based rules, you drastically minimize your attack surface and retain precise control over corporate traffic flows.

Key concepts to keep in mind when engineering PAN-OS policies:

• Structure object groupings cleanly before crafting security policies.
• Always construct policies using Pre-NAT IP addresses combined with Post-NAT Egress Zones.
• Enforce strict operational security using application-default for standard service ports.
• Regularly verify live traffic sessions via CLI and Traffic Logs to validate App-ID classification.
• Augment permissive rules with comprehensive Security Profiles to defeat zero-day threats and malicious payloads.