Making Remote Modbus Connectivity Reliable and Transparent
The Challenge
Connecting remote PLCs to a central monitoring environment sounds straightforward: create a VPN, route the remote networks, and let the applications communicate with the PLCs directly. That was our initial approach.
From a conventional networking perspective, everything looked correct. The networks were reachable, routing was working, and the applications could establish TCP connections.
But the PLCs told a different story. We started experiencing dropped connections and unreliable Modbus communication.
The challenge wasn't simply to make the networks reachable. The challenge was to make the communication reliable for the industrial devices themselves.
The First Approach: Direct WireGuard Connectivity
Our initial architecture used a direct WireGuard-based connection between the central environment and the remote networks. The concept was simple: Application → WireGuard → remote router → PLC.
This is a perfectly reasonable approach for many networking scenarios. However, in our environment, the resulting traffic behaviour caused problems with the PLC connections.
The important discovery was that the problem wasn't limited to one particular SCADA application. Other services using Modbus TCP were affected as well. This told us we weren't dealing with an application-specific problem — we were dealing with the way the Modbus connections were being transported across the network.
When "Network Connectivity" Isn't Enough
One of the most useful lessons from the project was that traditional connectivity tests aren't always enough in industrial environments. We could verify:
- VPN connectivity;
- routing;
- reachability;
- established TCP connections.
Yet the actual industrial communication could still become unstable. This distinction is important: a network connection being technically possible does not necessarily mean that an industrial protocol will behave reliably across it.
Instead of continuing to modify the direct VPN architecture, we stepped back and looked at the infrastructure already available at the remote sites.
Reusing the Infrastructure Already in Place
Each remote location already had a MikroTik router responsible for the local network. Rather than replacing that architecture, we decided to use the existing routers as a controlled communication point between the central environment and the PLC networks.
This led us away from direct routed Modbus traffic. Instead, we established an encrypted SSH transport between the central Linux infrastructure and the remote routers: central environment → encrypted tunnel → remote router → local TCP connection → PLC.
The important difference was that the actual connection to the PLC was initiated from the remote network. The VPN was effectively carrying the secure transport connection rather than exposing the Modbus session directly across the VPN.
The Second Challenge: Keeping Everything Transparent
There was another requirement: we didn't want to redesign the applications around the new architecture. Existing applications already knew the PLCs by their normal network addresses. Changing every application to use special tunnel addresses or local proxy ports would have created another operational problem.
So we designed the solution so that the tunnelling mechanism would be transparent to the applications. The application continues to communicate with the PLC using its normal address. Behind the scenes, the central Linux firewall redirects that connection into the appropriate secure tunnel: application → normal PLC address → central firewall → transparent redirection → encrypted tunnel → remote router → PLC.
The application doesn't need to know that the tunnel exists. That turned out to be one of the most important characteristics of the final architecture.
The Firewall Became Part of the Solution
The firewall wasn't only being used for security. It became the mechanism that allowed us to separate the logical connection from the physical transport path.
From the application's perspective: Application → PLC.
Behind the scenes: application → firewall translation → encrypted tunnel → remote router → PLC.
This allowed us to introduce the new transport mechanism without redesigning the applications using Modbus. It also meant that different services could continue operating normally without being individually configured for the tunnels.
An Important Troubleshooting Discovery
During the implementation we encountered another issue. The encrypted tunnel could be established successfully, but the PLC communication still didn't work.
The investigation eventually led us to the remote router's SSH configuration: SSH forwarding was disabled by default. Once the appropriate forwarding functionality was enabled, the router could establish the required connection toward the PLC.
This was a good reminder that troubleshooting these systems requires looking at every layer independently: VPN → SSH → Firewall → remote router → TCP → Modbus → PLC.
Testing each layer separately made it possible to identify where the communication was actually stopping.
Making the Solution Resilient
- A tunnel that works only while an administrator is watching it isn't a production solution — the connections needed to be persistent and self-recovering.
- We implemented the tunnels as managed services with automatic reconnection.
- Resilience against temporary Internet outages.
- Resilience against VPN interruptions and SSH disconnections.
- Resilience against remote router restarts and central server restarts.
- The result: a connectivity layer that could operate continuously without manual intervention.
Why We Didn't Simply Keep the Direct VPN
The direct VPN approach was technically attractive because it was simple from a routing perspective. However, our objective wasn't to build the most elegant theoretical network — our objective was to provide stable industrial communication.
The direct approach produced unreliable behaviour with the PLCs. The alternative architecture allowed us to:
- reuse the existing remote routers;
- isolate the Modbus connections;
- control how connections reached the PLCs;
- keep applications unchanged;
- centrally manage the connectivity;
- automatically recover interrupted tunnels.
That combination made the SSH-based approach a better fit for our particular environment.
The Final Architecture
The resulting architecture can be simplified to: applications connect using the normal PLC address → central firewall performs transparent redirection → encrypted tunnel → existing router → PLC.
The complexity is deliberately kept underneath the application layer. For the software using Modbus, the PLC still looks like the same PLC.
What We Learned
1. Industrial networking is not always solved by adding more routing.
A solution that looks perfect from a network diagram can still produce undesirable behaviour when real industrial devices are involved.
2. The successful approach came from combining several relatively simple technologies.
Encrypted connectivity, existing edge routers, controlled SSH forwarding, firewall-based transparent redirection, and automatic tunnel recovery.
3. None of these components alone was particularly complicated.
The engineering challenge was combining them in a way that solved the actual problem without forcing changes onto the applications or PLCs.
4. The final solution wasn't about hiding complexity for the sake of it.
It was about putting that complexity where it could be controlled — a controlled connectivity layer underneath the applications and PLCs, instead of asking each of them to understand the VPN architecture.
5. That separation is what ultimately made the architecture reliable enough for production use.
Applications see PLCs. The network sees encrypted tunnels. The remote routers handle the local connection. And the PLCs see a predictable connection from their local network.
Is Your Remote Industrial Connectivity Unreliable?
If your PLC or SCADA connectivity behaves unpredictably despite a "healthy" network, the problem is likely in how the protocol is being transported — not just in routing. We'll review your architecture at no cost.
