Troubleshooting practice questions

Security policy hit counts

Why it fails: Security policy hit counts belong to policy and traffic monitoring views, not the Device Health report, which covers resource utilisation such as CPU, memory, disk and session counts. It is tempting because policy statistics are reported elsewhere in Panorama, but they are not part of device health telemetry.

Active user count

Why it fails: Device Health reports interface status, system resources and HA state, not session or user telemetry; active user counts appear in User Activity or ACC, not Device Health. It is tempting because user counts are a health-adjacent metric, but Panorama's Device Health covers hardware and connectivity only.

Packet Capture (pcap)

Why it fails: A packet capture records raw frames on the wire, showing that traffic is dropped but never which firewall rule matched it. It is tempting because it proves connectivity failure at the packet level, and it would be correct for diagnosing MTU, TCP handshake or application-layer faults rather than policy rule hits.

GlobalProtect logs

Why it fails: GlobalProtect logs record VPN and endpoint connectivity events, not security policy rule evaluations, so they cannot identify which rule matched the traffic. They would be correct when diagnosing remote user tunnel or authentication problems rather than policy enforcement.

Traffic Monitor

Why it fails: Traffic Monitor shows flow-level allow/deny logs but cannot identify the individual rule that matched, so it cannot pinpoint the blocking rule. It is tempting because it visualises traffic flows across the firewall, and it would be the right tool for spotting anomalous or unexpected traffic patterns rather than rule attribution.

Mobile user location

Why it fails: Mobile user locations are the Prisma Access compute locations where remote users connect. They process user traffic but do not directly route traffic to the corporate network. The actual connection to the corporate network is established via service connections.

Remote network

Why it fails: A remote network in Prisma Access refers to a branch or data center that connects to Prisma Access via IPSec tunnels. It is used for site-to-site connectivity, not for routing user traffic to internal applications. The service connection is the component that links Prisma Access to the corporate network for user traffic.

Explicit proxy

Why it fails: Explicit proxy is a feature that allows users to forward web traffic to Prisma Access without a VPN client. It is not used for routing traffic to internal applications. Service connections are required for internal access.

Decryption Logs.

Why it fails: Decryption logs record which traffic the firewall successfully decrypted; a user failing to reach the internet may never have a decryption event, so these logs cannot establish the failure. They are tempting because decryption logs are essential when diagnosing TLS inspection or certificate-related blocking.

Config Logs.

Why it fails: Config logs record device configuration changes, not the live traffic needed to trace a failed connection. They are tempting because configuration drift often causes outages, making them the right choice when verifying whether a recent change altered routing or firewall rules.

Threat Logs.

Why it fails: Threat logs record detections from security services, not the session or interface data needed to trace a failed connection. They are tempting because a blocked exploit can sever connectivity, making them correct when investigating whether a security control dropped the user's traffic.

The Security Policy is missing a Decryption Profile.

Why it fails: A missing Decryption Profile affects TLS inspection handling, not App-ID completeness; without decryption the firewall may identify the app from certificate or SNI alone. It is tempting because decryption gaps do impair identification, but it would be correct when traffic is encrypted and cannot be inspected, not when App-ID shows 'incomplete'.

The App-ID database is outdated.

Why it fails: An outdated App-ID database causes unknown applications to be identified as 'unknown-tcp' or 'unknown-udp', not 'incomplete'. It is tempting because signature gaps do block traffic, but it would be correct when the log shows unknown App-IDs; 'incomplete' specifically indicates insufficient packets for identification.

The application is using a custom port not defined in the Service object.

Why it fails: A custom port outside the Service object affects port matching, not App-ID classification; the firewall still identifies the application from payload signatures. It is tempting because service mismatches do cause blocks, but it would be correct when the log shows the application correctly identified yet denied on port grounds.

Transport layer

Why it fails: The Transport layer provides end-to-end communication services such as TCP and UDP, including port numbers and reliability. It does not perform logical addressing or routing between networks; those responsibilities belong to the layer that encapsulates packets with source and destination IP addresses.

Application layer

Why it fails: The Application layer in the TCP/IP model encompasses protocols such as HTTP, DNS, and SMTP that interact with user applications. It does not handle logical addressing or routing; those functions occur at lower layers, so it cannot be the layer responsible for moving packets between networks.

