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

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.

The following firewall policy shows the default configuration for the service object 'ALL':

Example below: 'ALL' default service is modified with the service.

To correct all services to default, use the following 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):
.....

The iprope information will also list the service configured. In certain scenarios, information that has been missed in the GUI can be further verified via CLI output. In the GUI, the firewall policy of policy ID 41 was configured with the 'ALL' service.

policy index=41 uuid_idx=882 action=accept
flag (8010001): log master pol_stats
flag2 (6200): no_asic log_fail resolve_sso
flag3 (a0): link-local best-route
schedule(always)
cos_fwd=255 cos_rev=255
group=00100004 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=0
zone(1): 32 -> zone(1): 41
source(1): 0.0.0.0-255.255.255.255, uuid_idx=550,
dest(1): 0.0.0.0-255.255.255.255, uuid_idx=550,
service(1):
[6:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

In the above example, the first column refers to the protocol number. 6 refers to the TCP protocol. Refer to the Protocol number for the full list of protocol numbers. The third column (0,65535)->(0,65535)refers to the source and destination port range. 

Based on the output of iprope information, the expected behavior is that traffic coming in from port20 to lan interface will only be permitted by firewall policy 41 if the protocol transmitted is TCP. Any other protocol will be processed by another firewall policy or denied.

The following iprope information shows the output of the default value of "ALL" service object for the same policy:

policy index=41 uuid_idx=882 action=accept
flag (8010001): log master pol_stats
flag2 (6200): no_asic log_fail resolve_sso
flag3 (a0): link-local best-route
schedule(always)
cos_fwd=255 cos_rev=255
group=00100004 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=0
zone(1): 32 -> zone(1): 41
source(1): 0.0.0.0-255.255.255.255, uuid_idx=550,
dest(1): 0.0.0.0-255.255.255.255, uuid_idx=550,
service(1):
[0:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

The value 0 refers to all protocols. Hence, firewall policy 41 will process traffic for all protocols.

Related articles: 

Technical Tip: Firewall policy lookups

Technical Tip: iprope policies group