VTScada and VPNs

Virtual Private Networks (VPNs) are commonly used to connect the networks of remote sites together and to provide remote access for individual computers. VPNs have largely replaced RAS (Remote Access Server) for remote connections.

 

A VPN is established between either two network appliances (in the case of joining two otherwise remote networks together) or between a remote computer (such as an engineer's laptop) and a network appliance (VPN gateway).

 

In the case of two networks being joined together, this usually appears to VTScada as an additional subnet on the LAN. If there are two or more VTScada servers communicating across the VPN, they must have a route to each other. VTScada relies on name resolution to determine the set of IP addresses that may provide a connection to a remote VTScada server and will attempt to connect to each of those IP addresses that there is a route for.

Try to ensure that each VTScada server that must communicate using a VPN can successfully establish a connection to other remote VTScada servers. In other words, that not only can server A initiate and establish a connection with server B, but server B can also initiate and establish a connection with server A. This reduces the connection delay between peer servers and provides some redundancy in the case that one end cannot initiate a connection to the other.

We advise against configuring routing such that a connection attempt will be tried to a gateway that allows the connection to open, only to close it off quickly when the gateway discovers it has no route to the endpoint. Currently, VTScada cannot distinguish between this and a transient connection failure and so will continually retry the connection attempt in the hope that it will eventually work. VTScada will always try and maintain connections to its peers in order to keep data distributed and up-to-date.

 

In the case of an individual VTScada workstation requiring remote access using a VPN, the VPN may be established using HTTPS or other technology, such as IPSec. The VTScada workstation sees this as a separate network adapter with a route that allows connection to a VTScada server on the remote network.

VTScada will automatically detect the addition / change to the network adapter. Once again, it relies on name resolution to determine the IP addresses to which the remote server(s) can connect.

Often the IP address supplied to the workstation by the VPN gateway will be dynamically assigned from a pool of IP addresses (DHCP). If the IP address assigned to the workstation has been used for a different VTScada workstation recently then DNS records should be updated as soon as possible to allow the server to initiate a connection to the workstation for optimal connection maintenance.

It is strongly recommended that DNS be used for name resolution. DNS allows multiple IP addresses to be obtained for a given server name and will be updated soon after changes to the IP mappings are made, either by clients, a DHCP server or manually.

 

A local hosts file may be used, or IP addresses (rather than server names) may be specified in the application configuration. Hosts files are limited by only being able to identify one IP address per endpoint. Hosts files and application configured IP addresses carry a higher maintenance overhead should IP address assignments change and do not follow dynamic changes to IP address assignments.

Network Address Translation (NAT) routers are not compatible with VTScada. Do not use.
Each thick-client server must have a unique IP address. A NAT device will cause the same IP address to be assigned to more than one server. VTScada cannot operate in this environment.
As shown in the following illustration, a NAT device will cause Server B and Server C both appear to Server A as if they were on the same IP address.