Troubleshooting Scenario Questions

Whether logging is enabled on the rule.

Why it fails: Logging is for visibility, not for blocking decision.

Whether SSL decryption is enabled for the traffic.

Why it fails: Decryption is for inspection, not a direct cause of blocking.

The HA2 link is down or misconfigured

Why it fails: HA2 link failure would break state synchronisation, but the passive firewall was upgraded to 10.1 while the active remains on 10.0; PAN-OS requires matching versions for HA synchronisation. HA2 misconfiguration tempts because it commonly causes sync failures, yet here the version mismatch is the direct cause.

The HA keepalive timer is misconfigured

Why it fails: Keepalive timers govern heartbeat failure detection, not configuration synchronisation between peers. The passive firewall runs PAN-OS 10.1 while the active runs 10.0, and mismatched versions prevent HA sync. Timer misconfiguration tempts because it causes HA problems, but it would not produce this version-specific failure.

The passive firewall has preemption enabled

Why it fails: PAN-OS requires matching major versions for HA configuration synchronisation, so a 10.0 active peer cannot sync with a 10.1 passive peer regardless of preemption. Preemption only governs which firewall assumes the active role after failover, making it the right setting to tune when controlling failback order, not version compatibility.

The application must be set to 'any'.

Why it fails: Setting the application to web-browsing already matches HTTP traffic on port 80, so changing it to 'any' is unnecessary. App-ID resolves the actual application regardless of port. 'Any' would be correct only when the application is unknown or when you deliberately want to permit all applications in a broad rule.

The log setting is preventing hits.

Why it fails: Log at session end only controls whether a log is generated when the session terminates; it has no bearing on rule matching or hit counters. The rule would still increment if traffic matched. This setting is correctly chosen when you want logging without affecting enforcement, so it is a plausible but irrelevant factor here.

The destination address is too broad.

Why it fails: A destination address of 'any' matches every destination, including 1.2.3.4, so it cannot prevent the rule from being hit. Broad destinations are normal in outbound rules. A narrower destination would be correct when you need to restrict egress to specific external hosts or subnets.

Verify that the decryption certificate is valid

Why it fails: A valid decryption certificate matters, but the firewall can still decrypt with an untrusted or expired certificate, so validity is not the first gate. Sessions that never match the decryption policy's source, destination and service criteria are simply not decrypted, making rule-match verification the initial step.

Disable the SSL/TLS service profile

Why it fails: Disabling the SSL/TLS service profile removes the settings the firewall uses to present its decryption certificate, which would break decryption further rather than restore it. The profile is required for forward-proxy and inbound inspection; troubleshooting starts by confirming the session matches the decryption policy.

Ensure that the server's certificate is imported

Why it fails: Importing the server certificate addresses forward-proxy trust for outbound decryption, not inbound decryption of traffic to that server. The first check is whether the traffic actually matches the decryption policy's source, destination and service/URL criteria, since unmatched sessions bypass decryption entirely.

Threat logs

Why it fails: Threat logs record traffic matching security profiles such as antivirus, anti-spyware, and vulnerability protection, so they capture exploit or malware signatures rather than administrative events. They are the right choice when tracing a detected threat to its source session, not for logins or commit failures.

Traffic logs

Why it fails: Traffic logs record session start and end entries with source, destination, application, and action, so they describe allowed or denied flows rather than administrative activity. They are the correct source for troubleshooting connectivity or policy enforcement, not for user logins and commit failures.

URL filtering logs

Why it fails: URL filtering logs record web requests matched against URL categories and profiles, so they show browsing destinations, not administrative activity. They would be the correct source when investigating which sites a user visited or why a category block fired, not for logins or commit failures.

OSPF is flapping and causing route instability.

Why it fails: OSPF neighbors are stable, so flapping is not present.

A DDoS attack is overwhelming the management plane.

Why it fails: DDoS would affect dataplane more, and management CPU would not be sole symptom.

The firewall's licenses have expired, causing feature degradation.

Why it fails: License expiry would not cause the described symptoms.

The security rule is misconfigured because it lacks an application field.

Why it fails: A rule lacking an application field matches on other criteria and would not itself produce an incomplete application value; incomplete is a session state, not a rule error. It tempts because misconfigured rules are a common cause of blocked traffic, but here the block is a symptom, not the cause.

The firewall does not have an App-ID signature for the website.

Why it fails: App-ID identifies applications from traffic patterns regardless of port, so a missing signature yields unknown-tcp, not incomplete; incomplete means the firewall saw too few packets to classify. It tempts because signature gaps do cause unknown application results, but that is a different log value.

SSL decryption is not enabled, so App-ID cannot identify HTTPS traffic.

Why it fails: Without SSL decryption, App-ID still identifies HTTPS applications via server certificate and SNI, so traffic is not left incomplete for that reason alone. It tempts because decryption does improve App-ID coverage, and it is the right answer when encrypted sessions show unknown-tcp.

The new rule has an incorrect source zone.

Why it fails: An incorrect source zone would block traffic matching that zone entirely, producing consistent failures rather than the mixed connectivity reported. It tempts because zone errors are a common cause of dropped traffic, and checking rule placement is a sensible step once session-level explanations have been excluded.

There is a mismatch between the virtual wire vs layer3 interface.

Why it fails: Virtual wire versus Layer 3 interface is a design-time configuration choice, not something that changes per user after a commit, so it cannot explain why only some users lose connectivity. It tempts because interface mode errors do break traffic, but they break it uniformly for everything traversing that path.

The committed configuration is still in candidate state.

Why it fails: A commit moves the candidate configuration to running, so it cannot remain in candidate state afterwards; the partial, user-specific symptoms point to session or application dependence instead. It tempts because uncommitted changes do explain absent enforcement, but that would affect all users equally rather than only some.

