Supported Upgrade Paths – FortiOS

Supported Models

While it is not necessarily an upgrade issue, one very good reason for reading the Release Notes is to verify that your model of FortiGate is supported by the firmware. The reasons for a particular model not being supported can be:

  • The hardware was out of development when the firmware was released
  • The hardware was developed after the firmware was released
  • The hardware doesn’t have enough resources to run effectively using the firmware
  • Only some models were included in the development of the firmware.

There a some instances where a model may not be supported by only some builds of the firmware. But just because a model appears to go out of support does not mean that the situation will continue moving forward. It’s worth checking to make sure.

For example, the FortiGate/FortiWiFi 80C and 81CM were not supported by the  5.4.0 firmware. There is no version 5.4.0  firmware for these models. However, these models were brought back into the supported list for 5.4.1. This presents a slightly different problem than normal for the people using the upgrade path tables as some of those paths could refer to upgrading to 5.4.0 before upgrading to 5.4.1 or one of the later versions of 5.4.

The solution is relatively straightforward. Use the 5.2 table to upgrade to the latest version of 5.2. From there, it should be easy to then use the 5.4 table to upgrade to whatever is the latest version of 5.4, effectively skipping right over 5.4.0.

Potential upgrade issues

These are some issues, in no particular order, that have been brought to the attention of the Technical Assistance Center or the Documentation Team that could result during the course of a firmware upgrade.

Failure of secondary WAN IP for admin access

There is an issue with the 5.2.4 version of the firmware that affects a very specific configuration. In dual-wan setups, after upgrading to FortiOS 5.2.4, secondary WAN IP cannot be used for administrative HTTPS access or SSL-VPN. PING and VIP using the second WAN as external interface are working fine.

Packets are correctly sent to the second WAN IP address but the reply is sent through the other WAN interface.

Most instances will not be affected by this, but the upgrade path table has been modified to avoid 5.2.4 just to avoid any possible impact.

Loss of secondary IP address for everyone

Similar to the above issue with secondary IP addresses and admin access there is an even more significant example of losing the secondary IP address. At one point, a number of the upgrade paths to the 5.4 version of the firmware involved going to 5.4.0. This worked well enough, until the system was upgraded to 5.4.1 at which point any secondary IP addresses were lost. This problem did not exist when going directly from a 5.2.x version to 5.4.1 so the tables were changed to bypass 5.4.0. This cannot be done if you are already on 5.4.0, so if you do upgrade from 5.4.0 to a more recent version, remember to record any instances of a secondary IP address on any of the interfaces so that they can be added manually after the upgrade.

Changing of Category Numbers

When looking at the FortiGuard Webfilter categories or Application categories in the GUI we see the nice easily understood names that indicate what they refer to but in the code of the firmware these categories are referenced by a integer and not a text string. Periodically the list of categories changes, whether by the number growing larger or smaller it doesn’t matter. If the list changes then so do the values of objects in that list. If your policies are everything is wide open you are not likely to see an issue but if there are carefully crafted restrictions in place.

Web filter category removal and FortiManager

Sometimes an issue in the upgrade process will not effect the FortiGate itself but one of the other devices connecting to the FortiGate. This issue has the same flavor as the changing of Category numbers issue, but it differs in that it effects the FortiManager rather than the FortiGate itself.

Instead of changing the subject of a category, there is an instance where a category was completely removed from the list of categories. Firmware upgrades developed soon after the removal of the category sanitized the configuration file. Later firmware versions ignored the category if it was left in the configuration file. An upgrade from 4.3.18 to 5.0.12 may leave the category in place, but this does not effect the FortiGate. However, if FortiManager, running a current version of its firmware, tries to work with a configuration file with the removed category in it, an error message is triggered.

To determine if your FortiGate may effect the FortiGate later on, run this simple check.

  1. Save your configuration file to your hard drive
  2. Open it in your favorite text or code editor.
  3. Go to the “config webfilter profile” section.
  4. Check to see if any of the webfilter profiles are set to perform an action on category 32 or if you’re feeling lazy, do a search for “set category 32

