HA pair on different os version

[jdprovine]

I have a HA pair (active/passive) that I want to upgrade from 6.1.11 to a stable version of 7.  I also am using global protect with certs. According to some information I gathered from the community if I upgrade to what I was told was the current most stable version of 7.06 that is would break my vpn certs. So I am trying to do an upgrade that will not break my certs and still make it possbile to go to the best version of 7. Here are some of the options I was considering

Upgrade my secondary to 7.01 and then to 7.06 see what happens. But I don't know how long that will take and how long I can leave my HA pair out of synch. Once I fail over to the secondary and make sure everything works okay then I would run on the secondary and upgrade the primary.

If I go straight to 7.06 can I fix my certs without an intermediate upgrade? As we all know time is a precious commodity.

[reaper]

you'd need to manually fix your configuration (through a text- or XML editor) to fix the issue introduced by skipping 7.0.1 which will likely cost you more time. 

skipping the step causes the tls/ssl profile for your certs to not be generated properly causing your certificates to stop working but also can't be deleted at that point due to them pointing to an inexistent profile. you'd need to delete the malformed entry in the config file and then create a new one

[jdprovine]

what if you removed the cert and re-add it after the upgrade to 7.06?  Do you know if you can upgrade only one of the pair and leave it as a test till you make sure everything works. I am talking about at least a week or so

[reaper]

if you'd remove the cert before the upgrade, then upgrade and create the tls/ssl profile and re-add the certificates you would be good

you can always leave a cluster with one member in a disabled state ...

BUT: you'd need to set one member to suspended mode as in a normal cluster environment the member wiuth the lowest PAN-OS will assume the active role while the upgraded member is non-functional

you'd no longer have a cluster and in case the upgraded member were to fail you would need a manual intervention to make the not-yet-upgraded member start taking sessions... I'd not recommend this for a prolonged period of time

[jdprovine]

Any idea how long I could keep them in that state? I would rather break the secondary and try to fix it than break the primary at least I would have time to fix it

[reaper]

indefinately, but you'd also not have a cluster for as long as the HA pair is set in this way

[jdprovine]

So I could do the upgrade on the secondary while it is in that passive state. Fail it over during the off hours, test and make sure everything works and operate on the secondary and then do the other one if everything tests out

[jdprovine]

I would also need a could config backup and a roll back plan if the secondary upgrade failed

[reaper]

---

@jdprovine wrote:

So I could do the upgrade on the secondary while it is in that passive state. Fail it over during the off hours, test and make sure everything works and operate on the secondary and then do the other one if everything tests out

---

yes, exactly

as a fallback your primary node will be available and i would recommend extracting both a config backup and a 'device state' right before performing the upgrade of the secondary so you can roll back the software and simply push config or device state without worrying about intra-PAN-OS config conversion

[jdprovine]

Would  I have to turn off HA while there are on different os versions? The biggest change in th 7 is the acc isn't it? If I want to revert back on the secondary from 7 to 6 is that as easy as reinstalling the previous OS?

[reaper]

There's no need to turn off the HA, it will simply not function as normal so you'd need to make sure that once your secondary is upgraded, you manually set your primary member in a suspended state so it no longer participates (this because the lowest pan-os will have priority if you do not suspend that member)

> request high-availability state suspend 

If you disable HA the behavior will change and both firewalls will want to try and be active, which would require you to unplug one of the devices.

the biggest visual change from 6.1 to 7.0 is the acc, there are a couple other nice new features (like configurable deny action, check out the video 🙂 ) but nothing that should cause any trouble (they all need to be configured after they become available so they won't suddenly be 'on' and cause a surprise)

going back to 6.1 is as simple as installing a new PAN-OS (I do recommend you grab a backup of the 6.1 configuration and load that if you do need to roll back, just for ease of mind)

[jdprovine]

So will they continue to synch the configuration when they are at a differen OS's? If the secondary does not go well my plan is to move all the traffic back to the primary well I try to fix the secondary.

[reaper]

you'll be able to sync the config as long as you don't activate new features on the newly upgraded peer and try to push that over to the not-yet-upgrade peer

I would recommend changing as little as possible while they are in this intermediary state as the cluster is not intended to operate in this fashion for a prolonged period of time

[jdprovine]

So I would be able to create new policies and they would synch, not sure other than the acc what has really changed that I would be updating anyway

[reaper]

correct

one of the really cool new features is "configurable deny" where you can now choose to send an ICMP unreachable or TCP RST packets instead of the default silent drop. that wouldn't sync