Symptoms
When traffic on a Palo Alto Networks firewall fails to match the expected security policy rule, administrators typically observe one or more of the following symptoms:
- Sessions are dropped silently with no log entry tied to the expected rule
- The
test security-policy-match
command returns a different rule name than anticipated - Traffic is permitted by a broad catch-all rule instead of a specific, more restrictive rule
- Applications fail to connect across firewall zones despite an apparently correct rule being present
- Security policy hit counters do not increment on the intended rule after traffic is generated
- Traffic logs show sessions matching the wrong source or destination zone
- Threat prevention, URL filtering, or other security profiles are not applied because traffic hits the wrong rule
- Users on the 10.10.10.0/24 segment report intermittent failures that correlate with App-ID reclassification events in the session table
Root Cause 1: Wrong Zone Assignment
Why It Happens
Palo Alto Networks firewalls use zones — not interfaces — as the primary policy matching criterion. Every security rule specifies a source zone and a destination zone. If the physical or logical interface carrying the traffic is assigned to the wrong zone, or if a subinterface VLAN tag is misconfigured, traffic will arrive in the data plane with incorrect zone context and will not match rules written for the correct zones. This is particularly common after network changes, VLAN reconfigurations, or when virtual router routing policies have been modified without updating the corresponding zone assignments.
How to Identify It
Run the policy match simulation from the operational CLI, specifying the exact source IP, destination IP, protocol, port, and zone parameters you expect the traffic to use:
admin@sw-infrarunbook-01> test security-policy-match source 10.10.10.50 destination 192.168.1.100 destination-port 443 protocol 6 from trust to untrustIf the command returns "No matching rule found" or resolves to an unexpected rule, immediately verify the zone assigned to the ingress interface:
admin@sw-infrarunbook-01> show interface ethernet1/3
-------------------------------------------------------------------------------
Name : ethernet1/3
Vsys : vsys1
Zone : dmz
Link Status : up
IP : 172.16.50.1/24If the rule expects source zone trust but the interface is assigned to dmz, this zone mismatch is your root cause. Enumerate all zone memberships to cross-reference:
admin@sw-infrarunbook-01> show zone
vsys vsys1:
trust : [ ethernet1/1 ethernet1/2 ]
untrust : [ ethernet1/4 ]
dmz : [ ethernet1/3 ]For subinterfaces, verify both the VLAN tag and zone assignment:
admin@sw-infrarunbook-01> show interface ethernet1/3.100
Tag : 100
Zone : trust
IP : 10.10.10.1/24How to Fix It
Reassign the interface to the correct zone in configuration mode:
admin@sw-infrarunbook-01# set network interface ethernet1/3 layer3 zone trust
admin@sw-infrarunbook-01# commitAlternatively, navigate in the web UI to Network > Interfaces, select the interface, open the Config tab, and update the Security Zone drop-down. After committing, re-run
test security-policy-matchwith the same parameters to confirm the intended rule now resolves.
Root Cause 2: Rule Order Issue (Rule Shadowing)
Why It Happens
Palo Alto security policies are evaluated in strict top-down order; the first rule whose criteria match the traffic wins, and no further rules are evaluated. If a broader, less-specific rule appears above a more specific rule in the policy table, traffic that should hit the specific rule will be consumed by the broader rule and will never reach the intended one. This is one of the most frequent misconfigurations in environments where rules are added incrementally over time without reviewing the full rule base. A common scenario is a legacy "allow-all-outbound" rule that was placed near the top of the policy before application-specific rules were built below it.
How to Identify It
Use the policy match simulation and note the rule name returned:
admin@sw-infrarunbook-01> test security-policy-match source 10.10.10.50 destination 192.168.1.100 destination-port 8443 protocol 6 from trust to untrust
Rule Name : allow-all-outbound
Action : allow
From Zone : trust
To Zone : untrustIf allow-all-outbound is returned but the intended rule is allow-https-solvethenetwork, the rule order is the cause. Inspect the full policy to find relative positions:
admin@sw-infrarunbook-01> show running security-policyLook for the broader rule appearing above the more specific one. Confirm with hit counts — a rule with zero hits that should be receiving production traffic is a definitive indicator of shadowing:
admin@sw-infrarunbook-01> show rule-hit-count vsys vsys1 rule-base security rules all
Rule Name Hit Count Last Hit Time
allow-all-outbound 148392 2026/04/04 11:47:02
allow-https-solvethenetwork 0 NeverHow to Fix It
Move the more specific rule above the broader rule using the
movecommand in configuration mode:
admin@sw-infrarunbook-01# move security rules allow-https-solvethenetwork before allow-all-outbound
admin@sw-infrarunbook-01# commitTo move a rule to the very top of the policy:
admin@sw-infrarunbook-01# move security rules allow-https-solvethenetwork topIn the web UI or Panorama, drag the specific rule above the broader rule in the policy table. After committing, re-run
test security-policy-matchand verify the correct rule is returned. Monitor hit counts over the next hour to confirm the specific rule is now accumulating hits.
Root Cause 3: App-ID Mismatch
Why It Happens
Palo Alto Networks uses App-ID to identify applications by their actual behavior, signatures, and protocol characteristics — not merely by port number. During the first few packets of a session, the firewall classifies traffic as a generic application such as web-browsing or ssl. Once enough packet data is inspected, App-ID reclassifies the traffic to its true application identifier (e.g., google-drive-uploading, sharepoint-online, or ms-teams). If your security rule specifies an App-ID that does not match what the firewall ultimately identifies, the session either fails to match the rule during initial classification or is dropped mid-session upon reclassification when no rule covers the new App-ID.
How to Identify It
Filter the traffic log for sessions to the target destination and observe the application column:
admin@sw-infrarunbook-01> show log traffic direction equal forward destination equal 192.168.1.100 | match "8443"
2026/04/04 09:12:31 10.10.10.50 192.168.1.100 8443 web-browsing allow-all-outbound allow
2026/04/04 09:12:33 10.10.10.50 192.168.1.100 8443 ssl deny-default deny
2026/04/04 09:12:55 10.10.10.50 192.168.1.100 8443 sharepoint-online deny-default denyThe firewall first classifies the traffic as web-browsing (matched and allowed), then reclassifies it as ssl and finally sharepoint-online — neither of which is covered by the intended rule. Inspect active sessions directly to see the current App-ID in use:
admin@sw-infrarunbook-01> show session all filter source 10.10.10.50 destination 192.168.1.100
ID Application State Type Flag Src[Sport]/Zone/Proto
182734 ssl ACTIVE FLOW NS 10.10.10.50[52341]/trust/6admin@sw-infrarunbook-01> show session id 182734
Application : ssl
Rule : allow-all-outbound
Source : 10.10.10.50
Destination : 192.168.1.100How to Fix It
Update the security rule to include all App-IDs that the firewall may classify this traffic as. Include the final identified application and any dependency applications listed in Objects > Applications under the "Depends on" field:
admin@sw-infrarunbook-01# set security rules allow-https-solvethenetwork application [ ssl web-browsing sharepoint-online ms-office365 ]If you want to allow all applications that ride on a standard protocol without enumerating each one, use the parent application and set the service explicitly:
admin@sw-infrarunbook-01# set security rules allow-https-solvethenetwork application any service svc-https-443
admin@sw-infrarunbook-01# commitFor situations where App-ID reclassification consistently causes mid-session drops for a known application on a non-standard port, create an Application Override policy to force App-ID classification without deep inspection on that port combination.
Root Cause 4: Service/Port Mismatch
Why It Happens
The Service field in a Palo Alto security rule defines the TCP or UDP port scope the rule applies to. When set to application-default, the firewall only matches traffic arriving on the ports defined as standard for the selected App-ID in the App-ID database. If the application runs on a non-standard port — for example, an internal HTTPS portal at solvethenetwork.com running on TCP 8443 instead of the standard TCP 443 — traffic on 8443 will not match a rule configured with "application-default" for the ssl application. The reverse also applies: if the service is locked to a specific port object (e.g., TCP/443) but traffic arrives on a different port, the rule will not match regardless of App-ID.
How to Identify It
Run the policy match test specifying the non-standard port and note the result:
admin@sw-infrarunbook-01> test security-policy-match source 10.10.10.50 destination 192.168.1.100 destination-port 8443 protocol 6 from trust to untrust
Rule Name : deny-default
Action : denyNow run it with the standard port to confirm the rule exists but is port-restricted:
admin@sw-infrarunbook-01> test security-policy-match source 10.10.10.50 destination 192.168.1.100 destination-port 443 protocol 6 from trust to untrust
Rule Name : allow-https-solvethenetwork
Action : allowReview the service configuration on the suspect rule:
admin@sw-infrarunbook-01> show running security-policy | match -A 10 allow-https-solvethenetwork
service : application-default
application : sslConfirming that application-default is set for the ssl application (which defaults to TCP 443) explains why TCP 8443 traffic does not match.
How to Fix It
Create a custom service object for the non-standard port and attach it to the rule:
admin@sw-infrarunbook-01# set service svc-https-8443 protocol tcp port 8443
admin@sw-infrarunbook-01# set security rules allow-https-solvethenetwork service svc-https-8443
admin@sw-infrarunbook-01# commitIf both standard and non-standard ports need to be covered, create a service group:
admin@sw-infrarunbook-01# set service-group svc-grp-https members [ svc-https-8443 svc-https-443 ]
admin@sw-infrarunbook-01# set security rules allow-https-solvethenetwork service svc-grp-https
admin@sw-infrarunbook-01# commitAfter committing, re-run both port-specific policy match tests to confirm both TCP 443 and TCP 8443 now resolve to the correct rule.
Root Cause 5: Security Profile Blocking Traffic
Why It Happens
A security rule may match traffic correctly — returning an allow action — yet a security profile attached to that rule is configured to block or reset the session at the content inspection layer. Security profiles enforced by the data plane include Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, and File Blocking profiles. This failure mode is particularly deceptive: the traffic log shows the session matching the correct rule with an allow action, but a separate threat log or URL filtering log entry reveals the actual block. Administrators focused solely on security policy often overlook profile-level enforcement entirely.
How to Identify It
After confirming the traffic log shows the correct rule matching, pivot immediately to the threat log:
admin@sw-infrarunbook-01> show log threat direction equal forward source equal 10.10.10.50
2026/04/04 10:05:12 THREAT vulnerability 10.10.10.50 192.168.1.100 443
Threat: CVE-2024-38112 Severity: critical Action: reset-both
Rule: allow-https-solvethenetworkThe rule allow-https-solvethenetwork is matching (action: allow), but the Vulnerability Protection profile is resetting the TCP connection for a critical-severity signature match. Check URL filtering blocks separately:
admin@sw-infrarunbook-01> show log url direction equal forward source equal 10.10.10.50
2026/04/04 10:06:44 URL 10.10.10.50 192.168.1.100 443 phishing block
URL: files.solvethenetwork.com/upload
Rule: allow-https-solvethenetworkVerify which security profiles are attached to the rule in question:
admin@sw-infrarunbook-01> show running security-policy | match -A 20 allow-https-solvethenetwork
profile-setting : profiles
antivirus : AV-Strict
vulnerability : VP-Critical-Block
url-filtering : URL-Corporate-Policy
anti-spyware : AS-DefaultHow to Fix It
If a vulnerability signature is triggering a false positive for legitimate traffic from 10.10.10.50 to 192.168.1.100, create a targeted exception in the Vulnerability Protection profile rather than disabling the profile entirely:
admin@sw-infrarunbook-01# set profiles vulnerability-protection VP-Critical-Block rules FP-Internal-Host threat-name any host-name 10.10.10.50 category any severity any action allow packet-capture disable
admin@sw-infrarunbook-01# commitFor URL filtering blocks, determine the category assigned to the URL and either request a re-categorization via the Palo Alto Networks URL database or create a custom URL category exception in the URL Filtering profile. Always investigate why the profile is blocking before creating exceptions — the block may be responding to a genuine threat indicator and the exception may introduce risk.
Root Cause 6: NAT Policy Interfering with Zone Resolution
Why It Happens
Source NAT changes the post-NAT source address but does not alter the zone context used for security policy matching — pre-NAT source addresses and zones are used. However, destination NAT (DNAT) introduces a critical nuance: the destination zone in the security rule must reflect the post-NAT destination zone, not the pre-NAT zone. When inbound traffic arrives on the untrust interface destined for a public IP (e.g., 198.51.100.10), DNAT translates it to an internal host at 10.10.10.100 in the trust zone. The security rule must therefore specify trust as the destination zone — matching the post-NAT result — even though the packet originally arrived with an untrust-zone destination. Many administrators write the rule with "untrust" as both source and destination zone, which never matches after NAT translation.
How to Identify It
admin@sw-infrarunbook-01> test security-policy-match source 203.0.113.20 destination 10.10.10.100 destination-port 80 protocol 6 from untrust to trust
Rule Name : allow-inbound-web
Action : allowadmin@sw-infrarunbook-01> test security-policy-match source 203.0.113.20 destination 198.51.100.10 destination-port 80 protocol 6 from untrust to untrust
No matching rule found.The second test mirrors what the rule incorrectly specifies. The first test (post-NAT IP, post-NAT zone) is how the firewall actually evaluates the session.
How to Fix It
Rewrite the security rule to use the post-NAT destination IP and destination zone:
admin@sw-infrarunbook-01# set security rules allow-inbound-web destination 10.10.10.100
admin@sw-infrarunbook-01# set security rules allow-inbound-web to trust
admin@sw-infrarunbook-01# commitRoot Cause 7: Address Object or Group Misconfiguration
Why It Happens
Security rules frequently reference named address objects or address groups rather than literal IP addresses. If an address object is configured with the wrong subnet mask (e.g., /32 instead of /24), a typo in the IP base address, or an FQDN that has not yet been resolved by the firewall's DNS client, traffic from the actual source or destination IP will fall outside the object's defined range and will not match the rule. This is especially common when address objects are created manually during maintenance windows under time pressure.
How to Identify It
admin@sw-infrarunbook-01> show address name addr-web-servers
Name : addr-web-servers
IP Netmask : 192.168.1.50/32If the security rule references addr-web-servers but the actual server is at 192.168.1.100, no traffic to 192.168.1.100 will ever match. Verify what the rule has defined for source and destination:
admin@sw-infrarunbook-01> show running security-policy | match allow-https-solvethenetwork
destination : addr-web-serversFor FQDN objects, confirm the firewall has successfully resolved the hostname:
admin@sw-infrarunbook-01> show dns-proxy fqdn all
FQDN IP TTL Last Resolved
portal.solvethenetwork.com 192.168.1.100 300 2026/04/04 09:50:12How to Fix It
admin@sw-infrarunbook-01# set address addr-web-servers ip-netmask 192.168.1.0/24
admin@sw-infrarunbook-01# commitIf the address object needs to cover multiple non-contiguous hosts, create an address group:
admin@sw-infrarunbook-01# set address addr-web-server-100 ip-netmask 192.168.1.100/32
admin@sw-infrarunbook-01# set address-group ag-web-servers static [ addr-web-servers addr-web-server-100 ]
admin@sw-infrarunbook-01# set security rules allow-https-solvethenetwork destination ag-web-servers
admin@sw-infrarunbook-01# commitPrevention
Preventing security rule mismatches requires both disciplined configuration practices and proactive verification habits embedded into every change workflow.
- Always run
test security-policy-match
before and after every rule change. Document the output as part of your change record. This command simulates real traffic parameters and immediately reveals mismatches without requiring live traffic generation. - Audit rule order on a scheduled basis. Use the Security Policy Optimizer available in Panorama to identify shadowed, unused, and overly permissive rules. Review hit counts quarterly using
show rule-hit-count vsys vsys1 rule-base security rules all
and investigate any rule with zero hits that should be active. - Use descriptive, structured rule names. A name like allow-trust-to-untrust-https-portal-solvethenetwork is self-documenting and far harder to misplace in the rule order than Rule_47. Enforce a naming convention organization-wide.
- Standardize zone naming and interface documentation. Maintain a living document that maps every interface and subinterface to its zone. Require zone verification as part of network change procedures before any interface reconfiguration is approved.
- Include App-ID dependency applications in every rule. Before finalizing any rule that specifies a particular App-ID, check the "Depends on" field in Objects > Applications and add all dependency applications to the rule.
- Prefer explicit service objects over "any". Maintain a centralized service object library with consistent naming (e.g., svc-https-443, svc-https-8443) so port scope is clearly defined and auditable across the entire policy.
- Test security profiles in alert mode before enforcement. When deploying new Vulnerability Protection, Antivirus, or URL Filtering profiles, set the profile action to alert first and monitor threat logs for false positives before switching to block or reset-both.
- Implement formal change control that mandates policy match testing. No new or modified security rule should be approved for commit without an accompanying
test security-policy-match
output showing the correct rule resolves. Treat this as a required artifact in your change management system. - Enable enhanced application logging on critical rules and set up log forwarding to a SIEM. Alerts on unexpected rule hits or zero-hit rules over time provide early warning before users report outages.
- Validate DNAT rules against the post-NAT zone requirement every time a NAT policy is modified. Create a runbook entry that explicitly states: destination zone in security rules must reflect post-NAT destination zone, not the ingress interface zone.
Frequently Asked Questions
Q: How do I test whether a security rule will match traffic before committing changes?
A: Use the
test security-policy-matchcommand in operational mode on the firewall CLI. Provide source IP, destination IP, destination port, IP protocol number (6 for TCP, 17 for UDP), source zone, and destination zone. The firewall returns the name and action of the first matching rule exactly as it would for live traffic, without generating any actual sessions or log entries.
Q: Why does my rule show an allow action in the policy but traffic is still being dropped?
A: The most common explanation is a security profile attached to the rule — Vulnerability Protection, Antivirus, Anti-Spyware, or URL Filtering — that is configured to block or reset sessions matching a specific threat signature or URL category. Check the threat log and URL filtering log filtered by the source IP. A session can match the correct security rule (allow) and still be terminated by content inspection within that same rule's security profile group.
Q: My rule has application set to "any" — why is traffic still being denied?
A: A rule with application set to any matches all App-IDs but still requires the source zone, destination zone, source address, destination address, and service field to all match simultaneously. Verify zone assignment on the ingress interface, check that the source and destination IPs fall within the address objects or groups referenced by the rule, and confirm the service field covers the port in use. Also verify that a more specific deny rule above yours is not consuming the traffic first.
Q: How does App-ID reclassification cause sessions to drop mid-transfer?
A: During the first few packets, the firewall classifies traffic as a generic App-ID (e.g., web-browsing). After inspecting more payload data, App-ID identifies the true application (e.g., sharepoint-online). If the security rule permits web-browsing but not sharepoint-online, the session is terminated the moment reclassification occurs. The fix is to include both the final identified App-ID and its dependency applications in the rule, or to use an Application Override policy for the specific port and IP combination.
Q: What is the difference between "application-default" and "any" in the Service field of a security rule?
A: application-default restricts the rule to matching traffic only on the port numbers defined as standard for the specified App-ID in the App-ID database. any matches traffic on all TCP and UDP ports regardless of the App-ID. Use application-default for strict enforcement of standard-port applications. If an application runs on a non-standard port, create a named service object for that port and assign it explicitly to the rule.
Q: How do I find which security rule is currently matching live sessions on the firewall?
A: Run
show session all filter source <IP> destination <IP>to list active sessions matching those endpoints, then use
show session id <session-id>to display the full session detail including the rule name, App-ID, action, and associated security profiles. For completed sessions, the traffic log records the rule name for each flow.
Q: Do I write my security rule using the pre-NAT or post-NAT IP address for destination NAT scenarios?
A: For destination NAT (DNAT), write the security rule using the post-NAT destination IP address and the post-NAT destination zone. Palo Alto evaluates the NAT policy first to determine the translated destination, then evaluates the security policy against that post-NAT result. Source addresses in security rules always use the pre-NAT (original) source address, regardless of whether source NAT is in effect.
Q: Why does test security-policy-match
show the correct rule but traffic still fails end-to-end?
A: The policy match test confirms which security rule matches the traffic tuple but does not evaluate security profiles, SSL/TLS decryption policies, DoS protection policies, or Application Override rules. Traffic can match the correct security rule and still be blocked by a security profile action, decrypted and inspected by a separate decryption policy, or rate-limited by a DoS policy. After confirming the correct rule matches, check the threat log, URL log, and decryption log for additional enforcement actions.
Q: How can I tell if a security rule has never received traffic?
A: Run
show rule-hit-count vsys vsys1 rule-base security rules allto display hit counts and last-hit timestamps for every security rule. A count of zero on a rule that should be receiving production traffic is a strong signal that the rule is being shadowed by an earlier rule or that the traffic parameters (zones, addresses, ports, App-ID) do not match what the rule defines. Cross-reference with the policy match test to confirm which rule is actually consuming the traffic.
Q: What does the log reason "policy-deny" mean in the traffic log?
A: A policy-deny reason means the session matched a security rule with a deny action configured, or it reached the implicit deny-all rule at the bottom of the security policy (the default behavior when no explicit rule matches). Use
test security-policy-matchwith the exact traffic parameters from the log entry to identify which rule is responsible. If the implicit deny is matching, the traffic zones, addresses, or ports do not match any explicit allow rule and a new rule must be created.
Q: Can a misconfigured address group cause a security rule to stop matching traffic?
A: Yes. If a security rule references an address group and a particular source or destination IP is missing from that group — or is within a subnet that is not included, or is covered by a /32 object where a /24 was intended — traffic from or to that IP will not match the rule. Run
show address-group name <group-name>to list all member objects, then
show address name <object-name>for each member to verify the IP range is correct. Correct the subnet mask or add the missing host to the group and commit.