Who rated this post

There are multiple ways to handle this.

Make sure that you have a policy on the gateway that ensures that you can reach the gateway using SSH throughout the entire process. Also, make sure that you can reach the management server using SSH from the gateway. Then you simply connect to the gateway using SSH. Do the in-place upgrade. The gateway should be booting with the initial policy after the upgrade so you are still able to reach it using SSH.

Then you utilise ssh from the gateway to reach the management and you can utilise mgmt_cli to push policy from the management to the upgraded gateway. If you already changed the gateway object so it has the correct version using SmartConsole beforehand all you have to do is to push policy using mgmt_cli which is quite simple:

mgmt_cli install-policy policy-package "NAME-OF-THE-POLICY-PACKAGE" access true threat-prevention true

And you're done.

If you are upgrading to R81 or R81.10 you can utilise the version upgrade feature directly in Smart Console. Just right-click the gateway --> actions --> version upgrade and do it through the wizard in Smart Console. You will obviously lose track of what is going on you will lose access to Smart Console when the gateway is upgrading. But this is simply using central deployment tool so as soon as you have initiated the process it doesn't matter if you lose access to Smart Console or not. Everything is running directly between the management server and the gateway using cdt so unless something happens during the process causing it to fail it will transfer the cpuse package or blink package of your choosing to the gateway, it will do the upgrade, it will automatically switch the gateway object in the management database to the new version and it will automatically push policy. So you should be back up and running. This is risky of course as you lose access so you don't really know what is happening and if something fails it might be difficult for you to understand what is going on besides looking at various .elg files through SSH on the gateway and management server.

This whole thing can be done even if you are not going to R81 or R81.10 by using the central deployment tool the old way (not through Smart Console). It's a more manual process but it's quite easy. Just follow sk111158.

You even have a third option. As long as you have SSH to the gateway you can temporarily enable AllowTcpForwarding within /etc/ssh/sshd_config on the gateway. Then you can utilise tcp forwarding within Putty to simply forward TCP-18190 (CPMI) and TCP-19009 (CPM) through your gateway and towards your management server. As long your gateway is allowed to run SSH to the management server you can then run Smart Console towards localhost / 127.0.0.1, Putty is then forwarding the traffic to your management server via the gateway. Just remember to disable AllowTcpForwarding afterwards as it's a major security risk to have it enabled. This has saved me so many times during upgrades, especially when going from R77 to R80 as many customers didn't have control connections activated under global properties / implied rules and they didn't allow for CPM-19009 that was added in R80 so we ended up with no Smart Console after the upgrade.