Palo Alto IPsec VPN Is Up but No Traffic Passes

Scope: IPv4 route-based site-to-site IPsec on Palo Alto Networks firewalls running PAN-OS. The addresses and tunnel names below are illustrative. The example uses a standard virtual router.

If the IPsec tunnel is up but an application still times out, follow one connection across both peers. An established security association (SA) does not confirm that the firewall sends your application traffic into that SA or that the remote host can reply.

Symptom and test flow

A client at 10.10.10.25 cannot connect to a server at 10.20.20.50 on TCP/443. The local tunnel is named HQ-BRANCH, its interface is tunnel.41, and it belongs to the VPN zone. Generate a fresh HTTPS connection from the LAN client and note the timestamp. A firewall-generated ping follows a different path from a client session.

1. Confirm the SA and its traffic selectors

show vpn ike-sa tunnel HQ-BRANCH
show vpn ipsec-sa tunnel HQ-BRANCH
show vpn flow

Check IKE and IPsec separately. If IKE is established but there is no IPsec SA for the relevant traffic, inspect the peer’s negotiation logs and compare Phase 2 settings. Where Proxy IDs are configured or required by the peer, verify that the negotiated selectors cover the source and destination. Local and remote networks are reversed on the far end. If the design intentionally translates VPN traffic, compare the selectors to the translated addresses.

2. Check routing, tunnel zone, and return path

show routing route

On the local firewall, find the route covering 10.20.20.50 in the routing instance that forwards the client traffic. The expected egress is tunnel.41. Confirm the interface is in the intended virtual router and zone. Check policy-based forwarding if it is configured. On the peer, verify the return route for the source address as the peer sees it. A valid local route tells you where the firewall intends to send a packet. It does not establish that the peer can return it.

3. Confirm which Security and NAT rules matched

In Monitor → Logs → Traffic, filter by the client and server addresses, then inspect the newest matching session. Check action, rule name, source and destination zones, translated addresses, and bytes sent and received. For this outbound flow, expect Trust to VPN locally and a tunnel-zone-to-LAN rule on the peer. Also verify the rule allows the intended service and application. An absent log is inconclusive if logging is disabled or the session has not ended.

Check for an internet source NAT rule that also matches the VPN destination. If the design preserves original addresses, verify that the matching NAT rule leaves the flow untranslated. Replies are part of the existing stateful session. For a connection initiated at Site B, verify that the applicable Security policies also allow the reverse initiation.

4. Compare counters and capture at the right stage

show vpn flow tunnel-id <tunnel-id>

Use the numeric ID from show vpn flow. Compare encapsulation and decapsulation counters before and after a few test connections. On Site A, look for encapsulation. On Site B, look for the corresponding decapsulation, then reverse the check for replies. Counters can include unrelated flows, so use a narrow capture to confirm the individual session.

In Monitor → Packet Capture, use narrow filters for the flow and its reverse direction. Enable capture only for the test window. Inspect the receive, firewall, and drop stages. The outgoing inner packet may be absent from a logical tunnel capture because the transmit stage can show encrypted traffic. Correlate the tunnel counters with the peer’s capture before treating a missing packet as a drop. Stop the capture when the test is complete.

SYN arrives on the local LAN but never reaches the peer: check the matched Security rule, forwarding decision, NAT, and the SA. The peer forwards the SYN to the server but sees no SYN-ACK: check the service listener, endpoint firewall, and server gateway. The peer sees the SYN-ACK but the client does not: trace the return route and compare peer encapsulation with local decapsulation.

5. Verify the fix

Repeat the original TCP/443 test from the LAN client. Confirm the TCP handshake and an application response, then confirm that both firewalls show the expected flow. Record which check identified the fault and what changed. The initial checks above do not require clearing the tunnel or restarting IKE.

References and related guides

Site-to-site VPN CLI troubleshooting · Test VPN connectivity · Proxy IDs · Verify tunnel transmit traffic

Working with a FortiGate peer? See FortiGate IPsec VPN Is Up but No Traffic Passes.

If the remote peer is a Check Point firewall, see the Check Point IPsec troubleshooting guide.