If you find a reference to category 32 and you have already upgraded past FortiOS 4.3.18, go into your configuration using the CLI, and remove any references to category 32 and proceed as close as possible to the upgrade path below.

To completely remove the chance of this effecting the FortiManager, use the following path when upgrading the FortiGate:

4.3.18 > 5.0.2 > 5.0.4 > 5.0.6 > 5.0.10

There appears to be a large number of intermediate steps where the sanitizing of the configuration file should be taking place. This is because references to the category were not removed all at once. It first disappeared from the GUI and then from various points within the CLI and the firmware code.

After reaching 5.0.10 proceed as normal.

This path was not added to the main table as it is a somewhat isolated case.

HA Virtual MAC Address Changes

HA virtual MAC addresses are created for each FortiGate interface based on that interface’s index number. Between FortiOS 4.3 and 5.0 interface indexing changed. After upgrading a cluster to FortiOS 5.0 the virtual MAC addresses assigned to individual FortiGate interfaces may be different. You can use the get hardware nic command to view the virtual MAC address of each FortiGate interface.

The practical consequences of this could be seen in a situation where, in a very security conscious environment, there is some blocking or allowed traffic based on mac addresses. When the firewall’s mac address is not on the list of allowed addresses any traffic going through the firewall is likely to be problematic.

Changing of Logging Settings

There was a case where upgrading a few builds too far, in a very specific scenario, changed a logging setting. When going from one of the 4.3 builds to one of the earlier 5.0 builds, VDOM policies that also had IPS profiles had one of the  log setting change from logging all traffic to logging only UTM events. The upgrade path works in all other respects; it just a case of having to go through the affected policies and change the setting.

Oddly enough, if the upgrade had gone all the way to 5.0.8, the issue would not have occurred.

Familiar features removed or changed

While not an issue that will potentially stop the FortiGate from working, this issue will sometimes make it worthwhile to keep a close eye on the performance of your FortiGate after an upgrade to make sure everything is still doing what it was before the upgrade.

Example: Logtraffic function

For instance, when upgrading from 4.3 to version 5, the logtraffic-start function is disabled by default.

In version 4.3, the extended-traffic-logoption in config log [memory|disk|fortianalyzer|syslog] filter controlled the session start logging. In version 5.0, this is controlled by logtraffic-start in the policy settings. If before the upgrade, the”extended-traffic-log” was enabled, the logtraffic-start in policy settings will be disabled. More often than not this is the default setting of after an upgrade..

While for some users the loss of this function may be inconsequential, to other users this function might be useful. This is another reason to read the Release Notes; checking to verify that features commonly used in your environment will be there after the upgrade.

Example: Disk Logging

In version 4.3, logging to the local disk was only possible if Disk Logging was enabled and by default, it was disabled. Enabling the feature could be done either through the GUI or the CLI. In 5.0, not only was the feature disabled by default, but enabling it could only be done through the CLI, and even then, a message would appear stating that Logging to the local disk could seriously impact performance and that it should not be done. Despite the warning, it was possible to override the disabling of the feature and turn it on. In version 5.2, for devices that had only a single hard drive, it is not possible to override the disabling of the feature. The feature is still part of the firmware and available through the CLI, just not to all models.

This brings up an interesting situation regarding the Release Notes. The fact that this feature was, by default disabled in 5.0 is mentioned in the Release Notes for 5.0. Because, the feature was still disabled between 5.0 and 5.2, although more strictly, it was not referred to the Release Notes for 5.2. If one is steadily upgrading the firmware on devices as they come out and reading the Release Notes, the evolution can be seen and this is not an issue. But making the jump from 4.3 to 5.2, and not reading the Release Notes of the intermediate firmware builds can lead to finding a feature missing that was expected to be there, if you happen to have one of the specific models affected.

Example: config system autoupdate override

When upgrading to 5.0.12 the config systemautoupdate override function is removed. This feature was used to specify an alternate FDS server, usually a FortiManager, in the event that the FortiGuard Distribution Network(FDN) was unavailable.

Combination of variables that produce unexpected results

Every single possibility of variables cannot be tested, so every now and then a specific combination of variables will produce a side effect that is completely unexpected. Most of the time these side effects may not even be noticed but occasionally there can be some loss of functionality.