Network Access layer

Why it fails: The Network Access layer (also called Link layer) handles physical transmission and framing on the local link, including MAC addressing. It does not provide logical addressing or routing between different networks, which are functions of the layer above it in the TCP/IP stack.

Session Browser

Why it fails: The Session Browser displays active sessions and their details, including the identified application. While it can show identification, it is not the primary tool for verifying application identification across the network. ACC provides aggregated views and is better suited for this purpose.

Application Override policy

Why it fails: An Application Override policy can force traffic to be identified as a specific application, but it is a corrective measure, not a verification tool. It does not help verify the current identification; it only changes it. To verify, the administrator should first use monitoring tools like the Application Command Center or logs.

Packet Capture

Why it fails: Packet Capture allows the administrator to capture packets for analysis, but it does not directly show how the firewall identifies the application. It is used for deep troubleshooting of packet-level issues, not for verifying App-ID results. The ACC or Session Browser would be more appropriate for application identification verification.

Configure 'DNS over HTTPS' to force all traffic through the firewall.

Why it fails: DNS over HTTPS encrypts queries between client and resolver, so the firewall cannot inspect or block malicious domains, defeating the profile's purpose. DoH is chosen when privacy from on-path observers matters, not when inline DNS security inspection is required.

Create a 'DNS Proxy' object for every zone.

Why it fails: A DNS Proxy object is created per firewall DNS proxy instance to forward queries, not per zone; creating one for every zone adds no malware filtering. It is the right choice when the firewall must resolve and forward client DNS requests on behalf of internal hosts.

Enable 'Packet Capture' for all DNS traffic.

Why it fails: Packet capture only records DNS traffic for later forensic analysis; it neither detects nor blocks malware-related queries in real time. It is the correct action when troubleshooting or evidencing suspicious DNS activity after an incident, not for enforcing a security profile.

The rule is not matching because the source zone is set to 'any'.

Why it fails: Setting the source zone to 'any' would actually make the rule more inclusive, not less. If the rule is at the top and has the correct destination IP, it should match regardless of source zone. The issue is more likely related to the destination address object or rule order. Using 'any' for source zone is common in blocking rules and would not prevent the rule from matching.

The rule is being overridden by a more specific rule below it.

Why it fails: Security policy rules are evaluated top-down, and the first match is applied. A rule below cannot override a rule above it. If the blocking rule is at the top and matches, it will be enforced regardless of rules below. Therefore, this is not a valid cause. The issue must be that the top rule is not matching, likely due to an incorrect address object.

The rule action 'deny' is not supported; the correct action is 'drop'.

Why it fails: Palo Alto Networks firewalls support both 'deny' and 'drop' actions. 'Deny' silently discards the packet, while 'drop' also discards but may send a TCP reset. Both are valid for blocking traffic. The action is not the cause of the rule not working. The problem is more likely with the match criteria, such as the address object.

show session all filter source 10.1.1.1 destination 10.2.2.2

Why it fails: The 'show session all filter' command displays session details but does not show which security policy rule matched the session. It provides information like source, destination, application, and state, but not the rule name. To see the rule, you need to use a command that specifically queries the policy lookup, such as 'test security-policy-match'. This command is useful for session details but not for identifying the matching rule.

show running security-policy

Why it fails: The 'show running security-policy' command displays the entire security policy configuration, but it does not evaluate a specific flow. It lists all rules, which can be overwhelming and does not tell you which rule matches a particular session. It is useful for reviewing the configuration but not for real-time troubleshooting of a specific flow. It does not provide the action taken for a specific packet.

debug dataplane policy

Why it fails: The 'debug dataplane policy' command is not a valid command for policy lookup. Debug commands are used for advanced troubleshooting and can impact performance. There is no such command that directly shows the matching security policy rule for a flow. Using debug commands is not the recommended method for this task; the 'test security-policy-match' command is designed for this purpose.

The firewall is configured to use the management interface for DNS resolution, but the FQDN objects require a DNS proxy configured on a dataplane interface.

