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.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
@saneeshpv_FTNT @internet_contributer @jera @hbac @dbhavsar
I want to express my gratitude to everyone. I truly appreciate all your help. I understand that I've had many requests, but when it comes to work, it's important to get things done .the issue is not in the static route or in the policies , the issue was the fortigate it self , the version that i was working with it v7.2.0-build so when i change the version it work dirctly .
@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.
There's no drop observed on FW-A. How about FW-B? Did you collect debugs on FW-B?
Regards,
Created on 02-28-2024 06:15 AM Edited on 02-28-2024 06:18 AM
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
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,
Created on 02-28-2024 06:13 AM Edited on 02-28-2024 06:22 AM
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
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)
Created on 02-28-2024 11:19 PM Edited on 02-28-2024 11:20 PM
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
@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...
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,
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1087 | |
752 | |
446 | |
227 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.