MikroTik : VPN WireGuard site à site

📍 Guide principal : Réseau d’entreprise : MikroTik, pfSense, OPNsense, FortiGate
Ce tutoriel fait partie d’une série sur le cœur de réseau professionnel. Pour la vue d’ensemble, lisez d’abord le guide principal.

WireGuard a bousculé le monde des VPN avec une promesse simple : une configuration tenant en quelques lignes, une cryptographie moderne et des performances supérieures aux protocoles historiques. RouterOS 7 l’intègre nativement, ce qui fait de MikroTik une plateforme idéale pour relier deux sites rapidement et à moindre coût. Dans ce tutoriel, vous allez monter un tunnel WireGuard site à site entre deux routeurs MikroTik, échanger les clés, router les réseaux internes et vérifier la connectivité chiffrée.

🎯 Ce que vous allez apprendre

• Comprendre le modèle de clés publiques/privées et de pairs propre à WireGuard.
• Créer une interface WireGuard et générer la paire de clés sur chaque routeur.
• Déclarer le pair distant avec sa clé publique, son adresse et ses réseaux autorisés.
• Router les réseaux internes à travers le tunnel et vérifier qu’ils communiquent.

🛠️ Ce que vous allez construire

À la fin, deux routeurs MikroTik — siège et agence — seront reliés par un tunnel WireGuard permanent. Les réseaux internes des deux sites se joindront de façon transparente et chiffrée. Le résultat est équivalent à un VPN IPsec, mais obtenu avec une fraction de la configuration.

Prérequis

• Deux routeurs MikroTik sous RouterOS 7 (7.21.x ou ultérieur recommandé), où WireGuard est intégré nativement.
• Une adresse IP publique joignable sur au moins un des deux sites (l’extrémité que l’autre contactera).
• Des plans d’adressage internes distincts (par exemple 192.168.10.0/24 au siège, 192.168.20.0/24 à l’agence).
• Niveau : intermédiaire. Test express : si vous savez ouvrir un terminal WinBox et lire une route, vous êtes prêt.
• ⏱️ Temps estimé : ~35 minutes.

Étape 1 — Comprendre le modèle WireGuard

WireGuard raisonne en termes de pairs (peers), pas de client et de serveur. Chaque routeur possède une paire de clés : une clé privée qu’il garde secrète, et une clé publique qu’il communique à l’autre. Pour qu’un pair accepte le trafic d’un autre, il doit connaître sa clé publique et la liste des adresses qu’il l’autorise à utiliser, le champ allowed-address.

Ce champ allowed-address est le concept central et la source de la plupart des erreurs. Il joue un double rôle : en sortie, il indique quel trafic chiffrer et envoyer vers ce pair ; en entrée, il filtre les adresses sources acceptées venant de ce pair. Concrètement, il doit contenir l’adresse du tunnel du pair distant et les réseaux internes situés derrière lui. Bien saisir ce champ, c’est avoir un tunnel qui marche du premier coup.

Étape 2 — Créer l’interface WireGuard sur le siège

Sur le routeur du siège, on commence par créer l’interface WireGuard. RouterOS génère automatiquement la paire de clés au moment de la création : il suffit ensuite de l’afficher pour récupérer la clé publique.

/interface wireguard
add listen-port=13231 name=wg-siege

# Afficher la clé publique générée
/interface wireguard print

La commande crée une interface wg-siege écoutant sur le port UDP 13231. Le print affiche les détails, dont la clé publique (public-key) que vous devez noter : elle sera fournie au routeur de l’agence. On assigne ensuite une adresse au tunnel lui-même, dans un sous-réseau dédié distinct des réseaux internes.

/ip address
add address=10.255.255.1/30 interface=wg-siege

Le réseau 10.255.255.0/30 ne sert qu’au transport du tunnel : il offre exactement deux adresses utilisables, une par extrémité. Cette séparation entre l’adressage du tunnel et celui des réseaux internes garde la configuration claire et évite les conflits.

Étape 3 — Créer l’interface WireGuard sur l’agence

On répète l’opération sur le routeur de l’agence, avec sa propre paire de clés et l’autre adresse du sous-réseau de transport. Pensez à relever également la clé publique de ce côté.

/interface wireguard
add listen-port=13231 name=wg-agence
/interface wireguard print

/ip address
add address=10.255.255.2/30 interface=wg-agence

À ce stade, chaque routeur a son interface, sa paire de clés et son adresse de tunnel. Vous disposez de deux clés publiques — une par site. L’étape suivante consiste à les présenter l’une à l’autre en déclarant les pairs. Aucune des deux interfaces ne communique encore : le tunnel n’existera qu’une fois les pairs configurés.

