Troubleshooting — Remote Access

This guide covers the most common issues that arise when setting up or using remote access via Eziwan Gateway. Each issue is accompanied by its likely causes and troubleshooting steps.

Problem 1: The OpenVPN/IPSec VPN tunnel won't connect​

Symptom: The gateway appears offline in the Eziwan dashboard, or the tunnel status has remained "Connecting" for more than 2 minutes.

Possible Causes​

CauseProbabilityHow to Check
SIM card with no active data🔴 Very commonRed SIM LED on the gateway
Incorrect carrier APN🟠 CommonSIM logs in the web console
Firewall blocking UDP 1194🟠 FrequentTest from another network
Gateway not properly powered🟡 OccasionalPWR LED off or flashing
Eziwan Cloud account expired🟡 OccasionalCheck subscription status
OpenVPN IP address conflict🔵 RareOpenVPN logs on the gateway

Step-by-Step Solution​

Step 1 — Check the power supply

Check that the PWR LED is lit with a steady green light. The gateway requires a regulated power supply between 9 V DC and 36 V DC. An underpowered or noisy power supply may cause unexpected reboots.

LED PWR : vert fixe     → Alimentation OK
LED PWR : orange        → Tension limite (< 10V ou > 34V)
PWR LED: off → No power

Step 2 — Check 4G Connectivity

Check the SIM1 and SIM2 LEDs:

SIM LED: steady green     → Connected and data active
SIM LED: flashing green → Registered, no data
SIM LED: steady red    → SIM not recognized or PIN required
SIM LED: Off → No SIM card inserted

If the SIM LED is flashing green: Check the APN in the gateway's network settings. Contact your carrier to obtain the correct APN.

Step 3 — Check the network firewall

OpenVPN uses UDP port 1194 for outbound traffic. Make sure that no corporate firewall or proxy is blocking this outbound traffic.

# Test from a PC on the same network as the gateway
nc -zvu cloud.eziwan.com 1194
# Expected result: "Connection to cloud.eziwan.com on port 1194 [UDP] succeeded!"

If this test fails, contact your IT department to open UDP port 1194 for outbound traffic to cloud.eziwan.com.

Step 4 — Check the OpenVPN logs

From the gateway's web console (default: http://192.168.1.1):

Menu : Diagnostics → Logs → OpenVPN

Common errors in logs:

Log messageMeaningAction
Invalid handshakeCorrupted OpenVPN keysReset keys from the cloud
No route to hostDNS resolution failedCheck primary DNS (8.8.8.8)
Handshake timeoutFirewall blocking UDP 1194Open outgoing UDP port 1194
peer is unreachableEziwan Cloud unreachableCheck status at cloud.eziwan.com

Problem 2: High latency in the VPN tunnel​

Symptom: Connections through the tunnel are working but are slow (latency > 500 ms, throughput < 1 Mbps).

Causes and Solutions​

Reason 1: Weak 4G signal

Measuring RSRP from the web console:

Menu: Network → Cellular Status → Signal

Reference values:

RSRP (dBm)Signal QualityAction
> -80ExcellentNo action required
-80 to -95GoodCheck antenna alignment
-95 to -105FairExternal antenna recommended
< -105PoorReposition or use an outdoor antenna

Reason 2: MTU is too high

OpenVPN encapsulates packets. If the MTU of the OpenVPN interface is too large, IP fragmentation causes latency. Recommended value:

MTU OpenVPN : 1380 bytes (vs 1500 bytes Ethernet standard)

Edit the following in the gateway's OpenVPN configuration:

# .ovpn file for the gateway
tun-mtu 1380
mssfix 1340

Reason 3: 4G Bandwidth Congestion

If multiple MQTT + VPN + monitoring streams are running simultaneously, prioritize VPN traffic using QoS:

Menu: Network → QoS → VPN Priority: High

Problem 3: Frequent tunnel disconnections​

Symptom: The VPN tunnel disconnects every X minutes or hours and reconnects automatically.

Checking the OpenVPN keepalive​

By default, OpenVPN sends regular keepalive pings to keep the NAT tables active. Some 4G carriers have more aggressive NAT timeouts (< 20 s). Solution — reduce the interval in the .ovpn configuration:

# Ping every 10 seconds; restart the tunnel after 60 seconds without a response
keepalive 10 60

Reducing the keepalive ping to 10 seconds resolves 95% of disconnections related to carrier NAT tables.

Checking the Watchdog​

The Eziwan gateway has both a hardware and software watchdog. If the gateway restarts every X minutes:

Menu: Diagnostics → System Logs → Filter for "watchdog"

A watchdog reset may indicate overheating or a CPU load spike. Check that the temperature inside the electrical cabinet does not exceed 65°C (maximum operating temperature: +75°C).

Problem 4: Unable to reach the PLC via the tunnel​

Symptom: The VPN tunnel is established (gateway "online"), but connections to OT devices (PLCs, HMIs) fail.

Diagnostic Checklist​

1. Check IP routes

From your PC, with the OpenVPN client connected, verify that the route to the OT network is present:

# Windows
route print | findstr 192.168.
# Linux/Mac
ip route show

The path to the OT network (e.g., 192.168.100.0/24) must point to the OpenVPN interface (tun0).

2. Check for IP address conflicts

If your local network (office, remote work) uses the same subnet as the remote OT network, there will be a routing conflict.

Local Network (PC)Remote OT NetworkConflict
192.168.1.0/24192.168.100.0/24❌ No
192.168.1.0/24192.168.1.0/24✅ Yes — rename one of them

3. Check the PLC's local firewall

Some PLCs (such as the Siemens S7-1200/1500) have a built-in firewall. Check in TIA Portal:

TIA Portal → PLC Properties → Protection & Security → Connection Mechanisms

Allow connections from the IP address of the gateway's VPN interface (usually 10.10.0.x).

4. Test with a ping

From your PC, through the active VPN tunnel:

ping 192.168.100.1  # PLC IP address
ping 192.168.100.1 -l 64  # Ping avec payload 64 bytes

If the ping responds but an application (TIA Portal, Step 7) is not working, the problem is with a specific application port (Siemens S7Comm: TCP 102; Modbus TCP: TCP 502).

Problem 5: 2FA authentication fails​

Symptom: The TOTP code (Google Authenticator, Authy) is rejected during login.

Causes and Solutions​

CauseSolution
PC clock is off by > 30 sSynchronize the PC's NTP time
TOTP code has expired (valid for 30 s)Enter it immediately after it is generated
Wrong 2FA accountVerify that the correct account is selected in the app
2FA app resetRescan the QR code from the Eziwan portal

To resynchronize the NTP time on Windows:

w32tm /resync /force

To reconfigure a user's 2FA (admin privileges required):

Eziwan Portal → Users → [Technician Name] → Security → Reset 2FA

Complete Diagnostic Checklist (10 Steps)​

Follow these steps in order before contacting support:

  • 1. PWR green LED steady — power supply OK
  • 2. SIM1 or SIM2 green LED steady — 4G data active
  • 3. RSRP > -105 dBm — sufficient signal
  • 4. Outbound UDP port 1194 is not blocked from the gateway network
  • 5. DNS resolves cloud.eziwan.com from the gateway network
  • 6. No IP address conflict between the local network and the OT network
  • 7. VPN routes present on the client PC
  • 8. PLC firewall allows connections from the VPN IP
  • 9. PC clock synchronized (< 30 s offset)
  • 10. Active Eziwan Cloud account, subscription up to date

Contact Eziwan Support​

If the problem persists after following this checklist:

  1. Export diagnostic logs: Menu → Diagnostics → Export logs (.tar.gz file)
  2. Open a ticket at support.eziwan.com and attach the log file
  3. Provide the following details: gateway model, firmware version, SIM carrier, and an exact description of the problem

Eziwan technical support responds within < 4 business hours for partners and within < 24 hours for other customers.

Frequently Asked Questions​

The VPN tunnel won't connect—where do I start?​

First, check the gateway's connectivity (4G/Ethernet status in the console), then the device's clock (a significant time discrepancy invalidates the certificates), and finally, ensure that the site's firewall allows outbound traffic on UDP 1194 or TCP 443.

I can see the gateway is online, but not the PLC behind it?​

This is almost always a local routing issue: the PLC must have the Eziwan gateway set as its default gateway (or a static route to the VPN subnet), and its IP address must belong to the subnet specified in the console.

The remote session is slow—what should I check?​

First, check the 4G signal (RSRP < -110 dBm = degraded connection), then check the link load (is a large data transfer in progress?). When manufacturer consoles (such as TIA Portal) are loaded, enabling compression in the VPN profile is recommended.

An expired certificate is blocking the connection. How do I renew it?​

From the console: Certificates are rotated remotely without the need to travel, and automatic renewal before expiration can be enabled in the fleet settings to prevent recurrence.