top of page
Search

Palo Alto Security Policy Miss: test security-policy-match When Traffic Hits Interzone-Default

  • Aug 15
  • 2 min read
Palo Alto network security troubleshooting lab
Palo Alto · Techclick CLI troubleshooting lab
App team says HTTPS is allowed. Traffic log shows interzone-default deny. They want the rule name, not a lecture.

This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.

What you will be able to do

  • Name the first CLI command to run on Palo Alto for this ticket

  • Separate the layer that is actually broken from the layer people blame

  • Apply one scoped fix instead of a global disable

  • Prove the ticket closed with a session, log, or counter

Quick answer

Use test security-policy-match with the real 5-tuple and application. If the result is interzone-default, the session never reached your intended rule — fix zone, user, or app-id before you add another any-any.

Why this ticket shows up

Palo Alto matches top-down on zone, user, app, service, and HIP. A wrong source zone or an unknown-tcp app-id sends good traffic to the default deny.

Symptoms operators actually see

  • Traffic log action deny, rule interzone-default

  • Same host works from another VLAN

  • App-ID shows unknown-tcp or ssl instead of the real app

  • User column is empty

CLI first — copy this block

Run these on the Palo Alto device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.

test security-policy-match from trust to untrust source 10.20.30.40 destination 203.0.113.10 destination-port 443 protocol 6 application ssl
show session all filter source 10.20.30.40 destination 203.0.113.10
show log traffic query equal "( addr.src in 10.20.30.40 ) and ( addr.dst in 203.0.113.10 )"
show user ip-user-mapping ip 10.20.30.40

How to read that output

The test command prints the first matching rule. If it prints interzone-default, your intended rule never saw the packet. Empty user mapping means a user-based rule cannot hit. unknown-tcp means App-ID did not finish — you may need an application-override or a wider service only as a temporary prove-it step.

Triage order

  1. Pull one denied session from the traffic log and copy its 5-tuple exactly.

  2. Run test security-policy-match with those values, including application if you know it.

  3. If the match is interzone-default, check source/destination zone against the ingress interface.

  4. Confirm user mapping if the rule is user-based.

  5. Only then edit the rule — do not insert a new any-any above it.

Classic traps

What you see

Real cause

Fix

Port 443 is open

Rule uses application slack, not ssl/web-browsing

Match on the App-ID you actually see

Host is in trust

Packet arrived on a guest interface

Fix zone, not the rule

User is in AD

User-ID never mapped the IP

Fix mapping before policy

Proof the ticket is closed

  • test security-policy-match returns your named rule

  • New allow session appears with the same rule

  • No new any-any was added

Say this in an interview

I reproduce the deny with test security-policy-match before I touch the policy. If it already matches, the problem is not the rule.

Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/

Comments

bottom of page