Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
pieciaq
New Contributor III

IPSec tunnel up (phase 1 and 2) but no Outgoing Data

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

Piotr$
Piotr$
1 Solution
pieciaq
New Contributor III

Toshi_Esumi thanks for all your efort. Analyzing debug flow, starting to check why it is droping on policy and find this post: 

https://community.fortinet.com/t5/Fortinet-Forum/msg-quot-iprope-in-check-check-failed-on-policy-0-d...

 

 

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

Piotr$

View solution in original post

Piotr$
12 REPLIES 12
amouawad
Staff
Staff

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?

pieciaq
New Contributor III

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"

Piotr$
Piotr$
Toshi_Esumi
Esteemed Contributor III

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

Toshi_Esumi
Esteemed Contributor III

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?

pieciaq
New Contributor III

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

Piotr$
Piotr$
Toshi_Esumi
Esteemed Contributor III

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?

pieciaq
New Contributor III

Toshi_Esumi thanks for all your efort. Analyzing debug flow, starting to check why it is droping on policy and find this post: 

https://community.fortinet.com/t5/Fortinet-Forum/msg-quot-iprope-in-check-check-failed-on-policy-0-d...

 

 

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

Piotr$
Piotr$
Toshi_Esumi
Esteemed Contributor III

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.

pieciaq
New Contributor III

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"

Piotr$
Piotr$
Labels
Top Kudoed Authors