- By Jonathan Griffith
- The two main ways to implement secure remote access are with a hosted VPN and with a traditional VPN.
- A hosted VPN works well in most applications and is much simpler to implement and support.
- A traditional VPN may be necessary in applications with very high bandwidth requirements, but requires extensive IT involvement and support.
Advantages and design considerations for the two main methods of remote VPN access
By Jonathan Griffith
Remote access to local programmable logic controllers (PLCs), human machine interfaces (HMIs), and other automation system components is becoming a requirement for many machine builders, plants, and facilities. Although many industrial networks were previously configured with a router without a virtual private network (VPN), new installations should not do this because of the security risks.
Although a VPN is a key element in a defense-in-depth strategy, implementing remote and secure connectivity to local components presents technical, cost, and resource allocation challenges. The two options presented in this article address these issues in different ways. Each approach has advantages and design considerations (summarized in the table). Option 1 is a hosted VPN, and option 2 is a traditional VPN.
The decision to use a hosted VPN versus a traditional VPN hinges on four primary factors:
- Will all of my remote access needs fall under similar information technology (IT) conditions, with each site able to use the same router configurations?
- Is IT expertise available to support a traditional VPN?
- Is the IT team willing to support the traditional VPN?
- Will high bandwidth be required?
As shown in the decision tree (figure 1), if the answer to any of these questions is "no," then the hosted VPN solution is likely the best option. When the answers to these four questions are "yes," then a traditional VPN may be preferred.
Option 1: Hosted VPN
Hosted VPNs provide a secure connection with simple setup and network configuration. Typical hosted VPN solutions include a VPN router, a hosted VPN server, a VPN client, and connected automation system components (figure 2).
A secure connection between the VPN client and the router is established after the router and VPN client each make a connection to the cloud-hosted VPN server. The router makes this connection immediately upon startup, but the VPN client only connects upon a verified request from a remote user. Once both connections have been made, all data passing through this VPN tunnel is secure.
Most hosted VPN solutions have a free monthly bandwidth allocation for basic operation, and then offer a premium plan for additional bandwidth. Normal troubleshooting and programming needs usually fall under the data requirements in the free plan, but extensive data monitoring or video surveillance may require additional bandwidth, depending on the amount of data transmitted over the VPN.
The router initiates communication to the server via an outbound connection through standard ports that are typically open, such as HTTPS. This usually requires no changes to the corporate IT firewall, and satisfies IT security concerns. By contrast, traditional VPNs require inbound firewall ports to be opened, which requires IT involvement and oversight.
Another advantage to a hosted VPN is the router configuration is extremely simple. Because the secure router (figure 3) is connected to a predefined cloud server, the router comes preconfigured, requiring only the most basic network information from the user. The router's internal firewall comes with a default setup to keep the plant floor network separate from the corporate network.
The platform and hosted servers do the complicated VPN networking behind the scenes, so non-IT staff can easily configure it. Staff members only need to know the IP addresses of the automation components connected to the local area network, and whether their ISP or corporate-wide area network router (not the hosted VPN router) provides IP addresses dynamically or statically.
In addition to a wired local area network (LAN) option, the hosted VPN should have Wi-Fi and 4G LTE connectivity options. Wi-Fi provides a simple access point or client connection, and allows plant personnel to access the router's LAN network wirelessly, rather than opening the panel to access the physical LAN connection ports. With 4G LTE connectivity, users have access from remote locations without Internet access or locations that will not provide access to the corporate network.
This approach has a very low security risk, because the client connection to the cloud server uses the proven encryption standard SSL/TLS, along with TLS 1.2. The required TLS key exchange, crucial for security, is done in accordance with the industry standard 2048-bit RSA with SHA-256. In addition, some vendors have advanced user management, event logging, and two-factor authentication-which requires a second time-based password generated at login-for an extra level of security at the user access level.
Hosted VPN design considerations
Those considering this solution must have a high level of trust in the hosted VPN vendor, as it will be responsible for securely storing data and making it available to only those who need it. Monthly costs incurred for high data bandwidth usage must also be considered\, particularly as those costs are zero for a traditional VPN solution.
The hosted VPN solution does not require an IT team for support, because it is simple to implement and maintain, and most companies accept it as secure. Those companies that do not accept a hosted VPN solution for security reasons would likely not accept a traditional VPN either because of its required firewall changes.
The simplicity of this solution comes at the cost of limiting some of the advanced routing features that may be required for sophisticated networks, such as machine-to-machine networking, advanced network address translation (NAT) configuration, and access control lists. However, for most users these advanced features are not required.
Other design considerations depend on specific features offered by the router vendor. Including these key features addresses the issues, while excluding them may present problems. These key features include data logging, widgets for configuring remote access screens, a Web-based platform for router configuration, and a digital input for enabling or disabling remote access. The traditional VPN solution requires a third-party HMI, either PC based or embedded (figure 4)\, to provide data logging and widgets for configuring remote access screens.
Data logging provides collection, storage, and display of data via a cloud-based platform. Users can store and access a nearly unlimited amount of data, while only paying for the capacity required. Users can start with a small amount of storage, and scale up as needed. Cloud-based data logging typically requires an additional license or subscription from the router vendor to collect and store the data in the cloud, and this cost must be considered, particularly since the traditional VPN option does not have this expense.
Some cloud-based data storage and monitoring solutions allow users to configure dashboards using widgets for remote access viewing on their PC or mobile device. Alerts and notifications can be configured to inform users when parameters fall outside a predefined range. If this feature is not provided, designing remote access viewing screens can be cumbersome.
A Web-based platform lets users quickly and easily configure the VPN router, often as simply as registering an account, configuring and downloading router settings, and installing a secure client on a PC. The main advantage of a Web-based platform over a PC-based configuration is that platform updates can be made without the user having to reinstall a new version. This is particularly useful when new features are added regularly.
An important safety feature for the VPN router is a digital input for a switch to locally enable or disable communications, preventing remote control of a machine during maintenance periods. If this option is not provided, it should be added, which will add cost and design time.
Option 2: Traditional VPN
This option requires a local VPN router to connect through the Internet with a secure VPN tunnel to a second remote VPN router or software client (figure 5). Once connected, remote users can access automation components connected to the local router through the VPN tunnel.
Unlike option 1, there is no cloud server between the two devices with either method of connection: VPN router to VPN router, or VPN router to VPN software client. This option is preferred when large amounts of data need to be continuously exchanged between the local and remote sites\, as to view local video remotely.
This solution is widely used, and it was the only method of secure two-way access before the introduction of cloud-based remote access solutions. It can be complex and costly in terms of internal resources required for support, both at the local and the remote sites.
Traditional VPN design considerations
The main design consideration for this option is the capability and willingness of an IT team to support this solution at both the local and remote sites for each installation. For example, an original equipment manufacturer (OEM) machine builder must consider every customer site, and make sure all of its customers are willing to provide IT support. If not, the OEM will have to customize its remote access solution for each customer.
This solution is often more expensive up front than a hosted VPN because of increased hardware costs and the IT resources required to configure the connection. Some companies have a dedicated IT staff to provide this support\, but many smaller companies do not. Ongoing external costs are lower, because there are no monthly cloud service fees, but internal costs are higher due to the need for IT support.
IT must open an inbound VPN port on the firewall. This provides full remote control and monitoring, as it effectively creates one network joining local and remote users, but also presents a security concern. This port must be protected from unwanted access at all times. Ongoing security vigilance is required to ensure the router and VPN protocols remain up to date, and other technical considerations must also be addressed, including:
- Firewall configuration may be challenging.
- Subnet conflicts must be addressed across sites with similar network designs.
- User management and access must be well controlled.
- Event logging is not usually implemented and must be added if needed.
- Security certificates must be created and managed.
- Advanced networking knowledge is required.
- Client configuration is needed for each connection point.
Despite some drawbacks, this method is the preferred VPN solution if the IT staff is available and willing to make firewall changes, if the application requires high data bandwidth, or if the company does not want to rely on a hosting vendor.
Application example: Traditional VPN
Consider two types of OEM machine builders. The first OEM sells very large and complex printing presses with thousands of automation system I/O points, and its customers require the OEM to support the machine, including uptime and throughput guarantees. The OEM needs to remotely monitor and support its presses worldwide to make sure it meets its guarantees to customers. The OEM has considerable IT expertise and is capable of implementing a traditional VPN, and each of the customers is willing to allow the required firewall modifications.
Each press also has multiple video cameras installed for remote viewing, a necessity for solving some of the more complex troubleshooting issues. Each printing press has a full-featured PC-based HMI installed for local viewing and data storage, with high-speed remote access to the HMI and its stored data required at all times. Therefore, large amounts of operating data must be continuously transmitted to the remote corporate control center.
A traditional VPN is the right solution in this application, because of the significant amount of data exchange required, which could be cost prohibitive for a hosted VPN, and because the right IT resources are available to support the solution at the control center and at each site.
Application example: Hosted VPN
The second OEM sells a machine that does not require video monitoring. Local operator interface is provided by an embedded HMI with limited data logging and storage functionality. The OEM machine builder needs two kinds of remote access. The first is VPN access to remotely troubleshoot, debug, and program the machine’s PLC and HMI. Second, the OEM and its customers want to monitor the machine’s most important operating parameters on dashboard screens from remote devices, such as smartphones and tablets.
The OEM machine builder does not have an IT department, just one part-time person who set up the internal network. The automation staff consists of one or two control systems professionals who are experts when it comes to programming PLCs and HMIs to automate their machines, but who are not very familiar with IT, VPN, and router technology. Most of the OEM’s customers are not willing or able to reconfigure their firewalls, eliminating the traditional VPN option. In this case, a hosted VPN is the best choice, because it will satisfy all of the OEM’s and its customers’ requirements, and it can be implemented without IT staff.
Data logging is provided in the cloud, so the local HMI’s limited data storage capability is not an issue. The machine builder can use widgets to create dashboard screens that many different users can view on remote devices. When full control and monitoring is required, it can be done by installing a lightweight software client on a PC, which can connect to the cloud from any location worldwide.
When designing a remote access solution using VPNs, there are many considerations influencing final implementation: initial and sustaining costs, technical expertise during installation and ongoing operation, site control, security risks, and data storage capabilities.
Using the information in this article, end users can evaluate each option based on their needs, budget, and internal expertise—and then select the best choice for their applications.
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.