Connect Secure choosing a software release

[bylie]

Hi,

Currently we're running Pulse Connect Secure 9.1R14.3 and our clients are a mix of 9.1R13 and 9.1R14. Overall, for the functionality we need, it works well enough such that we haven't been following the latests and greatests releases. However when looking at the Granular Software Release EOL timelines and Support Matrix we get the feeling we're lagging more and more behind and might soon be running an obsolete and potentially insecure release with a wide upgradegap. But we also don't really know what the best upgrade strategy would be as the following questions keep coming up:

• Why was 9.1R14 designated as an LTS release, anything special about that release?
• Will there be a new LTS release in the future?
• What is the difference between "End of Engineering" and "End of Support", especially for newly found security issues? Do those still get fixed in dot releases until the "End of Support" or is the security party over when "End of Engineering" is reached?
• Regarding the list of supported client versions, should this be interpreted as "we only support these client versions when you open a supportcase but older/newer client versions will most likely also work without problems" or "only these client versions are expected to work, older or newer will probaby give issues".
• We always first upgraded the serverside after which we roll out the newer client to our users over the span of a couple of months via SCCM. This way we can fully control the rollout (testgroups etc) instead of an all or nothing operation via the Pulse Secure appliance itself. Would first upgrading the clients to a newer version, before upgrading the serverside, also be a viable course of action? Better or worse?
• Is there a clear overview between the different release trains which might explain why we would be more conservative and for example choose 9.1R15 as our next version instead of going directly to the newer 9.1R16.x or higher such as the future 9.1R17?
• We found some reports of issues with ACL's containing wildcards when 9.1R16 was newly released which also indicates that basic functionality might still get broken in a new release. Is there any concensus on waiting for minor dot releases like with other vendors?

Thanks for replying and providing insights.

[zanyterp]

• please check with your account team for the quesion on LTS release and if there will be changes to that designation/release
• end of engineering means that there is no additional feature work; security fixes may, or may not, be applied depending on what is available on the physical platform (e.g. 7.1 was the last release to support the SA appliances and received security fixes well-beyond when no features were being added; however, it stopped receiving security fixes after the hardware was no longer supported). it is recommended to stay on the latest release for security. end of support means that support will provide best effort support; but one of the first solutions/requests will be to test newer versions to rule out any unexpected fixes
• the client matrix is that those are expected to work and engineering will work to ensure those versions match and work. older clients are expected to work; however, if there is a mismatch in that, the newer client will need to be tested
• upgrading the clients before the server is supported. it is neither better nor worse than doing the server first as you still control the upgrade process
• unfortunately, yes, software finds new ways to break with each upgrade. there should be no concern with upgrading to new releases once they are available; however, as with all platforms, testing in a lab/UAT environment is recommended to help reduce impact of unexpected items (such as the ACL issue in 9.1R16)

[bylie]

Thanks for the reply!

Regarding the client and server compatibility how far does this extend generally? I'm just trying to get a grasp about how much of a version gap in practice (and looking at the track record of Pulse Secure software) can exist between the two as 99% of our clients are managed but there are some manual installs that don't really get kept up to date and might lag behind quite a bit as time goes by.

It's quite understandable that bugs happen but as an admin we do also have an obligation to our users/org to provide a working service. So if picking the right version at the right time helps to prevent outages or downtime even better. With some vendors we feel we can upgrade without to much worry, even to newer .0 releases while with others it's quite a minefield to know when it's ok to upgrade or not if you don't want (or have the resources) to do QA testing for the vendor.

[zanyterp]

you are welcome; glad to assist
server:client compatibility has historically been within 3 major releases, minus the new features that rely on parts that may or may not be present on the other side (e.g. version enforcement; FQDN; SplitDNS; etc). due to the recent change in compatibility, it is now based on the minor release (e.g. 9.1R15 PCS is supported with 9.1R15, 9.1R14, and 9.1R13 clients); if outside that range, the first thing that will be asked is testing with a supported/qualified release to ensure that it is not yet fixed. as long as you are seeing connections succeed, you are fine to have a wider gap than that.
does that help the mud become slightly clearer?

[bylie]

Do such incompatible changes happen often when looking at the history of the product?

[zanyterp · Accepted solution]

historically? no
up until less than 6 months ago, it was current - 2 releases (meaning 9.1, 9.0, and 5.3 clients were supported…the 5.3 client was released in 2018). i cannot comment on why the change from focusing on major release to minor release; however, my guess is that it was to reduce confusion on what is supported. i would recommend reaching out to your account team.
or if you were asking how often features are added in new server versions and not backported to the client? every 3 - 6 months…but you may not need the new features, so it may not apply

[bylie]

It seems the official support window has been narrowed quite a bit then, previously 4 years, now maybe 1 year going on the recent release cadence. But understandable in view of the ever increasing complexity and possible interactions between server and client.

I guess also the "release early, release often" and "fail fast, fail often" mantras are making their way everywhere.