The source IP is negated in the rule.

Why it fails: Negating the source IP inverts the match, so the rule would target every address except the specified one, not block that address. Negation is tempting for whitelisting all-but-one hosts, which is its legitimate use, but it does not explain a higher rule permitting the traffic.

The rule is placed at the top of the rulebase and overridden by a later rule.

Why it fails: The stem already states the rule sits at the bottom of the rulebase, so a top placement contradicts the given facts. Top placement is tempting because first-match evaluation means an early rule wins, which is exactly why administrators put broad blocks there deliberately.

The rule is disabled in the rulebase.

Why it fails: A disabled rule cannot match traffic at all, so it would not be the rule permitting the connection; the stem states traffic is being allowed by a rule higher in the list. Disabling is tempting when decommissioning a rule temporarily, but an enabled rule above is the actual cause here.

Application override configured for HTTP

Why it fails: An application override forces traffic on those ports to a custom application, so return packets are classified differently and fail to match the original session, causing drops. Overrides are correct when a bespoke internal application must be identified instead of App-ID's default signature.

DNS resolution failure

Why it fails: DNS failure would prevent the initial connection entirely, yet the stem states the session initiates correctly, so name resolution already succeeded. DNS troubleshooting is correct when clients cannot resolve the destination hostname at all, producing no session in the table.

NAT policy mismatch

Why it fails: A NAT policy mismatch breaks return-path translation, so replies arrive with a destination the firewall cannot match to the existing session, which explains why the session initiates but return traffic is dropped. NAT policy is genuinely required when internal addresses must be translated to reach external hosts, but here the stem already confirms the outbound session formed correctly.

Review the system resources to check CPU usage.

Why it fails: CPU usage reflects device health and dataplane load, not whether a specific session matched a security policy rule. It is tempting during troubleshooting because resource exhaustion can cause drops, but system resources would be the right check when traffic is broadly failing rather than one website being unreachable.

Look at the Threat log for any malware detections.

Why it fails: The Threat log records signatures, antivirus and vulnerability events after traffic is allowed, so it cannot confirm whether the policy rule matched the session. It is tempting because a blocked website feels security-related, but Threat logs are the correct place when traffic passes the policy and a threat inspection action drops it.

Examine the URL filtering profile applied to the policy.

Why it fails: A URL filtering profile inspects HTTP request URLs for category or custom blocking, not whether the security policy rule matched the session. It is tempting because the symptom involves a specific website, but URL filtering would be the right check when the policy already permits traffic and a category block is suspected.

The TCP sequence numbers are out of order, causing the packets to be out of the expected window.

Why it fails: Out-of-order sequence numbers trigger a different drop reason, such as 'tcp-out-of-window' or 'tcp-replay', because the firewall tracks the expected sequence range separately from the initial handshake state. Sequence checking is the relevant mechanism when diagnosing retransmission or asymmetric-routing issues, not a missing SYN.

The NAT policy is misconfigured, causing the source IP to not be translated correctly.

Why it fails: A NAT misconfiguration alters translated addresses and typically yields routing or session-setup failures, not a 'tcp-non-syn' termination, since the firewall still observes the initial SYN. NAT policy troubleshooting applies when return traffic fails to match an existing session or source translation is absent.

The security policy uses an incorrect service object that doesn't match the application.

Why it fails: An incorrect service object would cause the session to be denied outright by policy, producing a deny log rather than an allow-then-terminate 'tcp-non-syn' entry. Service objects are the right focus when traffic on unexpected ports is silently blocked despite an apparently permissive rule.

System logs

Why it fails: System logs cover firewall system events, not decryption actions.

URL Filtering logs

Why it fails: URL Filtering logs show URL categories and policy actions, not decryption specifics.

Threat logs

Why it fails: Threat logs record security threats, not decryption details.

A zone protection profile is blocking ICMP packets.

Why it fails: Zone protection profiles apply to ingress traffic on a zone and can drop ICMP, but the user successfully pings the firewall's management IP, proving ICMP reaches the device. It tempts because zone protection does block flood and reconnaissance traffic. The likely cause is virtual-router or inter-zone forwarding configuration.

The decryption policy is blocking the traffic because it is not decrypted.

Why it fails: Decryption policy only inspects traffic matching its rules; unencrypted ping/HTTP traffic is bypassed, not blocked, so it cannot explain the failure. It is tempting because decryption failures do cause silent drops, but that applies when sessions are actually encrypted and a decryption profile rejects them.

The NAT policy is missing for the outbound traffic.

Why it fails: NAT is applied after the security policy and is required for outbound translation, but the stem states the security policy allows the traffic and the user reaches the firewall's management IP, so the failure lies in virtual-router routing or inter-zone forwarding. NAT policy is the correct focus when translation itself is absent.

The security rule is not placed at the top of the rulebase.

Why it fails: Rule order only matters when an earlier rule shadows the matching rule; the stem states traffic matches this rule, so position is irrelevant. Top placement would be the fix when a broader deny or different rule above intercepts the traffic before it reaches the intended allow rule.

A zone protection profile is blocking the traffic.

Why it fails: Zone protection profiles defend against flood, reconnaissance and packet-based attacks at ingress; they do not silently drop a single permitted session matching an allow rule. Such a profile would be the correct answer when the symptom is volumetric, such as SYN floods or port scans, rather than one blocked flow.

The destination server does not have a route back to the 192.168.1.0/24 subnet.

Why it fails: A missing return route would cause the server's replies to fail, but the stem specifies packets are dropped by the firewall, indicating the drop occurs on the forward path before any reply. Return-route absence is the answer when the firewall shows the session allowed yet no response reaches the client.