Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Zenith
New Contributor

5.2.2 bug causes ALL service group to be ignored

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.

1 Solution
piterros1
New Contributor II

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

View solution in original post

3 REPLIES 3
iJake
Contributor

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

...... -Jake
piterros1
New Contributor II

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

Zenith

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.

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors