IPSEC Tunnel

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.

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.

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

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.

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?