Hi,
I prepared a test lab, and found a strange issue. The scenario is simple and as followed: FW-X <Tunnel> FW-Y root <vlink> FW-Y custom VDOM After implementing a basic configuration, if I execute a ping, sourced from FW-X Loopback interface, destined to the VLink IP on the FW-X custom VDOM IP-address, there will always only two pings be replied. IP address schema: FW-X Loopback 10.1.67.101/32 ping source
Tunnel FW-X <> FW-Y 10.1.64.128/30 FW-Y vlink root 10.1.64.1/30 FW-Y vlink vdom 10.1.64.2/30 ping destination If I exec the ping to the roots vlink side (.64.1), the ping works fine, but not to the custom VDOMs address (.64.2). Even if I ping to a Loopback destined on the destination VDOM, the ping is only replied two times. FW-X (source) FW-X # execute ping-options source 10.1.67.101 FW-X # execute ping 10.1.64.2 FW-X # diagnose sniffer packet any icmp 4 interfaces=[any] filters=[icmp] 2.721381 TU_FW-X_GL out 10.1.67.101 -> 10.1.64.2: icmp: echo request 2.721736 TU_FW-X_GL in 10.1.64.2 -> 10.1.67.101: icmp: echo reply 3.739325 TU_FW-X_GL out 10.1.67.101 -> 10.1.64.2: icmp: echo request 3.739621 TU_FW-X_GL in 10.1.64.2 -> 10.1.67.101: icmp: echo reply 4.749321 TU_FW-X_GL out 10.1.67.101 -> 10.1.64.2: icmp: echo request <- !!!! 5.759319 TU_FW-X_GL out 10.1.67.101 -> 10.1.64.2: icmp: echo request <- !!!! 6.769300 TU_FW-X_GL out 10.1.67.101 -> 10.1.64.2: icmp: echo request <- !!!! ^C FW-X # execute traceroute-options source 10.1.67.101 FW-X # execute traceroute 10.1.64.2 traceroute to 10.1.64.2 (10.1.64.2), 32 hops max, 3 probe packets per hop, 72 byte packets 1 10.1.64.129 0.333 ms 0.451 ms 0.135 ms <- Tunnel IP on FW-X root side 2 10.1.64.2 0.272 ms 0.343 ms * FW-Y root (intermediate hop) FW-Y (root) # diagnose sniffer packet TU_FW-Y_GL icmp 4 interfaces=[TU_FW-Y_GL] filters=[icmp] 4.895695 TU_FW-Y_GL -- 10.1.67.101 -> 10.1.64.2: icmp: echo request 4.895916 TU_FW-Y_GL -- 10.1.64.2 -> 10.1.67.101: icmp: echo reply 5.913637 TU_FW-Y_GL -- 10.1.67.101 -> 10.1.64.2: icmp: echo request 5.913803 TU_FW-Y_GL -- 10.1.64.2 -> 10.1.67.101: icmp: echo reply ^C FW-Y VDOM (destination) FW-Y (custom) # diag sniffer packet npu0_vlink1 icmp 4 interfaces=[npu0_vlink1] filters=[icmp] 10.895799 npu0_vlink1 -- 10.1.67.101 -> 10.1.64.2: icmp: echo request 10.895881 npu0_vlink1 -- 10.1.64.2 -> 10.1.67.101: icmp: echo reply 11.913708 npu0_vlink1 -- 10.1.67.101 -> 10.1.64.2: icmp: echo request 11.913755 npu0_vlink1 -- 10.1.64.2 -> 10.1.67.101: icmp: echo reply ^C The sniffer output shows the generated request packets on FW-X, but already on the next-hop FW-Y root, on the end of the tunnel, they do not appear.
Routing can not be an issue, otherwise no packet would be replied. The traceroute is ok. The only strange issue is, that the connected tunnel appears two times in the routing table. But that is the same outgoing interface, that is used for the working destination.
[size="2"]S 10.1.64.0/30 [10/0] via 10.1.64.129, TU_FW-X_GL <- route to ping destination[/size] [size="2"]C 10.1.64.128/30 is directly connected, TU_FW-X_GL[/size] [size="2"] is directly connected, TU_FW-X_GL[size="2"] [size="2"]<- duplicate entry !?[/size][/size][/size] [size="2"]S 10.1.67.1/32 [10/0] via 10.1.64.129, TU_FW-X_GL[/size] [size="2"]S 10.1.67.2/32 [10/0] via 10.1.64.129, TU_FW-X_GL[/size] C 10.1.67.101/32 is directly connected, LOOPBACK [size="2"]S 172.16.1.11/32 [10/0] via 172.16.2.1, wan1[/size] C 172.16.2.0/24 is directly connected, wan1
All policies are set to any/any all/all/ALL. Tunnel Phase 2 ist set to 0.0.0.0/0. Dial-up tunnel on FW-Y.
The same issue appears in the opposite direction, when ping is sourced from FW-Y custom vdom. All five request arrive on FW-X, five replies will be generated, but only two will appear on the tunnel end. Even other communication will not work, e.g. I cannot start an SSH session over that path.
Lab was completely new rebuild from factory setting, with the same results.
Hard/software: FWF60E, v5.6.5 build1600 (GA) Any Ideas? Many thanks in advance. best regards Hakan
User | Count |
---|---|
2568 | |
1362 | |
796 | |
650 | |
455 |
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 2025 Fortinet, Inc. All Rights Reserved.