Why it fails: FQDN objects are resolved by the management plane using the DNS servers configured in the device settings. A DNS proxy on a dataplane interface is not required. The management plane performs periodic DNS lookups to refresh the IP addresses associated with FQDN objects. Therefore, this is not the cause.

The FQDN objects are not supported in security policies; only IP addresses can be used.

Why it fails: Palo Alto Networks firewalls do support FQDN objects in security policies. They are resolved to IP addresses dynamically. The issue is not lack of support but rather the resolution mechanism. If DNS is not working, FQDN objects will not resolve. Therefore, this statement is false.

The DNS servers configured on the management interface are not reachable from the dataplane.

Why it fails: FQDN resolution for security policies is performed by the management plane, not the dataplane. The management interface's DNS settings are used for this purpose. If the management interface can reach the DNS servers, resolution should work. Dataplane reachability is not required for FQDN object resolution. Thus, this is not the cause.

Configuration logs

Why it fails: Configuration logs record policy commits, administrator edits and object changes, not the management tunnel's transport state. They are tempting because they do capture management-plane activity, and would be the right source when auditing who altered a rule or troubleshooting a failed commit. Here the SCM connection's negotiation and heartbeat detail sits in the system logs instead.

Threat logs

Why it fails: Threat logs record security events such as intrusion or malware signatures, not management-plane session state. They would be the right source when investigating attacks or vulnerability exploits, but they contain no detail about the firewall's connection to the SCM service.

Traffic logs

Why it fails: Traffic logs capture data-plane sessions passing through the firewall, not the management tunnel to SCM. They are the correct source for diagnosing user or application flow issues, but the SCM management connection is logged elsewhere.

The users are authenticating to the application with credentials that are not mapped by User-ID

Why it fails: User-ID mappings affect user-based policy matching, but the rule in question matches on application, not user. Even if User-ID mapping were incomplete, the drop reason would relate to user matching rather than application identification. The observed session end reason points to an App-ID issue instead.

The application is using a port that is not included in the application's default port list

Why it fails: If the application used a non-default port, application-default would not match the flow, and the rule would not be selected. However, the drop reason specifically indicates the application was not identified, which is a different failure mode. A port mismatch would more likely result in no rule match rather than an unidentified application drop.

The security rule's service was set to application-default, which disables App-ID inspection entirely

Why it fails: Setting the service to application-default does not disable App-ID. It simply means the port is derived from the application definition. App-ID inspection still occurs, and the application field is still evaluated. This setting is common and does not cause unidentified-traffic drops by itself, so it cannot be the root cause here.

The firewall's management interface is not configured to allow GlobalProtect connections.

Why it fails: The management interface is used for administrative access, not for GlobalProtect client connections. GlobalProtect connections are typically handled on a separate interface or the same interface with a different port. If the management interface were the issue, the user would not be able to authenticate at all. Since authentication succeeds, the connection to the portal/gateway is working, so the management interface is not the cause.

The GlobalProtect client is not receiving a DNS server address from the gateway.

Why it fails: DNS issues would typically cause name resolution failures, but the user might still access resources by IP. The symptom of 'Connected' but no access suggests a policy or routing issue, not DNS. While DNS misconfiguration can cause problems, it is less likely to cause a complete inability to access internal resources if IP addresses are used. The security policy is a more direct cause.

The GlobalProtect Gateway is not configured with a certificate for SSL/TLS.

Why it fails: A missing certificate would prevent the SSL/TLS handshake, and the user would not be able to connect at all. The scenario states the user is 'Connected', indicating the SSL/TLS connection was established. Therefore, certificate configuration is not the issue. The problem lies in post-connection access, which points to policy or routing.

Configure a policy-based forwarding rule to send SaaS traffic to the local internet breakout.

Why it fails: Policy-based forwarding can direct traffic to a specific egress interface, but it does not inherently integrate with the SWG for inspection. Without a SASE integration, traffic might bypass security inspection or still be backhauled. The scenario requires both direct internet routing and SWG inspection, which policy-based forwarding alone does not guarantee.

Apply an application override policy to force SaaS traffic through the data center proxy.

Why it fails: An application override policy typically forces traffic to a specific port or proxy, which would still route through the data center, not direct to the internet. It does not achieve local breakout or leverage the cloud SWG. This would not resolve the latency issue and could complicate security inspection.

