Just thought I'd post this here for others who have the same issue in future. According to Fortinet support there is a bug in firmware 5.2.2 that causes the "ALL" service group to be ignored, so any policy rules that use it will be ignored. It is fixed in 5.2.3, and in the meantime use "ALL_UDP, ALL_TCP & ALL_ICMP" instead of "ALL".
We upgraded a 100D on Saturday from 5.0.2 to 5.2.2 (following the correct upgrade process) on Saturday and today noticed some traffic being blocked. The GUI logs just showed "deny" with a PolicyID of 0 (no such policy ID visible). From the CLI a debug showed "Denied by forward policy check (policy 0)" for any traffic that used the ALL service group.
Solved! Go to Solution.
That problem is probably caused by wrong Protocol Number on "ALL" service object in "policy & objects" menu. If you got the same problem on version 5.2.2 (all packets are dropped by policy 0) check if that Protocol Number isn't set to 6. If it is, change that number to 0 and everything will start working fine.
Kind Regards
piterros1
Rarely would I use an ALL service object on an allow rule, but I'll keep an eye out for it!
Thanks for sharing.
......
-Jake
That problem is probably caused by wrong Protocol Number on "ALL" service object in "policy & objects" menu. If you got the same problem on version 5.2.2 (all packets are dropped by policy 0) check if that Protocol Number isn't set to 6. If it is, change that number to 0 and everything will start working fine.
Kind Regards
piterros1
I know this is a very old thread, but I got caught with this issue again last week and just wanted provide some more info for future travelers, maybe save an hour or two :).
The firewall in-question here has subsequently been upgraded through various versions and now sits on 5.6.12, I assumed the issue here was long since worked out of the Fortigate firmware so had not thought about it since (I didn't see piterros1's post at the time). However it seems that future versions of the Fortigate firmware do not actually fix your 'ALL' Service Object, so you can be on the latest firmware version and still see this issue if your device was originally built using that faulty version (or maybe passed through it at some point?), the issue just carries forward in the upgrade because it's a config problem, not a firmware bug. It would be great if Fortigate could run a check for the issue when doing firmware updates. To iJake's point above, the ALL Service object is so rarely used that it's only edge case scenarios when it catches you out, or when you're for example setting up a new site-to-site VPN and just want to test traffic is flowing before you start locking down.
In this case we were setting up a VPN and just used the wizard, which created ANY/ANY/ALL rules by default. The VPN connected no problem, but traffic would not flow. Analysis of the flow at the CLI was showing -
"Denied by forward policy check (policy 0)"
ie. the traffic was not matching to a firewall policy rule and was hitting the Default Deny rule (ID:0).
However running the connection parameters through the CLI policy test suggested that the traffic should actually hit policy 60!
diagnose firewall iprope lookup 192.168.1.54 5178 10.123.2.2 443 6 MyVPN
Result:
<src [192.168.1.54-5178] dst [10.123.2.2-443] proto 6 dev VPNToQHouse> matches policy id: 60
In the end I removed the ALL service and added ALL(UDP) and ALL(TCP) and traffic began flowing immediately.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.