Secomea’s “Relay VPN” and traditional VPN basically have the same purpose. They allow two IP enabled devices to communicate securely with each other remotely over the Internet, just as if the devices were connected on the same physical network. Although traditional VPN is widely used and suits the general purpose of interconnecting remote networks quite well, it has some serious drawbacks for remote device monitoring and management. Secomea’s first generation was also based on traditional VPN but with significant optimization on the ease of creating tunnels. The current 3rd generation solution has however evolved to an Internet-based technology that specifically addresses the security and usability requirements of linking service engineers with industrial equipment.
1. Subnet conflicts:
– Networks connected via traditional VPN must not use the same local subnet. But a Machine builder / System Integrator managing hundreds of customer installations are bound to run into lots of locations using the same subnet addresses. Asking the customers to change their addressing schemes is rarely an option, and juggling with NAT rules to deal with the existing addressing schemes can quite simply be a nightmare.
– With the Secomea Relay VPN, all sites could have the same subnet, and all equipment has the same IP address. The engineer and the remote device are simply linked to each other IP wise at connect.
2. Pre-configured connections are required:
– The connection between traditional VPN peers cannot be established dynamically upon request, but have to be configured beforehand. This needs the involvement of IT personnel and takes time – every time.
– Once the engineer with the LinkManager Client has an account on the GateManager represented by the user’s personal security certificate, the GateManager administrator can by point-and-click associate the account with exactly the site or group of equipment the technician should have access to, and it is immediately updated in the list of sites available in the LinkManager client.
3. Advanced routing challenges:
– Connecting two remote networks with traditional VPN via a central VPN concentrator requires configuration and management of advanced forwarding routing rules. Additionally Routing equipment usually needs to be able to support NAT-T and UDP encapsulation.
– Relay VPN does not use routing and subsequently, no NAT rules are required. IP addresses are simply linked via a central proxy server. Traditional VPN is suitable for one-to-one or many-to-one connections, but not one-to-many (one engineer to many sites), or many-to-many (many engineers to many sites). The Secomea Remote Access solution easily administers thousands of engineers needing access to thousands of sites, including management of individual access rights, and even limits access to specific types of equipment, or specific protocols/services of equipment.
4. Firewall opening challenges:
– Traditional IPSec based VPN require special ports and protocol open in firewalls to communicate through.
– All Relay VPN connections from SiteManagers and LinkManagers are established inside out, and only standard Web ports are used (such as 443). All these encrypted connections are terminated at the central Internet-based GateManager server, and through these encrypted connections, the linking between engineers and devices is dynamically established.
5. Firewall blocking challenges:
– VPN routes everything and not just the protocols you need unless efforts are put into creating and managing a number of firewall rules also.
– The device agents defined on the SiteManager are automatically limited to only allowing access to the ports or services defined for the agent type; for instance, when defining a Beckhoff PLC agent on the SiteManager, the ports that are opened are TCP port 987, 5120, 48897-48899 and UDP 48898-48899. Only these are activated when a LinkManager connects to the agent representing the Beckhoff PLC.
6. Certificate management:
– A good VPN solution is usually based on x.509 certificates that are exchanged or signed by a Certificate Authority (CA). This adds overhead and makes it tedious to set up individual connections.
– GateManager acts as the CA authority for both SiteManagers and LinkManager clients. The Client access is secured by a two-factor system (certificate and password), known from web banking solutions. But the Secomea solution is extended with the possibility for using temporary SMS pin codes as login authentication.
7. Activity Logging:
– The principle of traditional VPN is to connect two networks and have everything accessible between the two peers. Therefore logging is at best only done when establishing the connection, but once connected nothing is logged.
– The GateManager server will not only centrally log who made the connection and to what, but also when the connection was established, and what services were accessed. The log is kept centrally on the GateManager and cannot be deleted by administrators, and can, therefore, act as evidence in case of legal disputes.
8. Managing the ”Concentrator”
– Typical IPSec based VPN solutions require an IT administered concentrator since it requires networking knowledge. Also, individual concentrators must typically be installed at each service provider, in order to avoid very complex triangular routing and firewall setups. SSL VPN based solutions that overcome some of the issues of IPSec based VPNs, but advanced routing and firewall configuration rules are not services exposed to the customers on hosted solutions.
– The ”concentrator” for the Secomea Remote Access solution is a central service in form of the GateManager server, where each service provider gets an isolated account. Here the administrator issues account certificates, organizes his equipment and users in domain structures and dynamically controls what equipment and which sites each service engineer should have access to. There is no networking or other IT skill sets required.
