Skip to main content
Zenith
Zenith
New Member
February 9, 2015
Solved

5.2.2 bug causes ALL service group to be ignored

  • February 9, 2015
  • 2 replies
  • 10827 views

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.

    Best answer by piterros1

    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

    2 replies

    iJake
    iJake
    New Member
    February 9, 2015

    Rarely would I use an ALL service object on an allow rule, but I'll keep an eye out for it!

    Thanks for sharing.

    piterros1
    piterros1Answer
    New Member
    February 11, 2015

    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
    ZenithAuthor
    New Member
    March 18, 2020

    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.

    Terms & ConditionsAccessibility statement