FortiGate IPSec - wrong interface detected for incoming traffic

@Satory 

Could you please share your configuration related to IPSec, Firewall policy and routing at each end. Also if you have any capture showing it received on VLAN instead of the tunnel interface, please share here.

Yoy may also look into the below link mentioning "T to use dynamic routing with the tunnel or be able to ping the tunnel interface, specify an address for the remote end of the tunnel in remote-ip and an address for this end of the tunnel in IP. This is only available if the type is tunnel."

https://community.fortinet.com/t5/FortiGate/Technical-Note-Dynamic-routing-BGP-over-IPsec-tunnel/ta-p/193955

Best Regards,

The issue you're describing with the FortiGate IPSec tunnel is quite specific and could have several potential causes. Here are some steps you can take to troubleshoot and fix the problem:

1. Verify Interface Configuration:

• Double-check the interface configuration on both FG500E and FG40F. Ensure that the tunnel interface is correctly defined with the assigned IP addresses (10.0.66.16/32 and 10.0.66.17/32) and associated with the appropriate physical interface where the IPSec traffic arrives.
• Verify that the firewall policies on both devices allow traffic through the tunnel interface for the desired protocols (e.g., ICMP for pings, TCP/UDP for other communication).

2. Check Routing Configuration:

• Make sure the routing tables on both devices correctly route traffic destined for the tunnel IP addresses through the IPSec tunnel interface.
• Verify that static routes or dynamic routing protocols (e.g., OSPF, BGP) are configured correctly to send traffic through the tunnel.

3. Inspect Traffic Logs:

• Enable logging on both devices for the IPSec tunnel interface and analyze the logs when attempting to ping or send other traffic through the tunnel. This can help identify dropped packets and the reason for their discard.
• Pay attention to any error messages or warnings related to interface mismatch or routing issues.

4. Consider FortiGate Support:

• If the above steps don't resolve the issue, it's recommended to contact FortiGate support for further assistance. They can provide deeper insights into the specific configuration and potential bugs related to your FortiGate devices and software version.

By following these steps and potentially involving FortiGate support, you should be able to identify the root cause of the "wrong interface detected" issue and get your IPSec tunnel functioning correctly.

@Satory

Please provide your route information as well.

# get router info routing-table deatils 10.0.66.17

Also try to ping a host behind each firewall instead of pinging the tunnel IP and share the outputs.

Based on the tunnel details you have shared earlier, we could clearly see traffic being received and decrypted and no traffic are returned because encrypted count is 0.

dec:pkts/bytes=16/1056, enc:pkts/bytes=0/0

Best Regards

Hi Satory;

I am trying to diagnose a similar issue with a device of my own, and am wondering if you have Central NAT enabled, and if 10.0.66.17 is the external IP address of a DNAT object?

(I assume that the two 10.0.66.16 and 10.0.66.17 IPs do not naturally overlap with the subnet of the VLAN that appears to have been chosen?)

If you are doing Central NAT + Destination NAT, check what the Interface value (extintf in the CLI) for the DNAT object which refers to (has extip) 10.0.66.17.  I have found that that value dictates the value that is then checked as the Source Interface in the IPv4 Policy.

The issue I am trying to diagnose is when there are more than one DNAT object with the same extip value but different extintf values (e.g. using a src-filter or srcintf-filter to differentiate).  I find that, while it picks the right DNAT value according to the filter, it always picks the value of extintf that was defined in the last value in the DNAT table which shares the same extip.  If I disable that last item, it picks the second-to-last, etc.

I have only been able to work around this in my config, by only setting extintf to be "any", not to any one specific interface.

I don't want to hijack your issue so, if you aren't using Central NAT / DNAT, then feel free to disregard.  However, if you are using a DNAT, try double-checking your value for extintf.

The problem and the solution was that the Tunnel was created initially as an dial-up one.

After changing it to standard IPSec - something has broken up inside it.

Recreating tunnel from scrap fixed the issue.