For some reason the security bulletins does not mention that the ICA session drop. BUT for example regarding the last one two days ago..the community article states that the sessions drop REF: community.citrix.com/techzone-blogs/110_security-updates/security-update-netscaler-adc-and-netscaler-gateway-vulnerabilities… This is critical info for many environments Why is this?..too complicated or what is the deal here.. WE really would like to know this in the official sec bulletin

• Upgrading NetScaler in an ICA proxy setup to Build 14.1-73.33 or later drops active sessions attempting to reconnect with pre-upgrade session tickets. Users must restart their sessions. Post-upgrade sessions and reconnections function normally without extra configuration. Source: https://docs.netscaler.com/en-us/updates?product=NetScaler%2520ADC%2520%28includes%2520NetScaler%2520Gateway%29&version=14.1&build=73.33 So while in in full agreement, I also consider it good enough to stick in the release notes, while it's fair enough bringing it up to discussion.

oh true..need to read more carefully these readme´s in the future..trend is that readme´s you read AFTER you get issues 🙂..since they have so much to read

We are planning on highlighting that at the top of release notes on future releases as well. This is to avoid the manual steps that were required last year (kill aaa session -all ... )

To be honest, I never assume sessions will recover, because regardless of release notes, there might always be an interruption of the session. So I play it safe and inform the customer that I cannot 100% guarantee sessions will automatically resume. What I do guarantee, is that after logging on again, they will reconnect to the same session.

One thought to add on the “sessions must be restarted” behaviour. Two very different reasons for dropping sessions look identical to admins today. One is security driven, where the tickets or tokens are part of the vulnerability and immediate invalidation is the fix. The other is incidental, where the ticket format simply changed between builds. Right now that distinction lives in release notes or a community blog instead of the security bulletin. Four things that would help: 1. State in the security bulletin whether active ICA sessions will be dropped, and whether session tickets or AAA tokens are in scope of the CVE. One line, and most of the surprise goes away. 2. Show the impact by default. The upgrade flow already knows it is about to invalidate tickets, so it should say how many active ICA sessions will be dropped, in the upgrade prompt or the upgrade log. No flag to set, no separate command to remember. Today we learn that number from the helpdesk queue. 3. An opt in, admin set grace period, default zero, hours not days. Old tickets accepted only for resuming existing sessions, never for new logons, every use logged with user, time and source IP. If the CVE covers tickets or tokens, the setting is ignored and invalidation stays immediate. 4. A way for Gateway to signal Delivery Controller before invalidation, so users can be warned inside their session. Today the drop is silent from the user side and Gateway has no path to tell them anything. Point 1 costs nothing and already removes most of the pain. The rest is nice to have.

Yeah I was wondering if this was related to the manual process of killing the sessions after upgrading. I just tell them there will be a blip but I'm also lucky enough to have a maintenance window where there is usually only a handful of active sessions remaining during upgrades. I like the idea of a warning showing how many current sessions will be dropped before continuing the upgrade.

I always set the expectation that reconnecting your session will likely be required. And schedule an outage. Even if it is only a momentary hold while it reconnects, it is likely the user will notice. Makes In Service Software Upgrade (ISSU) look better eh?

So there was a change in the failovers behaviour in general, why is this now mandatory or where there to many exploits still done after patching and not applying the kill all sessions @Eric Beiers? I get it but customers are complaining around this e.g. 24/7 companies with loads of sessions published through app publishing and the reconnect of existing apps can be erroring out. Further versions 13.1/14.1/15.1 are always going to forcibly disconnect older sessions as mandatory now?

We can't be the only partner that has customers where there are some terminals that are expected to be available always and re-establishing sessions to those might even require the local support to go restart them or something (touch screens on trucks in this case).

+1 on the trucks, it's a small user base but they also have 24/7 coverage, so not an ideal situation. The users are savvy enough to do it on their own, luckily.

I find its so random if sessions will drop or not after a firmware upgrade / HA failover nowadays....... i just did a HA failover to updated secondary running 14.1-73-33 from the primary which was on 13.1-63-21 and had a blip for one second and session carried on like normal other times i have to reconnect to sessions

Both versions were safe for the previous CVE, could that explain it? I mean if you would’ve upgraded from an older version of each major release, it would’ve likely disconnect?

That's a good point, perhaps it's only a safety measure on the CVE-versions?*