Troubleshooting Tip: One-way traffic via the IPsec tunnel

Description

This article describes how to troubleshoot one-way traffic over the IPSec tunnel between 2 FortiGates.

Scope

FortiGate.

Solution

Topology:

The machine on subnet 10.122.0.0/20 can reach (ping) devices on subnet 10.171.0.0/20, but not the other way around.

It is necessary to check:

1. Basic information to be verified is the routing table and phase 2 selectors of the IPSec tunnel.

get router info routing-table all

get router info routing-table database

diagnose vpn ike gateway list name <tunnel name>
diagnose vpn tunnel list name <tunnel name> 

2. Packet capture on FGT-A:

• If no egress traffic is coming out of the tunnel interface, then run the debug flow:

Example:

diagnose debug flow filter addr 10.171.0.10 10.122.0.10 and <----- This will capture traffic from and to these 2 addresses.
diagnose debug flow filter proto 1 <----- ICMP protocol.
diagnose debug flow show function-name enable
diagnose debug flow show iprope enable
diagnose debug flow trace start 100
diagnose debug enable

To disable:

diagnose debug disable

diagnose debug reset

The debug output will show how FortiGate processes the traffic.

Possible reasons:

1. No firewall policy to allow traffic initiated from subnet 10.171.0.0/20

2. Source NAT is enabled in the firewall policy

   1. If using an outgoing interface

      1. If the tunnel interface does not have an IP address assigned, then FortiGate will use the IP address of the smallest index interface. This IP address may not be routable in the environment, nor was it allowed within the phase2 selectors

      2. If the tunnel interface has an IP address assigned, then make sure this IP is routable and allowed within the FGT-B network

   2. If using IP Pool, make sure that the IP address is routable and allowed in the phase2 selectors

• If traffic is already allowed and forwarded out of the tunnel interface, continue Step 3.
  
  

Packet capture on FGT-B:

• If there is incoming traffic, but no egress, then do the same debug flow. Tweak the filter to capture the traffic.

• If the incoming traffic has already been forwarded out but no reply, check any neighbor device if the packet from FortiGate has already been received or not. Try to do a packet capture on the destination device as well.

• Similar to the details in Step 2, in some scenarios, the remote side has a route back to the Firewall IP and can route back the traffic, but the initiator's subnet is not known to the remote end, and masking this subnet is preferred. SNAT can be enabled on the policy for this traffic, which is also useful in scenarios where no changes can be made on the remote end.

• In some very rare cases, if there is no incoming traffic, there might be an issue with the ISP network. There are some cases where the ISP did not process the ESP/IPSec traffic properly. To verify this, use the following steps:
  

Disable NPU offloading in phase 1 of the IPsec tunnels and capture IKE and ESP traffic on both devices.

config vpn ipsec phase1-interface
    edit <tunnel name>
        set npu-offload disable
    next
end

Note: The above NPU setting may not be required on the FortiGate VM devices.

Flush the tunnel:

diagnose vpn ike gateway flush name <tunnel name>
diagnose vpn tunnel flush <tunnel name>

Capture IPsec traffic:

diagnose sniffer packet any 'host <Remote gateway IP of the tunnel endpoint>' 6 0 l

To get the capture in the Wireshark format, run it from the FortiGate GUI: Network -> Diagnostics.

If no NAT traversal is detected (no UPD encapsulated packets) and only one-way ESP traffic is visible, then check the NAT-T setting in phase 1 and try enabling NAT-T and flushing the tunnel. If this doesn't solve the problem, then use Forced NAT-T. This will allow FortiGate to use UDP 4500 encapsulation for data packets even if NAT-T is not detected.

The NAT-T detection varies from tunnel to tunnel, even if the tunnels terminate on the same device. Each tunnel may use a different path, and intermediate devices sometimes block ESP (protocol 50) packets. By enabling/forcing NAT-T, the ESP packets are encapsulated in UDP packets. It is recommended to use the same NAT-T setting on both tunnel endpoints. In case packets are already UDP 4500 encapsulated, and one tunnel endpoint doesn't receive these packets, it is recommended to consult the ISP for any blocks.

Related documents:

Technical Tip: Source IP for self-originating IPsec tunnel traffic
Debugging the packet flow