VMWare Web remote access fails when going through SAC
search cancel

VMWare Web remote access fails when going through SAC

book

Article ID: 267565

calendar_today

Updated On:

Products

Symantec ZTNA

Issue/Introduction

Users access VMWare management environment via SAC Web application.

Users can browse to view all available VMs without issues, but fail to get remote web console access. Instead of connecting to the remote host, the client would simply sit there doing nothing.

HAR files showed connectivity errors for connections to internal hostnames, and not the expected external application hostname.

Accessing the back end using a generic TCP application works fine.

Environment

SAC Web application.

Rewriter issues.

Cause

Web socket connection fails due to rewriting issues triggered by javascript application.

Resolution

Added custom rewriter entry to rewrite javascript code connection logic to reference the external SAC domain. In our example, we found that the Websocket connection was built on the following parameters

websocket="+("wss://"+l+"/"+host+";"+t)

Each variable within this logic needed to reference the external SAC domain, and not the internal host we were trying to access. To do this, we needed to track where each variable came from e.g. 'host' variable was the hostname, and see whether we could rewrite this. From the HAR file, we searched for the internal hostname and found it in response to a POST request to an endpoint as shown below.

 

POST /api/vApp/vm-827a-43d1-8ca2-c33828cac58e/screen/action/acquireMksTicket HTTP/2.0
 
HTTP/2.0 200
cache-control: no-store, must-revalidate
content-length: 1204
content-type: application/vnd.vmware.vcloud.mksticket+xml;version=36.2
date: Wed, 03 May 2023 14:51:39 GMT
strict-transport-security: max-age=31536000
vary: Accept-Encoding, User-Agent
x-vmware-vcloud-ceip-id: be35cbf8-347e-4dbd-9905-861f1503e39b
x-vmware-vcloud-request-execution-time: 156,156
x-vmware-vcloud-request-id: 21a6255c-aeed-49ed-a80d-b693fee491ac
 
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<MksTicket xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:vmext="http://www.vmware.com/vcloud/extension/v1.5" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" xmlns:common="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:ovfenv="http://schemas.dmtf.org/ovf/environment/1" xmlns:ns9="http://www.vmware.com/vcloud/versions">
    <Host>csm.bcom.com:8443</Host>
    <Vmx></Vmx>
    <Ticket>cst-o5WlqtLCjhzui8sU8ZreW+ktdqX4PkHAjYhjdPKTe8Tf8MakSPTF77YpXsifqU3zFkPpXYv3Jr+IEVIhPVrYyQtHwe1+oPmm++lg29MoRkUkHYl5jrdMnKV2ALY5mk0AdWiLXwVM64s6cL6bO8QFNoUvidQEyYpO1JVNrxYzPKTdjAU56tSZuzcWcaGC2xYvNvDCjSWYWeNZJeCbQyvjjf3TxxwWmLpDUSBqWTg3M8iRZxdLcPeRqz0NWyL6zfzFYwzk+av8Vm/3j78kUbTxmcrLnZ/c3Qu67YwZRyyj+6xAXKQHAks2eogviJMi8R+3wss55ZLtI5fIO0IA7vfgVTYtrG1/duhx+QElNB85OtE=-f7qKNfEfFVVbe3wVQ9VuTRIS2wd9mYlbxXlJ4Q==--tp-1F:07:77:30:67:87:66:45:73:A9:A3:B6:6D:B4:C7:B4:EB:0D:8A:0B--</Ticket>
    <Port>443</Port>
</MksTicket>
 

Armed with this information, we then created a custom link translation content rule to rewrite this host from the internal to it's external name.