Hi all,
got configured IPSec tunnel it is up (phase 1 and 2) but no Outgoing Data.
Policy from Zone (with vlan10 in it) to VPN tunnel configured, Static Route (with subnet I try to reach, and VPN interface configured) also.
When Ping from computer with vlan10 I see deny and hit policy 0 in FAZ.
What is the best practice to check why traffic is not hitting this tunnel or policy?
P.S I have access only to my side of tunnel.
P.S II. Is is possible that when my part of the tunnel is configured ok, policy and route also but on the other side of the tunnel something is missing tunnel will show up on 2 phases but will send no data to the tunnel?
What's bother me is that there is O B in Outgoing data.
FGT OS. 6.4.6
Solved! Go to Solution.
Toshi_Esumi thanks for all your efort. Analyzing debug flow, starting to check why it is droping on policy and find this post:
I had created a virtual IP that would meet a new connectivity and it was the cause of my problems, even if not linked to any policy
If it's hitting policy 0 (deny all) then the problem is on the FGT side not the other side.
Do you have a route in the FortiGate for the subnet you're trying to reach to go out through the VPN interface?
Yes Sir, got Static Route with VPN interface na subnet I want to reach.
Make some debug flow and notice that address with subnet I try to ping got route via root, I think it should be VPN tunnel name there, what's can causing this problem?
id=20085 trace_id=1 func=vf_ip_route_input_common line=2621 msg="find a route: flag=80000000 gw-10.55.10.51 via root"
What was in the next line after "find a route:" in the flow debug? Was it the "Denied by forward policy check (policy 0)"?
Toshi
And, I have some doubt about the status of the tunnel. Can you share the output of "get vpn ipsec tun name <phase1_name>" after modifying/masking some sensitive info?
Tunnel configuration seems ok:
get vpn ipsec tunnel name TUNNEL
gateway
name: 'TUNNEL'
type: route-based
local-gateway: xxx.xxx.xxx.xxx:0 (static)
remote-gateway: yyy.yyy.yyy.yyy:0 (static)
mode: ike-v1
interface: 'port1' (9)
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: 'Phase1'
auto-negotiate: disable
mode: tunnel
src: 0:192.168.5.1/255.255.255.255:0
dst: 0:10.56.yy.yy/255.255.255.0:0
SA
lifetime/rekey: 3600/707
mtu: 1438
tx-esp-seq: 1
replay: enabled
qat: 0
inbound
spi: 1ba9b6db
enc: aes-cb 5b5b4532927d24a15f84141f42164d39
auth: sha1 fbb3244bde10c709405785bbf168487807761773
outbound
spi: bacd23d5
enc: aes-cb 8e4e8f52bccf097ba6ba014a8562217d
auth: sha1 3c13468121dc7c8183b6d24e127cd08dd358fe06
NPU acceleration: none
selectors
name: 'Phase2'
auto-negotiate: disable
mode: tunnel
src: 0:192.168.6.0/255.255.255.0:0
dst: 0:10.56.yy.yy/255.255.255.0:0
SA
lifetime/rekey: 3600/710
mtu: 1438
tx-esp-seq: 1
replay: enabled
qat: 0
inbound
spi: 1ba9b6dc
enc: aes-cb 8caac5f1b3f185ee9229b4c1cf07ae06
auth: sha1 7a187db64dea41fc443e50bfc78236930b7ab26f
outbound
spi: 774ea32b
enc: aes-cb 04e5f2aad62f00a468760ce21b1d210f
auth: sha1 0b91283b340826c9102154abc2363fa6782468f0
NPU acceleration: none
So, 10.56.y.0/24 is the destination subnet on the other end of the tunnel. Then why does the flow debug show 10.56.yy.yy as its GW? Does the same subnet exist on the local side?
Toshi_Esumi thanks for all your efort. Analyzing debug flow, starting to check why it is droping on policy and find this post:
I had created a virtual IP that would meet a new connectivity and it was the cause of my problems, even if not linked to any policy
I think you already found where it was configured (in VIPs?). But easiest way to find this kind of issue is to just do "show | grep -f "10.56.y"" at the top command line hierarchy.
Rest look's like this:
id=20085 trace_id=1 func=print_pkt_detail line=5742 msg="vd-root:0 received a packet(proto=1, 10.0.xx.xx:1->10.56.yy.yy:2048) from VLAN2. type=8, code=0, id=1, seq=8656."
id=20085 trace_id=1 func=init_ip_session_common line=5913 msg="allocate a new session-5cba7027"
id=20085 trace_id=1 func=vf_ip_route_input_common line=2621 msg="find a route: flag=80000000 gw-10.56.yy.yy via root"
id=20085 trace_id=1 func=fw_local_in_handler line=435 msg="iprope_in_check() check failed on policy 0, drop"
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 2023 Fortinet, Inc. All Rights Reserved.