FortiGate IPSec - wrong interface detected for incoming traffic

[Satory]

We have an IPSec tunnel between two FortiGate devices - FG500E and FG40F, both running version 7.0.14.

The IPSec is established without any problems, but the traffic inside the tunnel has some very strange issue. The tunnel IP addresses are 10.0.66.16/32 and 10.0.66.17/32.

The FG500E device sends the packets inside the tunnel, but when it receives the response, for example ping requests, it sees the traffic as received from the VLAN interface on which is built the tunnel, thus discarding the traffic. As a result the two tunnel interface ends cannot ping each other and the communication is not possible, as we use iBGP for routing.

Has anyone experienced some similar issue and how to fix this?

[candc]

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.

[Satory]

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.