A Palo Alto IPsec tunnel can have an established security association while the application you care about still fails. Start by separating negotiation status from forwarding evidence: verify the relevant IPsec SA, generate one identifiable application connection, and trace that connection in both directions. PAN-OS exposes separate IKE SA, IPsec SA and VPN flow commands for these checks.[5][7]
This guide is a reusable incident worksheet for Palo Alto IPsec tunnel up but no traffic problems. It focuses on route-based site-to-site VPNs, not GlobalProtect clients. The matrix, workflow and acceptance criteria are original operational recommendations, not a report of a tested production incident. All command templates below are unexecuted examples; confirm syntax on your PAN-OS release.
First define what “up” actually means
Palo Alto's documented connectivity sequence checks the IKE security association and the IPsec security association separately, then inspects VPN flow information.[7] Record the exact tunnel and the affected subnet pair rather than taking a screenshot of an unrelated green gateway.
A tunnel interface must belong to a security zone and be assigned to a virtual router in the documented PAN-OS design.[6] Consequently, checking negotiation alone is not an adequate acceptance test for a new branch application.
Before changing anything, record:
- Firewall software release, active device, virtual system and routing context.
- IKE gateway, IPsec tunnel and tunnel interface associated with the failing service.
- Test-client address, destination address, protocol, port and start time.
- Whether the failure affects every application, one subnet, one direction or only larger transfers.
- The expected source identity: original client or intentionally translated address.
Keep real addresses and packet captures inside the incident system. The worksheet uses role names, not customer topology or addressing.
Packet-path diagram: locate the first missing observation
Start at the client and move toward the server. Repeat from the server toward the client. Do not interpret a tunnel-wide counter increase as proof of your test if unrelated traffic is using the same tunnel.
Troubleshooting matrix: observation, next check, safe action
The matrix is a hypothesis generator. Its rows describe where to investigate, not a claim that one counter proves one root cause. The underlying PAN-OS inspection commands are documented by Palo Alto Networks.[5][7]
| Observation during a controlled test | Investigate next | Safe next action / evidence to collect |
|---|---|---|
| IKE SA exists; relevant IPsec SA does not | IPsec negotiation and required subnet pair | Compare peer configuration and system logs before touching the working gateway |
| IPsec SA exists; the local firewall does not see the client attempt | Client route, local gateway, upstream filtering, wrong destination | Confirm the actual resolved address and capture or log the same connection at ingress |
| Local ingress is visible; expected tunnel egress is not | Forwarding choice, zone policy, translation, selector coverage | Record the selected route, actual session path, rule and original/translated tuple |
| Local encapsulation rises; peer sees no corresponding decapsulation | Underlay delivery, peer selection, inbound IPsec processing | Compare a narrow timed test on both peers; inspect drop evidence rather than resetting both sides |
| Peer decapsulation rises; server receives nothing | Peer security policy, route toward server, LAN path | Follow decrypted traffic from peer to server and inspect the receiving host |
| Server receives request; no reply enters the peer firewall | Server application, host firewall, server default gateway | Verify a listener and trace the actual server response path |
| Peer sends a reply; client never receives it | Reverse tunnel path and local post-decryption forwarding | Correlate reverse counters, local session and client-side observation |
| One subnet works; another fails | Subnet-specific route, policy, translation or selectors | Compare the working and failing tuples side by side |
| Small requests work; larger transactions stall | Packet-size sensitivity, loss, retransmissions or application behavior | Measure the failing size/path before considering MTU or MSS changes |
1. Verify the relevant SA without disturbing service
Use this read-only baseline; replace the angle-bracket placeholders before use. These commands come from Palo Alto's documented VPN troubleshooting procedure.[5][7]
show vpn ike-sa gateway <gateway_name>
show vpn ipsec-sa tunnel <tunnel_name>
show vpn flow
show running tunnel flow info
Save before-and-after snapshots around one approved application test. Record counter deltas only when the device output actually exposes the relevant counters. If the summary does not expose enough detail, use that release's CLI help and documented per-tunnel diagnostics; do not invent a field name or assume an aggregate is per-selector.
The vendor also documents test vpn commands for initiating negotiation and clear vpn commands that remove SAs.[5] Those are not passive observations: keep them out of the initial baseline and do not clear a shared tunnel merely because one application fails.
2. Check routing context and security-zone intent
For the documented static-routing design, the destination-subnet route selects the tunnel interface; a tunnel-interface IP address is not required simply to carry statically routed traffic.[8] Palo Alto specifies an address for tunnel monitoring or dynamic routing use cases.[6]
Check the route for the actual destination used by the client, not just an expected remote aggregate. Inspect any configured policy-based forwarding and compare its intended behavior with the observed session path. Repeat the process for the server's route back to the original or intentionally translated client identity.
A dedicated VPN zone is a documented option for visibility and policy separation, and traffic between that zone and the local trusted zone requires appropriate security policy.[6] Do not copy another site's zone names or add an unrestricted rule between internal and external zones. Propose the smallest correction supported by your observed flow and approved application requirements.
3. Compare selectors and translation as a pair
When the remote peer uses policy-based VPN, Palo Alto requires local and remote proxy IDs.[6] Its troubleshooting guide states that the peers' local and remote proxy IDs should be mirrors of each other and calls out prefix-length mismatches as a negotiation problem.[7]
Use this comparison worksheet for every affected subnet pair:
| Field | Local peer | Remote peer |
|---|---|---|
| Intended protected source | Local application/client network | Remote application/server network |
| Intended protected destination | Remote application/server network | Local application/client network |
| Configured selector or proxy ID | Copy exact local/remote pair into private worksheet | Compare reversed pair, masks and any protocol/port restrictions |
| Address translation | Record actual original and translated identities | Confirm which identities the remote design expects |
| Installed IPsec SA | Confirm the affected pair, not only another working pair | Confirm corresponding negotiation result |
| Return route | Route toward remote service | Route toward the client identity actually in use |
Do not broaden selectors to every address as a troubleshooting shortcut. If overlapping addressing requires intentional translation, document that design explicitly. A blanket “disable all NAT for VPN” prescription is not a substitute for checking the packet identities your two peers actually use.
If negotiation is failing, use the official error-to-cause table to distinguish crypto-profile, PFS and proxy-ID issues.[7] If the relevant SA is already established, prioritize evidence of the application path rather than repeatedly changing proposals.
4. Run a real application test in both directions
Select one approved client and service. Use the application's normal name and protocol, then note the resolved address and connection time. A firewall-originated probe can be a useful separate diagnostic, but do not count it as a replacement for the user's application transaction.
For each test, retain these observations:
- Client attempted the expected destination and port.
- Local firewall observed the flow and the intended route/policy behavior.
- Remote firewall observed the corresponding decrypted traffic.
- Server received the request and generated a response.
- Client received the response and completed an application-level operation.
If the symptom is size-dependent, add controlled small and larger transactions within the application's safe operating limits. Treat MTU/MSS as a measured hypothesis, not a universal tunnel fix. Avoid flooding a shared production VPN or collecting broad payload captures containing unrelated users' data.
Change and rollback worksheet
Make one narrowly scoped change at a time, through your normal approval and commit process. This is the suggested ticket template:
Symptom and affected service:
Known-working comparison flow:
Test tuple and timestamp:
Last confirmed observation in forward path:
Last confirmed observation in reverse path:
Evidence supporting proposed change:
Exact objects/rules/routes to change:
Expected improvement and negative test:
Rollback configuration and responsible operator:
Monitoring window and application-owner sign-off:
Retest with a new application connection after the approved change. Preserve the original evidence so a later reviewer can distinguish an actual forwarding correction from a coincidental recovery. If a reset is justified, schedule its scope and impact explicitly rather than resetting every VPN on the device.
Acceptance checklist: close the incident on application evidence
- [ ] Relevant IKE and IPsec SAs are present, not merely an unrelated gateway.
- [ ] Every required subnet pair has been checked against route, policy and selector intent.
- [ ] Expected source identity and return routing are documented on both sides.
- [ ] A fresh end-to-end application transaction completes from the intended client.
- [ ] Required reverse-initiated services are tested separately, if any.
- [ ] A representative larger transfer succeeds when that was the reported failure.
- [ ] An unauthorized test flow remains blocked; no broad temporary permit remains.
- [ ] Captures/debugging are stopped, artifacts protected and rollback information retained.
- [ ] Application owner confirms recovery; monitoring continues for the agreed window.
Practical takeaways
Do not troubleshoot a green icon. Troubleshoot one precisely identified connection. Start with passive SA and flow inspection, find the first missing observation, compare both peers' forwarding and selector intent, and change only what the evidence supports. Your durable output should be a completed worksheet and successful application test, not just “tunnel restarted.”
For related workflows, see Palo Alto NAT Troubleshooting: Why the Rule Matches but Traffic Still Fails, Palo Alto Firewall HA Failover Test Plan: Sessions, NAT and Routing Checklist and the Start Here networking index. The networking resources page collects further reading.
Sources
- [5] https://docs.paloaltonetworks.com/network-security/ipsec-vpn/administration/troubleshooting/troubleshooting-site-to-site-vpn-issues-using-cli
- [6] https://docs.paloaltonetworks.com/network-security/ipsec-vpn/administration/get-started-with-ipsec-vpn-site-to-site/site-to-site-vpn-overview/tunnel-interface
- [7] https://docs.paloaltonetworks.com/network-security/ipsec-vpn/administration/troubleshooting/test-vpn-connectivity
- [8] https://docs.paloaltonetworks.com/network-security/ipsec-vpn/administration/site-to-site-vpn-quick-configs/site-to-site-vpn-with-static-routing
Post a Comment