Handling Web Applications that use Non-Standard HTTP/S Ports

Products

Symantec ZTNA

Issue/Introduction

Resolution

Web Applications / Portals designed with a Local Area Network / Virtual Private Network "mentality" may contain references, either in the HTML pages or in AJAX scripts to URLs with non-standard ports (i.e., not TCP 80 for HTTP / TCP 443 for HTTPS).

This is a practice that might be used in legitimate business applications, such as VMware vSphere or various Oracle Business Applications. In the vast majority of the cases, the usage of non-standard ports will be done in a way that is transparent to the end-user, not as an initial page the user navigates to, but as a part of an internal flow.

Below diagram demonstrates a possible challenge:

Without any special handling, the Web Application/Portal will either contain broken links or will not function properly. Web Application Server 2 can reside on the same machine as Web Application Server 1 and only have a different port, this does not change the issue.

Following steps are required to configure the system to support such non-standard web applications:

1. Define a separate Web Application for the non-standard port

In the Administration Portal define a separate Web Application for the non-standard port. Make sure to define the port in the internal address. In order to avoid confusion, mark "Publish in Application Portal" as No (in the advanced settings).

2. Define an HTTP Response Custom Link Translation Rule

In the advanced settings of a Web Application representing Web Application Server 1 (not the newly created object), please click on "Edit Customer Rules" (if this capability does not appear in your portal, please open a support ticket to have it enabled).

Define the custom content rule according to the below:

Content Type - Can either remain blank, or, for optimization, can contain the content-type of the resource containing the reference to an internal address with a custom port, such as "application/json" or "application/javascript"

Message Type - Has to be set to "HTTP Response"

URI - Can either remain blank or contain specific URI that returns the resource containing the reference to an internal address with a custom port.

Source URL - A full or partial URL containing an internal address of Web Application Server 2 with a custom port.

Destination URL - A full or partial URL containing an external address of Web Application Server 2, accessible via Secure Access Cloud.

3. Optional (If CORS Policy Blocks the requests) - Define a Path Translation Rule

In some cases, if Web Application Server 1 has a strict CORS policy that would not allow browser/AJAX to call web-application-2-external address. While this case can be rare, in order to support it, the following change should be made to Destination URL parameters of the custom body rule:

Instead of web-application-2-external is should say: web-application-1-external/luminateto/web-application-2-external

This directive will cause the browser to send the request to a URI in Web Application Server 2 via a domain of Web Application Server 1 and a URI appended to /luminateto/web-application-2-external