Create a Post
Showing results for 
Search instead for 
Did you mean: 

VSX firewall gateway upgrade from R80.20 to R80.30

VSX firewall gateway upgrade from R80.20 to R80.30

Currently we are running R80.20 JHF T103 and want to upgrade to R80.30 T-155.

We already have files for R80.30 and R80.30 T-155



Installer verify (for 80.30)

Installer install (for 80.30)

Then  installer import local (for R80.30 T-155)

Installer verify (for 80.30 T-155)

Installer install (for 80.30 T-155)

Question 1: Does above upgrade plan will work with installer command?

Question 2: Back-out plan : does installer uninstall the above R80.30 will take us back to R80.20 T103 Or after uninstall R80.30 we need to install R80.20 again?

Thanks for the help. As we don’t have lab to test it just want to have good document to upgrade prod firewalls.

0 Kudos
5 Replies

I've done a couple of these and can definitely weigh in on some important details and advice.

First, I would make sure whatever Management / Log Servers you have running are upgraded to match the major R80 version + JHFA you plan to deploy to the Gateways. Its fine if it is something higher already, but it needs to be at least whatever the GW will run.

Next, I always make a point of making sure the CPUSE Agent is upgraded to the current version. I've run into weird errors during CPUSE upgrades that occurred simply because the Agent wasn't the right version. Since this is VSX, and there is no WebUI, you'll need to do this manually. sk92449 Explains how to do this + provides the download link. The CPUSE agent upgrade is non-distruptive to the Gateway. Do this to all Gateways in the VSX cluster.

Next and most importantly... take a manual backup of your management server and store it somewhere safe! Unfortunately, there is no method in VSX to "uninstall" and revert back to an earlier version. Once you run the vsx_util command I will mention in a moment, the "schema" is forever modified and cannot be reverted. The only way to go back to the previous GW version is to restore the Management backup to its state prior to the conversion. 

Once your backups are finished and saved off, you might as well perform backups of the Gateways themselves, as well. This is a little less important, because it is fairly easy to re-provision VSX to a clean GW. But, it also can't hurt to have these in case things go wrong. Now is also a good time to check $FWDIR/modules/fwkern.conf on your Gateways for any custom kernel settings you may have changed, and forgotten about!, over the years. If you have entries, either copy this file off or just copy + paste them to Notepad to save for later.

After the backups, if you are running VSX in VSLS mode, relocate all your VS's to run on a single Gateway. If you aren't running VSLS, disregard this step.

You're now ready to begin the upgrade process. First, SSH into your management server and run vsx_util upgradeOnce you log in, you should be able to select the cluster your are upgrading as well as specify the version you are upgrading to. Once you complete the "wizard", the Management server will begin the process of "upgrading" your policies and Gateway objects to the new version. This cannot be undone; which is why the backup is so important!

Once the vsx_util completes, you are ready to upgrade the standby gateway. Perform the CPUSE upgrade as you mentioned in your OP. (installer verify / installer upgrade) When the upgrade completes, the Gateway will reboot and it should pull the upgraded versions of your policies from the Management Server. Now is a good time to check the fwkern.conf file to make sure your custom kernel parameters persisted across the upgrade!

Once the base R80.30 is installed, go ahead and install the JHFA using CPUSE to bring it up to the latest version. Reboot again.

After the 2nd reboot, you should be able to run vsx stat -v to check to make sure your VS's came up and have policy. Assuming that all looks good, you can fail all your VS's over to the upgraded Gateway and begin testing everything. (When I did my upgrade it was in a maintenance window, so I just did a very unceremonious CPSTOP on the active Gateway.). Once you feel comfortable everything is up and working through the upgraded Gateway, its basically the same steps for the remaining Gateways in your cluster.

You don't need to run vsx_util again. You just skip straight to the CPUSE portion. One everything is upgraded, check your cluster status and make sure everything is clean! 

The process isn't quite as easy as non-VSX Gateways, but its probably less intimidating than it sounds. Just make sure you have good backups!!!

Hope this helps. Let me know if you have any other questions about the process! 

Good luck!



0 Kudos

Thank you so much for the detailed answer. I have found the below article for the upgrade from R77.30 into R80.10. Do you think these steps should work to upgrade R80.20 to R80.30.

1. Backup all your systems - gateways and management so you have solid rollback


2. Update VSX cluster object version on management server using vsx_util upgrade command:


When prompted, enter this information:

a) Security Gateway or main Domain Management Server IP address

b) Administrator name and password

c) Cluster name (if the VSX Gateway is a cluster member)

d) Version to upgrade to: R80.10


3. Log into standby VSX member CLISH and perform CPUSE upgrade:


HostName:0> show installer packages available-for-download


HostName:0> installer download <Package_Number for R80.10>


HostName:0> installer verify[press Space key][press Tab key]

HostName:0> installer verify <Package_Number for R80.10>


You should see something like this:


Result: Verifier results: Clean Install: Installation is allowed. Upgrade: Upgrade is allowed.

Status: Available for Install


HostName:0> installer upgrade[press Space key][press Tab key]

HostName:0> installer upgrade <Package_Number>


It should reboot itself at the end


Wait till VSX is up again and verify that you are running on R80.10


4. Cutover from R77 to R80 (reference here Connectivity Upgrade R77.x and R80.x Versions Best Practices )


On the upgraded member, run: cphaprob state


Make sure that this cluster member is in the Ready state.


On the cluster member that still runs the previous version, run: cphaprob state


Make sure that this cluster member is in Active or Active Attention state, and that the upgraded member is in Down state.


On the upgraded member, run: cphacu start no_dr


Make sure that the Connectivity Upgrade is complete.

On the cluster member that still runs the previous version, run:

vsenv 0

fwaccel off -a

fwaccel stat -a

Make sure the SecureXL is disabled (off). This is required to synchronize delayed connections.


cpstop (this is cutover!)

On the upgraded cluster member, run: cphaprob state

Make sure this cluster member is in Active state.


cphacu stat

Make sure this cluster member handles the traffic.


cphacu stop


5. Do your testing on newly upgraded member


6. Upgrade remaining cluster member just like in step 3. Once upgrade is complete and all VSes are up it should automatically fail back to it.


0 Kudos

Yes, I believe this was the article I originally referenced when I was preparing to lab my upgrade. There were just the couple extra steps, like the CPUSE upgrade, I added from my own prior experiences. I'm not sure whether an outdated CPUSE agent would cause an issue with this specific migration path. So, probably best to just do it regardless.

My apologies... I did forget about cphacu start no_dr. So, I'm glad that step is mentioned here!

Good luck and let me know if there's anything else you aren't sure about. 


Thank you.

0 Kudos

Hey @CPRQ,

Did you consider using CDT for the upgrade? most of the complex work will be performed automatically. might save you a lot of headache. 


0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events