WireGuard for Site-to-Site Connectivity: Connect Plants Securely

Remote-maintain distributed plants securely? WZ-IT builds sovereign remote-maintenance platforms with a WireGuard backend and a browser gateway. See our Remote Management Platforms

WireGuard connects distributed sites and plants through a lean, encrypted tunnel: every site becomes a peer with a key pair, AllowedIPs defines which subnets sit behind which peer, and all traffic runs encrypted over UDP. When the site builds the tunnel outbound, no open inbound port is required - ideal for connecting machines and plants behind NAT and firewalls. This article explains how it works and how to connect a plant step by step.

Table of contents

• How WireGuard works
• Site-to-site tunnel or full mesh?
• Outbound-only: no open inbound port
• Mesh overlays for many sites: NetBird and Headscale
• WireGuard vs. IPsec vs. OpenVPN
• Key management and security
• Connect a plant: step by step
• WireGuard as the backend under the browser gateway (Guacamole)
• How WZ-IT approaches this
• Further guides

---

How WireGuard works

WireGuard has been part of the mainline Linux kernel since 5.6 (March 2020) (wireguard.com). The model is deliberately simple: every participant is a peer. Each peer has a private key that never leaves the device and a derived public key that the counterparts know. A connection exists as soon as two peers have each other's public key configured.

The central concept is AllowedIPs (cryptokey routing). Per peer you declare which IP ranges are reachable through it. AllowedIPs serves two purposes at once: when sending, WireGuard uses the destination IP to choose which peer to encrypt to; when receiving, it only accepts packets whose source IP matches that peer's AllowedIPs. For site connectivity you therefore enter the plant's LAN subnet on the concentrator (e.g. 192.168.50.0/24) and the reachable headquarters subnet on the plant.

Transport runs over UDP only (conventional default port 51820, freely configurable). There is no TCP fallback and no cipher negotiation - the cryptography is fixed: Curve25519 for the key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing (wireguard.com/protocol). This fixed choice removes an entire class of misconfigurations.

Site-to-site tunnel or full mesh?

There are two basic patterns for site connectivity:

• Site-to-site (hub-and-spoke): A central concentrator at headquarters or the hoster is the hub, every site is a spoke. All inter-site traffic flows through the hub. This is easy to manage, easy to audit and usually sufficient for remote maintenance, because access should be centrally funnelled anyway.
• Full mesh: Every site talks directly to every other. This minimises inter-site latency but creates up to n*(n-1)/2 connections for n sites, and with it considerable overhead managing keys and AllowedIPs.

Hand-configured full mesh scales poorly. Once many sites are involved, an overlay (see below) handles the mesh automatically, so you do not maintain each connection by hand.

Outbound-only: no open inbound port

The decisive advantage for industrial plants: WireGuard needs no internet-reachable port at the site. The site peer builds the tunnel outbound to the central endpoint. Because WireGuard learns the counterpart from incoming packets (endpoint roaming) and sends empty packets periodically via PersistentKeepalive (typically 25 seconds), the NAT and firewall mapping stays open.

In practice the plant sits behind NAT, the router needs no port forward, and the firewall only permits outbound UDP. Only the central concentrator (or a relay) needs a publicly reachable UDP endpoint. This shrinks the attack surface at the site dramatically and is the basis for remote maintenance without a VPN client.

Mesh overlays for many sites: NetBird and Headscale

Beyond a handful of sites, manually maintaining keys, peers and AllowedIPs becomes tedious. Mesh overlays address this by using WireGuard as the data plane and layering a control plane on top:

• NetBird: A fully self-hostable WireGuard mesh stack (open source; clients under BSD-3, the management, signal and relay server components under AGPLv3) with its own control plane, clients, dashboard and relays. Peers connect automatically, access is policy-based (zero trust, nothing allowed by default), with SSO integration (e.g. Keycloak) and an audit trail. NAT traversal uses direct connections where possible and relays as a fallback.
• Headscale: An open-source reimplementation of the Tailscale coordination server API. You host the control plane yourself and use the official Tailscale clients on the devices. A good fit if you want the Tailscale ecosystem without its cloud.

