VPN

The Mirox platform's VPN provides secure remote access to the internal networks of individual plants. Instead of maintaining a separate VPN profile for each plant, every user receives a single, personal VPN profile through which all plants the user is authorized for become reachable. Permission changes, new plants, new subnets, or revoked cooperations are automatically reflected in the VPN profile — without the user having to reinstall it.

Concept

The VPN is built on WireGuard, a modern, lightweight, encrypted VPN protocol, and is designed as a personal single-sign-on tunnel to all granted plant networks:

• One profile per user: Every authenticated user can issue exactly one personal VPN profile and install it on their device. The platform calls this profile your VPN certificate — that is the product name for your personal WireGuard key pair; WireGuard itself uses key pairs rather than X.509 certificates.
• Modern cryptography: WireGuard uses a Curve25519 (X25519) key exchange and authenticated encryption. Your private key is generated on your own device and is never stored by Mirox — Mirox only ever sees your public key.
• Split tunnel: Only traffic destined for private plant networks enters the tunnel. Your normal internet traffic — email, web, video calls — stays on your own connection and never passes through Mirox.
• Automatic route management: The set of reachable plant subnets is derived dynamically from your current permissions (organization role, job role, cooperations). Any permission change automatically updates the route set.
• Highly available: The tunnel terminates on highly available, multi-region infrastructure and re-establishes automatically against a healthy entry point if its current one fails.

What the VPN delivers

Personal tunnel to all granted plants

Once the VPN profile is installed, the user can address all plant networks they have permissions for — exactly as if they were physically on site. This typically covers:

• Web interfaces of inverters, tracker controllers, data loggers, control-cabinet PCs
• SSH access to service devices
• Modbus / TCP diagnostic tools against components in the plant network
• The user's own tools that talk directly to the plant infrastructure

Multiple plants with overlapping local subnets (e.g. two plants both using 192.168.1.0/24) are automatically disambiguated by the system, so mix-ups are not possible.

Certificate lifecycle

The user controls their certificate directly through the platform UI:

• Issue: Creates a new VPN profile. The complete configuration file containing the private key is shown exactly once in the browser and is never stored in the cloud.
• Rotate: Replaces the key set without deleting the certificate. Useful e.g. when switching devices or when a compromise is suspected. The new private key is again shown only once.
• Revoke: Disables the certificate immediately. All ongoing connections are terminated at the next sync cycle. The certificate's audit trail is retained for the legally mandated retention period.

Route conflicts

The reachable subnets follow from your permissions and are kept current automatically (see How your routes stay current). One user-facing lever remains in your hands: conflicts between two plants that use the same local subnet are visibly marked in the route overview, and you decide which of the conflicting plants takes priority for you — the Use this park switch on the conflicting route swaps the priority at any time.

Session overview

The user has a dedicated session overview for their own certificate inside the platform:

• Current connections with connection time, duration, geographical source, IP address and transferred data volume
• Historical sessions for traceability

This overview is the user's self-transparency view of their own certificate. The full compliance audit trail — designed to meet KRITIS and EU NIS2 remote-access logging requirements — is maintained separately by the plant operator and is not part of this view — see Audit Logging.

Security and control

Who may issue a certificate?

Any authenticated user can issue a certificate of their own — but the certificate alone is not enough to reach any plant. Only the permissions granted through the permission system (organization role, job role, cooperation) actually open routes.

Who may reach which plant?

Network-level VPN access is the platform's most powerful remote-access capability, and it is decided plant by plant. A plant's subnets are added to your VPN profile only when you hold the Technical Manager job role — or Operator — on that plant. This is a single, authoritative rule — having a VPN profile, or being able to view a plant, never opens a route on its own.

Because the check runs per plant, the grant can be exactly as narrow as the job requires: one single plant, one portfolio, or the whole organization. The person doing technical operations management for three of your twenty plants reaches those three networks and no others.

You hold a qualifying role on a plant when it is granted in any of these ways:

• Directly — the Technical Manager or Operator job role is assigned to you on that specific plant or portfolio.
• Inherited through your organization — organization Administrators and Moderators map to Operator, and Asset Managers (Technical) map to Technical Manager, on their organization's own plants.
• Through a cooperation — another organization shares a plant with you and the cooperation grants Technical Manager or Operator; an external technician gets the same routes on that plant as the plant's own staff.

The commercial and read-only roles stop short of a network route, by design:

The result is a technical-versus-commercial split rather than a single privileged tier: the roles that carry technical responsibility for a plant reach its network, granted plant by plant, while the commercial and read-only side has no route into it.

Key custody

• The private key is generated in the user's browser and never leaves the device.
• Mirox only knows the user's public key and the tunnel IP assigned to them.
• On rotation or revocation, old keys are invalidated server-side immediately.

How your routes stay current

Your reachable plant list is never something you maintain by hand. It is derived from your live permissions, and Mirox keeps the two in lockstep automatically:

• Recomputed when a permission changes — usually within seconds, at the latest within 10 minutes. Most permission changes trigger an immediate recomputation of your route set. Some changes fan out too widely for that — a cooperation whose role is lowered can affect every user on both sides at once — so instead of an immediate recomputation for every conceivable path, a background synchronization runs continuously and closes any remaining gap. The guaranteed upper bound is 10 minutes; in practice it is seconds.
• New plants appear without re-downloading anything. You install your VPN profile once. Newly authorized plants show up in your reachable list on their own — you never re-import or reinstall the configuration to gain access to a plant. If you want the current state right now, Refresh on the VPN tab recomputes your routes immediately.
• Withdrawn access is removed and the path is torn down. When a permission is taken away — a cooperation ends, your job role changes, a plant is deleted — the corresponding routes are removed and the network path into that plant is torn down, under the same timing: normally within seconds, and never later than the 10-minute synchronization cycle. No manual action is required.
• The background synchronization is also the safety net. It re-verifies every active profile against current permissions on its recurring cycle and corrects any route that has drifted out of sync, so a single missed event cannot leave a route in place — and your reachable set always converges on your real permissions.

Multi-region availability

The personal VPN is engineered for high availability. It runs across multiple independent data-center regions, with multiple WireGuard VPN servers in each region, so there is no single point of failure. The platform architecture is engineered to deliver 99.999% availability.

• Automatic failover. Your tunnel always attaches to a healthy entry point. If one becomes unavailable, your connection is re-established automatically against another healthy server — you do not have to reconfigure anything.
• Best-region selection. When you connect, you are routed to an entry point that offers good reachability for your location, transparently selected by the system.
• Supervised plant agents. Each plant's monitoring agent — the on-site or cloud component that VPN traffic flows through — is supervised by an orchestration layer that continuously verifies the agent exists and is ready. If an agent fails, it is automatically redeployed or relocated to a healthy host, so a single host failure does not take a plant offline for long.

The plant's agent is the single point of entry

All VPN traffic to a plant flows through that plant's own monitoring agent. The agent is the chokepoint between Mirox and the plant network, and the design keeps that boundary tight:

• The agent only dials out to Mirox. It opens an outbound connection to the platform; the plant network never has to expose an inbound port to the internet for VPN access to work.
• No agent, no access. A plant is simply unreachable over VPN until its agent is online. Until then the plant shows as "not yet reachable" in your route list and goes live automatically once the agent connects.
• Bounded to its own plant. Each agent is confined to its own plant network. It is the single way into that plant and never crosses into another plant's or another organization's network.

Isolation between plants and organizations

Mirox runs the VPN as shared platform infrastructure, but every user's traffic is strictly confined:

• Your tunnel only carries your own routes. Each connection is served by its own isolated set of routes, derived solely from the plants you hold a qualifying technical role on.
• Unauthorized subnets are never routed. Plant networks you are not authorized for are not merely blocked — there is no route to them in the first place, so there is no path to reach them.
• Organizations cannot see each other. Because reachability is derived per user from that user's own authorizations, organizations sharing the platform can never see one another's plant networks.
• Defense in depth against scanning. On top of the per-user route isolation, the VPN entry points apply rate limiting that protects against network scanning and probing.

Audit and compliance

Every access through the VPN is fully audited by the Mirox system. The audit trail captures:

• Which user connected when and from where
• Which plant subnets were reached during the session
• Which specific devices (IP, protocol, port) were touched and how often
• How much data volume was transferred per session and subnet

The audit trail is retained for at least 730 days and is only accessible to the responsible operator organization of the respective plant — not to the connected user themselves. It is designed to meet the remote-access logging requirements of German KRITIS rules and the EU NIS2 directive; audit records cannot be edited or deleted by users. For details see Access Audit Logging.

Distinction From Related Features

Mirox offers several remote-access flavours that are easy to confuse. The personal VPN described on this page is one of five; the table shows what each is for and who controls it.

The personal VPN is the right tool for technical staff who need to use arbitrary tools productively against devices across several plants. The Browser Proxy is the right choice when only a device's web interface needs to be opened — with no VPN installation, straight from the browser. The organization and direct plant VPNs are infrastructure-level tunnels managed centrally, rather than a personal profile you carry.

IPv6

Mirox reaches a plant over IPv6 just as readily as over IPv4.

• IPv6-only plant connections. The tunnel that reaches a plant can be published as IPv6 only, IPv4 only, or both — for all three tunnel protocols (WireGuard, OpenVPN and IPsec). A plant whose line offers no usable public IPv4 — a DS-Lite or CGNAT connection, for example — is reached over IPv6 alone, with nothing to arrange at the plant beyond its own router. The setting is described in Configuring VPN Servers per Agent.
• Dual-stack by default. Where a plant has both, both address records are published and the plant's router uses whichever it can.
• IPv6-ready inside the tunnel. The plant networks you reach through the VPN are addressed over IPv4 today. The platform is already prepared for private IPv6 ranges on the plant side, so support can be enabled for plants that need it — please get in touch if you operate an IPv6-only plant network.

Related Features

• Proxy — browser-based access to plant devices without a VPN client
• Access Audit Logging — full audit trail of all VPN and Proxy access
• Permission System — controls which user reaches which plants
• Cooperations — sharing plants with third-party organizations
• Local Network Inspector — platform-side reachability checks of the plant network
• Remote Access FAQ — answers to common questions about VPN and Proxy access, routing, isolation, and availability