Table of Contents
- 1 Supported upgrade paths
- 2 Max Value Issues
- 3 Standalone vs. HA configuration upgrades
- 4 Parallel Development
- 5 Upgrade Methods
- 6 Special Builds
- 7 Why read the Release Notes?
- 8 Supported Models
- 9 Potential upgrade issues
- 10 Downgrading issues
- 11 Upgrade Issues specific to 5.6.x
- 12 Upgrade Issues specific to 5.4.x
The goal of this document is to prepare you to upgrade your FortiGate unit from an older version to the desired version. This will include:
- Showing you where to get the supported path of upgrades
- Helping you understand the surrounding context to help make sense of the supported upgrade paths
- Informing you of possible issues you could face
Supported upgrade paths
Supported upgrade path information is available on the Fortinet Customer Service & Support site.
To view supported upgrade path information:
- Go to https://support.fortinet.com
- From the Download menu, select Firmware Images.
- On the Upgrade Path tab, select:
- Current Product
- Current FortiOS Version
- Upgrade To FortiOS Version
- Click Go.
For most devices, these steps will show the path in steps from your current version to the latest Version, MR, and patch. The steps shown by the Supported Upgrade Path are not the only possible path, but they are supported and have been optimized to achieve the latest version of the firmware in the fewest steps.
Upgrade path tables and utilities do not include any references to release compatibility between Fortinet products. This is an issue that administrators of environments where different Fortinet products are used should be aware of. For instance, a specific version of FortiManager has a range of versions of FortiGate that it will be compatible with. If the FortiGates are upgraded without verifying that the FortiManager will be compatible with them, a situation could arise where the FortiManager will not be able to manage those newly upgraded FortiGates. On the other side of the equation, it is also possible to upgrade a FortiManager beyond the compatibility range of some of the older models of FortiGate.
If you have some older models of FortiGate that cannot be upgraded to current releases of firmware, and some brand new models of FortiGate that cannot run older firmware, the situation can arise where a single FortiManager will not be able to manage all of the FortiGates in the environment. This is an issue that the administrator needs to be aware of when making decisions about which firmware to run.
The compatibility between models is listed in the Release Notes of the products. These should be read and the environment should be planned out as a whole. It is possible that there is no one best option. The administrator will have to weigh the pros and cons of all of the variables and keep in mind what the most important requirements are for the environment.
Over the life of the firmware, the designation of the individual releases has changed but this document tries to make these designations as consistent and as easy to understand as possible.
Originally, the version designation was made up of a Version, possibly a major release within that version and possible a patch number within that major release. If one was trying to refer to one of the later patches in a later release of version 4 of the firmware it could be described as Version 4 MR 3 Patch 18.
To make writing the release name simpler a ‘shorthand’ developed using the pattern x.x.x. The numbers shown below are an abbreviated form of the firmware version names.
|1st Number||Version Number|
|2nd Number||Release Number|
|3rd Number||Patch Number|
Example: 3.7.10 = Version 3.0 MR7 Patch 10
Recently, the longer version of describing the release was dropped in favor of the simplified format.So it is not FortiOS Version 5 MR 2 Patch 1. It is simply FortiOS 5.2.1. Within the table, the simplified version is always used when describing the path.
In cases where there is no indication in the Web-based Manager what the version or build number is you can get the build number from the CLI by entering the command:
get system status
The value in the output of the command for “Branch point” will be the build number.
Max Value Issues
- There is a range of builds where the maximum number of some of the objects was lowered, but then a few builds later were raised back up. If a configuration on a device was to have a number of these objects in excess of the lower value when doing an upgrade there could be issues and even data loss so the upgrade paths listed are designed to avoid upgrading into this lower max value range even though the Release Notes state that upgrading to these firmware builds is supported. When the release notes were written the act of increasing the values was not foreseen.
- Seemingly unrelated features can sometimes affect Max Value parameters after an upgrade. For instance, a feature introduced in 5.4 affected the max number of application control sensors. The feature added a “
sniffer-profile“, which could not be deleted, upon the creation of a VDOM. The normal max number of application sensors could be 32 but if you had 10 VDOMs, that number was effectively usable sensors (32 – 10 = 22).
Standalone vs. HA configuration upgrades
If you read the Release Notes for the firmware upgrades you will notice a discrepancy between what the Release Notes say is possible for upgrades and what the Upgrade Steps Table shows.
In version 5 there is a difference in the steps between the patches depending on whether your FortiGate setup is in a standalone or an HA configuration. If you have a standalone setup you can upgrade from Patch 3 (5.0.3) directly to Patch 5 (5.0.5). However, if you are using an HA setup you need to add the intermediate step of going to Patch 4 (5.0.4), otherwise, only the slave unit in the configuration will be upgraded to Patch 5.
In the table describing the steps in progressing through the upgrades the most cautious path is listed. This minimizes the possibility of confusion for somebody who has an HA cluster but reads the Release Notes, like everybody should, but was unaware of the known issue with the HA clusters.
Development of the firmware is usually taking place on two paths at the same time. There is development taking place on the latest path, as well as the previous stable path. For instance, if the latest path was 5.0.x then the previous stable path that would still be in development would be 4.3.x. This has 2 significant ramifications as far as upgrades are concerned. The first is that patches are still being built for each of these paths. The second is that because this development is taking place in parallel the number identifiers for the builds do not correspond directly with the sequence in which the builds come out.
Occasionally it will appear as if there are some odd jumps in the upgrade sequence. This has to do with the timing of releases of different versions of the firmware. Later builds of different versions can come out close together and so have a high likelihood of compatibility. This is why 5.0.6 can only upgrade up to 5.0.9 but 4.3.18 can upgrade to 5.0.12
There are two methods of primary methods of upgrading the firmware through the GUI; either from a local file that has been previously downloaded or from the FortiGuard Network.
Upgrading from the Local Drive
When uploading the firmware from the local drive you must already have downloaded it from the Fortinet Support Site at https://support.fortinet.com/. Once you have logged in with the account ID and password that was created when registering the FortiGate, go to the Download section and select the icon for Firmware images. From there it is only a matter of selecting a product, such as a FortiGate and then selecting either HTTPS or FTP download. The layout of the firmware listing in both methods is a hierarchical tree. For instance, if you wanted firmware 5.0.7 you would select the v5.00 directory, then the 5.0 directory, then the 5.0.7 directory. Once in the directory scroll down until you find the correct firmware file name for your specific model. Then select the file you wish to download.
The file names are intended to be helpful in determining the correct firmware for the model you need. Here are some of the conventions found in the file names.
- FGT_ = FortiGate
- FWF_ = FortiWiFi
- POE = Power over Ethernet
- VM32/VM64 = Virtual Machine versions of the firmware. The 32 and 64 referring to the bit architecture of the OS.
Firmware going directly on a Fortinet Device will have the
Upgrading from the FortiGuard Network
The practice of strategically skipping some firmware versions to optimize the time and efficiency that it takes to get to the latest version is based on using the Upgrade from: Local Hard Drive option. If you try to use the Upgrade from: FortiGuard Network option you will notice that there is a limited number of firmware builds to which you may upgrade or downgrade. This is because only options that are always going to be safe are available. The logic being that because there are no intermediate options possible, the next consecutive build will always be a safe option.
Because of this limitation in options, it means that you will not be able to use the Upgrade from: FortiGuard Network option to see all of the safe upgrade options. You will either have to use the included upgrade path table or study the Release Notes.
The builds that will be shown will most like be as follows:
- The next build in the current version track
- The previous build in the current version track.
- The latest build in the previous version track.
Every now and then a “Special Build” is created for some specific purpose and some companies will put these into production. These special builds are not part of the normal upgrade path QA process and therefore have a greater risk of variance from what is normally expected in an upgrade. The table of the upgrade path is based on the Release Notes of the regular builds and may not have included testing against every special build as well. If you are running a special build, be even more cautious in upgrading than you would normally be.
Why read the Release Notes?
Previously in this document, it was recommended that before upgrading from one version of the firmware to a more recent one that the Release Notes be read. To give an indication of how important it is to read the Release Notes, we have provided a sampling on the next page of some of the possible issues that may have to be dealt with upon upgrading.
To offer some clarification on the contents of this sampling, some of these issues were and are unavoidable because of the nature of the configurations of the FortiGate devices and the networks they were in. The reason for reading the Release Notes is to make sure that users are prepared for changes or potential outages that may occur so that the affected parties can be forewarned and the issues can be dealt with in a timely manner.
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 are 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, the secondary WAN IP cannot be used for administrative HTTPS access or SSL-VPN. PING and VIP using the second WAN as an external interface will work 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 Web filter 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 an 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 affect 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 affects 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 affect 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 affect the FortiGate later on, run this simple check.
- Save your configuration file to your hard drive
- Open it in your favorite text or code editor.
- Go to the “
config webfilter profile” section.
- Check to see if any of the web filter 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 affecting 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
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 allowing of 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 mesh 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.
While most potential issues occur during the upgrade process there are occasional ones that can occur when downgrading firmware.
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.
A configuration file is essentially a number of CLI commands to the firmware that is 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.
Fortinet will sometimes produce different generations of the same model of a device. Ideally, the firmware should not be downgraded to a version earlier than what it came with from the factory.
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.
Upgrade Issues specific to 5.6.x
Use of Port 4433
This issue usually occurs when the Admin access port for HTTPS access is changed due to an SSL-VPN using 443.
The new FTM-push feature in 5.6.0 uses port 4433 by default. If a SysAdmin has changed the HTTP or HTTPS access port to 4433 before the upgrade and FTM is enabled on the interface, once the upgrade has been completed, FTM is now using this feature and the SysAdmin can be prevented from accessing the administrative features of the FortiGate through the GUI.
- The CLI doesn’t give any warnings regarding this issue.
- Removing FTM from the
allowaccesssetting does not get back the GUI access.
- If this issue is encountered, temporarily reset the admin ports back to their default settings to regain GUI access.
There is an issue with IPsec tunnels when upgrading from 5.4.5 to 5.6.0, but only between these two versions. Going from 5.4.4 to 5.6.0 doesn’t present an issue. If you do upgrade between these two versions any Phase 1 psksecrets will have to be reset.
Upgrade Issues specific to 5.4.x
FortiOS 5.2 allowed configurations to use wildcard FQDN objects in the firewall policies. This functionality was removed starting in 5.4. If a user has a firewall running FOS 5.2 with firewall rules configured to use wildcard FQNDs, when the customer upgrades the firewall to FOS 5.4.x or later, the firewall rules using wildcard FQDNs will be deleted. This can cause unexpected traffic to pass or be blocked.