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

msg="iprope_in_check() check failed on policy 0, drop"

Dear,

 

I have a FortiGate 300C recently started blocking access to work normally. My route points to the VPN an the tunnel is up. The policy is ok.

Strangely this connection stopped working and when I try to connect it does not match the policy.

 

The log I'm having is this:

id=20085 trace_id=4875 func=print_pkt_detail line=4469 msg="vd-root received a packet(proto=6, 10.10.10.10:63117->11.11.11.11:9160) from my_interface. flag , seq 2788299880, ack 0, win 8192"
id=20085 trace_id=4875 func=init_ip_session_common line=4620 msg="allocate a new session-7bd3977e"
id=20085 trace_id=4875 func=fw_local_in_handler line=385 msg="iprope_in_check() check failed on policy 0, drop"

 

Any idea?

15 REPLIES 15
emnoc
Esteemed Contributor III

Most like uRPF checks. Are you sure the ingress interface is correct for that route and traffic-flow?

 

Ken

 

PCNSE 

NSE 

StrongSwan  

andre_amaro
New Contributor II

emnoc wrote:

Most like uRPF checks. Are you sure the ingress interface is correct for that route and traffic-flow?

 

Ken

 

Yes, I'm sure. This problem started before I had made no intervention in this flow.

andre_amaro

Well, I managed to get on the solution to this problem. 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. That's because there was already an object using the same IP that I created. I'm not sure, but it seems I made the firewall did not understand what I wanted to do (would use the VIP or object).

 

Anyway ... just after deleting this VIP connectivities that used VPN normalized.

ede_pfau
Esteemed Contributor III

Background: when you create a VIP, the FGT will proxy arp for that address - even if it's not (yet) used in a policy. It's not just a NAT rule.

If there is no policy traffic will be denied. That's what you saw.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
andre_amaro

ede_pfau wrote:

Background: when you create a VIP, the FGT will proxy arp for that address - even if it's not (yet) used in a policy. It's not just a NAT rule.

If there is no policy traffic will be denied. That's what you saw.

 

Thank you for the explanation!

fortijake

You can control whether or not Fortigate sends out arp replies for the original IP in the VIP with this in case you need the VIP. but not the arp replies.

fortigate documentation below.

 

# config firewall vip
    edit <name>
        set arp-reply disable (default: enable)
    next
end

 

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-ARP-reply-setting-in-Virtual-IP-IP-Pool/ta...

baguma
New Contributor

Hi 

i have the same error .  Using an external  public VIP which isnt part of the fortigate interface IP

 

find a routeind a route: flag=80000000 gw-196.x.x.x via root" id=20085 trace_id=819 func=fw_local_in_handler line=394 msg="iprope_in_check() check failed on policy 0, drop" id=20085 trace_id=819 func=fw_local_in_handler line=394 msg="iprope_in_check() check failed on policy 0, drop"

jhouvenaghel_FTNT

"iprope_in_check() check failed on policy 0" means that the destination IP address is seen as local/belonging to the FGT and FOS will look through the iprope_in tables.

An ippool adress belongs to the FGT if arp-reply is enabled

If you use vip, you should look if the mapped iP address is not configured somewhere in a ippool for example

baguma

Thanks for the reply . Just for clarity  below is my design

 

client to VIP 197.x.x.147(ISP allocated IP)  port 3319  mapped to 192.168.X.13 (webserver) 3319

Interface to internet where the client is coming 196.23.X.249/30 

Interface to the webserver farm 192.168.x.1/24 

by overlap , do you mean webserver subnet?