Remote Access Without Inbound Ports: Outbound-Only OT Connectivity

Your OT security baseline is clear: no inbound ports on the firewall. Your automation team is equally clear: we need remote access to PLCs for commissioning. How do you reconcile these requirements without violating your security policy?

The answer is outbound-only connectivity. Instead of opening firewall ports to let engineers in, you configure your OT network to initiate outbound connections to a self-hosted control plane. Engineers receive routes to PLC subnets via the same outbound tunnel. No firewall changes, no inbound exposure, and full compliance with IEC 62443 and NIS2.

This guide explains how outbound-only connectivity works, what "no inbound ports" really guarantees (and what it doesn't), and how DERP relay ensures connectivity even through restrictive firewalls that block UDP.

Why Inbound Ports Violate OT Security Baselines

Opening inbound ports on an OT firewall violates every modern OT security standard for good reason:

IEC 62443-3-3: System Security Requirements

SR 3.4 explicitly requires "prevention of unauthorized data flow." Opening inbound ports creates an unsolicited data path from the internet to your OT network. Even with authentication, you've created an attack surface that can be probed, exploited, or misconfigured.

NIS2: EU Cybersecurity Directive

Article 21 requires "security of network and information systems." Inbound ports are a standing vulnerability: if your VPN server has a CVE (and all software has CVEs), attackers can exploit it before you patch. Outbound-only eliminates this risk.

Defense in Depth

OT security follows a defense-in-depth model. If your perimeter firewall has inbound ports, you're trusting a single layer (the VPN authentication). If that layer fails (credential theft, VPN exploit, authentication bypass), your OT network is exposed. Outbound-only adds a layer: the OT network initiates connections, not the other way around.

Operational Reality

Firewall rules with inbound ports are entropy. Engineers open ports for temporary access, forget to close them, and you accumulate standing exposure. Outbound-only is self-limiting: if the OT gateway loses connectivity, access stops. No standing VPN ports, no forgotten rules.

How Outbound-Only Connectivity Works

Voltrus Remote flips the connectivity model: your OT gateway initiates outbound to your self-hosted control plane, and engineers connect outbound to the same plane. Both sides establish WireGuard tunnels without any inbound firewall ports.

Traditional VPN (inbound ports):

Internet → [FIREWALL: OPEN PORT 443] → VPN Server → OT Network
                                        ↑
                                    Attack surface

Outbound-only WireGuard mesh:

OT Gateway → OUTBOUND → Headscale Control Plane ← OUTBOUND ← Engineer
  (192.168.1.0/24)                 (self-hosted)         (laptop)
        ↑                                                       ↑
        └──────────────── Routes advertised ──────────────────────┘
                  (PLC subnet reachable on engineer's laptop)
			

Key properties:

1. No firewall changes: Both the OT gateway and the engineer initiate outbound connections. No ports need to be opened inbound.
2. Scoped routes: The gateway advertises only the PLC subnets you choose (e.g., 192.168.1.0/24). Engineers receive routes only to subnets their ACL permits.
3. Self-hosted custody: The Headscale control plane runs on your infrastructure. You own the logs, user registry, and machine identities.

What "No Inbound Ports" Really Guarantees

Outbound-only connectivity is a powerful security measure, but it's important to understand what it guarantees and what it doesn't:

What It Guarantees

• No unsolicited connections: Your OT network cannot be reached from the internet without the gateway first initiating a connection. Attackers cannot probe your VPN server because there's no inbound port.
• No VPN server exploit path: If your VPN software has a vulnerability, it can't be exploited directly because there's no listening port. The gateway initiates connections; it doesn't accept them.
• Entropy reduction: Outbound-only rules are self-documenting and self-limiting. No "temporarily open port 4500 for contractor access" entropy.

What It Doesn't Guarantee

• Defense against credential theft: If an engineer's Voltrus Remote credentials are phished, the attacker can still access the PLC subnets that engineer's ACL permits. Outbound-only doesn't eliminate authentication risk — it eliminates network exposure risk.
• Defense against compromised endpoint: If an engineer's laptop is infected with malware, the malware can traverse the WireGuard tunnel to PLC subnets. This is why endpoint security (EDR, device certificates) remains necessary.
• Defense against insider threats: A malicious engineer with legitimate access can still cause harm. Outbound-only doesn't eliminate trust in authorized users.

DERP Relay: TCP/443 Fallback for Restrictive Firewalls

Some upstream firewalls block UDP entirely. This breaks traditional VPN NAT traversal. WireGuard with DERP solves this:

Normal WireGuard (UDP):

Engineer ←UDP→ Headscale ←UDP→ OT Gateway

UDP Blocked (corporate firewall, hotel Wi-Fi):

Engineer ←TCP/443→ DERP Relay ←TCP/443→ OT Gateway
(masquerades as HTTPS)

DERP = Distributed Encrypted Relay Protocol
Integrated into Headscale, no separate deployment
			

How DERP Works

1. Engineer attempts WireGuard connection over UDP to Headscale
2. If UDP fails, client falls back to DERP relay over TCP/443
3. DERP traffic looks like HTTPS to the upstream firewall
4. OT gateway also connects via DERP if UDP is blocked on its side
5. Once both sides are connected, routes are exchanged as normal

Performance Considerations

DERP adds ~10ms latency and a TCP overhead penalty. For most PLC programming tasks (TIA Portal project uploads, Modbus polling), this is imperceptible. For high-bandwidth tasks (bulk data transfer), DERP is slower than native UDP but still functional.

DERP vs "VPN Over TCP/443"

OpenVPN can run over TCP/443, but DERP has two advantages:

1. Integrated into the control plane: DERP is part of Headscale, no separate relay server to deploy
2. Fallback is automatic: Clients try UDP first, fall back to DERP transparently. No configuration needed

Compliance Alignment: IEC 62443 and NIS2

Outbound-only connectivity directly supports key compliance requirements:

IEC 62443-3-3: System Security Requirements

• SR 3.4: "Prevention of unauthorized data flow" — Outbound-only prevents unsolicited inbound connections
• SR 5.2: "Use of cryptographic algorithms" — WireGuard uses ChaCha20-Poly1305 (audited, modern cipher suite)
• SR 7.1: "Network segmentation" — ACLs limit engineers to advertised subnets only

NIS2: EU Cybersecurity Directive

• Article 21: "Security of network and information systems" — Outbound-only reduces attack surface by eliminating inbound ports
• Article 23: "Cryptographic protection" — WireGuard's Curve25519 ECDH and ChaCha20-Poly1305 meet modern crypto requirements
• Incident response: Audit logs on self-hosted Headscale instance support forensic requirements

Deployment Checklist

Step 1: Deploy Headscale Control Plane

# On your VPS or on-premise server
curl -fsSL https://headscale.de/keys/headscale.repo | sudo tee /etc/apt/sources.list.d/headscale.list
sudo apt update && sudo apt install headscale
sudo systemctl enable headscale
sudo systemctl start headscale

Step 2: Deploy OT Gateway

# On a Linux device on your PLC network
curl -fsSL https://get.voltrus.id/gateway | sudo bash

# Register with your control plane
voltrus-remote register --control-plane=https://headscale.your-domain.com

# Advertise PLC subnets
voltrus-remote advertise 192.168.1.0/24

Step 3: Define ACLs

# In Headscale ACL configuration
acls:
  - action: accept
    users: ["engineer@example.com"]
    routes: ["192.168.1.0/24"]

Step 4: Engineer Connects

# On engineer's laptop
voltrus-remote login --control-plane=https://headscale.your-domain.com

# PLC is now reachable at 192.168.1.20
ping 192.168.1.20

Operational Considerations

What Happens When the Gateway Loses Connectivity?

If the OT gateway loses internet (upstream router restart, ISP outage), the WireGuard tunnel drops and engineers lose access. This is a feature, not a bug — it ensures access requires active connectivity, not standing VPN credentials.

How to Handle Emergency Access?

For after-hours emergency access, create a separate ACL with broader routes and shorter expiry (e.g., 24 hours). This balances response time with least privilege. Voltrus Remote roadmap includes emergency approval workflows.

Multi-Site Deployments

For multiple PLC sites, deploy one gateway per site and advertise each site's subnets. Engineers can receive routes to multiple sites via ACLs. All sites share the same Headscale control plane.

The Bottom Line

"No inbound ports" isn't a security myth — it's a fundamental OT security baseline for a reason. Opening inbound ports on an OT firewall creates standing exposure that violates IEC 62443, NIS2, and defense-in-depth principles.

Outbound-only WireGuard connectivity gives you the best of both worlds:

• Security: No inbound ports, no unsolicited connections, no VPN server exploit path
• Compliance: Aligned with IEC 62443 SR 3.4 and NIS2 Article 21
• Usability: Engineers receive scoped routes to PLC subnets, TIA Portal works at native speed
• Resilience: DERP relay ensures connectivity even through restrictive firewalls that block UDP

The architectural shift from "open inbound ports for VPN" to "outbound-only mesh connectivity" is one of the most significant OT security improvements in recent years. For teams managing Siemens, Rockwell, Mitsubishi, Omron, or Schneider PLCs, it's the difference between "compliant remote access" and "security exception."

Outbound-only doesn't eliminate all risk — you still need endpoint security, authentication hygiene, and procedural controls. But it eliminates the network-level exposure that traditional VPNs introduce. And in OT security, that's the layer that matters most.