Étape 4 — Déclarer le pair distant sur chaque routeur

C’est l’étape qui relie tout. Sur le siège, on déclare l’agence comme pair : sa clé publique, son adresse publique et son port, et surtout les allowed-address — l’adresse de tunnel de l’agence plus son réseau interne.

# Sur le routeur du SIÈGE
/interface wireguard peers
add interface=wg-siege public-key="CLÉ_PUBLIQUE_AGENCE" \
    endpoint-address=<IP publique agence> endpoint-port=13231 \
    allowed-address=10.255.255.2/32,192.168.20.0/24 \
    persistent-keepalive=25

Cette déclaration dit au siège : « tout ce qui va vers l’adresse de tunnel de l’agence ou vers son réseau 192.168.20.0/24 doit être chiffré et envoyé à cette adresse publique ». Le paramètre persistent-keepalive envoie un petit paquet toutes les 25 secondes pour maintenir le tunnel ouvert à travers les équipements de traduction d’adresse. On configure ensuite le miroir sur l’agence.

# Sur le routeur de l'AGENCE
/interface wireguard peers
add interface=wg-agence public-key="CLÉ_PUBLIQUE_SIEGE" \
    endpoint-address=<IP publique siège> endpoint-port=13231 \
    allowed-address=10.255.255.1/32,192.168.10.0/24 \
    persistent-keepalive=25

L’agence connaît maintenant le siège et chiffre vers lui le trafic destiné à 192.168.10.0/24. La symétrie est totale : chaque côté autorise l’adresse de tunnel et le réseau interne de l’autre. Si vous vérifiez avec /interface wireguard peers print, la colonne du dernier contact (last-handshake) doit se mettre à jour, signe que les deux pairs se sont reconnus.

Étape 5 — Router les réseaux internes

Le tunnel est monté, mais les routeurs ne savent pas encore qu’il faut l’emprunter pour joindre le réseau interne d’en face. Il manque une route. Sur chaque site, on ajoute une route statique vers le réseau distant, en passant par l’adresse de tunnel de l’autre extrémité.

# Sur le SIÈGE : pour joindre l'agence
/ip route
add dst-address=192.168.20.0/24 gateway=10.255.255.2

# Sur l'AGENCE : pour joindre le siège
/ip route
add dst-address=192.168.10.0/24 gateway=10.255.255.1

Chaque route indique : « pour atteindre le réseau interne distant, passe par l’adresse de tunnel du pair ». Comme l’allowed-address du pair inclut déjà ce réseau, le trafic sera automatiquement chiffré et acheminé. Vérifiez avec /ip route print que les routes apparaissent comme actives.

Étape 6 — Vérifier et sécuriser

Testons la connectivité de bout en bout. Depuis un poste du siège, on ping une machine du réseau de l’agence ; le trafic doit traverser le tunnel.

# Depuis le routeur du siège, ping une machine de l'agence
/ping 192.168.20.10

# Confirmer l'activité du tunnel
/interface wireguard peers print

Si le ping répond et que les compteurs de transfert du pair augmentent, le tunnel est pleinement opérationnel. Un dernier point de sécurité : pensez à autoriser le port UDP du tunnel dans la chaîne input du pare-feu de l’extrémité joignable, sinon la négociation sera bloquée. Une règle acceptant le protocole UDP sur le port 13231 sur l’interface WAN suffit.

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=13231 in-interface=ether1 comment="WireGuard"

Cette règle laisse entrer la négociation WireGuard tout en gardant le reste fermé. Placez-la avant votre règle de refus général dans la chaîne input, faute de quoi elle ne servira à rien.

Pourquoi allowed-address est le cœur de WireGuard

Si un seul concept mérite qu’on s’y attarde, c’est allowed-address, car il condense à lui seul ce qui rend WireGuard à la fois élégant et déroutant. Contrairement à d’autres VPN qui séparent nettement le routage et le filtrage, WireGuard fusionne les deux dans ce champ. En émission, il agit comme une mini-table de routage : un paquet dont la destination tombe dans l’allowed-address d’un pair est chiffré et envoyé vers ce pair. En réception, il agit comme un filtre : un paquet venant d’un pair n’est accepté que si son adresse source figure dans l’allowed-address déclaré pour ce pair.

