Policy 0

" policy 0" is the implicit DENY policy at the very bottom of the policy chain. Packets arriving here have not been matched by any (custom) policy. If you expect some traffic to match and leave through some other policy then you' ve got to debug the mismatch.

Thanks Ede, I' ve put in a support ticket as it is happening across several policies that should be matching. It' s quite random, so I' m not quite sure how to debug it.

Can you give an example?

Here' s an example that should have matched a rule from 10.44.x.x to All 0.0.0.0 for HTTP. I' ve removed some of the irrelevant info: Status deny Src 10.44.2.251 Dst 65.55.227.140 Sent 0 B Received 0 B Rule 0 Service HTTP Policy ID 0 Level warning VDom root Serial Number 0 Duration 157451 Subtype other Type traffic Protocol 6 Log ID 7 Src Name 10.44.2.251 Dst Name 65.55.227.140 Src Interface port5 Dst Interface N/A Src Port 63265 Dst Port 80 Shaper Dropped Sent Bytes 0 Shaper Dropped Received Bytes 0 Per-IP Shaper Bytes Dropped 0 Destination Country United States Message no session matched

Here' s a snippet from a flow trace. This should have matched the same rule as above but for HTTPS: id=36871 trace_id=494 msg=" vd-root received a packet(proto=6, 10.44.2.7:55932->193.149.73.30:443) from port5." id=36871 trace_id=494 msg=" find a route: gw-(our gateway IP) via port1" id=36871 trace_id=494 msg=" no session matched" removed our gateway IP.

Here' s an example that should have matched a rule from 10.44.x.x to All 0.0.0.0 for HTTP. I' ve removed some of the irrelevant info: Status deny Src 10.44.2.251 Dst 65.55.227.140

Will I see a specific host for the dst (65.55.227.140 ), 0.0.0.0 is any and 65.55.227.140 is a specific match. What' s the ordering of the fwpolicies? I would double check your fwpolicies and ordering and re-sequence.

Here' s the relevant bits. The " Network - VM" = 10.44.0.0/16 set srcintf " port5" set dstintf " port1" set srcaddr " Network - VM" set dstaddr " All" set action accept set fsso enable set identity-based enable set nat enable set ippool enable set poolname " VM" config identity-based-policy edit 1 set schedule " always" set utm-status enable set groups " VM - All Users Fortigate" set service " ANY" set av-profile " Schools AntiVirus" set webfilter-profile " Schools Web Filter" set spamfilter-profile " Schools Email Filter" set application-list " Schools App Control" set profile-protocol-options " Schools"

set identity-based enable

What will the firewall do with traffic if the user didn' t authenticate first - forward it?

If they don' t authenticate, they go get denied by that policy. If I filter on our Analyzer for policy 0, it' s all traffic from our inside zones going to the outside that are hitting the policy 0. Some are policies with FSSO and some are not. Some are different subnets (192.168.x.x, 172.16.x.x, etc.) and having the same issue. It' s not consistent either, in that one machine will have some traffic go through to the web just fine, but the odd packet not match and get denied. I have had no complaints from users, so it' s not an outright block, but something isn' t right, that' s for sure!

Hello, You' re probably facing out-of-sync traffic generated by some host. I had this problem few weeks ago with a Palo Alto FW (MGMT interface) generating some traffic without the normal " 3 handshake" . Some sessions were dropped, other pass the firewall without any problem. In Checkpoint world, the reaseon of the drop is much clear : out-of-sync traffic flag. Regards, HA