Odd " reverse path check fail, drop" , no ICMP replies from interface

[mbrowndcm]

Hello, I am having a strange issue that when I ping the interface of the firewall, I do not receive an echo reply (" PING" to the interface is enabled). Tracing the flow, I see the following message: " reverse path check fail, drop" Performing some research, I saw this KB: http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30543 This is not the case at all: My host is 192.168.20.20, the firewall interface is 192.168.20.1. I do have restrictive firewall policies in place, specifically to deny anything across the firewall incoming on the port, but not to the port. Why would this be occurring? Thanks, Matt [edit] Found the issue :D # get router info routing-table all C 192.168.20.1/32 is directly connected, internal2 Apparently, something isn' t configured correctly... [edit 2] The netmask of the interface was configured as /32, it should have been /24. # get router info routing-table all C 192.168.20.0/24 is directly connected, internal2 [edit 3] Now I' m getting " iprope_in_check() check failed, drop" http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD31702 PING enabled on interface: Yes Ingress host match: Yes Traversing firewall interfaces: No hmmm.....

[ede_pfau]

Hi, either " restriced hosts" is set and does not match your source IP (netmask?), or mgmt is enabled on one interface, you get in via a different interface and there is no policy allowing this. The " /32" host route is a very nice example for the reverse path check failure: there was no route for .20.20 as this address was not included. Works as expected. But I' ve stumbled upon this one many times before.

[mbrowndcm]

Sure enough... In order to PING an interface, the host needs to be allowed in System> Admin> Administrators> a logon username> add host here Why have (part of) the ACL for ICMP on the interface there? Who knows! Thanks, Matt

[ede_pfau]

it' s not a bug...it' s a feature! You' ll find this in many places of the FortiOS: they try to separate options that control different scopes. In your case, the interface options control the overall accessibility, namely the allowed services - regardless of user or user priviledge. In the user options you (may) specify additional restrictions based on the source IP or source subnet of this user. So, service on one hand and (kind of) user-based ACL on the other. Both couldn' t be thrown together on one page without mixing global and user scope. Glad it works for you now.