Cette double fonction explique l’erreur la plus fréquente. Si vous oubliez d’inclure le réseau interne distant dans l’allowed-address, le handshake réussit — les deux pairs se reconnaissent — mais aucun trafic interne ne passe, car WireGuard ne sait pas qu’il faut chiffrer les paquets destinés à ce réseau. À l’inverse, déclarer une plage trop large, comme 0.0.0.0/0, redirige tout le trafic du routeur dans le tunnel, ce qui n’est presque jamais l’effet recherché en interconnexion de sites. La précision de ce champ fait toute la différence entre un tunnel chirurgical et une configuration ingérable.

Une bonne habitude consiste à lister explicitement, pour chaque pair, l’adresse de son tunnel en /32 puis chacun de ses réseaux internes. On voit ainsi d’un coup d’œil ce que chaque pair a le droit d’émettre et de recevoir, ce qui rend la configuration auto-documentée et facile à auditer plus tard.

Performances et sécurité des clés

WireGuard doit sa rapidité à un choix d’ingénierie radical : au lieu d’offrir une multitude d’algorithmes négociables comme IPsec ou OpenVPN, il impose une suite cryptographique unique et moderne. Il n’y a donc rien à négocier, ce qui supprime des allers-retours coûteux et réduit la latence d’établissement à quelques millisecondes. Sur du matériel modeste, cette efficacité se traduit par un débit chiffré supérieur pour une charge processeur moindre — un atout réel quand le routeur a d’autres tâches à assurer.

Cette simplicité ne dispense pas de soigner la gestion des clés. La clé privée d’un routeur ne doit jamais quitter l’équipement ni transiter par un canal non sûr ; seule la clé publique se partage. En cas de compromission suspectée d’un site, la bonne réponse est de régénérer la paire de clés sur ce routeur et de mettre à jour la clé publique chez tous ses pairs. Comme la configuration est concise, cette rotation se fait en quelques minutes, ce qui constitue un avantage opérationnel souvent sous-estimé : un dispositif qu’on sait faire évoluer vite est un dispositif qu’on maintient réellement.

🐞 Pièges fréquents

✅ Récapitulatif

Vous avez monté un tunnel WireGuard site à site entre deux MikroTik : création des interfaces et des clés, déclaration croisée des pairs avec le bon allowed-address, routage des réseaux internes, ouverture du port dans le pare-feu, puis vérification. Vous avez constaté la promesse de WireGuard : une interconnexion chiffrée robuste obtenue en une poignée de commandes, là où d’autres protocoles en demandent bien davantage. La clé de la réussite tient dans la maîtrise du champ allowed-address et la symétrie entre les deux extrémités.

🧾 Aide-mémoire

💪 À vous de jouer

Ajoutez un troisième site à cette topologie en étoile : un nouveau routeur qui se connecte au siège et peut joindre les deux autres réseaux internes.

Tutoriels de la même série

• FortiGate : VPN IPsec site à site — la même interconnexion avec le standard historique.
• MikroTik : VLAN et pare-feu — préparer les réseaux internes à relier.

Pour aller plus loin

• 🔝 Retour au guide principal : Réseau d’entreprise : MikroTik, pfSense, OPNsense, FortiGate
• Documentation officielle : help.mikrotik.com, page « WireGuard ».
• Tutoriel suivant suggéré : pfSense et OpenVPN pour l’accès distant individuel.

FAQ

Pourquoi WireGuard est-il plus rapide qu’IPsec ou OpenVPN ?
Son code est minimaliste et sa cryptographie fixe, sans négociation d’algorithmes complexe. Il s’exécute efficacement et établit ses tunnels presque instantanément, ce qui se traduit par moins de latence et un meilleur débit dans de nombreux scénarios.

Faut-il une IP publique des deux côtés ?
Non. Une seule extrémité joignable suffit : l’autre l’initie. Avec persistent-keepalive, le tunnel reste ouvert même si un côté est derrière un équipement de traduction d’adresse.

WireGuard est-il sûr ?
Oui, il s’appuie sur des primitives cryptographiques modernes et reconnues. Sa simplicité réduit la surface d’erreur de configuration, ce qui contribue aussi à sa sécurité réelle.

Puis-je relier un MikroTik à un autre type d’équipement en WireGuard ?
Oui, WireGuard est un standard interopérable. Un MikroTik peut former un tunnel avec un pfSense, un OPNsense ou un serveur Linux, à condition d’échanger correctement les clés et de concorder sur les allowed-address.

Mots-clés : MikroTik WireGuard, RouterOS 7, VPN site à site, allowed-address, persistent-keepalive, tunnel chiffré, clés publiques, interconnexion de sites.