ipsec vpn blackhole issue: i can't ping the other subnet throw the ipsec tunel

[khalilbouzaiene1]

I have two LAN networks: the first one is 192.168.1.0/24, and the second one is 10.0.0.0/24. Each LAN is directly connected to a FortiGate firewall. I have set up a site-to-site VPN using two FortiGate virtual machines running version 7.2.0. The VPN configuration was done using the wizard.

However, when I try to ping a host in the other subnet (for example, from 192.168.1.1 to 10.0.0.2), I don't receive any response. The ping requests seem to be unsuccessful.

I researched this issue and discovered that it might be related to the black hole route created by the VPN wizard template. If anyone has experienced this problem before, I would appreciate any suggestions or solutions for resolving it. If anyone has knowledge of how to fix this, please provide guidance.

[khalilbouzaiene1]

@dbhavsar  @saneeshpv_FTNT  @hbac @jera 

If there is an issue with the rules or routing or policies issue, the ping between 192.168.1.1 and 10.0.0.1 will not succeed. Furthermore, based on the debug logs, when the packet reaches FW-A, it is processed and allowed on the FW-A to FW-B interface, which serves as the VPN interface.

this is my explanation of the debug  :

msg="find a route: flag=04000000 gw-30.0.0.1 via FW-A to FW-B": This message indicates that the firewall found a route for the packet. Let's break it down further:
find a route: This part signifies that the firewall successfully determined a route for the packet based on its destination IP address.
flag=04000000: Flags provide additional information about the route. Here, 04000000 might indicate specific characteristics of the route, such as whether it's a direct route or if any special handling is required.
gw-30.0.0.1: This indicates the gateway IP address through which the packet will be forwarded. In this case, the gateway is 30.0.0.1.
via FW-A to FW-B: This part specifies the path the packet will take to reach its

and also this point here is good to know 
msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000" provides information about the DNAT result, such as the action taken (accept), and the flags set. 

[hbac]

@khalilbouzaiene1,

There's no drop observed on FW-A. How about FW-B? Did you collect debugs on FW-B?

Regards, 

[khalilbouzaiene1]

hello @hbac 
yes yes i try to collect logs from FW-B but there is no thing arrived 

in the first fgt FW-A we have arrived packet but in the second fgt DW-B no thing happen 

[saneeshpv_FTNT]

Hi @khalilbouzaiene1 ,

The session finds a route because there is a route available, but the gateway for that route is incorrect as it is pointing to your Physical interface next-hop. You can remove the Gateway IP from that route and test it and I think it should work. You don't need to define a gateway IP for this route and just keep the tunnel interface.

Please test this and let me know the results.

Best Regards,

[khalilbouzaiene1]

hi @saneeshpv_FTNT 

no i don't any gateway i just put on the interface my von interface and when i click on create i found that that ip 
it's automatic

[jera]

Hi @khalilbouzaiene1 ,

It seems your firewall policies are wrong. 

The interface involved should be the following based on your diagram.

FW-A to FW-B <> Port 2 

Port 2  <> FW-A to FW-B

You created policy going to port 3 instead of port 2 (LAN networks)

[khalilbouzaiene1]

hello @jera 

no no the policies are correct  just i have changed the lab a litle bite and this the new diagram

 which is related to  the rules and the routes that i have posted in snapshots 

based on this topology the rules should be from port3 to vpn interface and from vpn interface to port 3

[khalilbouzaiene1]

@jera @hbac @saneeshpv_FTNT @dbhavsar @netmin_02 

do we need to add an  ipnat pool in this situation because i saw this post and it seems like my situation .
https://community.fortinet.com/t5/Support-Forum/VPN-to-Checkpoint-with-encryption-domain-outside-loc...

[saneeshpv_FTNT]

Hi @khalilbouzaiene1 

NAT is not required until you have a specific requirement like overlap subnet at each side or hide your private IP from remote end etc.

Why don't you share your configuration from both devices if this is a only a labsetup so we could review and update.

Your earlier screen was showing the Gateway IP and if you have not defined it why would we see it there. I am attaching your screen shot and my lab device screenshot for comparison as I don't see it in there. So please share the configuration for a closure look from both device.  

Regards,

[khalilbouzaiene1]

hello @saneeshpv_FTNT 
so like what i said before in this configuration juste i have configured the tunnel with wizad and i found in the static route like that 
so the configuration of the FW-A :

FW-A # get vpn ipsec tunnel details

gateway
name: 'FW-A to FW-B'
local-gateway: 20.0.0.1:0 (static)
remote-gateway: 30.0.0.1:0 (static)
dpd-link: on
mode: ike-v1
interface: 'port2' (4)
rx packets: 0 bytes: 0 errors: 0
tx packets: 0 bytes: 0 errors: 0
dpd: on-demand/negotiated idle: 20000ms retry: 3 count: 0
selectors
name: 'FW-A to FW-B'
auto-negotiate: disable
mode: tunnel
src: 0:192.168.1.0/255.255.255.0:0
dst: 0:10.0.0.0/255.255.255.0:0
SA
lifetime/rekey: 43200/42269
mtu: 1446
tx-esp-seq: 1
replay: enabled
qat: 0
inbound
spi: 44e88424
enc: des be32d2dfd832d945
auth: md5 33510f2026b772abd5148477fd042da1
outbound
spi: a2a75b1d
enc: des 8484b8713cd0eac7
auth: md5 56a2da594c0c1237b45a52d6d8cb0282
NPU acceleration: none

and the confifuration of the tunnel in the FW-B :

FW-B # get vpn ipsec tunnel details

gateway
name: 'FW-B to FW-A'
local-gateway: 30.0.0.1:0 (static)
remote-gateway: 20.0.0.1:0 (static)
dpd-link: on
mode: ike-v1
interface: 'port2' (4)
rx packets: 0 bytes: 0 errors: 0
tx packets: 0 bytes: 0 errors: 0
dpd: on-demand/negotiated idle: 20000ms retry: 3 count: 0
selectors
name: 'FW-B to FW-A'
auto-negotiate: disable
mode: tunnel
src: 0:10.0.0.0/255.255.255.0:0
dst: 0:192.168.1.0/255.255.255.0:0
SA
lifetime/rekey: 43200/42352
mtu: 1446
tx-esp-seq: 1
replay: enabled
qat: 0
inbound
spi: a2a75b1d
enc: des 8484b8713cd0eac7
auth: md5 56a2da594c0c1237b45a52d6d8cb0282
outbound
spi: 44e88424
enc: des be32d2dfd832d945
auth: md5 33510f2026b772abd5148477fd042da1
NPU acceleration: none