Description
This article describes how to fix errors that occur when obtaining a debug flow for connectivity issues.
Scope
FortiGate.
Solution
When troubleshooting connectivity problems to or through a FortiGate with the 'diagnose debug flow' commands, the following messages may appear:
- 'iprope_in_check() check failed, drop'.
- 'Denied by forward policy check'.
- 'reverse path check fail, drop'.
- 'iprope_in_check() check failed on policy 0, drop'
See the following article for more details about troubleshooting with the 'diagnose debug flow' command:
Troubleshooting Tip: First steps to troubleshoot connectivity problems through a FortiGate with snif...
Possible root causes for 'iprope_in_check() check failed, drop'.
- When accessing the FortiGate for remote management (ping, telnet, ssh...), the service that is being accessed is not enabled on the interface.
For example: Pinging or telnet the DMZ interface FortiGate of a FortiGate, IP address 10.50.50.2, where ping and telnet are not enabled.
id=36870 pri=emergency trace_id=1 msg="vd-root received a packet(proto=1,10.50.50.1:4608->10.50.50.2:8) from dmz."
id=36870 pri=emergency trace_id=1 msg="allocate a new session-0000d5ad"
id=36870 pri=emergency trace_id=1 msg="iprope_in_check() check failed, drop"
id=36870 pri=emergency trace_id=8 msg="vd-root received a packet(proto=6, 10.50.50.1:1160->10.50.50.2:23) from dmz."
id=36870 pri=emergency trace_id=8 msg="allocate a new session-0000d96a"
id=36870 pri=emergency trace_id=8 msg="iprope_in_check() check failed, drop"
-
When accessing the FortiGate for remote management (ping, telnet, ssh...), the service that is being accessed is enabled on the interface but there are trusted hosts configured that do not match the source IP of the incoming packets.
Example: Pinging the DMZ interface of a FortiGate of IP address 10.50.50.2 from source IP 10.50.50.1 with trusted hosts configured as follows:
FGT # show system admin admin
config system admin
edit "admin"
set trusthost1 10.20.20.0 255.255.255.0
[...]id=36870 pri=emergency trace_id=26 msg="vd-root received a packet(proto=1, 10.50.50.1:5632->10.50.50.2:8) from dmz."
id=36870 pri=emergency trace_id=26 msg="allocate a new session-0000da15"
id=36870 pri=emergency trace_id=26 msg="iprope_in_check() check failed, drop" -
When accessing a FortiGate interface for remote management (ping, telnet, ssh...) through another interface of this same FortiGate, no firewall policy is present. Example: pinging wan2 at the IP address 10.70.70.1 through DMZ, but there is no firewall policy from DMZ to wan2.
-
Make sure that the remote management is through the customs port, the customs port should be added to the service, the firewall policy should have the service added.
id=36870 pri=emergency trace_id=756 msg="vd-root received a packet(proto=1, 10.50.50.1:11264->10.70.70.1:8) from dmz."
id=36870 pri=emergency trace_id=756 msg="allocate a new session-00000220"
id=36870 pri=emergency trace_id=756 msg="iprope_in_check() check failed, drop"
If, after validating everything is configured correctly, the 'iprope_in_check() check failed, drop,' error still appears; use the command below to force it to refresh.
diagnose firewall iprope flush
Disclaimer:
This command is meant to be hidden in the FortiOS CLI, not to be executed when troubleshooting forward traffic (traffic through the FortiGate), only for local traffic (traffic travel from/to the FortiGate). Executing this command will cause downtime, so only use it as the very last resort.
- The issue might also be due to the local-in policy which it is possible to verify using show full firewall local-in-policy.
- A VIP parameter must be set as detailed in the Configuration Example: Using VIP (Virtual IP) for Port Translation only.
-
An improper error can also be thrown if the default admin ports for SSH or HTTPS/HTTP are modified to custom ports and the admin is trying to access on a different port other than the configured custom port.
config system global
set admin-sport 443
set admin-port 80
set admin-ssh-port 22
end
The above values shown are the default. Cross-verify whether an attempt is being made to access the correct port.
- If it is using the interface IP address as the gateway in a policy route (by mistake), FortiGate will try to send it to the gateway IP (which belongs to the FortiGate root VDOM). This will trigger an 'iprope_in_check() check failed, drop' message. Also, If the gateway is set to 0.0.0.0, the FortiGate will look for a route via the same interface in the routing table. In other words, it gives preference to the Interface.
- Iprope Check Failure can be observed due to Geo-Location restrictions on SSL VPN settings. When trying SSL VPN from a country not included in the Geo restriction on SSL VPN setting FortiGate, the connection will not be successful. This is because the connection is being attempted from a different region than the one being allowed, and the debug flow will show the 'iprope_in_check() check failed on policy 0, drop' message.
See this article for more information. - Possible root cause for 'iprope_in_check() check failed on policy 0, drop'.
When trying to access the FortiGate for remote management through a dial-up IPsec and it fails due to the 'iprope_in_check() check failed on policy 0, drop' message appearing on the debug flow, it means that it cannot match a policy for this incoming traffic.
If the rest of the IPSec configuration (policies,selectors) looks fine, the issue might be in the user group authentication.
When configuring authentication for dial-up tunnel on FortiGate, there are two ways to match the users with the proper groups:
- Match the group on the phase 1 setting with the 'set authusrgrp'.
- Match the groups on the firewall policies for the IPsec tunnel created.
The 'iprope_in_check() check failed on policy 0, drop' message appears if the user group is configured both in the phase 1 settings and the corresponding policy.
Therefore, the authentication needs to take place only with one of these two ways.
* The key point of the second way is that the authentication of the users can be more flexible depending on different policies and therefore different ways of handling/inspecting them.
Root causes for 'Denied by forward policy check'.
- There is no firewall policy matching the traffic that needs to be routed or forwarded by the FortiGate (traffic will hit the Implicit Deny rule).
- The traffic matches a DENY firewall policy.
- The traffic matches an ALLOW firewall policy, but a DISCLAIMER is enabled. Consequently, traffic will not be accepted unless the end user accepts the HTTP disclaimer proposed by FortiGate while browsing an external site. This is usually encountered on IOT devices that are unable to select the disclaimer 'Yes, I agree' option, causing all access to be denied.
For example (messages are similar for both root causes):
id=36870 pri=emergency trace_id=19 msg="vd-root received a packet(proto=1, 10.50.50.1:7680->10.60.60.1:8) from dmz."
id=36870 pri=emergency trace_id=19 msg="allocate a new session-0000007d"
id=36870 pri=emergency trace_id=19 msg="Denied by forward policy check"
The root cause for 'reverse path check fail, drop'.
This is detailed in the related article at the end of this page: 'Technical Tip: Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing'.
Related articles:
FortiGate log information : traffic log with firewall policy of 0 (zero) "policyid=0"
Technical Tip: Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing
