Using a Reverse Proxy

There are two principal applications in using a reverse proxy for Thin Clients:

Load Balancing

Providing a single entry point into the system for clients. The proxy maintains seamless Thin Client access by distributing incoming requests to two or more VTScada servers. This is useful in several scenarios, like when some VTScada servers are offline for updates, availability to a single access point is still assured.

Traffic Monitoring

Sending all traffic via the reverse proxy. Useful for inspection by a Web Application Firewall, or exposure to advanced network setups where all traffic must be sent via a proxy.

In Load Balancing, a reverse proxy is being used to route initial connections to one URL towards two or more VTScada servers. This is only required for the early phases of the Thin Client connection.

For example, if the single entry point URL is 'scada.example.com' with a pair of Thin Client servers, 'vtscada1.example.com' and 'vtscada2.example.com', the setup should be configured as follows:

  1. Both vtscada1.example.com and vtscada2.example.com should be present in the ClientDefine the Connection Addresses list of the Thin Client/Server Setup dialog.

  2. Configure the proxy to route requests made to scada.example.com to either vtscada1.example.com, or vtscada2.example.com with appropriate handling for unreachable servers.

  3. Inform VTScada of the external name used if the proxy does not rewrite the 'Host' header. This is done with Domain Aliases (CORS).

Clients enter scada.example.com when connecting, and the proxy routes the request to one of the available Thin Client servers. After authenticating, the Thin Client's redundancy takes over and establishes connections directly to the hosts listed on the Client Connection Address list- in the example, vtscada1.example.com and vtscada2.example.com. While the Thin Client session remains active, no further requests are sent through the proxy.

In Traffic Monitoring, where it is desirable for all Thin Client traffic to be routed through a reverse proxy for security or advanced configuration (including the in-session requests), the following applies.

In this scenario, as above, there are a pair of Thin Client servers, 'vtscada1.example.com,' 'vtscada2.example.com,' and a single entry point at 'scada.example.com.' The behavior is as follows:

  1. From the client's perspective on the network, scada.example.com, vtscada1.example.com, and vtscada2.example.com should all resolve to the proxy server.

  2. The proxy is configured to route requests made to scada.example.com to either vtscada1.example.com, or vtscada2.example.com with appropriate handling for unreachable servers.

  3. The proxy server ensures requests are to the specific VTScada server instances are only forwarded to that specific server. VTScada Thin Clients directly implement load balancing once a connection is established, further load balancing these requests at the proxy past an initial connection will interfere with this process.

If host names used by clients do not have their 'Host' header re-written by the proxy and are using different addresses than those specified on the Client Connection Addresses list, (i.e. the 'Host' header received by VTScada is absent from the Thin Client Connection Address list) inform VTScada of the external host used by the request. For more information, see Domain Aliases (CORS).

Where the host name on the Client Connection Address list cannot be resolved on the VTScada machine to itself, VTScada will not accept Thin Client connections. Make sure that any host names in this category are resolvable from the VTScada machine's perspective to itself rather than the proxy, either via split-horizon DNS, or by adding entries to the hosts file on the VTScada machine.