How to troubleshoot traffic flowing in only one direction through IPsec tunnel

• Firewall
• IPsec tunnel

1. Find out which direction of traffic has stopped getting passed through the tunnel. Check on each side of your tunnel whether encap packets versus decap packets have stopped incrementing. Login to each firewall at the end point of the tunnel and issue couple of times the command below:

   show vpn flow name <value> | match cap

2. Compare the tunnel configuration on both ends of the tunnel to verify matching protocol, auth algorith, enc algorithm and that the local ip, local spi and proxy-id local ip of one is equal to the peer ip, remote spi and proxy-id remote ip of the other. Use the following command on the firewalls of each side of the tunnel for that:

   show running tunnel flow name <value>

3. Initiate a session from a local host part of the local subnet of one firewall towards the remote host of the peer subnet of the peer firewall. Assuming that step 1 helped you identify the problematical direction initiate the traffic in that direction of the IPsec tunnel. Consider a simple example like the one shown below:

Where session is initiated from local host with IP address 172.17.240.10 to remote host with IP address 172.17.241.100.

4. Set a packet capture on both firewalls Getting Started: Packet Capture.
5. Check for any packet drops using packet capture and global counters:

   show counter global filter packet-filter yes delta yes

6. Check if routing on both firewall has been properly configured for private routes propagation.

   test routing fib-lookup virtual-router default ip 172.17.241.100

   Output on PAN-FW-1 should be similar to below where the interface seen would be the tunnel interface.

--------------------------------------------------------------------------------
runtime route lookup
--------------------------------------------------------------------------------
virtual-router:   default
destination:      172.17.241.100
result:
  via 172.17.241.1 interface tunnel.1, source 192.168.1.10, metric 10
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
runtime route lookup
--------------------------------------------------------------------------------
virtual-router:   default
destination:      172.17.241.100
result:
  interface ethernet1/6, source 172.17.241.1
--------------------------------------------------------------------------------

7. Check which zones have been configured for inner and outer interface of the tunnel (to identify the inner and outer interface of the tunnel use the output of CLI in step 2) as well as the zone of ingress interface of traffic for PAN-FW-1 and the egressing interface of the traffic for PAN-FW-2. Use the command below to verify which security policy is hit for the interesting traffic to verify that your security policy rules are properly configured to allow this traffic.

   test security-policy-match from L3-Trust source 172.17.240.1 to L3-WAN destination 172.17.241.100 protocol 6 destination-port 443

   Example of the test security-policy-match command.
8. If NAT is supposed to be applied to the traffic make sure that the proper NAT rule is created on the firewalls under Policies > NAT.
9. Check if zone protection profile is applied to the zone of outer interface of the tunnel of both firewalls under Network > Zone and if that is the case, if the packet based attack protection with Strict IP Address is checked for that zone profile under Network > Network Profiles > Zone Protection. In that case, test disabling that check and committing that change to see if that fixes the problem.
10. If none of the above fixes your problem then refer to Resource List: IPSec Configuring and Troubleshooting or contact our technical support team.

Note1: Step 9 is applicable if you are running a PAN-OS version (9.1.12 and 9.1.13) affected by PAN-186937. This is issue is fixed in 9.1.13-h1 and 9.1.14.