IPSEC Tunnel

[IT_STAFF]

Hi

At my client I have made IPSEC tunnels between devices, Connections are Established on 2 phases, you can see the traffic that works, from the FG device I can  PING, Tracert, works properly however from the workstation itself unfortunately does not work,

I test Tracert from workstation:
goes to FG and disappears (only 1 hop to GW fortigate).
There are policies and routing set up.

I'll add that I'm using a non-RFC address in local network 192.100.100.0/24 (could this be the problem?) in Traffic Monitor I can see that traffic is going into Tunnel

[AEK]

Hi

Can you check on the remote FG (diag sniffer, diag debug flow) what is it doing with the received packets.

Using public address in local is not recommended but this should not be the root cause of your issue.

[IT_STAFF]

Hi,
I will prepare and come back with a logs. 

[IT_STAFF]

hi, sorry for late. I make some troubleshoot:

Spoiler

FortiGate-1 # diagnose sniffer packet any "host 10.255.8.65" 4
interfaces=[any]
filters=[host 10.255.8.65]
6.086150 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
10.610817 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
15.611112 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
93.406903 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
94.410984 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
96.421100 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
100.425681 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
108.434763 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
133.834983 internal in 192.100.100.152.137 -> 10.255.8.65.137: udp 50
135.346875 internal in 192.100.100.152.137 -> 10.255.8.65.137: udp 50
136.859221 internal in 192.100.100.152.137 -> 10.255.8.65.137: udp 50
138.395823 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
142.096628 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
146.100585 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
150.105406 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
154.108174 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
158.097140 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
162.112659 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
166.100899 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
170.097620 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
174.112649 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
178.099685 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
182.103755 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request

Spoiler

FortiGate-1 # 2025-03-03 12:42:19 id=65308 trace_id=11 func=print_pkt_detail line=5811 msg="vd-root:0 received a packet(proto=1, 192.100.100.152:1->10.255.8.65:2048) t
un_id=0.0.0.0 from internal. type=8, code=0, id=1, seq=4043."
2025-03-03 12:42:19 id=65308 trace_id=11 func=init_ip_session_common line=5995 msg="allocate a new session-003652ab"
2025-03-03 12:42:19 id=65308 trace_id=11 func=vf_ip_route_input_common line=2611 msg="find a route: flag=80000000 gw-10.255.8.65 via root"
2025-03-03 12:42:19 id=65308 trace_id=11 func=fw_local_in_handler line=606 msg="iprope_in_check() check failed on policy 0, drop"

From PC show policy ID 0 

Ping from Fortigate is ok.

Spoiler

PING 10.255.8.65 (10.255.8.65): 56 data bytes
64 bytes from 10.255.8.65: icmp_seq=0 ttl=255 time=0.1 ms
64 bytes from 10.255.8.65: icmp_seq=1 ttl=255 time=0.0 ms
64 bytes from 10.255.8.65: icmp_seq=2 ttl=255 time=0.0 ms
64 bytes from 10.255.8.65: icmp_seq=3 ttl=255 time=0.0 ms
64 bytes from 10.255.8.65: icmp_seq=4 ttl=255 time=0.0 ms

[sw2090]

most times i run into this (see traffic going into the ipsec but not seing it on the other end) it is due to bad or wrong pase2 quick selectors. So I would suggest checking on these.

[IT_STAFF]

hi, sorry for late. I make some troubleshoot:

I have create policies in both directions and static routes via tunnel ipsec.

FortiGate-1 # diagnose sniffer packet any "host 10.255.8.65" 4
interfaces=[any]
filters=[host 10.255.8.65]
6.086150 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
10.610817 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
15.611112 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
93.406903 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
94.410984 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
96.421100 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
100.425681 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
108.434763 internal in 192.100.100.152.58843 -> 10.255.8.65.443: syn 382569304
133.834983 internal in 192.100.100.152.137 -> 10.255.8.65.137: udp 50
135.346875 internal in 192.100.100.152.137 -> 10.255.8.65.137: udp 50
136.859221 internal in 192.100.100.152.137 -> 10.255.8.65.137: udp 50
138.395823 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
142.096628 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
146.100585 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
150.105406 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
154.108174 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
158.097140 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
162.112659 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
166.100899 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
170.097620 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
174.112649 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
178.099685 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request
182.103755 internal in 192.100.100.152 -> 10.255.8.65: icmp: echo request

FortiGate-1 # 2025-03-03 12:42:19 id=65308 trace_id=11 func=print_pkt_detail line=5811 msg="vd-root:0 received a packet(proto=1, 192.100.100.152:1->10.255.8.65:2048) t
un_id=0.0.0.0 from internal. type=8, code=0, id=1, seq=4043."
2025-03-03 12:42:19 id=65308 trace_id=11 func=init_ip_session_common line=5995 msg="allocate a new session-003652ab"
2025-03-03 12:42:19 id=65308 trace_id=11 func=vf_ip_route_input_common line=2611 msg="find a route: flag=80000000 gw-10.255.8.65 via root"
2025-03-03 12:42:19 id=65308 trace_id=11 func=fw_local_in_handler line=606 msg="iprope_in_check() check failed on policy 0, drop"

From PC show policy ID 0 

Ping from Fortigate is ok.

PING 10.255.8.65 (10.255.8.65): 56 data bytes
64 bytes from 10.255.8.65: icmp_seq=0 ttl=255 time=0.1 ms
64 bytes from 10.255.8.65: icmp_seq=1 ttl=255 time=0.0 ms
64 bytes from 10.255.8.65: icmp_seq=2 ttl=255 time=0.0 ms
64 bytes from 10.255.8.65: icmp_seq=3 ttl=255 time=0.0 ms
64 bytes from 10.255.8.65: icmp_seq=4 ttl=255 time=0.0 ms

[AEK]

Hi IT_STAF

The packet is being dropped by FortiGate-1 (check failed on policy 0, drop).

Most probably the firewall rule intended to allow this traffic is misconfigured. Other (less) possible reason is the phase 2 selector.

If you can share a screenshot of the firewall rule and phase 2 selector we may help.

[IT_STAFF]

Hi, thanks for help.

[AEK]

I see from FGT you can ping the destination in 0ms (64 bytes from 10.255.8.65: icmp_seq=4 ttl=255 time=0.0 ms). It's like if you have a local interface, a VIP or an IP pool having the same address as 10.255.8.65 (or on the same subnet) on your local FortiGate.

Can you double check?