Troubleshooting Case Studies

A security engineer migrates a legacy firewall's port-based rules to a new Palo Alto firewall using App-ID. They create a rule: Source Zone = trust, Destination Zone = untrust, Application = web-browsing, Action = Allow. Users can browse HTTP sites but all HTTPS (SSL/TLS) sites fail. The HTTP sites are fine. The Threat log shows no blocks.

The 'web-browsing' App-ID only covers HTTP (port 80). HTTPS traffic is identified as 'ssl' by App-ID — a completely separate application. The policy allowing 'web-browsing' does NOT match SSL/HTTPS sessions, which are dropped by the default interzone-deny rule. The Threat log doesn't show blocks — those appear in the Traffic log with Action = Deny.

• Add 'ssl' to the Application field of the same rule (alongside 'web-browsing'), OR
• Create a separate rule for 'ssl' with the same source/destination, OR
• Consider also adding specific sub-applications you need (google-base, facebook-base, etc.) for more granular control
• Check the Traffic log (Monitor → Logs → Traffic) for Deny entries to confirm the fix

An administrator creates a DNAT rule to translate 203.0.113.5:443 → 10.0.1.10:443. They also create a security policy: Source Zone = untrust, Destination Zone = untrust, Destination IP = 203.0.113.5, Application = ssl, Action = Allow. External clients report the web server is unreachable. The firewall's Session Browser shows no matching sessions.

The security policy is incorrect. For INBOUND Destination NAT, PAN-OS evaluates the security policy using the POST-NAT destination IP (10.0.1.10) and the POST-NAT destination zone (trust — where the internal server lives). The policy was written using the PRE-NAT public IP (203.0.113.5) and the untrust zone — this never matches after DNAT is applied.

• Change the security policy: Destination Zone = trust, Destination IP = 10.0.1.10
• Keep Source Zone = untrust (external clients originate from untrust)
• Application = ssl, Action = Allow

A security engineer attaches a WildFire Analysis Profile to all Allow rules that permit file downloads. WildFire Submissions (Monitor → WildFire Submissions) confirms files are being forwarded and verdicts return as 'malicious'. However, users can still download and run the malicious files. No blocks appear in the Threat log.

The WildFire Analysis Profile controls what to forward for analysis — it does NOT block anything. To block files based on WildFire verdicts, an Antivirus Profile must also be attached to the same security policy rules. The Antivirus Profile's 'WildFire Inline ML' and 'WildFire verdict' settings control the blocking action.

• Create or edit an Antivirus Profile — under WildFire verdict settings, set 'malicious' action to Block (or Reset)
• Attach BOTH the WildFire Analysis Profile AND the Antivirus Profile to the security policy rules
• Alternatively, use a Security Profile Group that bundles both profiles

'show vpn ike-sa' shows an established Phase 1 SA. 'show vpn ipsec-sa' shows an established Phase 2 SA. Both firewall engineers confirm the tunnel is 'green'. However, ping from 10.0.1.50 (local) to 192.168.10.50 (remote) fails. No sessions appear in the Session Browser for this traffic.

Two components beyond the VPN tunnel are required for traffic to flow in a route-based VPN: (1) A static route pointing the remote subnet (192.168.10.0/24) to the tunnel interface (tunnel.1). Without this, the firewall has no path to the remote network. (2) A security policy allowing traffic from the trust zone to the vpn zone (or vice versa). The session never starts because there's either no route or the policy is missing.

• Add static route: Destination = 192.168.10.0/24, Interface = tunnel.1 in the Virtual Router
• Add security policy: Source Zone = trust, Source Address = 10.0.1.0/24, Destination Zone = vpn, Destination Address = 192.168.10.0/24, Application = any (or specific), Action = Allow
• Also add the reverse rule (vpn zone → trust zone) for return traffic

A web server at 10.0.1.10 is published externally as 203.0.113.5 via DNAT. External users reach it fine. Internal users (10.0.0.0/24) who try to access 203.0.113.5 experience a half-open TCP connection — the SYN is sent, the SYN-ACK is received from 10.0.1.10 directly (bypassing the firewall), then the ACK from the client doesn't match the server's session.

Without U-Turn (Hairpin) NAT, the firewall performs DNAT (203.0.113.5 → 10.0.1.10) but does NOT source-NAT the client's IP. The server receives the request from 10.0.0.50 and replies DIRECTLY to 10.0.0.50 (bypassing the firewall). The client sent its SYN to 203.0.113.5 via the firewall but receives the SYN-ACK directly from 10.0.1.10 — TCP session table mismatch causes the connection to fail.

• Add a U-Turn NAT rule: Source Zone = trust, Destination Zone = trust (same zone), Source Address = 10.0.0.0/24, Destination Address = 203.0.113.5
• On the Translated Packet tab: DNAT to 10.0.1.10:443 AND SNAT to firewall's trust interface IP
• The SNAT ensures the server replies to the firewall (not directly to the client), maintaining session symmetry

SSL Forward Proxy decryption is enabled for all traffic from the corporate VPN zone (GlobalProtect users). After connecting to GlobalProtect, users report their mobile banking apps fail with TLS errors or connection resets. Desktop banking works fine. The Threat log shows no blocks for the affected sessions.

Mobile banking apps use certificate pinning — they verify the server's exact certificate or public key, not just the CA chain. When SSL Forward Proxy intercepts the connection and re-signs the server's certificate with the forward trust CA, the pin check in the mobile app fails. Desktop browsers don't implement certificate pinning (except for specific Google/browser certificates) and trust the CA chain, so they work. The Threat log is empty because the decryption failure occurs at the TLS handshake level, before any policy action.

• Create a custom URL category for banking domains (e.g., *.bankofengland.co.uk, *.hsbc.com)
• Add a Decryption Policy rule: Source Zone = vpn, Destination URL Category = [banking custom category], Action = No Decrypt — place this rule ABOVE the general Decrypt rule
• Alternatively, use the built-in 'financial-services' PAN-DB URL category for the No-Decrypt exclusion