January 18, 2024

Introduction and Background

We recently had a client upgrade their NetScalers from 13.1 b49.15 to b51.15. After upgrading, their StoreFront 2203 LTSR Stores configured with the HTML5 client failed to function via Citrix Gateway, hanging indefinitely at the screen below.

Of note, this customer has NetScaler WAF (AppFW) applying to their Citrix Gateways (a good practice).

Cause and Resolution

Upon examination of working and non-working appliances (i.e. ones not yet upgraded and those upgraded), we identified another delta beyond the firmware difference. As is common with firmware upgrades, the WAF signature file was also updated. Before the upgrade, this was WAF signature v105; post-upgrade it was v117. The customer does not have auto-upgrade enabled for signatures.

Suspecting WAF may be involved, we jumped into the shell and tailed the ns.log for “blocked”, and noted a repeated violation.

tail -f /var/log/ns.log | grep -i "blocked"

So we’ve quickly identified a rule that *may* be affecting the HTML5 client session launch, so we went back into the WAF signatures in use to disable the block and re-test.

Interestingly enough, on the yet-to-be-upgraded appliance, the block was intact for this signature, yet did not pose issues before, and it is not new.

Upon disabling the block, HTML5 client access was restored.

Delving deeper into the differences, we noted differences in the default signature rule.

Before Upgrade:

After Upgrade:

A colleague experiencing a similar issue very recently has provided the following synopsis, translating the match details with a URL decoder:

Before this particular signature rule matched on “../../../” and after upgrade matched on “..” In his case, he found the change was creating several false positives with another customer’s web app and required disabling the signature ID as well.

Subscribe