Example: Link Aggregation

One such example of this occurs when upgrading a FortiGate 600C from 4.3.18 to 5.0.11. If the FortiGate is configured to use Link Aggregation Control Protocol and an upgrade is done directly from 4.3.18 to 5.0.11, the VLANs under LACP will disappear and WiFi mash devices show up below it.

In order to prevent this from happening an upgrade to 5.0.7 needs to occur before the upgrade to 5.0.11. The reason that this path is not part of the table, is that   this situation refers to only 1 model and with a particular configuration.

Example:Application Control

When upgrading from 5.0 to 5.2, there is a curious time delay on a side effect involving Application Control profiles. If you have an Application Control profile that has some categories included, as well as some individual Application Control signatures, and you upgrade from 5.0 to 5.2 everything will work as it did before. There is the slight side effect that you will no longer see the individual signatures in the GUI, but the functionality will still be there. The problem arises when the profile is actually edited. Editing the profile removes the individual signatures. The only way to correct the error is to manually enter them in again.

Downgrading issues

While most potential issues occur during the upgrade process there are occasional ones that can occur when downgrading firmware.

Configuration  Files

There are a few reasons why downgrading is looked at with some trepidation. For the sake of clarity, we’ll use going from 5.2.3 to 5.0.12 as an example case.
The number of potential pitfalls increases proportionally with the complexity of the configuration. More settings involved means more places for things to go wrong. The most important thing to take into account is that the configuration file is firmware version specific. It does not play well with versions of the firmware that it was not written for. You cannot use a configuration file from 5.2.3 on a unit running 5.0.12.
If you are planning to downgrade and then upgrade to the current firmware version to fix an issue, chances are that somewhere along the upgrade process something was missed or broken. The more likely scenario is that the issue may not be with the firmware you are running, but with something in the configuration file.
The configuration file is essentially a number of CLI commands to the firmware that are run each time the unit is powered on. If there is a syntax error in those commands, the firmware may not behave as intended.
During an upgrade there is a background process that takes the existing configuration file and changes any commands and settings to comply with the syntax of the new firmware. Skipping a firmware version that should have been part of the upgrade path means that the syntax of one or more commands didn’t get updated to work with the current firmware. This means that even if you downgrade to 5.0.12 and throw in a factory reset to get a nice clean config file, after you go through the supported upgrade path to 5.2.3, which the current config file is from, it may not be advisable to install that configuration file. You could end up with the same issue.
The bad news is that you may need to rebuild your configuration from the ground up. The good news is that you may not have to downgrade and then upgrade. You can start with the firmware already installed. Depending on the issue, you might be able to get away with a simple factory reset, which will give you a brand new configuration file, and then just start customizing your configuration.
If you are comfortable in the CLI, you could use some techniques found in the SysAdmin Note http://cookbook.fortinet.com/t… to cut and paste portions of the existing configuration file into the new one. At some point, you are likely to come across an error as the firmware determines that the syntax is somehow wrong and then you will have to set up that portion of the configuration from scratch.

Generational incompatibility

Fortinet will sometimes produce different generations of the same model of device. Ideally, the firmware should not be downgraded to a version earlier that what it came with from the factory.

Example:

The FortiGate 3600C generation 3 came with a new NPU DDR chip that the first and second generations of the model did not have. The Support site has a firmware version 5.0.2 for the FortiGate 3600C.This would have been for the first generation of the model but the third generation of the model will not properly run this version of the firmware.

Supported upgrade path tables

Currently these are the supported FortiOS firmware versions:

* Note: The end of support date for FortiOS v4.3 was March 19th, 2014, unless the device does not support FortiOS 5.0 or higher. In those cases the end of support date is March 19th, 2017.

To keep the tables from becoming unwieldy, they do not all go back to the first version of the firmware. While there may be some instances where an upgrade is needed from an unsupported version of the firmware to one of the supported versions, the assumption has been made that the bulk of our readers/users are relatively current.

The 3 main tables, which show the supported upgrade paths to the most recent publicly available instance of the supported versions will have as its earliest starting point, the last version and patch of the latest of the unsupported versions of the firmware.

