Policy 0

[cheaman]

I' m seeing a fair amount of " Policy 0" with " No Session Matched" in our logs. Some of them are legit blocks, but a lot of them should match a policy and be allowed. What would cause this sort of deny?

[cheaman]

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!

[HA]

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

[cheaman]

HA, How would I figure out if this is the case?

[emnoc]

Why don' t you make a more specific policy and for one single /32 hosts, move it ahead of the others and monitor that policy for match with diag debug flow. That' s what I would do to ensure your catching that policy and only one policy. if a user doesn' t authenticate, I would suspect that he/she would match on policy0 if I had to guess. I might lab that up and see what happens ( kinda of curious now ). Also did you check your ordering of fwpolicies as suggested earlier?

[cheaman]

I will try a new/clean policy above the existing one and see what happens. The order looks fine to me. Would order not give a consistent pass or deny as well? Here' s the last few seconds from our analyzer filtering on policy 0 and HTTP. all of the 10.x.x.x are different policies. All of these should be passing this traffic. The 172.25.x.x policies do not have FSSO or any UTM on them. 2013-09-17 12:40:10 deny 172.25.0.61 54.249.29.224 0 B 0 B 0 HTTP 0 N/A 2 2013-09-17 12:40:10 deny 10.19.3.5 157.56.200.61 0 B 0 B 0 HTTP 0 N/A 3 2013-09-17 12:40:10 deny 10.19.3.5 157.56.200.61 0 B 0 B 0 HTTP 0 N/A 4 2013-09-17 12:40:10 deny 10.19.3.5 65.55.227.140 0 B 0 B 0 HTTP 0 N/A 5 2013-09-17 12:40:09 deny 10.44.5.90 173.194.43.122 0 B 0 B 0 HTTP 0 N/A 6 2013-09-17 12:40:09 deny 10.37.1.127 192.254.232.239 0 B 0 B 0 HTTP 0 N/A 7 2013-09-17 12:40:09 deny 10.37.1.127 206.190.37.99 0 B 0 B 0 HTTP 0 N/A 8 2013-09-17 12:40:09 deny 10.37.1.127 74.125.226.155 0 B 0 B 0 HTTP 0 N/A 9 2013-09-17 12:40:09 deny 10.37.1.127 98.138.81.83 0 B 0 B 0 HTTP 0 N/A 10 2013-09-17 12:40:09 deny 172.25.0.61 54.249.29.224 0 B 0 B 0 HTTP 0 N/A 11 2013-09-17 12:40:09 deny 172.25.0.61 23.63.226.75 0 B 0 B 0 HTTP 0 N/A 12 2013-09-17 12:40:09 deny 10.30.1.97 216.123.55.101 0 B 0 B 0 HTTP 0 N/A 13 2013-09-17 12:40:09 deny 10.30.1.97 216.123.55.35 0 B 0 B 0 HTTP 0 N/A 14 2013-09-17 12:40:09 deny 10.30.1.97 216.123.55.49 0 B 0 B 0 HTTP 0 N/A 15 2013-09-17 12:40:09 deny 10.30.1.97 216.123.55.57 0 B 0 B 0 HTTP 0 N/A 16 2013-09-17 12:40:09 deny 10.44.3.155 74.217.75.7 0 B 0 B 0 HTTP 0 N/A 17 2013-09-17 12:40:09 deny 172.25.0.62 74.217.75.8 0 B 0 B 0 HTTP 0 N/A 18 2013-09-17 12:40:08 deny 172.25.0.61 96.16.45.15 0 B 0 B 0 HTTP 0 N/A 19 2013-09-17 12:40:08 deny 10.23.2.21 216.73.79.249 0 B 0 B 0 HTTP 0 N/A 20 2013-09-17 12:40:08 deny 10.23.2.21 216.73.79.249 0 B 0 B 0 HTTP 0 N/A 21 2013-09-17 12:40:08 deny 10.23.2.21 216.73.79.248 0 B 0 B 0 HTTP 0 N/A 22 2013-09-17 12:40:08 deny 10.23.2.21 23.194.159.139 0 B 0 B 0 HTTP 0 N/A 23 2013-09-17 12:40:08 deny 10.23.2.21 67.202.66.171 0 B 0 B 0 HTTP 0 N/A 24 2013-09-17 12:40:08 deny 10.23.2.21 108.170.196.75 0 B 0 B 0 HTTP 0 N/A 25 2013-09-17 12:40:08 deny 10.23.2.21 23.194.161.224 0 B 0 B 0 HTTP 0 N/A 26 2013-09-17 12:40:08 deny 10.19.3.5 157.56.200.34 0 B 0 B 0 HTTP 0 N/A 27 2013-09-17 12:40:08 deny 10.19.3.5 157.56.200.34 0 B 0 B 0 HTTP 0 N/A 28 2013-09-17 12:40:08 deny 10.19.3.5 65.55.227.140 0 B 0 B 0 HTTP 0 N/A 29 2013-09-17 12:40:08 deny 10.19.3.5 65.55.227.140 0 B 0 B 0 HTTP 0 N/A 30 2013-09-17 12:40:08 deny 172.25.0.61 123.126.68.164 0 B 0 B 0 HTTP 0 N/A 31 2013-09-17 12:40:07 deny 172.25.0.61 183.136.223.249 0 B 0 B 0 HTTP 0 N/A 32 2013-09-17 12:40:07 deny 172.25.0.61 23.63.226.58 0 B 0 B 0 HTTP 0 N/A 33 2013-09-17 12:40:04 deny 10.37.1.33 50.116.194.23 0 B 0 B 0 HTTP 0 N/A 34 2013-09-17 12:40:04 deny 10.37.1.33 205.210.186.236 0 B 0 B 0 HTTP 0 N/A 35 2013-09-17 12:40:04 deny 10.37.1.33 162.217.96.200 0 B 0 B 0 HTTP 0 N/A 36 2013-09-17 12:40:04 deny 10.37.1.33 204.2.197.201 0 B 0 B 0 HTTP 0 N/A 37 2013-09-17 12:40:04 deny 10.37.1.33 199.233.57.41 0 B 0 B 0 HTTP 0 N/A 38 2013-09-17 12:40:04 deny 10.37.1.33 138.108.6.20 0 B 0 B 0 HTTP 0 N/A 39 2013-09-17 12:40:04 deny 10.37.1.33 74.217.78.146 0 B 0 B 0 HTTP 0 N/A 40 2013-09-17 12:40:04 deny 10.37.1.33 216.123.55.112 0 B 0 B 0 HTTP 0 N/A 41 2013-09-17 12:40:04 deny 10.37.1.33 184.73.157.129 0 B 0 B 0 HTTP 0 N/A 42 2013-09-17 12:40:04 deny 10.37.1.33 72.21.91.121 0 B 0 B 0 HTTP 0 N/A 43 2013-09-17 12:40:04 deny 10.37.1.33 199.27.73.134 0 B 0 B 0 HTTP 0 N/A 44 2013-09-17 12:40:04 deny 10.37.1.33 54.213.72.135 0 B 0 B 0 HTTP 0 N/A 45 2013-09-17 12:40:04 deny 10.37.1.33 54.243.168.135 0 B 0 B 0 HTTP 0

