top of page
Search

Palo Alto Security Policy Not Matching: Proving Which Rule Traffic Actually Hit

  • Aug 15
  • 3 min read

The ticket says the application is blocked. You open the firewall, find the rule, and it looks exactly right - correct source, correct destination, correct service, action allow. The traffic is still denied.

The rule being correct and the rule being matched are two different things. This is the order to prove which one actually fired.

Why is my Palo Alto security policy not matching?

In almost every case the traffic is matching a different rule higher in the list, or the session started as one application and was re-identified as another once enough packets arrived. Palo Alto evaluates rules top to bottom and stops at the first match, so a broader rule above yours will always win. Run a policy test with the exact five-tuple before changing any configuration.

Step 1 - Ask the firewall which rule it would use

Do not read the rulebase and guess. The firewall will tell you directly.

admin@PA-VM> test security-policy-match \
    source 10.20.30.40 destination 52.114.77.33 \
    destination-port 443 protocol 6 application ssl

"Legacy-Any-Outbound" {
        from TRUST;
        source any;
        to UNTRUST;
        destination any;
        source-user any;
        category any;
        application/service [ any/tcp/any/any ];
        action deny;
        terminal yes;
}

There it is. The traffic never reaches your new rule - a legacy any-any rule sitting above it is matching first and denying. Your rule was never wrong; it was unreachable.

Common Mistake: Editing the rule you believe should match, committing, and testing again. If a rule above is shadowing it, you can edit yours all day and nothing changes. Test the match first, every time.

Step 2 - Read the hit counters

A rule with zero hits since the last reset is either unreachable or genuinely unused. Both are worth knowing.

admin@PA-VM> show rule-hit-count vsys vsys1 rule-base security rules all

rule                      hit-count   last-hit
-------------------------------------------------------
Legacy-Any-Outbound       8842119     2026-08-14 21:03
Teams-Media-Allow         0           -
Guest-Web                 44021       2026-08-14 20:58

Zero hits on the rule you are debugging, millions on a legacy rule above it. That is shadowing, confirmed with numbers rather than opinion.

Step 3 - The App-ID trap

This is the one that separates engineers who have run Palo Alto in production from those who have only configured it. A session does not have a final application on its first packet. The firewall initially identifies it by port and protocol, then re-evaluates as the handshake progresses.

So a session can start as ssl, match a rule that allows ssl, and then be re-identified as ms-teams once enough packets arrive. If your rule allows ssl but not ms-teams, the session is dropped mid-flight - which users report as "it connects then dies after a few seconds".

admin@PA-VM> show session all filter destination 52.114.77.33

ID      Application    State   Src            Dst              Rule
-----------------------------------------------------------------------
180422  ms-teams       ACTIVE  10.20.30.40    52.114.77.33     Legacy-Any-Outbound

admin@PA-VM> show session id 180422

  Session  180422
    application            : ms-teams
    session to be logged at end   : True
    rule                   : Legacy-Any-Outbound
    application changed    : yes  (ssl -> ms-teams)

Key Concept: "application changed: yes" is the single most useful line in that output. It tells you the rule that admitted the session is not the rule that should govern it. Any rule written around ssl alone will behave unpredictably for modern applications.

Step 4 - Fix it in the right order

Move the specific rule above the broad one, and name the real application rather than the transport.

admin@PA-VM# set rulebase security rules Teams-Media-Allow \
    application [ ms-teams ms-teams-media ] service application-default

admin@PA-VM# move rulebase security rules Teams-Media-Allow \
    before Legacy-Any-Outbound

admin@PA-VM# commit

Verify: run the same policy test again. It should now return your rule, not the legacy one. Then clear the session so it re-establishes against the corrected policy - an existing session keeps the rule it was admitted under.

admin@PA-VM> test security-policy-match source 10.20.30.40 \
    destination 52.114.77.33 destination-port 443 \
    protocol 6 application ms-teams

"Teams-Media-Allow" {
        action allow;
}

admin@PA-VM> clear session id 180422

Pro Tip: Always pair an App-ID rule with service application-default. Leaving the service as "any" allows that application on any port, which quietly undoes the reason you moved to App-ID in the first place.

Exam Trap: PCNSE asks what happens when App-ID re-identifies a session that a rule already permitted. The answer is that the firewall re-evaluates policy against the new application - it does not keep the original decision for the life of the session.

The order, in short

1  test security-policy-match     which rule WOULD match
2  show rule-hit-count            is my rule reachable at all
3  show session id <id>           did the application change
4  move / application-default     fix ordering and specificity
5  clear session + re-test        prove it, do not assume it

This sequence is part of the Palo Alto module in our Network Security Package - 90 hours covering Palo Alto, Zscaler and F5 BIG-IP, preparing you for PCNSE. Full syllabus: https://ai.techclick.in/courses

- Team Techclick techclick.in | +91 92772 29456 @techclick_in | exam.techclick.com

Comments

bottom of page