App-ID Mid-Session Shift — 'Allowed Then Suddenly Denied'
The Call Comes In
- "Application works for two or three seconds then disconnects"
- "Traffic initially shows as allowed in logs then there is a deny for the same session"
- "Started after an App-ID content update last night"
- "Random application failures — not all users, not all the time"
- "The policy allows the application but it still gets denied"
- "Everything was working fine until the content update"
- "The session log shows allowed and then denied for the same five-tuple"
Why This Is the Most Confusing NGFW Outage
What Most Engineers Try First (And Why It Fails)
- Add any/any rule temporarily — hides the problem but does not explain it, and is a security risk
- Disable threat prevention profiles — profiles are not the cause, App-ID identification is
- Blame the application team for a broken app — the app is fine, the policy does not cover its final identified App-ID
- Roll back the content update — may temporarily fix symptoms but re-enables the content update next cycle
- Check the security policy — finds the allow rule, confirms it exists, confused why deny still happens
How TAC Thinks About This Problem
Recall from Module 1: App-ID is dynamic. For the first packets of a session, the firewall identifies traffic as an intermediate application — typically web-browsing, ssl, or unknown. As more packets arrive, App-ID narrows the identification until it determines the final application.
Security policy is evaluated at session start with the intermediate application, and then re-evaluated when App-ID finalizes the identification. If the final application is not permitted by any rule in the rulebase, the session is denied — even though it was previously allowed under the intermediate application.
The allow log entry and the deny log entry for the same session are both correct. Allow happened when traffic was identified as ssl. Deny happened when App-ID completed identification as salesforce (or teams, or dropbox) and found no rule permitting it.
This problem frequently appears after a content update because Palo Alto Networks continuously improves App-ID signatures. An application that was not identified three months ago might now be precisely identified — meaning traffic that was passing as ssl now gets identified as its true application and hits a different (or no) policy.
The Actual TAC Debug Sequence
Step 1 — Identify the App-ID Shift in Logs
# Look at traffic logs for the affected user/application # Filter by time window when issue was reported show log traffic direction equal forward | match "<affected-user-ip>" # Look for two log entries for similar 5-tuple: # Entry 1: app=ssl, action=allow, rule=allow-web-traffic # Entry 2: app=office365-base, action=deny, rule=deny-others # Same source/destination IP and port, same approximate time = same session # Also check the application field specifically show log traffic direction equal forward app equal ssl | match "<server-ip>" # Then check if the final identified app has its own log entry show log traffic direction equal forward app equal office365-base | match "<server-ip>"
Step 2 — Check Session Browser for App State
# Find the active session show session all filter source <client-ip> destination <server-ip> # Get session detail — look at the application field show session id <session-id> # Key fields to check: # application: ssl ← still in intermediate state # application: office365 ← App-ID has completed — check if policy allows this # rule: <rule-name> ← which rule this session is currently matched to # If the session shows the final application but is still active, # the deny may not have happened yet for this particular session. # Reproduce the issue and immediately re-check.
Step 3 — Validate What Policy Would Match the Final App
# Test what rule matches for the FINAL identified application test security-policy-match from trust to untrust source <client-ip> destination <server-ip> application office365-base destination-port 443 # If result is "deny" or hits a deny rule — policy gap confirmed # Check what application dependencies exist # (Some apps require helper applications to be allowed) show application name office365-base | match "depends-on|use-application"
Step 4 — Check Content Update Version
# Confirm when the last content update was applied show system info | match "app-version|threat-version" # Check if the application signature changed recently # (This tells you whether the update changed identification behavior) show application name <app-name> # List applications by category to understand scope show application | match "saas|collaboration|office365"
Root Cause Patterns
Pattern 1: Policy Allows Intermediate App, Not Final App
The most common pattern. A rule says "allow ssl from trust to untrust" — the intent was to allow all HTTPS traffic. But the rule was written with ssl as the application, not web-browsing or any, and newer applications like Teams, Zoom, or Salesforce are now identified as their own App-IDs, not ssl. The rule no longer matches.
Fix: Add the specific application to the security rule, OR add the application's dependencies to an existing rule that uses ssl or web-browsing as the base application.
Long-term fix: Use application groups and maintain them. Never write rules with port-based applications (ssl, web-browsing) as the primary application control for known business applications.
Pattern 2: Missing Application Dependencies
Many SaaS applications depend on sub-applications for full functionality. The security rule allows office365-base but not the dependent applications (office365-consumer-access, ms-update, windows-azure-base). The primary app connects, but functionality fails because dependent calls are denied.
# Find all dependencies for an application show application name <app-name> # Look for the "depends-on" field in output # Example output: # depends-on: ssl,web-browsing,ms-update,windows-azure-base # All listed dependencies must be allowed in the same rule # or in a rule that applies before the session is established
Pattern 3: App Override Used Incorrectly
App override policies force a specific application identification for a traffic flow, bypassing App-ID entirely. When an app override exists and the security policy is written for the real App-ID, the override causes a mismatch — policy expects office365-base but App-ID has been forced to ssl by the override.
# Check if app override exists for affected traffic show running app-override-policy # Test if app override would match for this traffic test app-override-policy-match from trust to untrust source <client-ip> destination <server-ip> protocol 6 port 443
App Override Tradeoff
Pattern 4: Content Update Changed App Identification
After a content update, the vendor may have introduced or updated signatures for an application. Traffic that previously matched as web-browsing now matches as a specific application with its own policy requirements. This is intended behavior — improved visibility — but it surfaces policy gaps that were previously hidden.
| Before Update | After Update | Result |
|---|---|---|
| Traffic identified as: ssl | Traffic identified as: zoom | Policy allows ssl, not zoom → deny |
| Traffic identified as: web-browsing | Traffic identified as: dropbox | Dropbox blocked by category rule → deny |
| Traffic identified as: unknown-tcp | Traffic identified as: custom-app-v2 | No rule for custom-app-v2 → implicit deny |
The Fix and Long-Term Prevention
Immediate Fix — Add the Application to Policy
Once you have identified which application the traffic is shifting to, add it to the security rule that was previously allowing the intermediate application:
- Open the security rule that was allowing ssl or web-browsing
- Add the final identified application (e.g., office365-base) to the application list
- Also add all application dependencies identified from 'show application name'
- Commit and validate — session should now survive App-ID identification
Prevention — Test App-ID Before Applying Content Updates
# Before applying a content update in production: # Download update to the device but do not install request content upgrade download latest # Review the release notes for changed App-ID signatures # (Visible in Panorama or on the the vendor support portal) # After update, monitor traffic logs for new deny patterns show log traffic action equal deny | match "$(date +%Y/%m/%d)" # Check policy optimizer for unused or overly permissive rules # (Available in NGFW GUI: Policies > Policy Optimizer) # Use application filter in security rules rather than specific App-IDs # for known SaaS — this auto-includes new sub-apps as they are identified
Prevention — Use Application Groups and Filters
Instead of rule: allow [office365-base, office365-consumer-access, ms-update, windows-azure-base, ...] — create an Application Group called "Microsoft-365-Apps" and add all components. When new sub-applications are added in a content update, add them to the group once and all policies that reference the group are automatically updated.
Use Application Filters for categories like "saas-and-cloud" or "collaboration" — this catches new applications added to those categories automatically without requiring policy changes after every content update.