Visitor III

Solved

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

Forum|Forum|2 years ago
February 23, 2024
15 replies
16780 views

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.

Best answer by khalilbouzaiene1

@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 .

jera

Staff

Hi @khalilbouzaiene1 ,

Setup:

192.168.1.0/24 <> FW1 <IPSEC> FW2 <> (10.0.0.0/24)

Good day! The first thing you need to check is the availability of routes going to your remote LAN (10.0.0.0/24) from your FW1. This network should be learned from your IPSEC interface.

If you are learning the 10.0.0.0/24 from your wan/other interface, make sure to configure the route via IPSEC with a lower administrative distance.

config router static     edit <id>         set dst 10.0.0.0/24
        set distance <value>         set device "to_IPSEC"     next end

You should do the same route verification in FW2. The 192.168.1.0/24 must be learned from your IPSEC interface. You can double check your IPSEC configuration using this guide:

https://docs.fortinet.com/document/fortigate/7.2.7/administration-guide/913287/basic-site-to-site-vpn-with-pre-shared-key

IPSEC Troubleshooting Guide: https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Troubleshooting-IPsec-Site-to-Site-Tunnel/ta-p/195672

khalilbouzaiene1Author

Visitor III

in my case juste i have created the vpn tunel with the wizard template and no thnig else
this the topology of my network

and the static rules created by the wizard template are here
FW-A

and also in the other fortigate : FW-B

do i need to add that configuration so that the ping will be successfull ?!!!

Rajneesh

Staff

Hello @khalilbouzaiene1

You can run the sniffer on one of the FGT to check if he is sending the traffic out or not :

diagnose sniffer packet any 'host <source IP of user behind FGT> and icmp 4 0 l

Same you can tun on the other FGT to check if that device is also receiving packets or not.

khalilbouzaiene1Author

Visitor III

no thing yet guys no one of these preposition is the solution
and the packet they can't reatch the fortigate vpn interface when i try to sniffing the packet on my vpn interface

saneeshpv_FTNT

Staff

@khalilbouzaiene1

You can make this tunnel to a Custom tunnel and then remove the Gateway configuration from the Static routes at each side which is incorrect.

Once that is done you will be able to ping.

Best Regards

khalilbouzaiene1Author

Visitor III

hi
i have tryed also to do a custom tunel , it have been estableched and it bring up but also i can't ping the host in the other lan

when i ping from the lan interface which directly connectted to the fortigate to the other lan interface which also connected to the other foertigate , (192.168.1.1 --> 10.0.0.1 )it work but when i try to ping the host no thing (192.168.1.2 ---> 10.0.0.2 )

jera

Staff

Hello @khalilbouzaiene1 ,

It's a great progress. If you are able to ping from local LAN gateway to remote LAN gateway (vise versa) , it means the tunnel is now working.

If the ping source is your server and can't reach the remote LAN Server. You can do another sniffer trace using only the remote IP as host to check if you have a two way traffic.

If no logs generated on sniffer trace, it's possible that your server do not have the proper default gateway. If you see in/out traffic on sniffer it means that ICMP is blocked from your servers.

khalilbouzaiene1Author

Visitor III

hello jera hope you doing well
so after the sniffer test that i have done so fare , i notice that when i try to ping the other host in the other lan (10.0.0.2) from the host (192.168.1.2) and in the same time i write this cmd in the cli of the fw-a i have these logs : sniffer 1.png

and also when i wrote the same cmd in the cli if the fw-b i have these logs :
sniffer 2.png

so when i try to ping the other host from the 192.lan , the packet are resived on the port 3 interface and do not forwarded to the int of the tunel

khalilbouzaiene1Author

Visitor III

and also i have done other test
i try to ping the other host from the fortigate lan interface (192.168.1.1) , so for this i wrote these cmd in fw-a cli
execute ping-options source 192.168.1.1
execute ping 10.0.0.2
and also in the other fortigate b i write this commande to sniffer the packet recived
and i have these logs
sniffer 3.png
so in my case i thing that there is no gateway issue

netmin_02

New Member

Try disable windows firewall on Win4 and Win5

By default windows firewall accept only localnet remote ip from icmp traffic.

khalilbouzaiene1Author

Visitor III

hello friend
thank you for your support , but i have disabled win firewall from the begining .

saneeshpv_FTNT

Staff

@khalilbouzaiene1

For your Tunnel routes, you don't need to define a Gateway IP which you defined incorrectly as I see from one of the screenshots you shared earlier. The route just needs the tunnel interface name for it to forward the traffic to tunnel.

On Firewall A You need route to 10.0.0.0/24 via To-FW-B

config router static
edit 0
set dst 10.0.0.0/24
set device "To-FW-B"
next
end

On Firewall B You need route to 192.168.10/24 via To-FW-A

config router static
edit 0
set dst 192.168.10/24
set device "To-FW-A"
next
end

Having different session ID for ICMP traffic ECHO request is normal because ICMP session are short lived in the firewall and every new request FW creates a different session as you see sequence number & identifier is different for each of them.

Best Regards

khalilbouzaiene1Author

Visitor III

hello

thank you for you support but in the two snapshots of the static route in the two fortigate the remote subnet is the group of adresses created by wizard template when i have configured the tunnel :

FW-A to FW-B_remote : is the subnet 10.0.0.0/24
FW-B to -FW-A_remote : is the subnet 192.168.1.0/24
and i thing that the comfiguration that you have gave it to me is the same thing of these route juste in the place of this groupe of addresses we will find juste like this

dst : 10.0.0.0/24 gw :30.0.0.1 int : FW-A to FW-B

dbhavsar

Staff

Hello @khalilbouzaiene1 ,

Let's collect output of the following debugs:
di de reset
diagnose debug flow filter saddr xx.xx.xx.xx <---SourceIP
diagnose debug flow filter daddr yy.yy.yy.yy <---DestinationIP
di de flow filter proto 1
diagnose debug flow show function enable
diagnose debug flow show iprope enable
diagnose debug console timestamp enable
diagnose debug flow trace start 999
diagnose debug enable

- Also please show the policies that was created by the wizard and the tunnel interface config using following command:
show full system interface <tunnel-name>

- Once done remove the route created by the wizard or disable it and create a same route manually this won't add the gateway.

khalilbouzaiene1Author

Visitor III

hello @dbhavsar

thank you for your support

so the logs for this debug :

di de reset
diagnose debug flow filter saddr 192.168.1.2
diagnose debug flow filter daddr 10.0.0.2
di de flow filter proto 1
diagnose debug flow show function enable
diagnose debug flow show iprope enable
diagnose debug console timestamp enable
diagnose debug flow trace start 999
diagnose debug enable
are those :

FW-A # 2024-02-28 05:20:36 id=65308 trace_id=9 func=print_pkt_detail line=5895 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:1->10.0.0.2:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=64."
2024-02-28 05:20:36 id=65308 trace_id=9 func=init_ip_session_common line=6076 msg="allocate a new session-000004b6, tun_id=0.0.0.0"
2024-02-28 05:20:36 id=65308 trace_id=9 func=iprope_dnat_check line=5331 msg="in-[port3], out-[]"
2024-02-28 05:20:36 id=65308 trace_id=9 func=iprope_dnat_tree_check line=823 msg="len=0"
2024-02-28 05:20:36 id=65308 trace_id=9 func=iprope_dnat_check line=5343 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2024-02-28 05:20:36 id=65308 trace_id=9 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-30.0.0.1 via FW-A to FW-B"
2024-02-28 05:20:40 id=65308 trace_id=10 func=print_pkt_detail line=5895 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:1->10.0.0.2:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=65."
2024-02-28 05:20:40 id=65308 trace_id=10 func=init_ip_session_common line=6076 msg="allocate a new session-000004bc, tun_id=0.0.0.0"
2024-02-28 05:20:40 id=65308 trace_id=10 func=iprope_dnat_check line=5331 msg="in-[port3], out-[]"
2024-02-28 05:20:40 id=65308 trace_id=10 func=iprope_dnat_tree_check line=823 msg="len=0"
2024-02-28 05:20:41 id=65308 trace_id=10 func=iprope_dnat_check line=5343 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2024-02-28 05:20:41 id=65308 trace_id=10 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-30.0.0.1 via FW-A to FW-B"
2024-02-28 05:20:45 id=65308 trace_id=11 func=print_pkt_detail line=5895 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:1->10.0.0.2:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=66."
2024-02-28 05:20:45 id=65308 trace_id=11 func=init_ip_session_common line=6076 msg="allocate a new session-000004c6, tun_id=0.0.0.0"
2024-02-28 05:20:45 id=65308 trace_id=11 func=iprope_dnat_check line=5331 msg="in-[port3], out-[]"
2024-02-28 05:20:45 id=65308 trace_id=11 func=iprope_dnat_tree_check line=823 msg="len=0"
2024-02-28 05:20:45 id=65308 trace_id=11 func=iprope_dnat_check line=5343 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2024-02-28 05:20:46 id=65308 trace_id=11 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-30.0.0.1 via FW-A to FW-B"
2024-02-28 05:20:50 id=65308 trace_id=12 func=print_pkt_detail line=5895 msg="vd-root:0 received a packet(proto=1, 192.168.1.2:1->10.0.0.2:2048) tun_id=0.0.0.0 from port3. type=8, code=0, id=1, seq=67."
2024-02-28 05:20:50 id=65308 trace_id=12 func=init_ip_session_common line=6076 msg="allocate a new session-000004c9, tun_id=0.0.0.0"
2024-02-28 05:20:50 id=65308 trace_id=12 func=iprope_dnat_check line=5331 msg="in-[port3], out-[]"
2024-02-28 05:20:50 id=65308 trace_id=12 func=iprope_dnat_tree_check line=823 msg="len=0"
2024-02-28 05:20:50 id=65308 trace_id=12 func=iprope_dnat_check line=5343 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2024-02-28 05:20:51 id=65308 trace_id=12 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-30.0.0.1 via FW-A to FW-B"

