SDA Connectivity Service

Overview

The SDA Connectivity Service relies on the SDA Glue, the application for Gateways, available for Linux and Windows hosts. The service is powered by SoftEther VPN, which supports OpenVPN on Windows clients, establishing a secure TCP tunnel between a network interface in the Gateway and the SDA cloud services, such as IDEaaS, Backup and Deployment VMs. It also combines OS native firewalls, Linux iptables and Windows Filtering Platform (WFP), with a NAT table to bridge vendor specific software, like Siemens TIA Portal and Rockwell Studio 500, directly with the device in the manufacturing control layer.

Key Points

Managing industrial assets with SDA is powered by a comprehensive and secure industrial connectivity solution that bridges the gap between manufacturing environments and cloud-based services. By leveraging proven technologies and implementing robust security measures, the service delivers enterprise-grade connectivity tailored specifically for industrial automation and control systems.

Industrial-Grade Security: The integration with AWS IoT Core provides secure TLS connections with fine-grained access control policies. This follows industrial IoT security best practices, allowing administrators to restrict access based on device properties and context.

Proven VPN Foundation: The service utilizes SoftEther VPN, which provides AES 256-bit and RSA 4096-bit encryption with high-speed throughput performance and low memory and CPU usage, ensuring that data in transit remains secure from eavesdropping and unauthorised access, ideal for industrial applications where security and performance are critic.

Zero-Trust Network Access: The service eliminates the need for traditional static VPNs by establishing connections on-demand. This Point-to-Point architecture ensures that users can only access specifically authorised devices, not entire network segments, significantly reducing the attack surface.

Factory-Friendly Design: All connections are initiated from the Gateway outward, requiring no inbound firewall rules in the manufacturing environment. This design respects existing industrial security architectures while providing secure remote access capabilities.

Architecture

The peers in a virtual network are called Nodes, that are the main components in the Connectivity Service. Each connection is built from the interaction of a chain of Nodes, each one with a specific role.

Devices: industrial assets usually located in the manufacturing secure network that can be accessed by their IP address, e.g. PLCs, HMIs and Robots. Devices are declared in the SDA Console for each Tenant, and user access is managed by Role-Based Access Control. Connectivity requires that every Device is linked with at least one network Gateway.

Gateways: network hosts with secure access to the Internet and to the Devices managed in the SDA Console. They are usually IPCs, VMs, Containers, and even Raspberry Pis, located in a firewall zone that requires specific rules to access the SDA Cloud resources, like Tenant Servers. Every Gateway runs the SDA Glue, which is a OS service listening to connection requests and providing telemetry data.

Tenant Servers: bastion hosts running in a secure SDA Cloud environment, dedicated for every Tenant, that bridge the Gateway’s network interface with an SDA Service VM, or with another Gateway. These Servers guarantee the required filtering policies to ensure Point-to-Point connection only, like from IDEaaS to a specific PLC, and not to other unwanted devices in the same network as the Gateway. They also authenticate the access from Gateways based on a credentials rotation policy for every connection.

Service VMs: run the applications needed by SDA Services, like IDEaaS, Backup and Deployment Pipelines. These VMs rely on the Connectivity Service to access Devices on the network layer, by their IP address, which is essential for industrial applications.

Cloud

Instead of using traditional static VPNs, the SDA Connectivity Service establishes connections to industrial assets upon requests, that are forwarded to a chain of Nodes that operates together to provide Point-to-Point network access between SDA Services and Devices.

For the manufacturing network, all connections are initiated from the Gateway, requiring no inbound connection rules in the factory. To achieve that, Nodes are constantly listening on an IoT message broker for incoming requests, which is powered by AWS IoT Core.

This architecture enables users to interact with assets in the factory from any place with Internet, from any computer, depending only on browser.

Network

The Gateway is an edge device sitting between a manufacturing control layer and the Internet, which provides SDA services with controlled access to assets defined in the Console. Therefore, it is very important to consolidate an architecture that securely bridges the SDA Cloud with the local infrastructure. We recommend one of the two proposed setups for the Gateway, as follows.

