Skip to main content
Salamihawk
New Member
July 9, 2013
Solved

Upgrading from FortiOS 4 to FortiOS 5, Service ANY/All Problems?

  • July 9, 2013
  • 10 replies
  • 32248 views
Hello, I recently upgraded a Fortigate 40C from FortiOS 4 (the latest release, build 665) to FortiOS 5 build 208. There was an existing configuration with very simple policies (any internal to any over WAN1 using any service with destination interface NAT). Before the upgrade everything worked just fine, however after the upgrade, no communication to the internet was possible because the Fortigate was blocking all traffic. I found the problem: Fortinet decided to rename the service " ANY" to " All" (which makes sense IMHO), but didn' t bother to upgrade my configuration to reflect this change, thereby essentially breaking my Firewall. My question is: Has anyone else noticed this behavior? Is there an official word on this from Fortinet? At work, my team and I manage a larger 3950B Firewall with over 130 Virtual Domains. If this is the normal behavior, upgrading our machine to FortiOS 5 would be a catastrophe, as we would have to go through every single VDOM manually and change service " ANY" to service " All" .
    Best answer by Jan_Scholten

    Had the problem just yesterday.

    All Policys using Service "Any" were ignored. Therefore traffic "Denied by forward policy check (policy 0)"

     

    turns out the definition of "Any/All" is missing a line after upgrade

     

    config firewall service custom
        edit "ALL"
            set category "General"
            set protocol IP
        next

     

    but must be

    config firewall service custom
        edit "ALL"
            set category "General"
            set protocol IP
            set protocol-number 0
        next

     

    once you edit the service and gibe it back the

    "        set protocol-number 0"

     

    It works again. 

     

    Gave me a mild heartattack with a upgrade in a remote location and a small maintenance window.

     

    10 replies

    ede_pfau
    SuperUser
    SuperUser
    July 9, 2013
    You could a) define a custom service " ANY" or b) backup the config, search&replace in an editor and restore. The latter method requires a reboot.
    Rick_H
    New Member
    July 9, 2013
    I recently did a similar upgrade on an 80C from 4.3.14 (build 665) to 5.0.3 (build 208). The only conversion problem I had was related to web-filter policies, but it was easily fixed. Ede' s advice is what I' d do (the latter unless I couldn' t afford the downtime).
    Salamihawk
    New Member
    July 9, 2013
    I know what can be done to rectify the situation. The config on the 3950B, though, is something to the tune of 35 megabytes, so it' s quite a bit of a challenge to modify. I really wanted to know if anyone else had run into similar issues and if it was documented on Fortinet' s side. If you say you did an upgrade on an 80C between the same revisions, then it' s probably something specific to the 40C image.
    Dave_Hall
    New Member
    July 9, 2013
    Whenever there is a new firmware release, I would save the config before and after performing the upgrade, then use a text comparison tool (my personally preference is to use WinMerge for this) to see what changes were made. I also use this approach when " converting" configs from one model to another or troubleshooting a customer' s fgt (vs a base or test unit config). Using the above approach we manage to avoid much of the problems noted on these forums.
    bbache99
    New Member
    July 9, 2013
    Did you follow the release notes correctly? If you update to version 5 GA first this change should be covered. I have upgraded many boxes from 4 to 5 and not experienced this problem.
    seadave
    New Member
    January 23, 2015

    I had the same problem.  I have two FG-100Ds.  Our production is running 4.3.18.  Upgrade guides indicate I should be able to go from 4.3.18-5.0.10-5.2.2.

     

    I did a factory reset on our backup FG-100D.  Then did a TFTP firmware load and boot device format to 4.3.18.  Worked fine.  Then I restored the production firmware from our 4.3.18 system and all of the settings came over.

     

    Next I upgraded to 5.0.10.  I watched via the console and noted that some things were changed using the "diag debug config-error-log read" to show what had change.  All changes were minor.

     

    Finally I upgraded to 5.2.2, again reviewing any errors to the config the first time it reboots.

     

    I spent the rest of the day attempting to test throughput using a temp config between port 15 and WAN 2, thus leaving my other policies intact.  I could not get it to work.  Finally I realized it was the ALL/ANY problem.  I was simply trying to verify services would pass.  I knew WAN2 was working as the Firewall registered with Fortinet and downloaded latest updates.

     

    I could ping from the CLI to 8.8.8.8 (Google) but I could not ping via a laptop connected to port 15.  Nor could I ping the IP assigned to WAN 2.  I finally realized if I changed the service to "Ping" instead of "All" it worked.  I also tried ALL_TCP and ALL_UDP.  That also did not allow Ping because it is ICMP.  So not sure how to create an "allow anything" service definition.  I have a few systems that I allow that for outbound because of dynamic ports.

     

    So I'm not sure what the default options should be.  Attached is screenshot of my "General" services.  Can someone else on 5.2.2 confirm this is what they have?

    Jan_Scholten
    New Member
    January 23, 2015

    Had the problem just yesterday.

    All Policys using Service "Any" were ignored. Therefore traffic "Denied by forward policy check (policy 0)"

     

    turns out the definition of "Any/All" is missing a line after upgrade

     

    config firewall service custom
        edit "ALL"
            set category "General"
            set protocol IP
        next

     

    but must be

    config firewall service custom
        edit "ALL"
            set category "General"
            set protocol IP
            set protocol-number 0
        next

     

    once you edit the service and gibe it back the

    "        set protocol-number 0"

     

    It works again. 

     

    Gave me a mild heartattack with a upgrade in a remote location and a small maintenance window.

     

    seadave
    New Member
    January 23, 2015

    Ah!  Now I understand.  On my system it changed ALL to Protocol IP, Protocol number 6.  Once I changed it in the GUI to Protocol number 0, it now display under Details as "ANY".

     

    Thanks SO much.  These are the kinds of little things about Fortinet firmware upgrades that drive me crazy but I still wouldn't use any other vendor.

     

    Doing a little more research, I see that IP Protocol 0 is listed as being "IPv6 Hop-by-Hop Option"

    http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

     

    Not sure what kind of a problem that causes if you are using IPv6.

    HASimac
    New Member
    January 27, 2015

    Hello,

     

    Few days ago, I upgraded 10 FGT 90D from 5.0.9 to 5.2.2.

    For two of them, protocol number was changed from 0 to 6 (so only TCP traffic was allowed)...

     

    Regards,

    HA

     

    emnoc
    New Member
    January 27, 2015

      Doing a little more research, I see that IP Protocol 0 is listed as being "IPv6 Hop-by-Hop Option" http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers   Not sure what kind of a problem that causes if you are using IPv6.

     

    Just a little background protocol#0 just means ipv4 for ipv4 . Query  any unix system /etc/protocols files and you will see the following or similar in your file ( I  believe windows stills has this also )

     

    http://www.isi.edu/in-not...ments/protocol-numbers # ip      0       IP              # internet protocol, pseudo protocol number

     

     

    Over the years the change in in the IANA protocols # assignments ( see the link above ) has caused a lot of confusion. But the numbers are misleading;

     

    It should be the interpret as the following;

     

    ProtocolIP = 0  IPv4 encapsulation, pseudo protocol number

    ProtocolHOPOPT = 0 IPv6 Hop-by-Hop Option

     

     

    A now for more fun , if you use tcpdump and proto 0 you will find  ipv6 HBH packets, which has nothing to do with ipv4.

     

    03:48:59.665061 IP6 b5bc:4214:8004::1400:200:0:1a1b > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24 03:51:04.671297 IP6 c0d:e0f:1011:1213:1415:1617:1819:1a1b > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24 03:53:09.677661 IP6 4140:4d41:4ca1:1f02:43e:e9e0:8c02:100 > ff02::1: HBH ICMP6, multicast listener querymax resp delay: 1000 addr: ::, length 24

     

    Now are you  really confused