Status code 526 returned access Web application via Secure Access Cloud

Products

• Symantec ZTNA

Issue/Introduction

When trying to access the UI of an f5 virtual appliance (hosted on ec2) via Secure Access Cloud, you discover that not all of the objects load on one of the pages. The objects which fail to load are part of a wider dashboard needed for monitoring purposes. 

• SAC forensic logs for the Web application report a number of 526 error. When bypassing SAC completely all objects on the page load without issue.
• HAR files also shows the 526 status responses, and always for the same object - https://dev-web-f5-0-copy.example.luminatesec.com/tmui/tmui/dashboard/app/main/dashboardManager.template.html 
• HAR file also includes payload information from 526 status response with following - which indicates a potential 200 OK response from Web server, which SAC has turned into a 526.

{
 "title": "Application unreachable",
 "message": "You cannot access the application (HTTP status 526).",
 "reason_message": "We failed processing the response",
 "remediation_message": "Please contact your administrator for assistance.",
 "additional_details": "Failed Processing Response: Failed processing HTTP Response 'HTTP/1.1 200 OK' (request-id: 1234, application-id: #########, connector-id: ##########).. Exception: null",
 "code": 526,
 "reason_phrase": "Failed Processing Response",
 "show_error": true,
 "request_id": "####################",
 "template_file": "branded_error_dude.html",
 "show_contact": true,
 "show_support_contact": false,
 "username": "[email protected]"
}

Cause

SAC Proxy not handling compressed response from Web server correctly.

Resolution

Fixed in the SAC code update for April '23. When these issues occur with compressed payloads that SAC cannot understand, the following workarounds may be possible:

1. Disable to Content-encoding HTTP header in outbound request so that no compressed data comes back (needs HTTP header plugin on browser).
2. Disable the back end Web server from sending GZIP/Deflate compressed responses if possible.
3. Disable default content flag in the Web Application advanced options as shown below:

Additional Information

HAR file decodes the responses to display, and hence you cannot get the info you need to replicate easily.

Using curl, you can generate the request to the Web server directly and save the output with -o parameter:

• curl 'https://xx.xx.xx.xxx/tmui/tmui/dashboard/app/main/dashboardManager.template.html' -o response.gz

Now that you have the output file, you can add this to an internal testing web server and replicate the issue easily.