Gateway in LAN

This is the most common approach, in which we place the Gateway next to the PLCs that are onboarded onto the SDA platform. Here, a firewall strictly controls the outbounds from the Gateway to the Internet.

The Gateway has access to the subnet where it is located, but a firewall may be provisioned in the network’s router as an Access Control Layer (ACL). Is is also common to use a Gateway device with two network interfaces: one pointing to the DMZ, and a private one in the control layer. This architecture allows repeated IP zones, e.g., both with the subnet 10.0.0.0/24.

Gateway in DMZ

This approach is much used when the Gateways runs in a dedicated Virtual Machine, somewhere in the server infrastructure. The IT team will provide special routes between the VM and the target PLCs in the control layer, and firewalls will probably exist on both acesses to the Internet and to OT.

A Network Address Translation (NAT) may also exist when going downstream to the PLCs. However, this requires attention: some PLC vendor-specific software may not be compatible with addressing the PLC by an IP alias, they might require accessing the IP which is explicitly configured in the project.

In this case, every PLC in the manufacturing unit must have a unique IP address, otherwise there can be collisions. Also, depending on the network infrastructure, Layer 2 access from Gateways to PLC may not work, which is an up-coming feature for the integration of Real-Time Industrial Networks in the SDA services.

Software

The SDA Glue is an application that runs as an OS service, ensuring high availability of the Gateway with automated startup and restart in case of errors. In order to establish the network tunnels by managing network resources like interfaces, routes and firewall rules, it requires elevation as a system user.

Auto-Updates are enabled by default. The Glue service will read the latest stable version from repository.eu1.sdacosole.io and apply the update once there are no active connections. The updating mechanism downloads the new application binary, replaces it with the old one, and restarts the service.

AWS IoT Core will be connected during login, which uses the endpoint iot.eu1.sdaconsole.io. Once connected, the Glue service will be constantly listening to requests from the SDA Cloud, and publishing telemetry data, like the status of the Devices that are associated with the Gateway. The IoT authentication is protected by a short ID and a one-time password that can be retrieved from the SDA Console. The connection to IoT is also secured by a secret key in the application binary. The connection to IoT can be configured to be established via MQTT SSL or WebSocket Secure, both on port 443.

The network mechanisms are different for Linux and Windows. Therefore, they are described separately.

Linux

SDA Glue on Linux relies on the SoftEther VPN Client, which is open-source (Apache License 2.0), installed from SDA’s mirror on repository.eu1.sdaconsole.io during Glue installation.

For each connection, Glue uses the SoftEther Client to create a NIC network interface, and connect it to the Tenant Server. It will also use Linux IP tools to assign an IP address to that interface and create the necessary routes between the Service VM and the target Device.

Internal firewall rules and NAT translation are created in iptables, which does not allow incoming network packets to the Gateway, but only forwarding packets to the target Device.

📚 Linux Resource Management in Connections

To understand how the Linux Gateway bridges cloud services with factory devices, let's walk through a concrete example with specific IP addresses that illustrate the complete flow.

Consider a factory network where a target Device (such as a PLC) has the local IP address 10.0.0.5, and the Gateway sits on the same network with IP 10.0.0.2. In the SDA Cloud, a Service VM needs to connect to this Device and will be assigned the VPN IP 100.112.20.3, while the Gateway's VPN interface will receive 100.112.10.6.

Establishing the Tunnel

When a connection request arrives, both the Gateway and the Service VM spring into action. The Gateway creates a new virtual network interface called vpn_iface and assigns it the address 100.112.10.6. Simultaneously, the Service VM in the cloud creates its own VPN interface with the IP 100.112.20.3. Both endpoints then connect to the Tenant Server, establishing a secure encrypted tunnel between them.

