A user opens an internal HTTPS application and the request times out. In PAN-OS Traffic Logs, the matching connection shows Action: allow. That field tells you the Security Policy decision. To find out where the connection stalled, follow the same TCP flow through the end log, the session table, and, if needed, a short dataplane capture.
This walkthrough uses client 10.10.20.25, server 192.0.2.40, and TCP port 443. The server address is reserved for documentation. Substitute addresses from an environment you administer. The example has no NAT, so the same addresses apply on both sides of the firewall.
1. Match the log to the failed connection
Open Monitor > Logs > Traffic on the firewall or in Panorama. Reproduce the failure once and record the timestamp, source and destination IPs, TCP destination port, and, if available, the client source port. If the user supplied a hostname, confirm the IP the client actually contacted. An application can use several endpoints, and a successful connection to one of them can appear next to the failing connection.
Open the detailed view and record the following fields.
| Field | How to use it |
|---|---|
| Type and Session ID | Use the session ID with the firewall and timestamp to correlate records. Prefer the end entry when examining the completed attempt. |
| Rule, Action, and Application | Confirm the matched rule and recorded action. If the application remains incomplete, check the handshake before investigating application identification. |
| Ingress and egress interfaces | Confirm the flow followed the path you expected. |
| NAT addresses and ports | Record both the original and translated tuples before filtering a packet capture. |
| Bytes and packets sent and received | Look for traffic in both directions. Sent and received are relative to the session source. |
| Session End Reason | Use it to decide which evidence to collect next. |
A session-start log cannot tell you how the connection ended. Depending on the logging configuration and how far the connection progressed, the end log may also be absent. In that case, observe a new attempt in the session table or packet capture.
Palo Alto Networks – Traffic log fields · Session logging considerations
2. Inspect the live session from the CLI
Connect to the firewall carrying the traffic. While the client makes a fresh HTTPS request, run:
show session all filter source 10.10.20.25 destination 192.0.2.40 destination-port 443 protocol 6Use the session ID from that attempt to open its detail. Replace 12345 with the actual ID.
show session id 12345Compare the c2s (client to server) and s2c (server to client) flows. Check their addresses, ports, and packet counters, then confirm the ingress and egress interfaces. If NAT applies, compare the translated tuple with the firewall logs and use the address visible at each observation point.
If you see client-to-server packets and no server-to-client packets, check whether the firewall transmitted the SYN and whether a SYN-ACK returned. If both directions show traffic, determine whether TCP completed before looking at TLS or the application. A failed connection can disappear from the session table before you query it, so run the check during the next attempt.
Palo Alto Networks – PAN-OS 11.1 operational CLI hierarchy · Firewall session overview
3. Capture one attempt at the firewall
Check whether another capture is active before making changes. The CLI shows the current packet diagnostics settings:
debug dataplane packet-diag show settingIn Monitor > Packet Capture, configure narrow IPv4 filters for the client and server. For this no-NAT example, match TCP from 10.10.20.25 to 192.0.2.40 with destination port 443, and add a reverse filter with source port 443. If NAT applies, account for the translated addresses and ports when setting up the capture, especially for the returning traffic.
Enable the receive, firewall, transmit, and drop stages with separate filenames. Turn on filtering, start the capture, reproduce once from the client, and turn capturing off. Download the files and restore the diagnostic settings you changed. Use only the capture window you need. If a stage appears empty, check filter coverage, capture limits, and hardware offload before treating the absence as evidence.
| What the capture shows | What to check next |
|---|---|
| Client SYN appears in receive and transmit. No matching SYN-ACK appears in receive. | Check the next hop and take a server-side capture. Verify whether the SYN arrived and where the reply was routed. |
| Matching SYN-ACK appears in receive and drop, with no transmit copy. | Inspect the matching session, capture details, and relevant firewall logs before changing policy. |
| SYN, SYN-ACK, and ACK complete, then the TLS exchange fails. | Correlate the timestamps with Decryption logs if enabled, TLS alerts, and server or proxy logs. |
| TCP handshake completes and the application returns an HTTP error. | Check the response and application or reverse proxy logs for the same request. |
Palo Alto Networks – Custom packet capture · Packet capture limits and offload considerations
4. Use the session end reason to narrow the investigation
aged-outmeans the session expired. Combine it with directional counters and the capture to see whether the handshake ever completed.tcp-rst-from-serverortcp-rst-from-clientidentifies the observed reset direction. Inspect the packets immediately before the reset and correlate with logs from the endpoint or intermediate proxy.threatpoints to a threat-related enforcement action. Check Threat Logs using the session ID and timestamp.decrypt-cert-validation,decrypt-unsupport-param, ordecrypt-errorpoints toward the TLS inspection path. Check the Decryption log and applicable profile before changing the Security Policy.
Palo Alto Networks – Session End Reason values
Worked example: The server replies through a different gateway
In this illustrative case, the Traffic log shows allow and aged-out, with zero packets received from the server. The firewall capture shows the client SYN entering and leaving. A capture on the server shows that the SYN arrived and that the server sent a SYN-ACK. The firewall never sees that reply.
The server’s routing table sends traffic for the client subnet through a different gateway. After correcting the route under the approved change process, repeat the HTTPS request with a fresh connection. Confirm that the firewall receives and forwards the SYN-ACK, that TLS completes, and that the application returns the expected response. This closes the loop from a policy decision to a verified application result.