A VPS can act as a VPN concentrator: a central, always-on hub that every industrial site connects to over WireGuard, letting head office reach PLCs and SCADA systems at any site through one secure, encrypted tunnel rather than exposing industrial protocols directly to the internet or relying on each site’s own variable internet connection for inbound access.
The problem this solves
Industrial sites are often geographically scattered, on connections you don’t fully control (cellular routers, site broadband of varying quality), running protocols like Modbus and DNP3 that were never designed with security in mind. The traditional answer, port forwarding directly to a PLC, exposes a protocol with no authentication and no encryption straight to the internet, which is a genuinely common cause of real industrial security incidents, not a theoretical risk. The alternative, a site-to-site VPN per location, manually configured, becomes unmanageable past a handful of sites.
A VPS as a central VPN hub solves both problems: each site makes an outbound connection to the hub (so no inbound ports need opening at the site itself, working around restrictive site firewalls and CGNAT cellular connections), and once connected, every site’s industrial network is reachable from head office through one encrypted tunnel, never directly exposed.
How it fits together
Why WireGuard specifically
WireGuard has become the practical default for this pattern over older options like OpenVPN or IPsec, for reasons that matter specifically here: it’s dramatically simpler to configure (a WireGuard config file is a handful of lines, versus pages of OpenVPN certificate management), it’s built into the Linux kernel directly rather than running as a userspace process, and it handles connection drops and IP changes gracefully, which matters a lot for sites on cellular or variable-quality connections.
| VPN type | Setup complexity | Performance | Best for this use case |
|---|---|---|---|
| WireGuard | Low | Excellent, low overhead | Yes, the recommended default |
| OpenVPN | High, certificate-heavy | Good, more overhead than WireGuard | Still solid if existing infrastructure already uses it |
| IPsec | High | Good | More common in enterprise router-to-router setups than this use case |
Setting up the VPS as the hub
sudo apt install wireguard
wg genkey | tee privatekey | wg pubkey > publickeyThe hub’s config (/etc/wireguard/wg0.conf) defines itself and lists each site as a peer:
[Interface]
PrivateKey = <hub-private-key>
Address = 10.10.0.1/24
ListenPort = 51820
[Peer]
# Site A
PublicKey = <site-a-public-key>
AllowedIPs = 10.10.0.2/32, 192.168.10.0/24
[Peer]
# Site B
PublicKey = <site-b-public-key>
AllowedIPs = 10.10.0.3/32, 192.168.20.0/24The AllowedIPs line for each peer is doing two jobs: it’s both the tunnel address for that site, and the route telling the hub which local network behind that site’s router it should forward traffic to. This is what lets head office reach a PLC at 192.168.10.50, for example, by routing through the tunnel rather than the open internet.
Enable IP forwarding on the hub so it can actually route traffic between connected sites and head office, not just terminate the tunnels:
echo 'net.ipv4.ip_forward=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -pEach site’s configuration
The router or gateway device at each site runs the mirror image: its own WireGuard peer config pointing back at the hub’s public IP, with AllowedIPs set to whatever it needs to reach centrally (often just 10.10.0.0/24, the whole VPN subnet). Because the site initiates the connection outbound, this works behind CGNAT or restrictive cellular firewalls without any special configuration on the carrier side, which is often the actual reason this pattern gets chosen over a traditional site-to-site setup.
Why this is safer than direct exposure
Modbus and DNP3 were both designed assuming a trusted, isolated network, not the open internet. Modbus TCP (port 502) has no authentication or encryption at the protocol level at all: anything that can complete a TCP connection to port 502 can issue commands, with no username or password involved. Routing access through a VPN tunnel instead means the industrial protocol itself never touches the public internet; only WireGuard’s own encrypted, authenticated tunnel does, and the industrial devices stay on a private network reachable only through it.
Sizing for this role
A VPS acting purely as a VPN concentrator is lightweight on CPU and RAM (WireGuard’s kernel-level implementation is efficient), but worth sizing bandwidth generously if you’re aggregating many sites or passing meaningful data volumes through, and worth choosing a provider with solid network reliability and a datacentre location with good routing to your sites, since the VPS is now a single point every site depends on for remote access.
LumaDock‘s standard VPS tier handles this role comfortably for most multi-site setups; see VPS for IoT: The Complete Guide for general sizing guidance. For a deeper look at VPN-specific connectivity considerations across multiple sites, iotvpn.co.uk covers this in more depth.
Troubleshooting common problems
A site’s tunnel shows as connected but traffic doesn’t pass through. Almost always an AllowedIPs misconfiguration, the most common WireGuard mistake. Confirm the hub’s peer entry for that site includes the site’s actual local subnet (not just its tunnel address), and confirm IP forwarding is genuinely enabled on the hub with sysctl net.ipv4.ip_forward, which should return 1.
A site connects, then drops repeatedly. Often a keepalive issue on connections behind NAT or a cellular router; adding PersistentKeepalive = 25 to that peer’s configuration sends a periodic packet to keep the NAT mapping alive, which resolves the large majority of intermittent-drop cases on cellular-connected sites specifically.
Can reach the hub itself but not devices behind a remote site. Check the site-side router or gateway has appropriate routing configured for traffic arriving via the tunnel to actually reach the local industrial network, not just terminate at the gateway device itself; this is a common gap when a site’s WireGuard peer is running on a separate small device rather than the same router handling the local network’s own routing.
Hub becomes unreachable after a server reboot. Confirm the WireGuard interface is set to start automatically: sudo systemctl enable wg-quick@wg0, since a manually started interface doesn’t survive a reboot without this.
Key management as the hub scales
Each site needs its own unique key pair, never shared between sites. As the number of sites grows, keeping track of which public key belongs to which physical location becomes a genuine operational task worth taking seriously: a simple spreadsheet or, better, a version-controlled configuration file with comments noting site name, location and the date the key was issued saves real confusion later, particularly when a site’s hardware eventually needs replacing and its key needs rotating.
What redundancy looks like for this pattern
A single VPS hub is, by design, a single point of failure for remote connectivity, which is an honest trade-off worth naming rather than glossing over. For deployments where that risk genuinely matters, a second standby VPS with the same WireGuard configuration, kept in sync and ready to take over via a DNS or IP failover if the primary goes down, is the common mitigation. For most projects on this site, the operational simplicity of a single hub outweighs this risk, but it’s worth deciding deliberately rather than not considering it at all.
Monitoring tunnel health
wg show on the hub gives a live summary of every connected peer, including the timestamp of their last handshake, the simplest way to spot a site that’s silently dropped off without waiting for someone to notice missing data downstream:
sudo wg show wg0Feeding this into an automated check (a simple script comparing the last-handshake timestamp against an expected threshold, alerting if a site goes quiet) is a natural next step once more than a couple of sites depend on the hub, and ties naturally into the same alerting patterns covered in Multi-Site Industrial IoT Data Aggregation.
Frequently asked questions
What happens if the VPS goes down?
Every site loses central connectivity until it’s back, which is why this pattern suits remote monitoring and management access rather than anything safety-critical that needs to keep functioning with no central infrastructure at all. Local control logic at each site should never depend on the VPN tunnel being up.
How many sites can one VPS hub realistically support?
WireGuard handles hundreds of peers without strain on modest hardware; the practical limit for most setups on this site is more about bandwidth and operational complexity (key management, monitoring) than raw VPN performance.
Is this different from a standard “VPN for remote work” setup?
The core technology is the same, but the topology differs: this is site-to-site (whole networks reachable through the tunnel), not a single remote user connecting to one network, which is the more common consumer use case for VPN software.
What’s the next step after the VPN hub is working?
See Remote Access to PLCs and Modbus Devices via VPS for what you actually do once the secure tunnel is in place.
Do all sites need the same hardware or router to use this pattern?
No, any device capable of running a WireGuard client works as a site endpoint, from a dedicated industrial router with built-in WireGuard support down to a small single-board computer. Consistency helps operationally, but it’s not a technical requirement.
Network segmentation within each site
The hub pattern in this guide secures the link between sites and head office, but it’s worth pairing with sensible segmentation at each site too. Putting industrial devices on their own VLAN or subnet, separate from any office or guest network at the same site, means a compromise of an unrelated device (a staff laptop, a guest Wi-Fi user) doesn’t automatically grant a path to PLCs and SCADA systems, even if that site’s own local network were compromised. This is a complementary control, not a replacement for the VPN pattern, since both address different parts of the overall attack surface.
Choosing the hub’s location deliberately
For sites genuinely spread across a country or further, the VPS hub’s own datacentre location affects round-trip latency to every connected site somewhat differently depending on geography. For most monitoring and occasional engineering access use cases this rarely matters in practice, since WireGuard’s overhead is already small and the underlying internet routing dominates the latency budget regardless of hub placement. It becomes worth choosing deliberately mainly for latency-sensitive interactive use, such as frequent remote desktop sessions into engineering workstations, where a hub roughly central to the connected sites measurably helps.
Can this same hub also serve a smart-home or office VPN, not just industrial sites?
Yes, there’s no technical reason to keep them separate, though it’s worth being deliberate about AllowedIPs scoping so an office device can’t accidentally route into an industrial site’s network, or vice versa, unless that’s specifically intended.
How do I revoke access for a site that’s been decommissioned?
Remove its peer block entirely from the hub’s wg0.conf and reload the interface (sudo wg syncconf wg0 <(wg-quick strip wg0)). The site’s key becomes immediately useless against the hub once its peer entry is gone, with no separate revocation process needed.
Does this pattern work for sites using mobile/cellular routers rather than fixed broadband?
Yes, and it’s a particularly good fit, since the outbound-initiated connection pattern works cleanly behind the carrier-grade NAT that’s common on cellular connections, where inbound port forwarding usually isn’t possible at all.
Is there a cost difference between this and a traditional managed SD-WAN service?
Generally yes, substantially: a self-managed VPS-based WireGuard hub costs the price of the VPS itself, typically a few pounds a month, against the recurring per-site fees common with managed SD-WAN products. The trade-off is operational, you’re managing the keys and configuration yourself rather than through a vendor’s management console.
Can existing industrial routers act as the site-side WireGuard endpoint, or do I need extra hardware?
Many modern industrial routers include native WireGuard support, in which case no extra hardware is needed at all, just configuration matching the peer setup described in this guide. Older routers lacking this support typically need a small dedicated device added alongside them to run the WireGuard client.
Does adding more sites to the hub require any change to existing sites’ configuration?
No, each site’s peer entry on the hub is independent. Adding a new site means adding one new peer block to the hub’s configuration and the matching client configuration at the new site; existing sites continue working entirely unaffected.