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'.
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 sni...
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.
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 will cause downtime, therefore use this command as the very last resort!
-
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.
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.
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 KB article at the end of this page: 'Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing'.
Related articles:
