Skip to main content

Check out Interactive Visual Stories to gain hands-on experience with the SSE product features. Click here.

Skyhigh Security

Upgrade Best Practices and Understanding Release Branches

The Secure Web Gateway has two release branches, Main and Controlled. In this article, you should have a basic understanding of each release branch, the best practices for upgrading, and how to upgrade to the Secure Web Gateway version you want to use.

Main vs Controlled

Both main and controlled release branches are fully QA tested and supported. Here are some things to expect from each branch.

Main Release Branch

  • Default version on all new Secure Web Gateway appliances.
  • Maintenance releases are provided throughout the year (every two months).
  • Provides feature enhancements once a year.

Controlled Release Branch

  • Provides feature enhancements once every four months.
  • Patch releases are either made between feature releases or rolled into the next one.
  • Customers have to actively decide to switch to this branch.

At the end of the one-year period, the current controlled release version becomes the main release.

Best Practices

Skyhigh Support recommends that you stay on the Main Release Branch instead of going to the Controlled Branch unless you have a specific purpose (for example you need a new feature urgently). Most customer environments are better off with the main release branch and maintenance releases only.

Once you go to the Controlled Release, you cannot move back without a complete reimage and recreation of your rules. A backup from the Controlled Release cannot be imported to a Main Release version.

Upgrading

Please follow the best practices when upgrading to a different version.

  • Always take a backup (Configuration > Backup/Restore)
    upgrading.png
  • Be patient! If you are upgrading from one major version to another be sure to allocate an hour (at least) for maintenance. Most times upgrades should take less than 15 minutes or less depending on how far back you are.
  • If you are updating in Central Management Mode, please read over our best practices here about dismantling the cluster. Breaking up the cluster is not required, but is recommended when there is a difference in the minor version. Dismantling the cluster is recommended for n+1 difference because the newer version knows of properties that are not available in the older version
  • Dismantling is not essential when there is version differences in the same micro version.
  • If you have Secure Web Gateways setup in a ProxyHA, Transparent Router, or Transparent Bridge cluster, see the following thread:
  • We suggest doing upgrades via the command line and the "yum" command. This gives you more control and visibility into the process. Please make sure you have root access to the command line for this.
  • Always reboot the appliance after upgrading
  • Have some form of console access, either physical or by DRAC/RMM. This is in the event the reboot takes longer than expected (i.e., disk check requires user interaction). Also note that if you need to reimage, the DRAC/RMM cards can be used to mount an ISO image remotely.

Upgrades in Central Management Mode

If you're updating in Central Management mode, see the "Dismantling the client" here. 

  • Breaking up the cluster isn't needed, but we recommend it when there's a difference in the main version (for example, 8.1.x and 8.2.x). This is because the newer version has properties that are unavailable in the older version.
     
  • Perform the upgrade by removing all appliances separately from the Central Management cluster before you upgrade and then update each appliance individually.
    After you successfully update all your appliances, add them back to the Central Management cluster.
     
  • Dismantling is not essential when there are version differences in the same Feature or Maintenance version.
     
  • To update the appliance software on the nodes of a Central Management configuration, you can perform the update procedure from the user interface of one of the nodes. That node is then the last to be updated.

Upgrades with a ProxyHA, Transparent Router, or Transparent Bridge cluster

If you have the SWG appliance set up as a ProxyHA, Transparent Router, or Transparent Bridge cluster, you can leave the nodes as is or you can perform the following. Leaving the nodes as is interrupts traffic, whereas performing the following has minimal interruption.

NOTE: This method focuses on taking old nodes out of service, upgrading them, and then transitioning new nodes into service.
 

  1. Identify a redundant director node or scanning node that you want to upgrade. Take a backup before beginning as usual.
    1. Remove the port redirects under Configuration, Proxies. By removing the port redirects, this node stops receiving traffic from the director.
    2. Upgrade the node.
    3. When upgraded, add the removed port redirects back in, so the node starts receiving traffic again.
    4. Leave as standalone or add to the upgraded cluster.
       
  2. Now that the redundant director node and scanning nodes are upgraded, you can upgrade the current director node.
    1. Adjust the priority to be zero or lower than the redundant director. This new value transitions traffic from the director node to the redundant director node.
    2. Perform steps 1a–d listed above.

NOTES:

  • We recommend that you perform upgrades via the command line using the yum command. This approach gives you more control and visibility in the process. Make sure that you have root access to the command line.
  • In between each of these steps, we recommend that you verify that traffic is passing normally. This way you can easily revert to the last step. In step 2a, you might see an issue if you don't have a redundant director.

Upgrades in networks without internet access

The upgrade process uses Yum. Yum is a real-time upgrade performed by downloading files directly from our servers. If your appliances don’t have access to these servers, you must perform the upgrades by reimaging to the needed version and restoring a backup.

Upgrades in FIPS mode

FIPS mode doesn't allow you to upgrade. You must reimage your appliance with the needed version (and again, select FIPS during the install), and then restore a backup. SWG 7.8.2 is the latest product version that is FIPS-certified. SWG 8.x has no FIPS certification.

NOTE: FIPS backups can't be restored on non-FIPS appliances. 

How to upgrade to the latest version of either branch

Please see the release notes on the Content Security Portal. Each release notes document has an upgrading section at the bottom with release-specific instructions.

How to upgrade to a specific version

Often time’s customers need to test specific Secure Web Gateway versions before they can be rolled out into production. If a newer release has happened while you were testing, you have to take special steps to get to your desired version.

On the command line execute the following commands:

  1. mwg-switch-repo --sticky <version number>
  2. yum upgrade

The version number can be switched to any version.

Notes

  • A benefit of the 'mwg-switch-repo --sticky' command, is that it ensures that your Secure Web Gateway is updated to your intended version.
  • Once updated to a sticky release, you will not be able to update the Secure Web GatewayG from the UI. If you attempt to update via the Secure Web Gateway UI, you will receive a message stating "Nothing to update". This is because you're sticky to your current release.
  • For subsequent upgrades, you will need to issue another mwg-switch-repo --sticky <version> command as shown above.

Useful commands

How to check if you're using an Secure Web Gateway "sticky" release:

mwg-switch-repo -l

Example output: "Current Configuration: Non-sticky Secure Web Gateway <version number> (release)"

How to switch from a sticky release back to the main release repository:

mwg-switch-repo main

NOTE: Upgrading with this repository will always take you to the latest release in the Main Branch. Make sure you know the most current release within the Main repository before upgrading. This will help prevent an upgrade to an unexpected version.

Upgrades in Networks without Internet Access

yum is a real-time upgrade performed by downloading files directly from Skyhigh Security's servers. If your machines do not have access to these servers, you have to perform upgrades by re-imaging to the desired version and restoring a backup.

Upgrades in FIPS mode

FIPS mode does not allow you to upgrade. You need to reimage your appliance with the desired version (select FIPS again during install) and restore a backup. Note that FIPS backups cannot be restored on non-FIPS appliances.

Downgrading

Downgrading a Secure Web Gateway appliance is not supported at this time. If you still have a need for it you need to reimage with the older version and restore the backup you took before the upgrade.

Best practices during upgrade

  • Always take a configuration backup. For steps, see the product guide for your release.

  • When you upgrade from one major version to another, make sure to allocate at least one hour for maintenance. Most upgrades take less than 15 minutes, but the length of time depends on the age of your current installed release and target version.

  • ​Always reboot the appliance after the upgrade.

  • Always have some form of console access, either physical or by DRAC/RMM to the appliance available. This recommendation is in case the reboot takes longer than expected. For example, disk check requires user interaction. Also, if you need to reimage, you can use the DRAC/RMM cards to mount an ISO image remotely.

To upgrade SWG to a specific version:

You might need to test specific SWG versions before they can be rolled out into production. If a newer version is released while you're testing, you must perform special steps to upgrade to your needed version (for example, if 8.2.3 was released while you were testing 8.2.2). These steps can be performed only from the appliance command line:

  1. Log on to the SWG command line as a root user.

  2. Type mwg-switch-repo -l and press Enter. The output of this command can help you identify if a sticky bit is already set:
    Current Configuration: Non-sticky 

NOTE: A benefit of the mwg-switch-repo --sticky command is that it makes sure that your SWG is updated to your intended version.
 

  1. Define the version you want to update. Type mwg-switch-repo --sticky <version number> and then press Enter.

NOTE: The version number can be switched to any version, such as 8.2.3.

IMPORTANT: When updated to a sticky release, you can't update the SWG from the manager. 

  1. Start the update process. Type yum upgrade and then press Enter.

NOTES:

  • If you try to update via the SWG manager, you see the error below:

    Nothing to update.

    It's because your current release is set as the sticky release.
     

  • To perform subsequent upgrades, you must issue another mwg-switch-repo --sticky <version> command as shown above.
     

  • To switch back to the main release, type mwg-switch-repo main and press Enter.
     

  • Upgrading with this repository always takes you to the latest release in the Main Branch. Make sure you know the most current release within the Main repository before upgrading. This information can help prevent an upgrade to an unexpected version. You can verify the current main version using the Content Security Portal.

 

 

  • Was this article helpful?