Remote Access
Guide VPN IPsec site à site MikroTik
Créez un VPN IPsec site à site MikroTik : peer IKEv2, proposal, policy et la règle de contournement NAT qui fait fonctionner le tunnel.
Résumé Un VPN IPsec site à site MikroTik chiffre le trafic entre deux réseaux entiers — un siège et une agence, un NOC et un site relais — pour que les hôtes de chaque LAN atteignent l’autre comme s’il était local. Ce guide configure les deux routeurs sous RouterOS v7 : le peer IKEv2, l’identity à clé pré-partagée, la proposal de phase 2, la policy de tunnel, la règle de contournement NAT qui fait échouer la plupart des premiers essais, et les règles de pare-feu et vérifications qui confirment que le tunnel est actif.
Qu’est-ce qu’un VPN IPsec site à site MikroTik ?
Un VPN IPsec site à site MikroTik est un tunnel chiffré permanent entre deux routeurs, qui réunit deux LAN distincts en un seul réseau routable au niveau 3, sans qu’aucun des deux routeurs n’expose de port d’administration sur l’internet public. Contrairement aux VPN d’accès client comme WireGuard ou OpenVPN — où une seule machine d’administration se connecte — un tunnel site à site est toujours actif et fonctionne de sous-réseau à sous-réseau : chaque hôte derrière le routeur A joint automatiquement chaque hôte autorisé derrière le routeur B. IPsec est l’outil adapté ici parce que c’est un standard ouvert pris en charge par pratiquement tous les fabricants de pare-feux et de routeurs, qu’il s’exécute dans le noyau RouterOS pour un bon débit, et que sur MikroTik il est intégré, sans paquet supplémentaire à installer.
Le tunnel se construit en deux négociations. La phase 1 (IKE) authentifie les deux routeurs l’un auprès de l’autre et établit un canal sécurisé ; la phase 2 (IPsec) négocie les clés qui chiffrent réellement vos données. Si les deux phases concordent de chaque côté, le tunnel monte ; qu’un seul algorithme diffère et il échoue silencieusement — d’où l’importance de garder les deux extrémités symétriques dans les étapes qui suivent.
Avant de commencer
Il vous faut deux routeurs MikroTik sous RouterOS v7, chacun avec une adresse IP publique ou un nom DDNS fonctionnel, et deux sous-réseaux LAN sans recouvrement. Ce guide utilise 192.168.10.0/24 sur le Site A et 192.168.20.0/24 sur le Site B. Si les deux sites utilisent 192.168.88.0/24, le routage est impossible — réadressez d’abord un des côtés. Comme IPsec est très sensible aux dérives d’horloge, activez NTP sur les deux routeurs avant de commencer ; si les deux extrémités s’écartent, les security associations expirent et le tunnel tombe sans arrêt.
Suivre ce prérequis sur plus d’une poignée de sites relève déjà de la corvée. Quand vous gérez un parc, MKController vous offre une console unique pour vérifier la version de RouterOS et la source d’horloge de chaque routeur avant de basculer un tunnel, ce qui vous évite de vous connecter à chaque équipement juste pour confirmer qu’il est prêt.
Étape 1 : créer le profil IKE et le peer
Sur le Site A, définissez le profil de phase 1 et pointez un peer vers l’adresse publique du Site B :
/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \ enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \ profile=to-siteB exchange-mode=ike2dh-group=modp2048 correspond au groupe Diffie-Hellman 14 — une valeur par défaut moderne et solide. exchange-mode=ike2 sélectionne IKEv2, plus rapide et plus robuste que l’ancien mode main/IKEv1. Les deux extrémités doivent utiliser les mêmes valeurs de profil et le même mode d’échange.
Étape 2 : ajouter l’identity (clé pré-partagée)
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"Utilisez un secret long et aléatoire, et conservez-le comme vous le feriez d’une clé SSH — pas dans un message de chat. Le même secret est déposé sur les deux routeurs.
Étape 3 : définir la proposal de phase 2
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048La Perfect Forward Secrecy (pfs-group) fait que chaque renouvellement de clés utilise du matériel cryptographique neuf : une clé compromise n’expose jamais le trafic passé. Comme en phase 1, les algorithmes doivent correspondre aux deux extrémités.
Étape 4 : créer la policy de tunnel
La policy indique à RouterOS quel trafic chiffrer — du LAN local vers le LAN distant :
/ip ipsec policy add peer=siteB tunnel=yes \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \ proposal=to-siteB action=encryptC’est tunnel=yes qui rend la liaison site à site plutôt qu’hôte à hôte : les paquets d’origine sont encapsulés entiers, si bien que les deux LAN communiquent de façon transparente.
Étape 5 : ajouter la règle de contournement NAT (l’étape que tout le monde oublie)
C’est ici que la plupart des premiers essais échouent. Votre routeur possède déjà une règle de masquerade qui réécrit l’adresse source du trafic LAN sortant. Si elle s’applique avant IPsec, l’extrémité distante reçoit des paquets dont la source ne correspond plus à la policy et les rejette. Ajoutez une règle accept au-dessus du masquerade pour que le trafic destiné au tunnel saute le NAT :
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0 place la règle tout en haut de la chaîne srcnat, ce qui est obligatoire — une règle de contournement placée après le masquerade ne sert à rien.
Étape 6 : ouvrir le pare-feu et vérifier
Autorisez les ports IKE et NAT-T ainsi que le protocole ESP dans la chaîne input pour que le tunnel puisse s’établir, en particulier si l’un des sites se trouve derrière un autre équipement NAT :
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=acceptConfirmez ensuite que le tunnel est monté :
/ip ipsec active-peers print/ip ipsec policy printUn tunnel en bonne santé affiche un peer actif et une policy dont le ph2-state indique established. Un simple ping depuis un hôte d’un LAN vers un hôte de l’autre prouve la joignabilité de bout en bout.
Répliquer la configuration sur le Site B
Reprenez chaque étape sur le Site B avec les adresses inversées : le peer pointe vers l’IP publique du Site A, et la policy et le contournement NAT utilisent src-address=192.168.20.0/24 et dst-address=192.168.10.0/24. Le profil, la proposal, le secret de l’identity et le mode IKEv2 restent identiques. Quand les deux côtés concordent, les phases 1 et 2 aboutissent et le tunnel monte.
Conseils de sécurité et d’exploitation
Gardez RouterOS à jour — des versions récentes ont apporté des correctifs touchant à la vérification des certificats de peer IPsec/IKEv2, un tunnel qui fonctionnait le trimestre dernier mérite donc un nouveau test après chaque mise à niveau. Préférez IKEv2 avec PFS aux réglages par défaut hérités d’IKEv1. Lorsque c’est possible, passez du secret partagé à l’authentification par certificat à mesure que le nombre de tunnels augmente, car une seule clé pré-partagée divulguée affecte tous les sites qui la partagent. Et journalisez l’état des tunnels quelque part où vous regardez vraiment : une liaison site à site morte reste invisible jusqu’à ce que quelqu’un tente d’atteindre le LAN distant sans y parvenir.
Sur un parc, un tunnel IPsec qui tombe discrètement après une désynchronisation d’horloge ou une coupure WAN est exactement le type de panne qu’un client remarque avant vous. MKController comble ce manque : il surveille chaque routeur via un tunnel sortant sécurisé qui ne demande ni IP publique ni redirection de port sur l’équipement, conserve des sauvegardes de configuration versionnées pour comparer et restaurer un bloc IPsec fonctionnel après une mauvaise modification, et peut ouvrir un ticket sur un événement link-down avant que le téléphone ne sonne. Pour la configuration du tunnel elle-même, notre guide sur le NAT sur MikroTik explique la règle de masquerade que vous contournez ici, et pour atteindre un seul routeur plutôt que relier deux LAN, voyez la gestion à distance derrière le CGNAT et notre tutoriel sur la gestion à distance avec WireGuard.
Regroupez vos tunnels au même endroit
IPsec relie proprement deux sites, mais un ISP ou un MSP en croissance se retrouve vite avec des dizaines de tunnels, de clés et de règles de pare-feu à garder synchronisés — et chaque modification manuelle est une occasion de se verrouiller hors d’un site distant. MKController est conçu exactement pour cette échelle : gestion centralisée du parc, accès distant sécurisé sans port exposé, historique et sauvegardes de configuration, et déploiement à l’échelle du parc des changements de pare-feu et de policy, si bien qu’un modèle de tunnel se déploie une fois au lieu d’être ressaisi routeur par routeur. Les opérateurs qui exploitent MikroTik à grande échelle s’en servent pour transformer un après-midi perdu en SSH sur chaque équipement en quelques clics par changement.