WireGuard vs. OpenVPN vs. IPSec: Which Industrial VPN Should You Choose in 2025?
WireGuard, OpenVPN, or IPSec — the choice of VPN protocol is no small matter for an enterprise deployment. Latency, reliability of reconnection after a dual-SIM failover, traversing corporate firewalls, compatibility with legacy equipment, and NIS2 requirements: each protocol has its strengths and limitations in an OT context.
This comparison evaluates the three protocols from the perspective that matters most for industrial networks: not theoretical benchmarks over fiber, but real-world performance on 4G LTE with handover and dual-SIM failover, when compared to Siemens, Schneider, or Rockwell PLCs.
Why the Choice of VPN Protocol Matters in Industry
In traditional IT, all modern VPN protocols work. In an industrial OT environment, several constraints radically differentiate the options:
Latency and real-time protocols: Siemens' TIA Portal becomes unusable when latency exceeds 80 ms. The VPN protocol's overhead adds to the already variable LTE latency (typically 15–60 ms). Every millisecond counts.
Reconnection after a disconnection: On LTE, brief disconnections are common (handover between cell towers, temporary loss of coverage). A protocol that takes 30 seconds to reestablish its tunnel after a micro-disconnection is unusable for continuous monitoring.
Dual SIM failover: When the router switches from SIM1 (Orange) to SIM2 (SFR), the public IP address changes. Some protocols handle this IP change without interrupting the tunnel, while others do not.
Traversing corporate firewalls: Some industrial sites are behind corporate firewalls that block all non-standard UDP protocols. The VPN must be able to use TCP/443 if necessary.
FIPS 140-2 Compliance: Regulated environments (energy, water, defense) require FIPS 140-2-certified cryptographic suites.
WireGuard — The New High-Performance Standard
Architecture and Principles
WireGuard is a VPN protocol that has been in development since 2016, based on a philosophy that is radically different from that of its competitors: minimalism and performance. The source code is about 4,000 lines long (compared to 100,000+ for OpenVPN)—smaller, more auditable, and harder to hack.
Technical Specifications:
- Encryption: ChaCha20-Poly1305 (AEAD) — faster than AES on processors without AES-NI hardware acceleration
- Key exchange: Curve25519 (ECDH) + BLAKE2s (hash) + SipHash24 (routing table)
- Transport: UDP only (port 51820 by default, configurable)
- Model: peer-to-peer (no client/server distinction in the protocol)
- Kernel integration: natively integrated into Linux since version 5.6 — performance close to that of hardware
Performance on an Industrial ARM Gateway
WireGuard (ChaCha20-Poly1305) — measurements on the Eziwan gateway:
┌─────────────────────────────────────┐
│ Rated speed (LTE upload) │ 48 Mbps │
│ Measured download speed (LTE)│ 44 Mbps │
│ Latency added by the VPN │ +2–4 ms │
│ Temps reconnexion (coupure) │ 1–3 s │
│ Temps failover dual SIM │ 15–20 s │
│ Usage CPU gateway │ Faible │
└─────────────────────────────────────┘
Key advantage: WireGuard is 3 to 5 times faster than OpenVPN on ARM processors in industrial gateways, thanks to its kernel integration and ChaCha20, which does not require hardware-based AES acceleration.
Critical weakness: WireGuard uses UDP only. If there is a corporate firewall that blocks non-standard UDP traffic, WireGuard will not work. In industrial environments with sites behind strict corporate networks, this can be a deal-breaker.
WireGuard and Dual-SIM Failover
WireGuard handles public IP changes (roaming) more gracefully than traditional IPSec thanks to its peer-to-peer design. After a dual-SIM failover:
- New public IP obtained on SIM2
- WireGuard sends a keepalive packet → the peer recognizes the new IP
- The tunnel resumes in 2 to 8 seconds
This behavior depends on the PersistentKeepalive configuration (recommended: 25 seconds) and the NAT firewall on the concentrator side.
OpenVPN — The Proven, Universal Standard
Architecture and Principles
OpenVPN (2001) is based on the OpenSSL/TLS library, the most thoroughly audited in the world. Its strength lies in its transport flexibility.
Technical Specifications:
- Encryption: AES-256-GCM (AEAD) or AES-128-GCM
- Authentication: X.509 certificates (mutual TLS) + optional username/password
- Transport: UDP 1194 (performance) or TCP 443 (firewall traversal)
- Compatibility: Linux, Windows, macOS, iOS, Android, routers, FreeBSD...
- Maturity: code independently audited multiple times, in use for 20 years
The Decisive Advantage: TCP/443 to Get Through Any Firewall
That's the key difference from WireGuard. OpenVPN can run over TCP on port 443—the same port used by HTTPS. This means it can operate in environments where all UDP traffic is filtered:
When OpenVPN TCP/443 is essential:
├─ Enterprise firewall that blocks all outbound UDP traffic (very common)
├─ Site behind a transparent HTTP(S) proxy (hospitals, local governments)
├─ Mobile network with DPI (Deep Packet Inspection) that filters non-HTTP protocols
└─ Highly restricted network environments (airport, port, restricted area)
The industry rule: If you don't have control over the outgoing network at your sites (customer sites, leased sites, restricted areas), OpenVPN is the default choice—it will work anywhere.
Performance on an Industrial ARM Gateway
OpenVPN (AES-256-GCM) — measurements on the Eziwan Gateway:
┌─────────────────────────────────────┐
│ Rated speed (LTE upload) │ 38 Mbps │
│ Measured download speed (LTE)│ 35 Mbps │
│ Latency added by the VPN │ +5–12 ms│
│ Temps reconnexion (persist-tun)│ 5–15 s│
│ Temps failover dual SIM │ 20–40 s │
│ Gateway CPU usage │ Moderate │
└─────────────────────────────────────┘
Note: For common industrial applications (Modbus, SCADA monitoring, remote PLC access), 10 Mbps is more than enough. The difference in performance between WireGuard and OpenVPN is not a distinguishing factor in practice.
OpenVPN and Dual-SIM Failover
OpenVPN with persist-tun and keepalive 25 120 keeps the tunnel active during brief disconnections. During dual-SIM failover (change in public IP address):
- The existing tunnel "drops" (the public IP address changes)
- The automatic reconnection mechanism restarts the TLS handshake
- Reconnection takes 20 to 40 seconds, depending on the configuration
Configuring connect-retry 5 and connect-retry-max 10 in the OpenVPN profile reduces reconnection delays. Monitoring the connection via ping-restart 60 prevents “zombie” tunnels that appear active but are no longer transmitting data.
IPSec / IKEv2 — The enterprise-grade, certifiable alternative
Architecture and Principles
IPSec is a set of protocols defined by the IETF to secure IP communications. With IKEv2 (Internet Key Exchange version 2), it offers superior performance and mobility compared to previous versions.
Technical Specifications:
- Encryption: AES-256-GCM, AES-128-GCM, AES-CBC (configurable)
- Authentication: X.509 certificates, PSK (Pre-Shared Key), EAP
- Transport: UDP 500 (IKE) + UDP 4500 (ESP NAT-traversal)
- MOBIKE extension (IKEv2): IP address change without tunnel interruption
- Certifications: FIPS 140-2, Common Criteria — the only certifiable protocol for regulated environments in France
IPSec and Dual-SIM Failover: The MOBIKE Advantage
The MOBIKE extension (RFC 4555) is the key feature of IKEv2 in industrial settings with failover:
MOBIKE — Behavior During Dual-SIM Failover:
Avant failover : IP publique = 82.XX.XX.XX (Orange)
Failover : IP publique change → 185.XX.XX.XX (SFR)
MOBIKE: Notifies the hub of the IP address change
Result: IPSec tunnel maintained continuously, WITHOUT any interruptions
Failover time: < 2 seconds (if MOBIKE enabled on both sides)
It is the only protocol that enables truly transparent dual-SIM failover for mission-critical industrial applications (no reconnection, no interruption of the Modbus or SCADA data stream).
Limitations:
- Significantly higher configuration complexity (IKE policies, ESP transform sets, AH vs. ESP, tunnel/transport modes)
- NAT traversal can sometimes be problematic depending on the intermediate firewalls
- No TCP/443 fallback available (UDP required)
A Comprehensive Comparison of the 3 Protocols
Performance and Reliability
| Criterion | WireGuard | OpenVPN | IPSec / IKEv2 |
|---|---|---|---|
| Encrypted throughput (ARM gateway) | ⭐⭐⭐⭐⭐ 48 Mbps | ⭐⭐⭐⭐ 38 Mbps | ⭐⭐⭐⭐ 40 Mbps |
| Added latency | ⭐⭐⭐⭐⭐ +2–4 ms | ⭐⭐⭐⭐ +5–12 ms | ⭐⭐⭐⭐ +4–8 ms |
| Reconnection after a brief outage | ⭐⭐⭐⭐ 2–5 s | ⭐⭐⭐ 10–20 s | ⭐⭐⭐⭐ 3–8 s |
| Dual SIM failover (MOBIKE/roaming) | ⭐⭐⭐⭐ 15–25 s | ⭐⭐⭐ 20–40 s | ⭐⭐⭐⭐⭐ < 2 s (MOBIKE) |
Security and Compliance
| Criterion | WireGuard | OpenVPN | IPSec / IKEv2 |
|---|---|---|---|
| Encryption Algorithm | ChaCha20-Poly1305 | AES-256-GCM | AES-256-GCM |
| Attack Surface (Code Size) | ⭐⭐⭐⭐⭐ ~4,000 lines | ⭐⭐⭐ ~100,000 lines | ⭐⭐⭐ Complex standard |
| FIPS 140-2 certification | ❌ No | ⭐⭐⭐ Partial (OpenSSL) | ⭐⭐⭐⭐⭐ Native |
| Independent security audits | ⭐⭐⭐⭐ (2021) | ⭐⭐⭐⭐⭐ (numerous) | ⭐⭐⭐⭐⭐ (IETF) |
| NIS2 compliance | ✅ Yes | ✅ Yes | ✅ Yes |
Deployment and Operations
| Criterion | WireGuard | OpenVPN | IPSec / IKEv2 |
|---|---|---|---|
| TCP/443 firewall traversal | ❌ UDP only | ✅ TCP or UDP | ❌ UDP only |
| Legacy device compatibility | ⭐⭐⭐ Recent | ⭐⭐⭐⭐⭐ Universal | ⭐⭐⭐⭐ Native Cisco/Fortinet |
| Ease of configuration | ⭐⭐⭐⭐⭐ Simple | ⭐⭐⭐⭐ Reasonable | ⭐⭐ Complex |
| Fleet management (ZTP) | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Supported Clients (OS) | ⭐⭐⭐⭐ Windows/Mac/Linux/iOS/Android | ⭐⭐⭐⭐⭐ All | ⭐⭐⭐⭐ Native on all OS |
Decision Tree: Which Protocol Should You Use for Your Deployment?
Does your environment require FIPS 140-2 or certification?
→ OUI : IPSec/IKEv2 uniquement
→ NON : continuer
Your sites are behind strict corporate firewalls
(UDP blocked, DPI, transparent proxy)?
→ YES: OpenVPN TCP/443 (the only protocol that works everywhere)
→ NON : continuer
Tunnel Continuity During a Dual-SIM Failover
Is it critical (real-time monitoring, safety alarms)?
→ YES: IPSec/IKEv2 with MOBIKE (or WireGuard with short keepalives)
→ NON : continuer
Do you have gateways with low-end ARM processors?
or battery constraints (solar/battery site)?
→ OUI : WireGuard (faible consommation CPU)
→ NON : continuer
Default recommendation:
→ OpenVPN AES-256-GCM (universality, maturity, ZTP Eziwan)
Recommendation Table by Use Case
| Use Case | Recommended Protocol | Main Reason |
|---|---|---|
| Standard deployment (50 sites, LTE) | OpenVPN | Universality, ZTP, maturity |
| Sites behind strict corporate firewalls | OpenVPN TCP/443 | The only protocol that can pass through all firewalls |
| Absolute continuity (water and energy monitoring) | IPSec + MOBIKE | Transparent dual-SIM failover |
| FIPS-regulated environment (defense, nuclear) | IPSec/IKEv2 | Mandatory certification |
| Low-power ARM gateway (solar) | WireGuard | Performance/power consumption |
| Migration from Cisco/Juniper infrastructure | IPSec/IKEv2 | Native interoperability |
| Mobile technician access (4G, Starlink, Wi-Fi) | WireGuard | Fast reconnection on variable networks |
Configuration on the Eziwan Gateway
The Eziwan Gateway natively supports all three protocols. Configuration is done through the cloud dashboard or via YAML for automated deployments.
OpenVPN — Sample Configuration
# /etc/openvpn/eziwan-site.conf — automatically generated via ZTP
client
dev tun
proto udp # Use 'tcp' + port 443 if the firewall is strict
remote vpn.eziwan.com 1194
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
keepalive 25 120 # Maintains the connection through the ISP's NAT
persist-tun # Prevents the tun interface from being recreated upon reconnection
persist-key
connect-retry 5 30 # Quick reconnection in the event of an outage
nobind # No ports are listening on the server side (outbound only)
# X.509 certificate issued by Eziwan Zero-Touch Provisioning
WireGuard — Sample Configuration
# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <gateway private key — generated during ZTP>
Address = 10.24.1.X/32 # IP tunnel assigned by Eziwan
DNS = 10.24.0.1
[Peer]
PublicKey = <Eziwan Public Key Hub>
Endpoint = wg.eziwan.com:51820
AllowedIPs = 10.24.0.0/16 # Split tunneling: Only Eziwan traffic goes through the tunnel
PersistentKeepalive = 25 # Keeps the tunnel active through LTE NAT
IPSec (IKEv2) — strongSwan Configuration
# /etc/ipsec.conf — section connexion Eziwan
conn eziwan-site
keyexchange=ikev2
left=%defaultroute # Site's public IP address (dynamic LTE)
leftid=@site-lyon.eziwan.com
leftcert=site-lyon.crt
right=ipsec.eziwan.com
rightid=@concentrateur.eziwan.com
rightsubnet=10.24.0.0/16
ike=aes256gcm16-sha256-curve25519!
esp=aes256gcm16-sha256!
auto=start
mobike=yes # MOBIKE for transparent dual-SIM failover
dpdaction=restart
dpdtimeout=120s
Security: Key Considerations for All Protocols
Regardless of the protocol chosen, these practices are non-negotiable:
1. No Incoming Ports on the OT Network The VPN tunnel must always be established from the industrial site to the hub (outbound connection). No incoming ports should be open on the site's network.
2. Authentication via certificate, not PSK A Pre-Shared Key (PSK) shared among multiple sites is a security risk—if one site is compromised, all of them are. Use individual X.509 certificates for each site.
3. Perfect Forward Secrecy (PFS) enabled PFS (DHE or ECDHE) ensures that the compromise of a long-term key does not compromise past sessions. It is enabled by default in OpenVPN and WireGuard; check the IPSec configurations to verify.
4. Certificate Rotation Certificates have a limited validity period (maximum 2 years). The Eziwan platform automatically renews certificates before they expire.
An expired VPN certificate simultaneously cuts off remote access to all sites using that certificate. Check the expiration dates of all your certificates and enable automatic renewal.
Frequently Asked Questions
Is WireGuard more secure than OpenVPN? In terms of cryptographic algorithms, WireGuard uses modern primitives (ChaCha20, Curve25519, BLAKE2s) with a minimal attack surface (~4,000 lines of code). OpenVPN uses OpenSSL, which has been audited much more extensively but is more complex. In practice, both are secure for modern production deployments—the real risk lies in the configuration, not in the protocol.
Can WireGuard and OpenVPN be used simultaneously at the same location? Yes. The Eziwan Gateway can maintain multiple VPN tunnels simultaneously to different access points. This can be useful for redundancy or phased migration scenarios.
Is IPSec compatible with our Cisco ASA / Fortinet FortiGate firewall? Yes — IPSec/IKEv2 is the standard interoperability protocol for enterprise networking equipment. The Eziwan Gateway can establish an IPSec tunnel to a Cisco ASA, FortiGate, Palo Alto, or Juniper SRX in a standard site-to-site configuration.
What is the difference between OpenVPN and OpenVPN Access Server? OpenVPN (open source) is the protocol. OpenVPN Access Server is a commercial distribution with a web-based management interface. Eziwan integrates OpenVPN (open source) with its own centralized management platform—no need for a separate OpenVPN Access Server.
Is WireGuard compatible with older Windows systems (Windows 7, Windows Server 2008)? WireGuard has been natively integrated into Windows since Windows 10/Server 2019. On Windows 7 and Server 2008, WireGuard works but requires a third-party client (kernel integration is not available). OpenVPN remains more universally compatible on older systems.
How does an industrial VPN coexist with ADSL during a migration? No problem—the VPN works on any Internet connection (ADSL, LTE, fiber). The ADSL → LTE migration can be done using the same VPN tunnel: you keep the same VPN configuration and simply change the router’s WAN connection.
Further Reading
- Guide: Secure Remote Access for PLCs and SCADA — Complete Architecture
- Comparison: Industrial VPN vs. Zero Trust Network Access
- Documentation: VPN Configuration on the Eziwan Gateway
- NIS2 — Compliance Checklist for Industry
- Guide: OT Cybersecurity — Threats in 2026
In summary: OpenVPN remains the default choice due to its universal compatibility. WireGuard is the best option when CPU performance and minimal latency are critical. IPSec/IKEv2 is essential for regulated (FIPS) environments and fully transparent dual-SIM failover scenarios.
The common thread: all three protocols are vastly superior to not using a VPN—which, unfortunately, remains the case for many French industrial sites that expose their PLCs directly to the Internet.
Questions about choosing a VPN for your network? Talk to our technical team — configuration audit and recommendations with no obligation.
Additional Resources
- Industrial VPN — VPN solutions tailored for industrial OT networks
- Industrial VPN Comparison Guide — in-depth analysis of protocols
- Industrial Cybersecurity — overview of threats and security best practices
- Industrial Remote Access — secure architectures for accessing PLCs
- Traditional VPN vs. Industrial Remote Access — choosing the right approach