Both automate key distribution, route distribution and NAT traversal across many sites - exactly what makes hand-built full mesh expensive. More background on the data plane on our WireGuard expertise page.

WireGuard vs. IPsec vs. OpenVPN

WireGuard is lean, modern and performant - the small codebase of roughly 4,000 lines reduces attack surface and audit effort considerably (wireguard.com/performance). IPsec remains the standard in carrier and appliance environments with hardware offload, while OpenVPN scores with broad legacy compatibility and a TCP fallback. For new, sovereignly operated site networks, WireGuard is usually the right choice.

Key management and security

Security stands and falls with the keys:

• One key pair per site. Private keys are generated locally, never leave the device and are stored with restrictive file permissions (chmod 600).
• Keep AllowedIPs tight. Only expose the subnets actually needed, not 0.0.0.0/0 when only an HMI should be reachable. This segments per site.
• Rotation and revocation. Rotate keys regularly; on staff changes or a compromised device, remove the peer from the configuration immediately. A mesh overlay automates this.
• Auditability. Who accessed which plant and when belongs in a log - more on this in RBAC and audit for remote access.

WireGuard delivers modern cryptography out of the box but does not replace a security concept. For regulated operators, per-site network segmentation is also relevant with regard to the NIS2 directive; see NIS2-compliant remote access for details. This article is general information and not legal advice.

Connect a plant: step by step

Here is how to connect a single plant to an existing concentrator:

1. Generate keys (on the plant): wg genkey | tee privatekey | wg pubkey > publickey. Send the public key to headquarters and keep the private one.
2. Define the address plan. Assign the plant a tunnel IP from the overlay network (e.g. 10.10.0.7/32) and determine the plant's reachable LAN (e.g. 192.168.50.0/24).
3. Configure the concentrator. On the hub, add a [Peer] with the plant's public key and AllowedIPs = 10.10.0.7/32, 192.168.50.0/24.
4. Configure the plant. Local [Interface] with the private key and tunnel IP, plus a [Peer] for the hub with its public key, Endpoint = vpn.example.com:51820, AllowedIPs = 10.10.0.0/24 (plus required HQ subnets) and PersistentKeepalive = 25.
5. Enable routing. If the plant should expose its LAN, enable IP forwarding on the plant gateway (net.ipv4.ip_forward=1) and set NAT if needed.
6. Start and verify the tunnel: wg-quick up wg0, then wg show - the latest handshake time and transfer counters confirm the connection.

With many sites you replace steps 1, 3 and 4 with onboarding in the mesh overlay, which distributes keys and routes automatically.

WireGuard as the backend under the browser gateway (Guacamole)

WireGuard is the transport layer, not the access portal. In a sovereign remote-maintenance platform, a browser gateway such as Apache Guacamole sits on top, delivering RDP, VNC and SSH clientless in the browser. The technician logs into the web portal, the gateway connects through the WireGuard tunnel to the controller or HMI at the plant - WireGuard stays an invisible backend. What Guacamole does here is explained in What is Apache Guacamole?.

This setup separates concerns cleanly: WireGuard handles encrypted transport and the outbound-only connection, the gateway handles authentication, session recording and clientless access.

How WZ-IT approaches this

We build the WireGuard layer as the foundation of sovereign remote-maintenance platforms: sites are connected outbound-only, keys and routes are managed centrally, and access runs through an auditable browser gateway. For distributed industrial plants with HMI access, the ABCO Water Systems case study shows how this runs in production in Australia; for IoT fleet rollouts there is the nextGYM case study. On request we handle design, build and operation end to end - as part of our Remote Management Platforms.

Further guides

• WireGuard expertise - data plane and operations
• NetBird and Headscale - mesh overlays for many sites
• Remote maintenance without a VPN client
• What is Apache Guacamole?

Want to connect distributed sites cleanly? Book a free initial consultation or explore our Remote Management Platforms.