Factory Side:              Cloud Side:
Gateway                    Service VM
├─ Local: 10.0.0.2        ├─ VPN: 100.112.20.3
└─ VPN: 100.112.10.6      └─ Target: 10.0.0.5 (via Gateway)
Device
└─ Local: 10.0.0.5

At this point, the tunnel exists, but packets still don't know where to go. The Gateway needs to teach the system how to route traffic between these two worlds.

Building the Routes

The Gateway adds a routing rule that creates the connection between the VPN network and the factory floor:

ip route add 100.112.20.3 via 100.112.10.6 dev vpn_iface

This route tells the system a crucial piece of information: when the Device at 10.0.0.5 sends response packets, they should be forwarded through vpn_iface to reach the Service VM at 100.112.20.3. Without this route, the Gateway wouldn't know how to send the Device's replies back to the cloud.

But routing alone isn't enough. The Gateway's firewall would still block this traffic by default. To enable the connection, the Gateway must explicitly permit bidirectional packet forwarding between the VM and the Device:

iptables -A GLUE_FORWARD -s 100.112.20.3 -d 10.0.0.5 -j ACCEPT
iptables -A GLUE_FORWARD -s 10.0.0.5 -d 100.112.20.3 -j ACCEPT

These rules open a controlled pathway, allowing packets to flow from the Service VM to the Device and back again, while still maintaining the Gateway's security posture for all other traffic. Also, note that Glue uses it's own chains in iptables, not to cause conflicts with the other rules.

NAT Translation

The Device in the factory expects to communicate with local IP addresses — it has no knowledge of the cloud network at 100.112.20.3 and wouldn't know how to respond to packets from that address. The Gateway solves this by masquerading the Service VM's packets:

iptables -t nat -A GLUE_POSTROUTING -s 100.112.20.3 -d 10.0.0.5 -j MASQUERADE

With this NAT rule in place, when a packet arrives from the Service VM destined for the Device, the Gateway rewrites its source address from 100.112.20.3 to 10.0.0.2. From the Device's perspective, it appears to be communicating directly with the Gateway itself — a familiar, trusted address on its local network. When the Device sends its reply to 10.0.0.2, the Gateway performs the reverse translation, changing the destination address back to 100.112.20.3 so the packet reaches the Service VM through the VPN tunnel.

Through this orchestration of VPN tunneling, routing, firewall rules, and NAT translation, the Gateway creates a transparent point-to-point connection. The Device never sees the cloud infrastructure — it simply communicates with what appears to be the Gateway on its local network at 10.0.0.2. Meanwhile, the Service VM gains direct network-layer access to the Device by its IP address 10.0.0.5, enabling industrial applications like TIA Portal or Studio 5000 to function as if they were running on the local factory network itself.

Windows

SDA Glue on Windows does not support the embedded usage of SoftEther VPN Client, therefore it uses the OpenVPN Community Open-Source Client (GPL license version 2), installed from the SDA’s mirror on repository.eu1.sdaconsole.io during Glue installation.

For each connection, Glue uses OpenVPN TAP driver to create a network interface, and connect it to the Tenant Server using certificate-based authentication. It uses Windows native API to assign an IP to the interface and create the necessary routes between the Service VM and the target Device.

Glue also uses Windows Filtering Platform (WFP) to create dedicated layers and firewall rules. However, it depends on WinNAT, or NetNat, to declare the address translation between the Service VM and the Device, which may not be enabled by default.

Summary

The SDA Connectivity Service delivers a mature, secure, and scalable solution for industrial connectivity challenges. By combining proven open-source technologies like SoftEther VPN with enterprise-grade cloud infrastructure from AWS IoT Core, the service provides the reliability and security that industrial operations require while offering the flexibility and ease of use that modern engineering teams expect.

The service's architecture respects industrial security principles while enabling the digital transformation initiatives that drive operational efficiency, remote collaboration, and data-driven decision making. For organisations seeking to securely connect their industrial assets to cloud services without compromising network security or operational reliability, the SDA Connectivity Service provides a comprehensive, production-ready solution.