Troubleshooting Tip: One-way traffic via the IPsec tunnel

[darisandy]

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: Basic information to be verified is the routing table and phase2 selectors of the IPSec tunnel. Packet capture on FGT-A. If no egress traffic coming out of the tunnel interface, then run the debug flow: Example: dia de flow filter addr 10.171.0.10 10.122.0.10 and <----- This will capture traffic from and to these 2 addresses. dia de flow filter proto 1 <----- ICMP protocol. dia de flow sh fun ena dia de flow sh ip ena dia de flow trace start 100 dia de ena To disable: dia deb disable dia deb reset The debug output will show how FortiGate processes the traffic. Possible reasons: No firewall policy to allow traffic initiated from subnet 10.171.0.0/20 Source NAT enabled in the firewall policy If using an Outgoing interface If the tunnel interface does not have 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 allowed within the phase2 selectors If the tunnel interface has an IP address assigned, then make sure this IP is routable and allowed within the FGT-B network 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 tunnel interface, continue Step 3 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 packet capture on the destination device as well. Similar to the details in Step 2, in some scenarios, the remote side have a route back to the Firewall IP and can route back the traffic, but the initator'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 some issue with the ISP network. There are some cases wherein the ISP did not process the ESP/IPSec traffic properly. Related articles: Technical Tip: Source IP for self-originating IPsec tunnel traffic Debugging the packet flow