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?

[Satory]

Changing it fixed the tunnel list:

# diagnose vpn ike gateway list name O-BLA-DIS-PRIM

vd: root/0
name: O-BLA-DIS-PRIM
version: 2
interface: MAN_A1 50
addr: 192.168.3.3:500 -> 192.168.2.147:500
tun_id: 10.0.0.7/::10.0.0.7
remote_location: 0.0.0.0
network-id: 0
virtual-interface-addr: 10.0.66.16 -> 10.0.66.17
created: 72s ago
peer-id: 192.168.2.147
peer-id-auth: no
PPK: no
IKE SA: created 1/2  established 1/2  time 40/40/40 ms
IPsec SA: created 1/2  established 1/2  time 0/20/40 ms

  id/spi: 1737727 3a88af8db8e17aee/96af44d0b91286b5
  direction: initiator
  status: established 72-72s ago = 40ms
  proposal: aes256-sha512
  child: no
  SK_ei: 042ae9cd5dd246c3-5bdc008ff5212a50-0b9b73d5f2deb9ff-3de3ab28ca4153e8
  SK_er: db7b49224f01248b-5b5afac75eda4b23-fc07e67a1769706a-3a4655dda207bac3
  SK_ai: f654fa57b3b0f1fb-b3af20bb101dac09-311202eb1a49e30b-a0d38662f3c3b155-a35f2873363492e7-6abefe1f89824667-cbb3779d980a1693-f45a2734ad8b5a0e
  SK_ar: 13101d40b1232522-3bb0f1463bcb1f34-2ad5a25a247fc74e-46bb975d2853aff8-96ade2286492f255-2cabee48beab9580-89a3c1d8e75e5a51-e4b157f42913f141
  PPK: no
  message-id sent/recv: 2/0
  lifetime/rekey: 86400/86027
  DPD sent/recv: 00000000/00000000
  peer-id: 192.168.2.147

Unfortunately this did not fixed the issue:

024-02-23 15:33:26.332425 MAN_A1 in 10.0.66.17 -> 10.0.66.16: icmp: echo request
2024-02-23 15:33:27.342967 MAN_A1 in 10.0.66.17 -> 10.0.66.16: icmp: echo request
2024-02-23 15:33:28.353048 MAN_A1 in 10.0.66.17 -> 10.0.66.16: icmp: echo request
2024-02-23 15:33:29.363068 MAN_A1 in 10.0.66.17 -> 10.0.66.16: icmp: echo request
2024-02-23 15:33:30.373120 MAN_A1 in 10.0.66.17 -> 10.0.66.16: icmp: echo request

[hbac]

@Satory,

Have you tried pinging from a host behind the firewall instead? You can also run packet sniffer on the other side of the tunnel. 

Regards, 

[Satory]

Not possible, as I need to run the iBGP first!

[neilson1]

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.

[saneeshpv_FTNT]

@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

[Satory]

# get router info routing-table details 10.0.66.17

Routing table for VRF=0
Routing entry for 10.0.66.17/32
Known via "static", distance 5, metric 0, best
* via O-BLA-DIS-PRIM tunnel 10.0.0.7, tun_id

[Satory]

Also it is not possible to ping from IP behind the firewall, because the reason I need those IP addresses see each other is to run iBGP on the tunnel, like we did with the other devices we use.

[hbac]

@Satory,

You can create static routes for testing purposes. Also, please open a ticket with Fortinet TAC to further investigate the issue. 

Regards, 

[Satory]

I do not understand - what kind of static routes do you mean and why?
We have proper routing on both sides:

- on external interfaces we are able to establish the VPN;

- on tunnel - there is a routing for the tunnel interfaces on both sides!

[saneeshpv_FTNT]

@Satory 

From the details you have shared in the Forum, it almost looks like you have a proper configuration as we indeed see the traffic exiting the remote firewall through the tunnel interface, but unfortunately on the other side the traffic is not see as leaving as the decrypted bytes are still 0 even though you have proper route in place. 

My suggestion to you is to involve Fortinet Support for detailed troubleshooting of this issue with a remote session.

Best Regards,