Create a static route for SaaS IP ranges pointing to the data center VPN tunnel.

Why it fails: Creating a static route to the data center VPN tunnel would continue backhauling SaaS traffic, increasing latency and defeating the purpose of local breakout. It does not provide direct internet access or cloud SWG inspection. This would worsen the reported slowness and is contrary to the goal of optimizing SaaS access.

Traffic Logs in Panorama

Why it fails: Traffic logs record session allow or deny decisions with source, destination and application, but no latency or path-quality metrics. They are tempting because they show SaaS sessions, and would be correct for confirming whether traffic was permitted or which security policy matched.

GlobalProtect App logs

Why it fails: GlobalProtect App logs record client-side connection events and tunnel state, not hop-by-hop latency to the Service Connection. It is tempting because they are the natural first stop for mobile-client faults, and would be correct for diagnosing client authentication or tunnel-establishment failures.

ACC (Application Command Center)

Why it fails: ACC presents aggregated application, user and threat dashboards, not per-path latency measurements between client and Service Connection. It is tempting because it visualises SaaS application traffic, and would be correct for identifying which applications or users generate the most traffic.

Mismatched DH Group in Phase 2.

Why it fails: A mismatched DH group in Phase 2 affects IPsec quick mode, which only runs after Phase 1 completes; 'INIT' indicates Phase 1 itself never established. DH group mismatch is tempting because it is a common VPN fault, but it produces quick-mode failures, not the stuck initial state.

Incorrect Proxy-ID settings.

Why it fails: Proxy-ID mismatches surface during Phase 2 quick mode when selectors are exchanged, whereas 'INIT' means no Phase 1 SA has formed. Proxy-ID configuration is tempting because it commonly breaks site-to-site tunnels, but it cannot cause a tunnel to remain in the initial negotiation state.

Expired certificate on the peer.

Why it fails: An expired peer certificate breaks IKE authentication, producing a Phase 1 failure after negotiation begins, not the initial 'INIT' state where no ISAKMP response arrives. Certificate expiry is tempting because it does block tunnels, but it manifests as authentication failure rather than unreachable peer.

Traffic logs

Why it fails: Traffic logs record session flows permitted or denied by security policy, not BGP finite-state-machine transitions or neighbour messages. They are tempting because they are the first logs checked for connectivity faults, and would be correct when verifying whether routing or policy is dropping session traffic.

Threat logs

Why it fails: Threat logs record security events matching vulnerability or spyware profiles, not routing protocol messages. BGP neighbour state transitions and keepalive or notification messages appear in the routing log. Threat logs would be the correct choice when investigating intrusion attempts or malware traversing the firewall.

Config logs

Why it fails: Config logs capture administrative commits, user changes and configuration version history, not live BGP session events. Neighbour state changes and protocol messages are written to the routing log. Config logs would be correct when auditing who altered firewall policy or rolling back a bad commit.

The local device group lockdown setting.

Why it fails: Device group lockdown prevents local firewalls from overriding Panorama-pushed configuration, but it does not explain a template value differing from what the firewall displays. It is tempting because lockdown governs configuration precedence, yet it would be correct when local changes are being rejected, not when a template setting is not reaching the device.

The Panorama log collector status.

Why it fails: Log collector status concerns forwarding and storage of traffic, threat, and system logs; it has no bearing on whether template configuration reaches a firewall. It is tempting because Panorama health checks include collector connectivity, but it would be correct when logs are missing or delayed, not when a pushed setting is overridden.

The firewall's OS version compatibility.

Why it fails: Panorama manages firewalls running differing PAN-OS releases, and template values apply regardless of version; incompatibility would block template or device-group pushes entirely, not silently substitute a different value. It is tempting because version mismatches cause push failures, but it would be correct when the commit itself errors on unsupported syntax.

Disable all logging on the tunnel interface.

Why it fails: Logging is crucial for troubleshooting.

Enable DHCP on the tunnel interface.

Why it fails: DHCP is not used for site-to-site tunnel interfaces.

Configure the tunnel as an L2 bridge.

Why it fails: Tunnel interfaces are L3, not L2.