OpenVPN reste l'une des solutions VPN les plus robustes et les plus universellement compatibles pour donner accès au réseau de l'entreprise à des utilisateurs distants. Sur MikroTik, sa configuration demande quelques étapes précises — notamment côté certificats et routes push — et c'est facile de bloquer sur des détails. Ce tutoriel reprend la procédure complète, testée en production sur RouterOS 7.16, avec les pièges qu'on rencontre vraiment sur le terrain.
Client-to-Site ou Site-to-Site ?
Avant de plonger dans la config, il faut clarifier ce qu'on construit. Les deux architectures VPN n'ont pas le même usage ni la même complexité.
Client-to-Site (Remote Access)
Un utilisateur isolé (laptop, smartphone, poste à domicile) se connecte au réseau de l'entreprise pour accéder aux ressources internes (serveurs, NAS, imprimantes, applications métier). C'est l'architecture la plus fréquente pour le télétravail, les commerciaux en déplacement, ou les interventions depuis l'extérieur.
Site-to-Site
Deux réseaux d'entreprise sont interconnectés en permanence — typiquement le siège et une agence, ou deux sites d'un même groupe. Le tunnel est monté en continu entre les deux routeurs, et les utilisateurs des deux côtés voient les ressources de l'autre site comme s'ils étaient sur le même LAN.
Si vous avez besoin d'un Site-to-Site MikroTik (siège + agence par exemple), la configuration est différente — IPsec ou EoIP-over-IPsec sont généralement préférables à OpenVPN pour ce cas. On pourra y consacrer un article dédié.
Ce qu'il vous faut avant de commencer
Quatre prérequis incontournables. Si l'un manque, le serveur OpenVPN ne pourra pas être joignable depuis l'extérieur ou ne pourra pas être configuré proprement.
- Un routeur MikroTik en RouterOS 7.14 minimum (idéalement 7.16 ou supérieur — certaines commandes de ce tuto utilisent la syntaxe RouterOS 7.x récente).
- Une IP publique fixe ou à défaut un nom de domaine DynDNS pointant en permanence vers votre routeur. Sans ça, les clients ne pourront pas se reconnecter de manière fiable.
- Accès au terminal du routeur via Winbox (avec le terminal intégré) ou en SSH. Les commandes de ce tutoriel sont conçues pour être copiées-collées dans le terminal.
- Connaissances basiques RouterOS : naviguer dans les menus, comprendre les chemins de commande (
/system/certificate,/ip/pool, etc.), savoir consulter les logs.
Avant 7.14, certaines commandes liées à la gestion des routes push et au format des certificats diffèrent. Ce tutoriel a été validé sur 7.16 en production. Si vous êtes en version antérieure, consultez la documentation officielle MikroTik pour adapter la syntaxe.
Création des certificats PKI
OpenVPN s'appuie sur une infrastructure à clés publiques (PKI) pour authentifier serveur et clients. Concrètement, vous allez créer trois certificats :
- Un certificat d'autorité (CA) qui sert à signer les autres certificats.
- Un certificat serveur que le routeur MikroTik présente aux clients.
- Un certificat client par utilisateur (ici on prend "Alice" comme exemple).
Création des trois certificats
Connectez-vous au terminal de votre MikroTik et tapez :
/system/certificate
add name=CA common-name=CA key-usage=key-cert-sign,crl-sign
add name=server common-name=server
add name=Alice common-name=AliceÀ ce stade les trois certificats existent mais ne sont pas encore signés. Le rôle du paramètre key-usage sur le CA est important : il autorise ce certificat à signer les autres et à publier des listes de révocation.
Signature des certificats
Dans la commande ci-dessous, IP-Publique-x.x.x.x doit être remplacé par votre vraie IP publique (par exemple 203.0.113.45) ou votre nom DynDNS (par exemple monvpn.dyndns.org). Cette information est inscrite dans le certificat CA et sert à valider la connexion depuis les clients.
/system/certificate
sign CA ca-crl-host=IP-Publique-x.x.x.x name=CA
sign server ca=CA name=server
sign Alice ca=CA name=AliceConcrètement avec une IP publique 203.0.113.45, la première ligne devient sign CA ca-crl-host=203.0.113.45 name=CA.
Marquer les certificats comme fiables
/system/certificate
set CA trusted=yes
set server trusted=yesExport pour le client
Le client distant aura besoin du certificat CA (pour vérifier l'identité du serveur) et de son propre certificat client.
/certificate export-certificate CA
/certificate export-certificate Alice export-passphrase="MotDePasseSecurise123"Remplacez MotDePasseSecurise123 par une phrase de passe forte. Elle protège la clé privée du certificat Alice et sera demandée au client lors de la connexion. Les fichiers exportés se retrouvent dans le menu Files de Winbox — vous pourrez les récupérer plus tard pour les transférer au client.
Vos trois certificats sont créés, signés et exportés. À ce stade ils sont en attente — la suite consiste à connecter ces certificats à un pool d'IP et à une logique d'authentification PPP.
Pool d'adresses IP et profil PPP
Quand un client se connecte au VPN, il reçoit une IP dans un pool dédié. Ce pool ne doit pas chevaucher votre réseau local existant — sinon vous aurez des conflits de routage.
Création du pool
Si votre LAN est en 192.168.1.0/24, prenez par exemple 10.0.0.0/24 pour le VPN. Le pool ci-dessous permet jusqu'à 41 clients simultanés (de .10 à .50).
/ip/pool
add name=ovpn-pool ranges=10.0.0.10-10.0.0.50Profil PPP
Le profil PPP définit l'IP du serveur côté VPN (local-address) et le pool dans lequel piocher les IP clients (remote-address).
/ppp/profile
add name=itd-ovpn local-address=10.0.0.5 remote-address=ovpn-poolCréation de l'utilisateur (secret PPP)
L'authentification combine certificat (CA + client) et identifiant/mot de passe PPP. Le nom de l'utilisateur PPP doit correspondre exactement au common-name du certificat client.
/ppp/secret
add name=Alice password="MotDePasseVPN456" profile=itd-ovpnLe name du secret PPP doit être strictement identique au common-name du certificat. Une majuscule ou un espace en trop, et l'authentification échoue silencieusement côté serveur — c'est l'une des erreurs les plus fréquentes en dépannage.
Activation du serveur OpenVPN
Tout est en place côté authentification et adressage. Reste à activer le service OpenVPN proprement dit.
/interface/ovpn-server/server
set enabled=yes certificate=serverLe serveur écoute désormais sur le port 1194/TCP par défaut. Si votre routeur a un pare-feu actif (ce qui devrait être le cas), il faut ouvrir ce port en entrée pour que les clients puissent atteindre le service.
Règle pare-feu
/ip/firewall/filter
add chain=input protocol=tcp dst-port=1194 action=accept comment="OpenVPN"L'ordre des règles de pare-feu compte sur MikroTik. Cette règle d'acceptation doit être placée avant une éventuelle règle de blocage générique. Vérifiez avec /ip/firewall/filter print que la règle OpenVPN est bien atteinte avant un éventuel drop.
Routes push : l'étape critique
C'est ici que la plupart des configurations OpenVPN MikroTik échouent silencieusement. Sans routes push, le tunnel monte mais le client n'arrive à joindre aucune ressource du LAN distant.
Pourquoi c'est important
Par défaut, sans routes push correctement configurées, deux comportements sont possibles selon la config client :
- Soit tout le trafic du client passe par le VPN (y compris la navigation Internet), ce qui dégrade les performances et fait apparaître votre IP publique comme l'origine de tous les flux.
- Soit aucun trafic ne sait où aller, et le client est connecté au VPN sans pouvoir joindre quoi que ce soit du LAN distant.
Les routes push servent à dire au client : « pour atteindre tel sous-réseau précis, passe par le tunnel VPN. Le reste, continue à passer par ta connexion Internet normale ». C'est ce qu'on appelle le split tunneling.
Ajouter les routes
Exemple : votre réseau LAN d'entreprise est 192.168.1.0/24. Vous voulez que seul ce réseau passe par le VPN.
/interface/ovpn-server/server
set push-routes="192.168.1.0 255.255.255.0"Si vous avez plusieurs sous-réseaux à pousser (par exemple un LAN postes 192.168.1.0/24 et un VLAN serveurs 192.168.10.0/24), vous pouvez les concaténer :
set push-routes="192.168.1.0 255.255.255.0,192.168.10.0 255.255.255.0"- Sans routes push correctes : soit tout le trafic passe par le VPN (IP publique de sortie = celle du MikroTik), soit le client n'accède à rien.
- Avec routes push correctes : seul le trafic vers le LAN d'entreprise passe par le VPN, le reste utilise la connexion locale du client. C'est le bon comportement dans 95 % des cas.
Export du fichier de configuration client
RouterOS 7 sait générer automatiquement un fichier .ovpn prêt à l'emploi, qui contient à la fois la configuration et les certificats nécessaires côté client.
Via Winbox
- Ouvrez Winbox et connectez-vous au routeur.
- Menu PPP, onglet OVPN Server.
- Cliquez sur Generate Client Config.
- Sélectionnez le profil
Alice. - Cliquez sur Generate.
Récupération du fichier
Le fichier Alice.ovpn apparaît dans le menu Files. Clic droit sur le fichier puis Download. Transmettez-le à l'utilisateur final par un canal sécurisé (pas en pièce jointe email non chiffrée — préférez un partage temporaire chiffré ou une remise physique).
Ce fichier embarque la clé privée du client et lui permet de se connecter au VPN d'entreprise. Il doit être traité comme un mot de passe : transmission sécurisée, stockage chiffré côté utilisateur, suppression en cas de départ du collaborateur.
Configuration du client OpenVPN
Une fois le fichier Alice.ovpn récupéré côté utilisateur, son intégration est rapide. Voici la procédure pour les trois familles de systèmes les plus courantes.
Sur Windows
- Installer le client OpenVPN Community.
- Copier le fichier
Alice.ovpndansC:\Program Files\OpenVPN\config\. - Lancer OpenVPN GUI (l'icône apparaît dans la barre des tâches).
- Clic droit sur l'icône → Connect.
- Saisir la phrase de passe de la clé privée (celle définie à l'étape 1 lors de l'export du certificat).
Sur macOS et Linux
Sur macOS, l'application Tunnelblick est l'interface graphique de référence. Sur Linux, le client OpenVPN est généralement disponible directement dans le gestionnaire de paquets.
# Installation sur Debian / Ubuntu
sudo apt install openvpn
# Lancement de la connexion
sudo openvpn --config Alice.ovpnSur Android et iOS
- Installer l'application OpenVPN Connect depuis le Play Store ou l'App Store.
- Transférer le fichier
Alice.ovpnsur le téléphone (par email chiffré, AirDrop, ou stockage cloud sécurisé). - Ouvrir le fichier avec OpenVPN Connect, valider l'import.
- Lancer la connexion, saisir la phrase de passe.
Tests post-déploiement
Côté MikroTik
Une fois le client connecté, vérifiez la session active sur le routeur :
/ppp/active printVous devriez voir une ligne avec l'utilisateur Alice, son IP attribuée (par exemple 10.0.0.10) et le service ovpn. Dans Winbox, l'équivalent graphique est le menu PPP → onglet Active Connections.
Côté client
Depuis le poste connecté au VPN, lancez quelques tests réseau pour valider que tout est joignable :
# Ping du gateway VPN (devrait répondre)
ping 10.0.0.5
# Ping d'une machine du LAN distant
ping 192.168.1.10
# Test d'accès à un service réel (NAS, serveur de fichiers, etc.)
ping fichiers.entreprise.localSi les pings vers le gateway VPN passent mais pas vers le LAN, c'est très probablement un problème de routes push ou de pare-feu sur le routeur — voir la section dépannage plus bas.
Ajouter d'autres utilisateurs
Pour chaque utilisateur supplémentaire, vous reprenez la même logique : un certificat client + un secret PPP. Voici l'exemple pour ajouter Bob.
# Création et signature du certificat client
/system/certificate
add name=Bob common-name=Bob
sign Bob ca=CA name=Bob
# Export du certificat client
/certificate export-certificate Bob export-passphrase="MotDePasseBob789"
# Création du secret PPP correspondant
/ppp/secret
add name=Bob password="MotDePasseVPNBob" profile=itd-ovpnEnsuite, générez son fichier Bob.ovpn via Winbox comme à l'étape 5. Si vous avez plus de 5 à 10 utilisateurs à provisionner, il devient intéressant d'automatiser le tout via un script RouterOS — n'hésitez pas à demander si vous avez besoin d'un exemple.
Bonnes pratiques sécurité
Authentification et secrets
- Phrases de passe fortes sur les certificats clients et sur les secrets PPP. Les deux niveaux sont nécessaires.
- Pool d'IP restreint au nombre réel d'utilisateurs + une marge raisonnable. Pas la peine de provisionner 100 IPs si vous avez 8 utilisateurs.
- Désactivation des comptes inutilisés dans
/ppp/secret(utiliserdisabled=yesplutôt que de supprimer, ça garde l'historique). - Révocation propre en cas de départ : supprimer le secret PPP et désactiver le certificat correspondant. Pour une révocation rigoureuse avec CRL, voir la documentation MikroTik.
Surface d'exposition
- Port custom : changer le port par défaut 1194 vers un port moins prévisible réduit drastiquement le bruit des scanners automatisés.
set port=51194par exemple. - Limitation géographique : si tous vos utilisateurs sont en France, vous pouvez ajouter une règle pare-feu qui bloque les tentatives de connexion depuis l'étranger (via address-list géographique).
- Logs activés sur le service ovpn pour tracer toutes les connexions et tentatives d'authentification.
Performance et fiabilité
- Cipher : RouterOS 7 utilise AES-256-GCM par défaut, c'est le bon choix (sécurisé et performant).
- MTU : en cas de problèmes de transferts lents ou de fragmentation, tester entre 1400 et 1450 (au lieu de 1500 par défaut).
- Monitoring :
/ppp/active printpour les sessions,/log print where topics~"ovpn"pour le détail.
Problèmes fréquents et solutions
Le client ne se connecte pas du tout
Le client ne reçoit aucune réponse du serveur ou échoue au handshake. Points à vérifier dans l'ordre :
- Port 1194/TCP réellement ouvert dans le pare-feu MikroTik (vérifier l'ordre des règles).
- Box ou pare-feu en amont qui autorise le port 1194 entrant — si votre MikroTik est derrière une box opérateur, il faut une règle de redirection.
- IP publique du certificat CA qui correspond à votre IP actuelle (si elle a changé depuis la création du certificat, il faut le re-signer).
- Nom d'utilisateur dans
/ppp/secretstrictement identique aucommon-namedu certificat.
Le client se connecte mais n'a pas accès au LAN
Le tunnel est établi (visible dans /ppp/active) mais aucun ping ne passe vers le réseau interne. Causes courantes :
- Routes push absentes ou mal formées sur le serveur. Vérifier avec
/interface/ovpn-server/server print. - NAT mal configuré sur le routeur : le trafic VPN → LAN doit passer, vérifier dans
/ip/firewall/nat. - Pare-feu côté LAN qui bloque le trafic depuis le pool VPN (cas des serveurs Windows avec firewall Windows trop strict).
- Pare-feu MikroTik qui bloque le forwarding entre interface
ovpn-inet l'interface LAN — vérifier les règles dans la chainforward.
Activer les logs pour diagnostiquer
# Activer le logging du module ovpn vers la mémoire
/system/logging
add topics=ovpn action=memory
# Consulter les logs filtrés sur ovpn
/log print where topics~"ovpn"Les messages d'erreur OpenVPN sont généralement explicites : TLS Error, cert verify failed, peer info, etc. Une recherche sur le forum MikroTik avec le message exact donne souvent une piste immédiate.
FAQ
Puis-je faire tourner OpenVPN et WireGuard sur le même MikroTik ?
Oui, sans aucun problème. Les deux services coexistent sur des ports différents (1194/TCP pour OpenVPN, 13231/UDP par défaut pour WireGuard) et peuvent être utilisés en parallèle. C'est même une pratique courante : OpenVPN pour les utilisateurs en environnement restrictif (hôtels, hotspots qui filtrent UDP), WireGuard pour les utilisateurs où la performance prime.
Quelle est la différence entre OpenVPN et WireGuard ?
OpenVPN est plus ancien, plus compatible (notamment avec les réseaux restrictifs qui ne laissent passer que TCP/443), supporte TCP et UDP. WireGuard est plus moderne, plus rapide, plus simple à configurer, mais uniquement en UDP et avec une compatibilité moindre dans les environnements filtrés. Pour une entreprise qui veut le maximum de compatibilité (utilisateurs en déplacement à l'étranger, hôtels, etc.), OpenVPN reste souvent le choix le plus sûr. Pour des connexions site-à-site ou des utilisateurs en environnement maîtrisé, WireGuard est généralement préférable.
Combien de clients simultanés un MikroTik peut-il gérer ?
Cela dépend principalement du modèle de routeur et du trafic moyen par client. Un MikroTik d'entrée de gamme (hAP ac, RB750) gère facilement 10 à 20 clients simultanés avec un trafic modéré. Les modèles pro (CCR1009, CCR2004, RB5009) montent à 100+ clients sans difficulté. Le facteur limitant est généralement le CPU pour le chiffrement AES, pas la mémoire.
Faut-il redémarrer le routeur après la configuration ?
Non, aucun redémarrage n'est nécessaire. RouterOS applique toutes les modifications en temps réel. Le serveur OpenVPN devient opérationnel dès la commande set enabled=yes. Idem pour les modifications de pare-feu, de pool d'IP ou de routes push : pas de redémarrage requis.
Puis-je utiliser un port différent du 1194 par défaut ?
Oui, et c'est même recommandé pour réduire le bruit des scanners automatisés. Modifiez avec /interface/ovpn-server/server set port=51194 par exemple. Pensez ensuite à mettre à jour la règle de pare-feu pour autoriser le nouveau port, et à régénérer les fichiers de config client (le port est inscrit dans le .ovpn). Un port en 443 peut aussi être utilisé pour passer à travers les réseaux restrictifs qui ne laissent passer que HTTPS.
Comment révoquer un certificat client compromis ?
La méthode simple et immédiate : supprimer le secret PPP correspondant avec /ppp/secret remove Alice, et désactiver le certificat dans /system/certificate. L'utilisateur ne pourra plus s'authentifier. Pour une révocation plus formelle avec une CRL (Certificate Revocation List) publiée — utile si vous gérez beaucoup de clients ou si vous voulez une traçabilité légale — il faut configurer la publication de la CRL et la déclarer dans la config serveur. Voir la documentation MikroTik dédiée pour ce cas.
Si vous préférez nous laisser faire
Ce tutoriel est volontairement complet pour vous permettre de déployer votre VPN MikroTik en autonomie. C'est faisable, surtout si vous êtes à l'aise avec RouterOS. Mais ce n'est pas le bon usage du temps pour tout le monde — selon les structures, sous-traiter cette partie a du sens.
-
01
Expertise MikroTik historique
ITD déploie du MikroTik depuis 2013. Pare-feu, VPN, antennes 4G/5G outdoor, supervision avancée. C'est l'une de nos technologies de prédilection chez les clients TPE/PME en Rhône-Alpes.
-
02
Déploiement clé en main
Configuration complète du serveur OpenVPN, génération et distribution des fichiers clients, accompagnement des utilisateurs lors de la première connexion. Vous récupérez un VPN qui marche sans avoir touché à la ligne de commande.
-
03
Supervision continue
Une fois le VPN en production, on surveille les sessions actives, les anomalies (tentatives d'authentification, déconnexions répétées), la santé du certificat CA, l'évolution des versions RouterOS et les correctifs de sécurité à appliquer.