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. ... View more

Has anyone performed the BIOS upgrade for the PSA 5000 or 7000 platforms to mitigate the Trickboot vulnerability? Any gotcha's or things we should be aware of before planning this?   The SA states:   Question 9: We are using A/A or A/P Cluster, do we need to patch the nodes individually? Answer: Yes, we need to patch the appliances individually in the cluster scenario (No need to break the cluster)   Does this mean that the BIOS upgrade does not follow the usual software upgrade procedure where you only have to initiate and complete the upgrade on one node after which the other node(s) will automatically receive the new software and also upgrade?     ... View more

Since the announcement of CVE-2022-0778 by the OpenSSL project most of our systems that handle client certificates (FreeRADIUS, OpenVPN, ...) have been updated to mitigate this potential DoS. The new OpenSSL packages for these systems were available within hours after the announcement which probably means this was coordinated with the OpenSSL project.   However we've yet to find any information regarding this issue from Pulse Secure/Ivanti. We heavily use client/machine certificates for authentication and would like to know if Pulse Connect Secure is impacted and, if that's the case, when patches will be released. For good measure we've also created a ticket with our VAR so they can take it up directly with Pulse Secure/Ivanti and we're keeping an eye on the security announcements and knowledge base articles. ... View more