[HA]

Hello, You can use a sniffer to see if the traffic has the correct TCP flags, sequence number,etc But it' s very time consuming !! You can also try to change the way your firewall deal with Out of sequence traffic, etc see: http://docs.forticare.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/protection_chapter.035.07.html http://docs.forticare.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/protection_chapter.035.09.html Be sure you understand what you are doing because it can create security hole in your FW... Regards, HA

[emnoc]

fwiw: I highly doubt it' s out of tcp-outof-sequence packets and from that many of sources. He need to fix the real problem, and not add another potential issues to the mix.

[Maik]

No Session Matched

a blocking policy would return a message " Denied by Forward Policy check" The Policies are ok, but the fortigate cannot match the packet to a session. This is seen for example, when an ACK arrives from a different path as the previous SYN. Personaly I also think it' s rather a Layer 2 problem as " HA" indicates. another thing, in early 4.3 versions I saw something similiar which was resolved in a later patch. What FortiOS are you running?

[Maik]

another thing, in early 4.3 versions I saw something similiar which was resolved in a later patch. What FortiOS are you running?

something likes this: Does it only happen on HTTP Sessions? Description: HTTP proxy may terminate http session prematurely when the session has a slow connection. Bug ID: 140917 Status: Fixed in v4.0 MR3 - Patch Release 1. Duplicate sessions (same IP address and ports) causes dropped packets if created less than timewait-timer sec after the first one is closed. Bug ID: 160319 Status: Fixed in v4.0 MR3 - Patch Release 6.

[HA]

Hello, I was running MR3P12 when I faced " No Session Matched" in the log. The problem was on my PA FW generating Out-of-state packet (confirmed by Checkpoint Logs Viewer). I don' t think the problem is coming from Fortigate Release because checkpoint reacts in the same way !! Is it possible that you have asymmetric traffic flow in your topology ?? Regards, HA