Hello,
I havent seen such weird behavior on FGT before. I have S2S VPN with another location where there is some Local network - all is working good with s2s, but the problem is with local asset. After sometime one of IP is unreachable.
Debug commands says:
.."
id=20085 trace_id=161 func=init_ip_session_common line=6043 msg="allocate a new session-00bf3a66, tun_id=0.0.0.0"
id=20085 trace_id=161 func=vf_ip_route_input_common line=2611 msg="find a route: flag=80000000 gw-10.0.201.2 via root"
.."
id=20085 trace_id=161 func=fw_local_in_handler line=500 msg="iprope_in_check() check failed on policy 0, drop"
I do have enabled "snat-route-change enable" - for SDWan
I dont know why there is some problem with routing, where all is done as I used to do it regarding IPsec. Ive notice it after upgrade to 7.0.13(Mature)
Ive got a temporary workaround, I must flush iprobe routing with "diagnose firewall iprope flush".
Can someone point out what the hack? :)
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
I have found the issue. It turnes out that "ARP Reply" was enabled in IPPools. but I dont quite understand why this couses such weird problem, do you know maybe what it could be? How can I understand this? :)
Does this explanation match your case?
https://community.fortinet.com/t5/Support-Forum/msg-quot-iprope-in-check-check-failed-on-policy-0-dr...
Toshi
Sure i did check it but its not my case. My scenerio is pretty simple, s2s to destination, routing table to /24 net and 2 policies. One from vlan and second from sslvpn to that ipsec but using NAT address to acceaa destination device - cuz second side allows only one IP ;)
so no VIP exist under "show firewall vip"?
Created on 01-25-2024 02:22 PM Edited on 01-25-2024 02:49 PM
Exactly. I did tick manually "NAT" and then entered specific IP. So its not a VIP where you put into "Destination" field ;)
Created on 01-25-2024 02:58 PM Edited on 01-25-2024 03:09 PM
Do you happen to have that replacing IP configured somewhere else in the FGT? "show | grep -f <that_IP>".
https://gilfalko.wordpress.com/2015/02/15/how-to-fix-iprope_in_check-c-heck-failed-on-policy-0-drop/
Toshi
I have found the issue. It turnes out that "ARP Reply" was enabled in IPPools. but I dont quite understand why this couses such weird problem, do you know maybe what it could be? How can I understand this? :)
Created on 01-26-2024 07:56 AM Edited on 01-26-2024 09:14 AM
In the first link I posted to the old thread, @ede_pfau explains the mechanism.
And some more below:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Iprope-Check-Failure-observed-due-to-Geo-L...
For your specific situation, you probably need to oepn a ticket at TAC to get the exact reason why the FGT sees that's a problem.
Or, probably those two IPs in two ippools, which is not referred by any policies, exist in the other part of config like interface IP or GW IP of static routes.
Toshi
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1669 | |
1082 | |
752 | |
446 | |
226 |
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 2024 Fortinet, Inc. All Rights Reserved.