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

BUG in Mature Firmware? - msg="iprope_in_check() check failed on policy 0, drop"

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? :)

rkr
rkr
1 Solution
romank
New Contributor III

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? :)

IPPoolError.png

rkr

View solution in original post

rkr
7 REPLIES 7
Toshi_Esumi
SuperUser
SuperUser

romank
New Contributor III

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 ;)

rkr
rkr
Toshi_Esumi

so no VIP exist under "show firewall vip"?

romank
New Contributor III

Exactly. I did tick manually "NAT" and then entered specific IP. So its not a VIP where you put into "Destination" field ;)

rkr
rkr
Toshi_Esumi

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

romank
New Contributor III

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? :)

IPPoolError.png

rkr
rkr
Toshi_Esumi

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

Labels
Top Kudoed Authors