Configuring VPN Servers per Agent (Direct VPN)

A direct plant VPN is a dedicated tunnel between a single plant's Mirox-Agent and that plant's own router — the right tool when a plant already runs its own VPN, or when you want Mirox to host a VPN that the plant router dials into. Unlike the personal VPN, which gives every user one profile that reaches all their authorized plants, a direct VPN is a per-plant infrastructure tunnel you set up once and the whole team's traffic for that plant rides over.

You configure direct VPNs from a plant's Networking page, on the Site VPN tab. The Networking page has five tabs: Overview (the connection pipeline), Network Devices, Site VPN (this guide), Peers (shown when a hosted VPN has more than one connecting site), and Access Log.

Open in Mirox

Open the plant's Site VPN tab. In the app this is the plant's Networking page, Site VPN tab.

When to Use a Direct VPN

Reach for a direct VPN when the plant's connectivity does not fit the standard personal-VPN model:

  • The plant router already hosts its own VPN server. You have a configuration file (WireGuard .conf) or an OpenVPN profile (.ovpn) and want Mirox to dial out to it.
  • The plant router can only dial out, not accept inbound connections. Mirox hosts the VPN endpoint and the router connects to it.
  • You want one always-on tunnel for the whole plant rather than each user carrying a personal profile.

For day-to-day technical work across several plants — opening device web interfaces, running diagnostic tools — the personal VPN and the Browser Proxy are usually the better fit. The table below summarizes the distinction; the full comparison lives on the VPN feature page.

ToolWhat it isWho sets it up
Personal VPNOne personal profile reaching every plant you are authorized forEach user, within their permissions
Direct VPN (this guide)A per-plant tunnel between the plant's agent and its routerA Moderator or Admin of the plant's organization
Browser ProxyOpen a device's web interface from the browser, no client installThe plant operator

The Two Directions

A direct VPN can run in one of two directions. The setup wizard asks this first, under Where does the VPN server live?

Note: dashed lines indicate the connection direction — only one direction applies per direct VPN.

  • Outgoing connection — Mirox connects to the plant router. The plant router runs its own VPN server; the Mirox-Agent dials out as the client. The card shows a Client badge. Choose this when you already have a config file or credentials for the router's VPN.
  • Hosted here — the plant router connects to Mirox. Mirox runs the VPN server; the card shows a Server badge. The endpoint (a per-plant address and port), keys and certificates are generated by Mirox and handed to you to load onto the plant router. Choose this when the router can dial out but cannot accept inbound connections.

All three protocols — OpenVPN, WireGuard and IPsec (IKEv2) — are offered in both directions, but the right choice differs by direction: see Choosing the VPN Type below. A plant can host one server per protocol variant at the same time — WireGuard, OpenVPN over UDP, OpenVPN over TCP and IPsec — and can run any number of outgoing connections in parallel.

Choosing the VPN Type

Mirox speaks three tunnel protocols — OpenVPN, WireGuard and IPsec (IKEv2) — and the wizard shows them side by side with what speaks for and against each one. Which one is recommended depends on the direction you picked, and the "Recommended" badge moves accordingly. That is not a matter of taste: the two directions put the fragile part of the connection on opposite sides of the tunnel.

The fragile part is who resolves the other end's address, and how often. Mirox runs in several data-center regions, and a plant's VPN endpoint can move between them during a failover. A client that resolves the server's DNS name again on every reconnect follows that move on its own; a client that resolved it once at startup keeps dialing an address that no longer answers.

Which VPN protocol should I choose?

At a glance — the deeper, direction-specific detail follows below. The recommended option depends on the direction you picked, but the character of each protocol is the same either way:

ProtocolTypical useRuns over
WireGuardThe lean, modern option — quickest to set up, one key pair per side and no certificates. A good fit for a newly built site, or wherever certificate handling is the obstacle.IPv4, IPv6, or both
OpenVPNThe universal one — supported by practically every router, including firmware many years old. The safe default when Mirox hosts the server.IPv4, IPv6, or both
IPsec (IKEv2)The industrial standard, and often the only protocol an industrial router or firewall offers (Cisco, Lancom, Fortigate).IPv4 or IPv6

IPv4 or IPv6? A tunnel runs over IPv6 just as well as over IPv4, and when Mirox hosts the server it publishes both by default. See IP version for what to change and when. For an outgoing connection there is nothing to pick — the tunnel follows the address of the server on site.

IP version

Mirox publishes the tunnel's address in DNS. For a hosted VPN you decide which records are published for it:

SettingWhat is publishedWhen to use it
IPv4 + IPv6 (default)An A record and an AAAA recordAlmost always. The router uses whichever one it can.
IPv4 onlyAn A recordThe site has no working IPv6, or its router refuses IPv6 tunnels.
IPv6 onlyAn AAAA recordThe site is reachable over IPv6 and IPv4 is not wanted.

Keeping both records online is what gives the broadest compatibility, and it is why IPv4 + IPv6 is preselected. A router with working IPv6 will normally take the AAAA record — that is the ordinary behaviour of an IP stack that has both — and a router with only IPv4 takes the A record. Neither case needs anything configured at the plant.

Publishing both is not an automatic fallback for WireGuard

A WireGuard client looks the address up once, when the tunnel starts, and does not try the other family if that attempt fails. So a router whose IPv6 exists but is broken can take the AAAA record and stay down — publishing both records does not rescue it. That is what IPv4 only is for. OpenVPN behaves differently: it works through the addresses it resolved, so it recovers on its own.

IPsec (IKEv2) offers only IPv4 or IPv6, never both: an IKE connection dials one address family at a time.

Where to find it. Because the default is right for nearly every site, the setting is not part of the opening wizard flow for WireGuard and OpenVPN — open Show advanced options on the configuration step. IPsec asks for it directly, since it has no "both" to fall back on. On an existing VPN it sits at the top of Edit → Config. Changing it later does not disturb tunnels that are already up.

IPv6 inside the tunnel

The setting above decides which family carries the encrypted packet to the plant. What you address inside the tunnel — the plant's devices — is IPv4 today. The platform is prepared for IPv6 there as well; it is simply not built yet, because no site has needed it so far. If your plant's devices are addressed over IPv6, tell us and we will implement it.

In this direction the plant router is the client, so the re-resolving is done by its firmware — hardware we do not administer and cannot fix remotely.

OptionSpeaks for itSpeaks against it
OpenVPN (recommended)Resolves the server address again on every reconnect, so the tunnel comes back after a Mirox failover — whatever the router vendor or firmware. Supported by practically every router, including firmware that is many years old.Certificate-based: a CA, a certificate and a key have to be entered on the router, instead of a single key pair.
WireGuardSet up with a handful of values — one key pair per side, no certificate bundle.Most routers resolve the server address only once at start; after a Mirox failover the tunnel stays down until the router reboots or Mirox fails back. Older router firmware may not offer WireGuard at all.
IPsec (IKEv2)The standard on industrial routers (Cisco, Lancom, Fortigate).Pre-shared key and manual router setup — no config file to import. Slower: encryption runs in userspace, so it fits low-volume telemetry best.

The deciding question here is therefore not which protocol is the more modern one — WireGuard is — but which one survives a region failover on hardware we do not control. OpenVPN does that on any firmware, which is why it is preselected. Choose WireGuard when the certificate handling is the bigger obstacle for the router in front of you, and accept that a failover may need a router restart. Choose IPsec when the router offers nothing else.

The certificates do not expire on you

The certificate authority, the server certificate and every peer certificate Mirox issues for a hosted OpenVPN server are long-lived. There is no renewal chore and nothing quietly expiring years later — the cost of OpenVPN is the one-time import work on the router, not maintenance.

WireGuard reconnect port

WireGuard remembers the address it first connected to and never looks it up again. So if the Mirox server side of a hosted WireGuard tunnel is ever relocated — during a failover, or for maintenance — a connected site peer can stay disconnected until it is restarted. OpenVPN and IPsec re-check the address themselves and need no such setting; WireGuard does not.

The Reconnect port removes that weakness. It is the WireGuard listen port of the remote router (the site peer). Fill it in when you create a hosted WireGuard VPN, or later on an existing peer under Edit → Remote Peer, or per peer under Peers → Edit. With it set, Mirox can re-dial the peer at its own public address after the server side moves, so the tunnel re-establishes automatically and survives a failover. Left empty, the tunnel stays pinned: the server side is not moved, and after a relocation it would stay down until the router reconnects on its own. To remove a reconnect port again, simply clear the field and save.

Only set it when that port is really reachable

Setting a reconnect port is a promise that Mirox can reach the router there — and it is what allows the tunnel to be moved for failover. So once it is set, a relocation of the server side may happen, and that relocation briefly drops and then re-establishes the tunnel. For it to heal instead of stay broken, the site router must actually be listening on that WireGuard port, reachable on its public IPv4 or IPv6 address, with the port opened in the site firewall. If the port is not reachable, a move drops the tunnel with no way back — so only fill it in once the site's WireGuard endpoint is listening and the firewall allows it. When in doubt, leave it empty; the tunnel then simply stays where it is.

Setting a reconnect port for every WireGuard site peer is recommended wherever the router's listen port is known and reachable.

In this direction the server already exists on site and Mirox dials into it. That flips both arguments above:

  • The re-resolving side is now ours. Mirox re-resolves the address of the server on site and reconnects on its own, on every protocol — so the objection that decided the hosted case disappears completely.
  • The firmware question disappears too. Nothing has to be installed on the router; the protocol is simply the one the existing server speaks, and Mirox takes its settings from that server.

The server on site has to be reachable from the internet

This direction only works if Mirox can dial in, so the plant's line needs an address of its own that the public internet can reach. Either family is enough: a public IPv4 or a public IPv6. A line with no public IPv4 but working IPv6 is therefore perfectly fine.

What rules this direction out is a provider that keeps the line inside its own shared network, so the router holds no address anyone outside can reach on either family. Low-budget mobile and SIM tariffs are the usual case. Ask the site to check the router's internet page: an IPv4 marked as shared with other customers and no public IPv6 on the connection means this direction is impossible. A dynamic DNS name that resolves proves nothing here — it resolves on a shared line just as well.

When that is the situation, host the VPN here instead (the section above): the router then dials outwards, which works on any line. Choose OpenVPN there — on such a line a hosted WireGuard tunnel could not be repaired from our side either, because a reconnect port needs exactly the same reachability, so it would stay down after a failover until the router reconnects on its own.

What is left is what has to be imported into Mirox — and that is where the three genuinely differ:

OptionSpeaks for itSpeaks against it
WireGuard (recommended)A key pair and an endpoint are the whole import — nothing else has to line up between the two ends. Mirox re-resolves the address of the server on site and reconnects on its own, so a DynDNS change or a line drop repairs itself.The server on site has to add the Mirox public key as a peer — it cannot simply hand out a profile.
OpenVPNAlmost every existing VPN server offers it, and its .ovpn profile can be uploaded here as it is.Cipher, HMAC and TLS settings have to match the server exactly — a divergence fails silently, which is why the wizard reviews them with you on a separate step. The profile is a bundle: CA, certificate, key and the tls-auth key all have to come from the site.
IPsec (IKEv2)Often the only thing an industrial firewall offers (Cisco, Lancom, Fortigate).Pre-shared key and both IKE identities have to be agreed with the site by hand — there is no profile to import. Slower: encryption runs in userspace, so it fits low-volume telemetry best.

In practice the choice is often made for you: it has to be the protocol the existing server speaks. The recommendation applies when the site offers more than one — and when the site is still being built, asking for WireGuard is worth it.

UDP or TCP (OpenVPN only)

OpenVPN runs over UDP or TCP. UDP is how it is meant to run — faster, and far steadier on a weak mobile link — and it is the default. TCP is for the one site whose firewall lets no UDP out, or whose router offers TCP alone.

  • Hosted here: the choice sits on the Configuration step behind Show advanced options, next to the crypto settings. Leave it alone unless you know UDP is blocked. The transport is part of the server's identity, so a plant can host one UDP and one TCP OpenVPN server side by side.
  • Outgoing: an uploaded .ovpn already states it; with manual entry you pick UDP or TCP together with the connection details.

OpenVPN compatibility settings

These live on the Configuration step of the wizard. Its default view carries no knobs at all — an untouched hosted server renders the modern profile, which is right for every router still in support. The compatibility presets and the individual directives appear behind Show advanced options.

For OpenVPN you can match an older router's settings so even legacy firmware connects: cipher, authentication digest, minimum TLS version, compression, mssfix, renegotiation interval and the TLS auth mode. The wizard validates the combination as you type and rejects pairings that no supported router firmware can actually negotiate.

A hosted OpenVPN server additionally offers:

  • PKI key algorithm — new servers default to RSA-2048, the algorithm accepted by common industrial routers; ECDSA P-256 is available where the router supports it. The algorithm is fixed at creation; changing it later means rotating the whole certificate chain.
  • Rotate CA — re-issues the server's certificate authority, the server certificate and every connecting peer's certificate in one step. Each peer's new configuration is shown once for download; the old certificates stop working as soon as the rotation is applied.
  • Require user authentication — connecting peers must additionally present a username and password that you define per peer.

IPsec (IKEv2) settings

For IPsec the wizard asks what an IKEv2 responder needs: the pre-shared key — leave it blank on a hosted server and Mirox generates a strong one, shown once after creation — the local and remote IKE identities (optional; the endpoint FQDN is used by default), the IKE and ESP proposals, their lifetimes, and the DPD delay that decides how quickly a dead peer is noticed. Both ends must agree on the proposals, and there is no profile to exchange, so these values are typed into the router by hand.

Before You Start

Who can configure direct VPNs

The Site VPN tab is visible to Technical Manager or higher on the plant (including Operator). Creating, editing, or deleting a direct VPN requires a Moderator or Admin of the plant's own organization. Lower roles, and users reaching the plant through a cooperation, see the configured tunnels but cannot change them. Access follows the permission system.

Have ready:

  • The direction you need (outgoing vs hosted), based on what the plant router supports.
  • For the outgoing direction: the router's VPN config file (.conf or .ovpn), or the endpoint address and keys to enter manually.
  • For the outgoing direction, the protocol is dictated by the server already running on site. For the hosted direction you are free to choose — see Choosing the VPN Type.
  • The plant subnet(s) behind the router that you want to reach — the local network ranges (CIDRs) where the inverters, loggers, and other devices live.

Adding a Direct VPN

  1. Open in Mirox: open the plant's Site VPN tab — the plant's Networking page, Site VPN tab.
  2. Click Add VPN connection. A short wizard opens.
  3. Choose the direction — Mirox connects to Park-Router (outgoing) or Park-Router connects to Mirox (hosted).
  4. VPN type — choose OpenVPN, WireGuard or IPsec (IKEv2). The wizard marks the option recommended for the direction you picked and preselects it; each card lists what speaks for and against it. See Choosing the VPN Type.
  5. Configuration — (hosted only) the compatibility profile for the plant router. The default fits any router from the last few years; Show advanced options reveals the transport (UDP/TCP), the individual crypto directives, optional username/password authentication, the WireGuard pre-shared key or the IPsec responder settings.
  6. Connection details — (outgoing only) upload the router's .conf/.ovpn file, or switch to manual entry and type the endpoint and keys. For OpenVPN a compatibility review step follows, where the wizard shows what it read out of the profile so you can correct it.
  7. Plant subnet — add the local network range(s) reachable behind the router. The platform validates each range and blocks anything that would clash with the reserved tunnel range, an organization VPN route, or another direct VPN on the same plant.
  8. Review and apply — confirm the summary, then click Apply.

The tunnel names itself

There is no name to fill in. Mirox names the tunnel after the plant and the chosen protocol — for example Solarpark Nord OpenVPN-UDP — and adds a number if that name is taken, so it is unique on the plant. Rename it, or add a description, at any time under Edit → General.

Save the hosted-VPN credentials immediately

When you create a hosted VPN, Mirox generates the configuration the plant router needs to dial in — including its private key or certificate — and shows it only once. Download and load it onto the router before closing the dialog; it cannot be retrieved later. If it is lost, rotate the peer (WireGuard) or the certificates (OpenVPN) to get a fresh one.

Once the tunnel is up, the devices on the configured plant subnets become reachable, and any network device discovery you run on the plant scans through it.

Default route is never allowed

A direct VPN never carries a 0.0.0.0/0 "send everything" route. Always list the explicit plant subnets you want to reach. If you upload a config that contains a default route, the platform strips it and asks you to add the specific ranges.

Managing an Existing Direct VPN

Each direct VPN appears as a card on the Site VPN tab, marked Server (hosted) or Client (outgoing), with a live connection bar and traffic indicator. For a hosted VPN with several connecting sites, the bar shows the worst connecting peer — one down site colors the whole card. Open the card's ... menu for:

  • Edit — change the name, description, subnets, connection settings, or keys. The edit dialog has the tabs General, Subnets, Config (protocol settings) and Remote Peer (the connecting side's key/certificate, rotation, and adding further peers).
  • Restart VPN — cycle the tunnel without changing its configuration; useful after a settings change or a transient drop.
  • Live status — open the inspect dialog (see below) with live per-peer state, logs, diagnosis and debug tools.
  • Diagnose — (shown when the tunnel is currently disconnected) jump straight to the automatic diagnosis.
  • Manage peers — (hosted VPNs with more than one connecting site) jump to the Peers tab.
  • Delete — remove the tunnel. You must type the tunnel's name to confirm; the dialog lists the network devices that would lose their route.

The Inspect Dialog: Live Status, Logs, Diagnose, Debug

Live status on a card opens a dialog with four tabs and a live connection badge:

  • Live status — one card per peer, refreshed about once a second, straight from the plant: connection state, tunnel IP, endpoint, received/sent traffic with live rates, and — protocol-aware — the handshake age (WireGuard; over ~3 minutes means not currently established) or the session duration (OpenVPN). Peers with a tunnel address get an inline latency chart from a continuous reachability check.
  • Diagnose — the one-click automatic diagnosis: an AI assistant reads the tunnel's recent logs and live state, explains what it finds in plain language, and — for OpenVPN settings mismatches — can propose a safe configuration fix that you apply with one click. See also the AI assistant page.
  • Logs — the tunnel's live connection log with level colouring and scroll-back into history.
  • Debug — read-only tools that run at the plant: the tunnel routing table, a free-form ping across the tunnel, and an ICMP capture that shows whether requests actually leave and whether anything answers — the classic way to tell "tunnel up but the site doesn't respond" apart from "tunnel down".

Reconnecting a hosted WireGuard peer

WireGuard looks the other end up once, when the tunnel starts, so a site peer cannot find this server again if the server's address changes. When such a peer's tunnel is down, its card on Live status offers a Reconnect button with the last known address and port already filled in — sending one handshake from our side is enough: the peer re-resolves and carries the connection on its own from then on. Adjust the fields if the site has moved.

It is offered only for a hosted WireGuard VPN, only while that peer is disconnected, and it changes nothing that is stored — no configuration is written and the plant's agent is not restarted. Nothing entered here can make matters worse: if the peer later dials in from a different address, WireGuard simply adopts the address the packet really came from.

"No data — may be stale"

The live badge turns red when no fresh reading arrives. That means the reading is unavailable — it is deliberately never shown as "tunnel down", because a missing reading is not evidence of an outage.

Managing the Plant Subnets

The subnets a direct VPN routes are what make the plant's devices reachable. Add or remove ranges from the VPN's Edit view at any time. Removing a subnet that still has network devices behind it leaves those devices unrouted — the delete dialog warns you and lists which devices are affected, so you can reassign them to another tunnel first.

Hosted VPN: Connecting Peers

A hosted VPN accepts connecting peers of two kinds:

  • Site peers — the plant router itself (or another fixed site) dialing in and announcing its subnets. The first site peer is created for you when you set up a hosted VPN; its key or certificate lives on the Remote Peer tab of the edit dialog. A hosted VPN can serve several site peers — a plant split across multiple routers, each announcing its own ranges.
  • User peers — individual people dialing in to the same hosted server with a personal profile. A disconnected user peer is normal (people connect on demand) and never counts as a site outage.

With more than one site peer, the plant's Networking page shows the Peers tab: a table of all connecting peers with tunnel IP, identity (WireGuard public key or OpenVPN certificate name), traffic, connection history, and per-peer editing (subnets, key/certificate rotation, delete). With a single site peer the same settings live directly in the edit dialog and the Peers tab stays hidden.

Deleting a hosted server is destructive

Deleting a hosted VPN removes the server and every connecting peer — sites and users. Their configurations stop working immediately and cannot be reissued; recreating the server later means issuing fresh configurations to every peer.

If the Tunnel Won't Connect

The Diagnose tab automates most of this; the patterns below are what it (and the AI assistant) look for:

SymptomMost likely causeWhere to look
Hosted VPN, a peer has never connectedThe generated config was never installed on the router, or it dials the wrong address/portLoad the peer config onto the router; check the endpoint on the card
Peer was connected, now down, logs show "sent … received 0"The remote router stopped answering — often after a router or modem rebootPower-cycle the remote router/modem; check its internet uplink
Tunnel connected but devices unreachableThe site router blocks or does not route the traffic (on several router brands, VPN interfaces default to a WAN-like zone that only allows outgoing traffic)Debug tab: ping + ICMP capture — "traffic is leaving but nothing is answering" confirms it; add a route/firewall rule on the router
Outgoing OpenVPN never connectsSettings mismatch with the remote server (cipher, TLS version, compression …)Run Diagnose — it can propose the matching settings as a one-click fix
Outgoing WireGuard down right after a key/PSK changeThe tunnel has not reloaded the new keys yetRestart VPN on the card
Connection flaps (repeatedly up/down)Unstable uplink at the remote site, or one peer config used by two devicesConnection history on the card; issue a separate peer per device
Everything on the plant down at onceSite internet or power outage — not a VPN problemThe Overview tab's connection pipeline
MIT Licensed | Copyright 2026 Mirox Verwaltungs GmbH | Privacy