Example: if the oldest version of the supported firmware is 5.0 the earliest starting point for each of the tables will be from that last patch in version 4.3, which is 4.3.18.

If by some chain of events you are tasked with upgrading a device that has an even earlier version of the firmware, a table has been set up to show how to get from any of the earlier and unsupported versions to the latest patch in the latest version of the unsupported software and then you can switch to the table intended for the supported version of your choice

Leave a comment:

Before commenting, please read the site's comment policy. Only questions related to documentation will be answered. For other concerns, please contact Fortinet support.

  • Shagma

    Where is the FORTIAP upgrade path document?

  • Aleksandr

    Hello,
    Need help with searching the correct path.
    My Firmware Version v4.0,build0313,110301 (MR2 Patch 4)
    What numbers should I refer to? (4.2.4 313 >> 4.3.6 >> 4.3.11 >> 4.3.18? does build0313 equals to bild 313 from this table?)

    • bdickie

      Yes MR2 Patch 4 can also be expressed as 4.2.4 and yes 0313 and 313 are the same build. We aren’t planning on researching the optimal upgrade paths from 4.2.4. But once you get to any 4.3 build then any of the upgrade paths in the document should get you to 4.3.18 and beyond.

      • Aleksandr

        ok, thx for quick reply

  • Jorge

    Hi!
    How can I find the supported upgrade from 5.0.12 to 5.2.7? I only see the option directly to 5.2.9

    Thanks!

    • Judith Haney

      Hi Jorge, Page 11 of the Release Notes for 5.2.7 says that “FortiOS version 5.2.7 officially supports upgrade from version 5.0.12 or later” and that document can be found at this link: http://docs.fortinet.com/d/fortios-5.2.7-release-notes — Hope that helps!

      • Jorge

        Hi Judith,
        Does it mean upgrade directly from 5.0.12 to 5.2.7 is supported? Thanks for your quick answer!

        • Judith Haney

          Yes Jorge.

  • Mahfud Dahyani

    Hi, we have firmware 4.0 MR1 build 209 Patch8 want to upgrade to ver5.0, what step upgrade paths to do.. thanks. from the document we have to start from :
    4.0 MR1
    patch8
    209 ► 4.2.15 ► 4.3.11 ► 4.3.18 ► 5.0.12 ► 5.2.5 ► 5.40, we can’t find ver 4.2 and 4.3. can we jump to 5.0 for the upgrade ? thanks

  • Biswarup Datta

    Hi, I have upgraded from 5.4.1 to 5.4.2. Received an error “Internet-service versioin(3) is not supported” in time of reboot. What should be the probable reason???

    • Bruce Davis

      I have not experienced or heard of that particular error before. The first thing I would do verify is what generated the error. Was it the FortiGate or were you viewing it through a browser when you saw the error.The second thing to do would be to see if your FortiGate is functioning properly. Was the FortiGate successfully upgraded? Is it properly processing traffic? Once you have this information you could contact the Technical Assistance Center for any troubleshooting or ask them to forward the question to Developement.

  • Luis Danilo Ruiz Tórrez

    Hi, I think this version should be 5.0.12

    Version: FortiGate-240D v5.0,build0318,150514 (GA Patch 12)
    Branch point: 318

    My question is, can i upgrade FG directly into 5.2.9??

    As the tables states,
    5.0.12 318 >> 5.2.9 >> 5.4.3

    After 5.2.9 then again I could upgrade into 5.4.3, is that right?

    • Bruce Davis

      As long as the firmware that you are upgrading to supports the model of FortiGate that you’re going to be running it on, you should be able to upgrade from 5.0.12 to 5.2.9 and then to 5.4.3. This does not mean that you shouldn’t bother reading the Release Notes for the versions that you are upgrading to. The table is a simplified version of what is supported. Depending on your configuration, there may be some changes that go along with the upgrade that you will want to be aware of. These can usually be found in the Release Notes.

  • أمين مواتسي

    Hi ,please we have downgrade fortigate from FGT_300C-v5-build0688-FORTINET to FGT_300C-v4 -build0632-FORTINET and we crashed the firmware so please can you help us to upgrade to the current version.

    • Judith Haney

      Hello, I recommend you contact Fortinet Support to walk you through the upgrade. Reading the document at http://cookbook.fortinet.com/how-to-work-with-fortinet-support/ will help you make your time with Fortinet Support more efficient. — kind regards,
      J.

      • أمين مواتسي

        hello , judith thanks a lot for answering me , i appreciate , God bless you

        • Judith Haney

          My pleasure. — best regards

  • Fidel

    Hi I want to upgrade my FortiAP 5.0 and I have a v5.0,build0271 (GA Patch 6) 80C, I just want to know up until which version of FortiAP is supported by v5.0,build0271 (GA Patch 6) of the 80C

  • Maicon Pereira

    Hello, regard my environment I need downgrade my currently version v5.2.3,build670 to 5.0.12 after that I will go follow upgrade step by step as you tip. so I wonder it’s possible use the same file configuration through that steps ?

    • Bruce Davis

      Maicion,
      There are a few reasons why down grading is looked at with some trepidation. The amount of pitfalls increases proportionally with the complexity of the configuration. The most important thing to take into account is that the configuration file is firmware version specific. It does not play well with versions of the firmware that it was not written for. Right off the bat, you cannot use a configuration file from 5.2.3 on a unit running 5.0.12.
      I might be going out on a limb here but if you are downgrading and then upgrading to the same firmware version, I have to make an educated guess that something is not working properly, possibly because somewhere along the upgrade process something was missed or broken. Chances are the issue may not be with the firmware you are running, but with something in the configuration file.
      The configuration file is essentially a number of CLI commands to the firmware that are run each time the unit is powered on. If there is a syntax error in those commands, the firmware may not behave as intended.
      During an upgrade there is a background process that takes the existing configuration file and changes any commands and settings to comply with the syntax of the new firmware. Skipping an firmware version that should have been part of the upgrade path means that the syntax of one or more commands didn’t get updated to work with the current firmware. This means that even if you downgrade to 5.0.12 with a factory reset, when you go through the supported upgrade path to 5.2.3, which the current config file is from, it may not be advisable to install that configuration file. You could end up with the same issue.
      The bad news is that you may need to rebuild your configuration from the ground up. The good news is that you may not have to down grade and upgrade. You can start with the firmware you have installed now. Depending on the issue, you might be able to get away with a simple factory reset, which will give you a brand new configuration file, and then just start customizing your configuration.
      If you are comfortable in the CLI, you could use some techniques found in the SysAdmin Note http://cookbook.fortinet.com/transferring-configuration-file-one-model-another/ to cut and paste portions of the existing configuration file into the new one. At some point you are likely to come across an error as the it determines that the syntax is somehow wrong and then you will have to set up that portion of the configuration from scratch.
      Sorry I couldn’t give you happier news.

      • Maicon Pereira

        Thank you for your explanation!

  • ScottS

    I have several 30D firewalls still in the box that I need to configure. These have never been configured. They are at firmware 5.0.9. since there is not a configuration on it can I put the latest 5.4.4 firmware on it? Since there is no configuration issues to worry about is that allowable or do I still need to do all of the steps outlined by the upgrade path?

    • bdickie

      Yes you can go ahead and install the latest firmware without following the upgrade path. The upgrade path is only meant to make sure you don’t loose your own configuration changes during an upgrade.

      • ScottS

        Perfect. That will save me a tone of time.

        • premar

          I would recommend to factory reset the firewalls after the update. Sometimes you migrate faulty default settings.

  • Monica

    I am using Fortigate 60D – Firmware 5.2.7 (build 718)…should I download the firmware outlined in my upgrade path 5.27 >> 5.2.9 >> 5.2.10 manually then upgrade to 5.2.9 and the 5.2.10?

    • Victoria Martin

      Yes, it is recommended to follow that upgrade path.

  • ARL67

    I have several 60CM on 5.2.10 build742. I don’t see a specific 5.4.4 firmware image in the download section for the 60CM. I see only images for 60D & 60E. Can I use any of these ?

  • Huerta

    someone can tell me what version has the build 4234?? I need to upgrade a fortigate 100D v5.0.X that has that build