| 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 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>
- 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:
- No firewall policy to allow traffic initiated from subnet 10.171.0.0/20
- Source NAT is 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
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 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 an issue with the ISP network. There are some cases where 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
|