and for the policies created by the wizard are

here FW-A to FW-B_remote is 10.0.0.0/24 and FW-A to FW-B_local is 192.168.1.0/24

and finaly for the interface configuration

FW-A # show full system interface 'FW-A to FW-B'
config system interface
edit "FW-A to FW-B"
set vdom "root"
set vrf 0
set distance 5
set priority 1
set dhcp-relay-interface-select-method auto
set dhcp-relay-service disable
set ip 0.0.0.0 0.0.0.0
unset allowaccess
set arpforward enable
set broadcast-forward disable
set bfd global
set icmp-send-redirect enable
set icmp-accept-redirect enable
set reachable-time 30000
set ips-sniffer-mode disable
set ident-accept disable
set ipmac disable
set status up
set netbios-forward disable
set wins-ip 0.0.0.0
set type tunnel
set netflow-sampler disable
set sflow-sampler disable
set src-check enable
set sample-rate 2000
set polling-interval 20
set sample-direction both
set explicit-web-proxy disable
set explicit-ftp-proxy disable
set proxy-captive-portal disable
set tcp-mss 0
set inbandwidth 0
set outbandwidth 0
set egress-shaping-profile ''
set ingress-shaping-profile ''
set spillover-threshold 0
set ingress-spillover-threshold 0
set weight 0
set external disable
set remote-ip 0.0.0.0 0.0.0.0
set description ''
set alias ''
set security-mode none
set ike-saml-server ''
set estimated-upstream-bandwidth 0
set estimated-downstream-bandwidth 0
set measured-upstream-bandwidth 0
set measured-downstream-bandwidth 0
set bandwidth-measure-time 0
set monitor-bandwidth disable
set role undefined
set snmp-index 9
set preserve-session-route disable
set auto-auth-extension-device disable
set ap-discover enable
set ip-managed-by-fortiipam disable
set switch-controller-igmp-snooping-proxy disable
set switch-controller-igmp-snooping-fast-leave disable
set eap-supplicant disable
config ipv6
set ip6-mode static
set nd-mode basic
set ip6-address ::/0
unset ip6-allowaccess
set icmp6-send-redirect enable
set ra-send-mtu enable
set ip6-reachable-time 0
set ip6-retrans-time 0
set ip6-hop-limit 0
set dhcp6-prefix-delegation disable
set dhcp6-information-request disable
set ip6-send-adv disable
set autoconf disable
set dhcp6-relay-service disable
end
set dhcp-relay-request-all-server disable
set dns-server-override enable
set dns-server-protocol cleartext
set mtu-override disable
set wccp disable
set interface "port2"
next
end

khalilbouzaiene1Author

Visitor III

@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.

saneeshpv_FTNT

Staff

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,

khalilbouzaiene1Author

Visitor III

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

Staff

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)

khalilbouzaiene1Author

Visitor III

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

khalilbouzaiene1Author

Visitor III

@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-local-network/td-p/50073

saneeshpv_FTNT

Staff

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,

Customer-VPN Route.png

LAB-VPN Route.png

khalilbouzaiene1Author

Visitor III

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

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO