Troubleshooting — Accès Distant

Ce guide couvre les problèmes les plus fréquents lors de la configuration ou de l'utilisation de l'accès distant via Eziwan Gateway. Chaque problème est accompagné de ses causes probables et des étapes de résolution.

Problème 1 : Le tunnel VPN OpenVPN/IPSec ne s'établit pas​

Symptôme : La gateway apparaît hors ligne dans le tableau de bord Eziwan, ou le statut du tunnel reste sur "Connecting" depuis plus de 2 minutes.

Causes possibles​

CauseProbabilitéComment vérifier
Carte SIM sans données actives🔴 Très fréquenteLED SIM rouge sur la gateway
APN opérateur incorrect🟠 FréquenteLogs SIM dans la console web
Firewall bloquant UDP 1194🟠 FréquenteTest depuis un autre réseau
Gateway non alimentée correctement🟡 OccasionnelleLED PWR éteinte ou clignotante
Compte Eziwan Cloud expiré🟡 OccasionnelleVérifier statut abonnement
Conflit d'adresse IP OpenVPN🔵 RareLogs OpenVPN sur gateway

Résolution étape par étape​

Étape 1 — Vérifier l'alimentation

Contrôlez que la LED PWR est allumée en vert fixe. La gateway requiert une alimentation stabilisée entre 9 V DC et 36 V DC. Une alimentation sous-dimensionnée ou bruitée peut causer des redémarrages intempestifs.

LED PWR : vert fixe     → Alimentation OK
LED PWR : orange        → Tension limite (< 10V ou > 34V)
LED PWR : éteinte       → Pas d'alimentation

Étape 2 — Vérifier la connectivité 4G

Contrôlez les LED SIM1 et SIM2 :

LED SIM : vert fixe     → Connectée et données actives
LED SIM : vert clignotant → Enregistrée, pas de données
LED SIM : rouge fixe    → SIM non reconnue ou PIN requis
LED SIM : éteinte       → Aucune SIM insérée

Si la LED SIM est verte clignotante : vérifiez l'APN dans la configuration réseau de la gateway. Contactez votre opérateur pour obtenir l'APN correct.

Étape 3 — Vérifier le pare-feu réseau

OpenVPN utilise le port UDP 1194 en sortant. Vérifiez qu'aucun firewall d'entreprise ou proxy ne bloque ce trafic sortant.

# Test depuis un PC sur le même réseau que la gateway
nc -zvu cloud.eziwan.com 1194
# Résultat attendu : "Connection to cloud.eziwan.com 1194 port [udp] succeeded!"

Si ce test échoue, contactez votre DSI pour ouvrir le port UDP 1194 en sortant vers cloud.eziwan.com.

Étape 4 — Vérifier les logs OpenVPN

Depuis la console web de la gateway (http://192.168.1.1 par défaut) :

Menu : Diagnostics → Logs → OpenVPN

Erreurs fréquentes dans les logs :

Message de logSignificationAction
Invalid handshakeClés OpenVPN corrompuesRéinitialiser les clés depuis le cloud
No route to hostRésolution DNS échoueVérifier DNS primaire (8.8.8.8)
Handshake timeoutFirewall bloque UDP 1194Ouvrir le port UDP 1194 sortant
peer is unreachableCloud Eziwan inaccessibleVérifier statut cloud.eziwan.com

Problème 2 : Latence élevée dans le tunnel VPN​

Symptôme : Les connexions via le tunnel fonctionnent mais sont lentes (> 500 ms de latence, débit < 1 Mbps).

Causes et solutions​

Cause 1 : Signal 4G faible

Mesurer le RSRP depuis la console web :

Menu : Réseau → Statut cellulaire → Signal

Valeurs de référence :

RSRP (dBm)Qualité signalAction
> -80ExcellentAucune action
-80 à -95BonVérifier orientation antenne
-95 à -105MoyenAntenne externe recommandée
< -105FaibleRepositionner ou antenne outdoor

Cause 2 : MTU trop élevé

OpenVPN encapsule les paquets. Si le MTU de l'interface OpenVPN est trop grand, la fragmentation IP crée de la latence. Valeur recommandée :

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

Modifier dans la configuration OpenVPN de la gateway :

# fichier .ovpn de la gateway
tun-mtu 1380
mssfix 1340

Cause 3 : Encombrement de la bande passante 4G

Si plusieurs flux MQTT + VPN + supervision tournent simultanément, priorisez le trafic VPN via QoS :

Menu : Réseau → QoS → Priorité VPN : Élevée

Problème 3 : Déconnexions fréquentes du tunnel​

Symptôme : Le tunnel VPN se coupe toutes les X minutes ou heures et se rétablit automatiquement.

Vérification du keepalive OpenVPN​

Par défaut, OpenVPN envoie un ping de keepalive régulier pour maintenir les tables NAT actives. Certains opérateurs 4G ont des timeouts NAT plus agressifs (< 20 s). Solution — réduire l'intervalle dans la configuration .ovpn :

# ping toutes les 10 s, redémarrage du tunnel après 60 s sans réponse
keepalive 10 60

Réduire le ping de keepalive à 10 s résout 95 % des déconnexions liées aux tables NAT opérateur.

Vérification du watchdog​

La gateway Eziwan dispose d'un watchdog matériel et logiciel. Si la gateway redémarre toutes les X minutes :

Menu : Diagnostics → Logs Système → Filtrer "watchdog"

Un redémarrage watchdog peut indiquer une surchauffe ou un pic de charge CPU. Vérifiez que la température de l'armoire électrique ne dépasse pas 65°C (température opérationnelle max : +75°C).

Problème 4 : Impossible d'atteindre l'automate via le tunnel​

Symptôme : Le tunnel VPN est établi (gateway "en ligne") mais les connexions vers les équipements OT (automates, HMI) échouent.

Check-list diagnostic​

1. Vérifier les routes IP

Depuis votre PC avec le client OpenVPN connecté, vérifiez que la route vers le réseau OT est bien présente :

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

La route vers le réseau OT (ex: 192.168.100.0/24) doit pointer vers l'interface OpenVPN (tun0).

2. Vérifier l'absence de conflit d'adresses IP

Si votre réseau local (bureau, télétravail) utilise le même sous-réseau que le réseau OT distant, il y aura un conflit de routage.

Réseau local (PC)Réseau OT distantConflit
192.168.1.0/24192.168.100.0/24❌ Non
192.168.1.0/24192.168.1.0/24✅ Oui — renommer l'un des deux

3. Vérifier le firewall local de l'automate

Certains automates (notamment Siemens S7-1200/1500) ont un firewall intégré. Vérifiez dans TIA Portal :

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

Autoriser les connexions depuis l'adresse IP de l'interface VPN de la gateway (généralement 10.10.0.x).

4. Tester avec un ping

Depuis votre PC, via le tunnel VPN actif :

ping 192.168.100.1  # IP de l'automate
ping 192.168.100.1 -l 64  # Ping avec payload 64 bytes

Si le ping répond mais qu'une application (TIA Portal, Step 7) ne fonctionne pas, le problème vient d'un port applicatif spécifique (Siemens S7Comm : TCP 102 ; Modbus TCP : TCP 502).

Problème 5 : L'authentification 2FA échoue​

Symptôme : Le code TOTP (Google Authenticator, Authy) est refusé à la connexion.

Causes et solutions​

CauseSolution
Horloge PC décalée de > 30 sSynchroniser l'heure NTP du PC
Code TOTP expiré (30 s de validité)Saisir immédiatement après génération
Mauvais compte 2FAVérifier que le bon compte est sélectionné dans l'app
Application 2FA réinitialiséeRe-scanner le QR code depuis le portail Eziwan

Pour resynchroniser l'heure NTP sur Windows :

w32tm /resync /force

Pour reconfigurer le 2FA d'un utilisateur (admin requis) :

Portail Eziwan → Utilisateurs → [Nom technicien] → Sécurité → Réinitialiser 2FA

Checklist complète de diagnostic (10 étapes)​

Suivre ces étapes dans l'ordre avant de contacter le support :

  • 1. LED PWR verte fixe — alimentation correcte
  • 2. LED SIM1 ou SIM2 verte fixe — données 4G actives
  • 3. RSRP > -105 dBm — signal suffisant
  • 4. Port UDP 1194 sortant non bloqué depuis le réseau de la gateway
  • 5. DNS résout cloud.eziwan.com depuis le réseau de la gateway
  • 6. Pas de conflit d'adresses IP entre réseau local et réseau OT
  • 7. Routes VPN présentes sur le PC client
  • 8. Firewall automate autorise les connexions depuis l'IP VPN
  • 9. Horloge PC synchronisée (< 30 s de décalage)
  • 10. Compte Eziwan Cloud actif, abonnement à jour

Contacter le support Eziwan​

Si le problème persiste après avoir suivi cette checklist :

  1. Exporter les logs de diagnostic : Menu → Diagnostics → Exporter les logs (fichier .tar.gz)
  2. Ouvrir un ticket sur support.eziwan.com en joignant le fichier de logs
  3. Préciser : modèle de la gateway, version firmware, opérateur SIM, description exacte du problème

Le support technique Eziwan répond en < 4h ouvrées pour les partenaires et en < 24h pour les autres clients.

Questions fréquentes​

Le tunnel VPN ne monte pas, par où commencer ?​

Vérifiez d'abord la connectivité de la gateway (statut 4G/Ethernet dans la console), puis l'horloge de l'équipement (un décalage important invalide les certificats), et enfin que le pare-feu du site laisse sortir UDP 1194 ou TCP 443.

Je vois la gateway en ligne mais pas l'automate derrière ?​

C'est presque toujours un problème de routage local : l'automate doit avoir la gateway Eziwan comme passerelle par défaut (ou une route statique vers le sous-réseau VPN), et son IP doit appartenir au sous-réseau déclaré dans la console.

La session distante est lente, que vérifier ?​

Le signal 4G d'abord (RSRP < -110 dBm = lien dégradé), puis la charge du lien (transfert volumineux en cours ?). Les consoles constructeur chargées (TIA Portal) bénéficient de l'activation de la compression dans le profil VPN.

Un certificat expiré bloque la connexion, comment le renouveler ?​

Depuis la console : la rotation des certificats se fait à distance sans déplacement, et le renouvellement automatique avant expiration s'active dans les paramètres de flotte pour éviter la récidive.

Ressources associées​