Technical Tip: Traffic is hitting the implicit deny policy, even though the Firewall Policies are configured correctly to allow the traffic

[johnathan]

Description	This article describes how to resolve a scenario where traffic is incorrectly hitting the implicit deny when there is a policy configured to allow the traffic.
Scope	FortiGate.
Solution	The following policy should allow all traffic from the 100.64.0.202 IP to the internet. It is recommended to configure a debug. These are the commands to properly set the debug: diagnose debug flow filter addr <Host IP address> diagnose debug flow show iprope enable diagnose debug flow show function-name enable diagnose debug flow trace start <No. of packets to be analyzed> diagnose debug enable For more debug options, see this KB article: Troubleshooting Tip: First steps to troubleshoot connectivity problems. For this scenario, this was the debug configuration: diagnose debug flow filter addr 100.64.0.202 diagnose debug flow show iprope enable diagnose debug flow show function-name enable diagnose debug flow trace start 100 diagnose debug enable It is visible from a debug flow that the traffic is matching the implicit deny. The policy ID 0 is generally the 'Implicit Deny'. To confirm this, edit a policy, and on the top-right side, the ID information is found:   Or enable the 'ID' option in the columns, in Firewall Policy: It is important to check that the default objects used in that policy have not been modified. In this case, it is visible that the schedule object was modified, so the title does not match what is being applied to the policy. Make sure the service 'ALL' default value is not modified. Example: Example below: 'ALL' default service is modified with the service. To correct all services to default, use the below command : config firewall service custom     edit "ALL"         set category "General"         set protocol IP     next end From the GUI: Navigate to Policy & Objects -> Services -> Choose 'ALL' service, select 'edit ' and correct the Protocol Type to IP. Once this is corrected, it is possible to see in the debug flow that this traffic is now allowed. It is also possible to apply the filters in forward traffic logs to see if the traffic is hitting the policy as expected: Technical Tip: Forward traffic logs with filter Another option to validate the traffic if it hits the condition of a firewall policy is to use 'Policy Lookup'.  It can be identified easily using the iprope command. Example below when the Firewall Address 'all' was changed to 192.168.1.0/24. show firewall policy 2     config firewall policy         edit 2             set name "port2 Internet"            set srcintf "port2"             set dstintf "port1"             set action accept             set srcaddr "all"             set dstaddr "all"             set schedule "always"             set service "ALL"             set utm-status enable             set ssl-ssh-profile "certificate-inspection"             set nat enable         next      end diagnose firewall iprope list 100004 | grep "index=2" -A 15 policy index=2 uuid_idx=15749 action=accept ..... zone(1): 4 -> zone(1): 3 source(1): 192.168.1.0-192.168.1.255, uuid_idx=15732, dest(1): 192.168.1.0-192.168.1.255, uuid_idx=15732, service(1): [0:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto ..... Corrected the Firewall Address 'all' to 0.0.0.0/0. The iprope command output will be below. diagnose firewall iprope list 100004 | grep "index=2" -A 15 policy index=2 uuid_idx=15749 action=accept ..... zone(1): 4 -> zone(1): 3 source(1): 0.0.0.0-255.255.255.255, uuid_idx=15732, dest(1): 0.0.0.0-255.255.255.255, uuid_idx=15732, service(1): ..... Related articles:  Technical Tip: Firewall policy lookups Technical Tip: iprope policies group