MikroTik WireGuard site‑à‑site : modèle propre pour deux bureaux

Objectifs de conception (ce que nous optimisons)

Un VPN entre deux sites peut être « fonctionnel » et rester pourtant un casse‑tête opérationnel. L’objectif ici n’est pas de montrer de l’astuce.
L’objectif est de pouvoir répondre, rapidement et avec des preuves, à ces questions :

• Le tunnel est‑il en service ? (handshake + compteurs d’octets qui augmentent, pas des impressions)
• Le chemin est‑il correct ? (routes et NAT contourné, pas de détours accidentels)
• Les performances sont‑elles stables ? (MTU/MSS, files d’attente, interactions FastTrack)
• Un administrateur junior peut‑il le maintenir ? (noms cohérents, règles minimales)
• Pouvons‑nous étendre à d’autres sites plus tard ? (plan d’adressage et répartition des peers)

Ce modèle utilise un modèle routé (sous‑réseaux LAN distincts pour chaque bureau). Pas de bridge. Pas d’extension L2.
Le bridging est la façon d’importer tempêtes de broadcast et élections Windows mystérieuses dans votre vie. Vous avez déjà assez d’excitation.

Aussi : gardez l’espace d’adressage du tunnel séparé de l’espace LAN. Si vous réutilisez un sous‑réseau LAN dans le tunnel « parce qu’il est disponible »,
vous construisez une panne future. C’est juste une gratification différée, mais pour la douleur.

Quelques faits intéressants (contexte WireGuard + MikroTik)

Quelques points de contexte courts qui vous aident réellement à prendre de meilleures décisions :

1. WireGuard est volontairement petit. Il a été conçu avec une base de code réduite par rapport aux piles VPN héritées, visant à diminuer la surface d’attaque et la complexité d’audit.
2. Il utilise une cryptographie moderne par défaut. Pas de cirque de négociation de suites de chiffrement ; le protocole choisit un ensemble restreint (comme ChaCha20‑Poly1305) pour éviter les jeux de rétrogradation.
3. « Handshake up » ne signifie pas « le trafic circule ». WireGuard peut établir un handshake même si le routage/NAT/pare‑feu empêche les paquets de charge utile d’aller quelque part d’utile.
4. WireGuard est non‑étatique d’une certaine manière. Il ne construit pas une « session » traditionnelle comme certains VPN ; les pairs sont identifiés par des clés publiques, et les endpoints peuvent nomader.
5. PersistentKeepalive existe pour la réalité du NAT. Si un côté est derrière du NAT, des paquets périodiques maintiennent la traduction active pour que le trafic entrant ne meure pas après une période d’inactivité.
6. MikroTik a ajouté WireGuard relativement tard. Le support RouterOS est arrivé des années après que WireGuard soit populaire sur Linux, c’est pourquoi des flottes RouterOS plus anciennes combinent souvent VPN hérités et WG.
7. La simplicité de WireGuard déplace la complexité vers le routage. C’est une fonctionnalité. Vous voulez que le routage soit explicite, inspectable et journalisé.
8. Les problèmes de MTU sont devenus plus visibles avec les applications web modernes. Les enregistrements TLS plus volumineux, HTTP/2, et les piles tout‑encapsulées font que la fragmentation et les MTU en blackhole se manifestent par des pannes applicatives étranges.

Une citation, parce que les ops méritent aussi de la poésie :
Tout échoue, tout le temps. — Werner Vogels

Pas cynique. Pratique. Nous construisons des systèmes qui échouent de façon prévisible et se rétablissent proprement.

Plan réseau : sous‑réseaux, IP du tunnel et DNS

Répartition des bureaux (exemple)

• LAN du bureau A : 10.10.10.0/24 (routeur : 10.10.10.1)
• LAN du bureau B : 10.20.20.0/24 (routeur : 10.20.20.1)
• Réseau du tunnel WireGuard : 10.99.0.0/30
  • IP WG bureau A : 10.99.0.1/30
  • IP WG bureau B : 10.99.0.2/30
• Port UDP WG : 13231/udp (choisissez un port et documentez‑le)

Pourquoi /30 pour le tunnel ?

Parce que c’est un lien point‑à‑point. Il vous faut deux IP. Un /30 est sobre, restreint, et vous empêche plus tard « d’ajouter utilement » des hôtes aléatoires sur le réseau du tunnel.
Si vous prévoyez 10+ sites, utilisez un /24 et allouez des /32 par site — mais pour deux bureaux, ne sur‑construisez pas.

Stratégie DNS (choisissez délibérément)

Le routage site‑à‑site est la moitié de la bataille. La résolution des noms est l’autre moitié. Vous avez trois options sensées :

1. Chaque site résout les noms locaux localement. Si le bureau A a besoin des ressources du bureau B, utilisez des FQDN qui résolvent sur 10.20.20.0/24 et vice versa.
2. DNS centralisé sur un site. Pointez les deux sites vers un DNS autoritaire (accessible via le tunnel). C’est courant en entreprise mais rend la disponibilité DNS dépendante du tunnel.
3. DNS à horizon séparé (split‑horizon). Idéal pour les réseaux hybrides, le plus pénible à maintenir. Utile si vous avez des services qui se chevauchent ou un besoin de séparation cloud/privé.

Mon biais opérationnel : gardez le DNS local quand c’est possible, et forwardez explicitement seulement ce qui est nécessaire via le tunnel. Ça réduit les « le VPN est down » qui sont en réalité des « DNS down ».

Modèle de configuration propre : Bureau A et Bureau B

Le modèle est conçu pour RouterOS v7+. Si vous êtes sur un RouterOS plus ancien, effectuez la mise à jour. Si vous ne pouvez pas mettre à jour, vous n’aurez pas de belles choses.
(Ce n’est pas une blague. C’est une politique de maintenance.)

Conventions de nommage qui vous sauveront plus tard

• Nom d’interface : wg-s2s-officeB (indiquez à votre futur vous ce que c’est)
• Noms des listes d’adresses : lan-officeA, lan-officeB
• Préfixes de commentaires pare‑feu : S2S-WG: pour pouvoir filtrer rapidement

Bureau A (IP publique, écoute)

Hypothèses :
Le routeur du bureau A a une WAN publique ou un redirection de port stable vers lui. Le bureau B peut être derrière du NAT.
Nous ferons écouter le Bureau A sur UDP 13231 et le Bureau B initiera avec keepalive.

cr0x@server:~$ cat office-a-routeros.rsc
# Office A: MikroTik RouterOS v7+ WireGuard site-to-site template

# Variables you must set:
# - Replace PUBLIC_WAN_INTERFACE if needed (example: ether1)
# - Set correct LAN interface/list and subnets
# - Paste actual keys (do not reuse this placeholder layout)

# 1) WireGuard interface
/interface/wireguard/add name=wg-s2s-officeB listen-port=13231 mtu=1420 comment="S2S-WG: OfficeA<->OfficeB"

# 2) WireGuard tunnel IP
/ip/address/add address=10.99.0.1/30 interface=wg-s2s-officeB comment="S2S-WG: tunnel IP OfficeA"

# 3) Peer (Office B)
/interface/wireguard/peers/add interface=wg-s2s-officeB public-key="OFFICE_B_PUBLIC_KEY" \
  allowed-address=10.99.0.2/32,10.20.20.0/24 \
  comment="S2S-WG: peer OfficeB"

# 4) Route to Office B LAN via WireGuard
/ip/route/add dst-address=10.20.20.0/24 gateway=wg-s2s-officeB comment="S2S-WG: route to OfficeB LAN"

# 5) Address lists for cleaner firewall rules
/ip/firewall/address-list/add list=lan-officeA address=10.10.10.0/24 comment="OfficeA LAN"
/ip/firewall/address-list/add list=lan-officeB address=10.20.20.0/24 comment="OfficeB LAN"

# 6) Firewall: allow WireGuard inbound on WAN
/ip/firewall/filter/add chain=input action=accept protocol=udp dst-port=13231 in-interface=ether1 \
  comment="S2S-WG: allow WireGuard UDP from WAN"

# 7) Firewall: allow WireGuard interface traffic to the router itself (optional but practical)
/ip/firewall/filter/add chain=input action=accept in-interface=wg-s2s-officeB \
  comment="S2S-WG: allow input from WireGuard (management/ping as needed)"

# 8) Firewall: allow forwarding between LANs over the tunnel
/ip/firewall/filter/add chain=forward action=accept in-interface=wg-s2s-officeB out-interface-list=LAN \
  comment="S2S-WG: allow WG to LAN forwarding"
/ip/firewall/filter/add chain=forward action=accept in-interface-list=LAN out-interface=wg-s2s-officeB \
  comment="S2S-WG: allow LAN to WG forwarding"

# 9) NAT bypass (no masquerade between sites)
# Place this BEFORE any general masquerade rule.
/ip/firewall/nat/add chain=srcnat action=accept src-address=10.10.10.0/24 dst-address=10.20.20.0/24 \
  comment="S2S-WG: no-NAT OfficeA->OfficeB"

# 10) Optional: log drops related to the tunnel during bring-up (disable after)
/ip/firewall/filter/add chain=forward action=log log-prefix="S2S-WG DROP " src-address=10.10.10.0/24 dst-address=10.20.20.0/24 \
  comment="S2S-WG: temporary debug log OfficeA->OfficeB"

Bureau B (derrière NAT, initie)

Le bureau B définira un endpoint pointant vers l’IP/DNS publique du Bureau A, et définira persistent-keepalive=25s.
Ce n’est pas de la magie ; c’est juste apprendre aux boîtes NAT à maintenir la traduction active.

cr0x@server:~$ cat office-b-routeros.rsc
# Office B: MikroTik RouterOS v7+ WireGuard site-to-site template

# 1) WireGuard interface
/interface/wireguard/add name=wg-s2s-officeA listen-port=13231 mtu=1420 comment="S2S-WG: OfficeB<->OfficeA"

# 2) WireGuard tunnel IP
/ip/address/add address=10.99.0.2/30 interface=wg-s2s-officeA comment="S2S-WG: tunnel IP OfficeB"

# 3) Peer (Office A)
/interface/wireguard/peers/add interface=wg-s2s-officeA public-key="OFFICE_A_PUBLIC_KEY" \
  endpoint-address=203.0.113.10 endpoint-port=13231 persistent-keepalive=25s \
  allowed-address=10.99.0.1/32,10.10.10.0/24 \
  comment="S2S-WG: peer OfficeA"

# 4) Route to Office A LAN via WireGuard
/ip/route/add dst-address=10.10.10.0/24 gateway=wg-s2s-officeA comment="S2S-WG: route to OfficeA LAN"

# 5) Address lists for cleaner firewall rules
/ip/firewall/address-list/add list=lan-officeA address=10.10.10.0/24 comment="OfficeA LAN"
/ip/firewall/address-list/add list=lan-officeB address=10.20.20.0/24 comment="OfficeB LAN"

# 6) Firewall: allow WireGuard traffic (input from WAN not needed if behind NAT, but allow from WG interface)
/ip/firewall/filter/add chain=input action=accept in-interface=wg-s2s-officeA \
  comment="S2S-WG: allow input from WireGuard (management/ping as needed)"

# 7) Firewall: allow forwarding between LANs over the tunnel
/ip/firewall/filter/add chain=forward action=accept in-interface=wg-s2s-officeA out-interface-list=LAN \
  comment="S2S-WG: allow WG to LAN forwarding"
/ip/firewall/filter/add chain=forward action=accept in-interface-list=LAN out-interface=wg-s2s-officeA \
  comment="S2S-WG: allow LAN to WG forwarding"

# 8) NAT bypass (no masquerade between sites)
# Place this BEFORE any general masquerade rule.
/ip/firewall/nat/add chain=srcnat action=accept src-address=10.20.20.0/24 dst-address=10.10.10.0/24 \
  comment="S2S-WG: no-NAT OfficeB->OfficeA"

# 9) Optional: log drops related to the tunnel during bring-up (disable after)
/ip/firewall/filter/add chain=forward action=log log-prefix="S2S-WG DROP " src-address=10.20.20.0/24 dst-address=10.10.10.0/24 \
  comment="S2S-WG: temporary debug log OfficeB->OfficeA"

Blague #1 : WireGuard est si simple que vous passerez le plus clair de votre temps à déboguer les parties que vous n’avez pas configurées, ce qui est remarquablement fidèle au réseau.

Gestion des clés (ne pas improviser)

Générez les clés sur chaque routeur et échangez les clés publiques. Gardez les clés privées privées. Oui, cette phrase est évidente.
C’est toujours là que les équipes échouent sous pression.

cr0x@server:~$ ssh admin@office-a 'wg genkey | tee /tmp/wg.key | wg pubkey > /tmp/wg.pub && ls -l /tmp/wg.* && cat /tmp/wg.pub'
-rw------- 1 admin admin 45 Dec 28 10:12 /tmp/wg.key
-rw-r--r-- 1 admin admin 45 Dec 28 10:12 /tmp/wg.pub
hF2m3dZyJf1q3oV6n8r2b1P9kY0aQk7mZxv6b2rNQXo=

Décision : stockez la clé privée uniquement dans la configuration de l’interface WireGuard du routeur ; ne l’envoyez pas par e‑mail, ne la collez pas dans des tickets, ne la laissez pas « temporairement » dans un chat partagé.
Si vous avez besoin d’audit, stockez‑la dans un gestionnaire de secrets approprié avec des contrôles d’accès stricts.

Pare‑feu et NAT : quoi autoriser, quoi refuser

Votre politique pare‑feu doit être explicite. « On autorise WireGuard » n’est pas une politique ; c’est une humeur.
Pour un site‑à‑site, vous voulez :

• Input : autoriser le port UDP 13231 vers le routeur (seulement sur le côté qui écoute sur une WAN publique)
• Forward : autoriser le trafic LAN↔WG (au mieux restreint)
• NAT : accepter (bypass) le trafic inter‑sites avant la masquerade générique

À propos de FastTrack (réalité spécifique à MikroTik)

FastTrack peut être génial… jusqu’à ce qu’il ne le soit plus. Selon votre version RouterOS et votre configuration, FastTrack peut contourner une partie du suivi de connexion et du mangle,
et cela peut interférer avec le shaping VPN, la comptabilité du pare‑feu, ou les règles de MSS clamping.

Ma règle : ne pas FastTrack le trafic qui entre ou sort de WireGuard tant que vous n’avez pas prouvé qu’il se comporte. Puis, si vous l’activez, faites‑le avec des exceptions et mesurez.

Bypass NAT : la cause la plus commune de « ça se connecte mais rien ne marche »

Si vous masquez (masquerade) le trafic OfficeA→OfficeB, le Bureau B verra des paquets provenant de l’IP du routeur du tunnel ou de l’IP WAN, pas de l’IP client d’origine.
Cela casse l’audit, peut casser les ACL, et transforme le dépannage en jeu de devinettes triste.

Ajoutez des règles explicites srcnat action=accept pour les sous‑réseaux inter‑sites, et placez‑les avant toute masquerade générale.
Ensuite, laissez un court commentaire sur la règle de masquerade pour prévenir votre futur vous de ne pas la réordonner.

Conception du routage : routes statiques qui ne vous surprennent pas

Pour deux sites, les routes statiques sont la quantité correcte d’ennui. Le routage dynamique peut être excellent, mais c’est aussi un second système en mouvement
avec ses propres modes de panne, son propre modèle de sécurité, et ses propres tickets « quelqu’un a changé une métrique ».

Utilisez une route par LAN distant, avec la passerelle définie sur l’interface WireGuard. C’est tout.
Si vous ajoutez plus tard des sites, vous pouvez garder des routes statiques si le nombre reste raisonnable.
Si ça grandit, utilisez un protocole de routage volontairement, pas parce qu’un collègue veut s’entraîner.

MTU, MSS clamping et pourquoi « les petits pings marchent » est un piège

WireGuard encapsule les paquets dans UDP. L’encapsulation ajoute de l’overhead. L’overhead réduit le MTU effectif. C’est normal.
Le mode de panne est normal aussi : certains réseaux suppriment les ICMP « fragmentation needed », donc la discovery du PMTU casse.
Ensuite, les gros paquets TCP disparaissent, et les utilisateurs signalent « certains sites chargent, d’autres non ».

Réglez le MTU WireGuard sur une valeur conservatrice (1420 est un point de départ courant). Testez ensuite avec de gros pings et du vrai TCP.
Si vous voyez des bizarreries, appliquez le clamp MSS sur le trafic traversant le tunnel.

Règle de MSS clamping (exemple)

C’est une correction pratique pour les problèmes de MTU en blackhole. Ce n’est pas un substitut à la compréhension de votre chemin, mais ça maintient la production stable.

cr0x@server:~$ cat mss-clamp-routeros.rsc
# Apply on both sides if needed
/ip/firewall/mangle/add chain=forward action=change-mss new-mss=1360 protocol=tcp tcp-flags=syn \
  in-interface=wg-s2s-officeB out-interface-list=LAN comment="S2S-WG: clamp MSS WG->LAN"
/ip/firewall/mangle/add chain=forward action=change-mss new-mss=1360 protocol=tcp tcp-flags=syn \
  in-interface-list=LAN out-interface=wg-s2s-officeB comment="S2S-WG: clamp MSS LAN->WG"

Décision : n’ajoutez le MSS clamping que si vous observez des pannes liées au MTU (ou si vous savez que vous traversez des liens avec MTU plus bas).
Clamper tout « au cas où » peut réduire le débit. Pas catastrophique, mais ne le faites pas par mimétisme.

Tâches opérationnelles : commandes, sorties et décisions (12+)

Ce sont les tâches que vous exécutez lors de la montée en charge et lors des incidents. Chacune inclut quoi vérifier et quelle décision prendre.
Utilisez‑les comme runbook, pas comme rituel.

Tâche 1 : Vérifier que l’interface WireGuard existe et fonctionne (RouterOS)

cr0x@server:~$ ssh admin@office-a 'interface/wireguard/print detail where name="wg-s2s-officeB"'
 0 name="wg-s2s-officeB" mtu=1420 listen-port=13231 private-key="<hidden>" running=yes

Signification : running=yes confirme que l’interface est opérationnelle.
Décision : si running=no, corrigez la création de l’interface, la présence de la clé ou les problèmes de version RouterOS avant de toucher au pare‑feu/routage.

Tâche 2 : Confirmer que le peer affiche un handshake récent

cr0x@server:~$ ssh admin@office-a 'interface/wireguard/peers/print detail where comment~"OfficeB"'
 0 interface=wg-s2s-officeB public-key="OFFICE_B_PUBLIC_KEY" allowed-address=10.99.0.2/32,10.20.20.0/24
   last-handshake=1m12s rx=183204 tx=201889 endpoint-address=198.51.100.55 endpoint-port=51820

Signification : last-handshake est récent et les compteurs rx/tx augmentent.
Décision : si le handshake est vide/ancien, vérifiez la reachabilité UDP et les paramètres d’endpoint avant de déboguer les routes.

Tâche 3 : Valider que les adresses du tunnel sont présentes

cr0x@server:~$ ssh admin@office-a 'ip/address/print where interface="wg-s2s-officeB"'
 0   address=10.99.0.1/30 network=10.99.0.0 interface=wg-s2s-officeB

Signification : le routeur a la bonne IP du tunnel.
Décision : si elle manque, le trafic peut encore faire le handshake mais le routage sera incorrect ; ajoutez l’adresse avant de continuer.

Tâche 4 : Vérifier que la route statique existe et est active

cr0x@server:~$ ssh admin@office-a 'ip/route/print detail where dst-address=10.20.20.0/24'
 0 dst-address=10.20.20.0/24 gateway=wg-s2s-officeB distance=1 scope=30 target-scope=10 active=yes

Signification : active=yes indique que le routeur considère la route utilisable.
Décision : si inactive, vous pouvez avoir une interface down, une passerelle incorrecte, ou un conflit de route (route plus spécifique ailleurs).

Tâche 5 : Ping de l’IP de tunnel distante depuis le routeur

cr0x@server:~$ ssh admin@office-a 'ping 10.99.0.2 count=5'
  SEQ HOST                                     SIZE TTL TIME       STATUS
    0 10.99.0.2                                   56  64 23ms       ok
    1 10.99.0.2                                   56  64 22ms       ok
    2 10.99.0.2                                   56  64 22ms       ok
    3 10.99.0.2                                   56  64 23ms       ok
    4 10.99.0.2                                   56  64 22ms       ok

Signification : la connectivité IP du tunnel est bonne.
Décision : si cela échoue mais que le handshake existe, cherchez des règles input sur le côté distant et des erreurs dans allowed-address.

Tâche 6 : Ping d’un hôte LAN distant depuis un hôte LAN local (bout à bout)

cr0x@server:~$ ping -c 4 10.20.20.50
PING 10.20.20.50 (10.20.20.50) 56(84) bytes of data.
64 bytes from 10.20.20.50: icmp_seq=1 ttl=62 time=25.1 ms
64 bytes from 10.20.20.50: icmp_seq=2 ttl=62 time=24.6 ms
64 bytes from 10.20.20.50: icmp_seq=3 ttl=62 time=24.9 ms
64 bytes from 10.20.20.50: icmp_seq=4 ttl=62 time=24.7 ms

--- 10.20.20.50 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms

Signification : le chemin applicatif réel fonctionne.
Décision : si routeur↔routeur fonctionne mais hôte↔hôte échoue, vous avez probablement des règles pare‑feu LAN manquantes, une passerelle par défaut incorrecte sur les hôtes, ou un routage asymétrique.

Tâche 7 : Tracer la route pour confirmer que le routage est effectivement utilisé

cr0x@server:~$ traceroute -n 10.20.20.50
traceroute to 10.20.20.50 (10.20.20.50), 30 hops max, 60 byte packets
 1  10.10.10.1  0.395 ms  0.324 ms  0.311 ms
 2  10.99.0.2   23.012 ms  22.911 ms  22.903 ms
 3  10.20.20.50 24.771 ms  24.701 ms  24.679 ms

Signification : le saut 2 est l’endpoint de tunnel distant ; le routage est correct.
Décision : si le saut 2 montre un saut ISP, votre trafic fuit sur l’internet parce que votre route/NAT est incorrect.

Tâche 8 : Valider l’ordre des règles de bypass NAT

cr0x@server:~$ ssh admin@office-a 'ip/firewall/nat/print where chain="srcnat"'
 0 chain=srcnat action=accept src-address=10.10.10.0/24 dst-address=10.20.20.0/24 comment="S2S-WG: no-NAT OfficeA->OfficeB"
 1 chain=srcnat action=masquerade out-interface=ether1 comment="MASQ: internet"

Signification : la règle accept est au‑dessus de la masquerade. Correct.
Décision : si la masquerade est au‑dessus de l’accept, corrigez l’ordre. Ce n’est pas négociable si vous tenez à préserver les IP sources.

Tâche 9 : Confirmer que les compteurs du pare‑feu incrémentent sur les règles prévues

cr0x@server:~$ ssh admin@office-a 'ip/firewall/filter/print stats where comment~"S2S-WG: allow"'
 0 chain=input action=accept packets=921 bytes=87244 comment="S2S-WG: allow WireGuard UDP from WAN"
 1 chain=input action=accept packets=110 bytes=9320 comment="S2S-WG: allow input from WireGuard (management/ping as needed)"
 2 chain=forward action=accept packets=12844 bytes=11833492 comment="S2S-WG: allow WG to LAN forwarding"
 3 chain=forward action=accept packets=12192 bytes=11011220 comment="S2S-WG: allow LAN to WG forwarding"

Signification : le trafic correspond à vos règles d’accept prévues, et ne tombe pas dans un drop par défaut.
Décision : si les compteurs restent à zéro alors que les utilisateurs se plaignent, vous n’êtes pas sur le chemin que vous pensez — vérifiez routes et listes d’interfaces.

Tâche 10 : Capturer des paquets sur l’interface WireGuard (sniffer RouterOS)

cr0x@server:~$ ssh admin@office-a 'tool/sniffer/quick interface=wg-s2s-officeB ip-address=10.20.20.50'
  TIME   NUM  DIR  SRC-ADDRESS        DST-ADDRESS        PROTOCOL  SIZE
  1.234   12  <->  10.10.10.25        10.20.20.50        icmp      98
  1.456   13  <->  10.20.20.50        10.10.10.25        icmp      98

Signification : les paquets traversent l’interface WG dans les deux sens.
Décision : si vous ne voyez qu’un seul sens, suspectez des drops pare‑feu du côté lointain ou des problèmes de route de retour/passarelle par défaut sur l’hôte destinataire.

Tâche 11 : Vérifier les conflits de routes (routes plus spécifiques gagnantes)

cr0x@server:~$ ssh admin@office-a 'ip/route/print where dst-address~"10.20.20."'
 0 dst-address=10.20.20.0/24 gateway=wg-s2s-officeB distance=1 active=yes
 1 dst-address=10.20.20.0/24 gateway=10.10.10.254 distance=1 active=no

Signification : il existe une autre route pour le même préfixe, actuellement inactive.
Décision : supprimez ou corrigez les routes conflictuelles ; sinon, de futurs changements d’état de lien peuvent basculer votre trafic de façon inattendue.

Tâche 12 : Test MTU avec ping « do not fragment »

cr0x@server:~$ ping -M do -s 1380 -c 3 10.20.20.50
PING 10.20.20.50 (10.20.20.50) 1380(1408) bytes of data.
1388 bytes from 10.20.20.50: icmp_seq=1 ttl=62 time=25.9 ms
1388 bytes from 10.20.20.50: icmp_seq=2 ttl=62 time=25.4 ms
1388 bytes from 10.20.20.50: icmp_seq=3 ttl=62 time=25.5 ms

--- 10.20.20.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Signification : une taille utile de 1380 fonctionne sans fragmentation ; c’est un bon signe pour les performances TCP.
Décision : si cela échoue à des tailles modérées (1360–1380), implémentez le MSS clamping et/ou réduisez le MTU WG.

Tâche 13 : Confirmer que le port UDP WireGuard est atteignable depuis Internet (depuis une machine de test)

cr0x@server:~$ sudo nmap -sU -p 13231 203.0.113.10
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 10:40 UTC
Nmap scan report for 203.0.113.10
Host is up (0.021s latency).

PORT      STATE         SERVICE
13231/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds

Signification : UDP affiche souvent open|filtered car il n’y a pas de handshake comme TCP.
Décision : si c’est closed, vous avez probablement un blocage ISP/edge ou un NAT/port‑forward incorrect. Réparez la reachabilité avant de toucher aux peers.

Tâche 14 : Surveillez les compteurs WireGuard pendant un test

cr0x@server:~$ ssh admin@office-b 'interface/wireguard/peers/print detail where comment~"OfficeA"'
 0 interface=wg-s2s-officeA public-key="OFFICE_A_PUBLIC_KEY" allowed-address=10.99.0.1/32,10.10.10.0/24
   last-handshake=14s rx=901233 tx=884120 endpoint-address=203.0.113.10 endpoint-port=13231

Signification : les compteurs changent quand vous générez du trafic. S’ils ne changent pas, votre test ne passe peut‑être pas par le tunnel du tout.
Décision : si rx augmente mais pas tx (ou inversement), vérifiez le pare‑feu et les routes dans la direction manquante.

Playbook de diagnostic rapide

Quand c’est en panne et que quelqu’un regarde, vous avez besoin d’un ordre d’opérations impitoyable. Ne redémarrez pas le tunnel.
Ne « reboot » pas le routeur. C’est comme ça qu’on efface des preuves et prolonge les pannes.

Première étape : le peer est‑il réellement vivant ?

1. Vérifiez le last-handshake sur les deux côtés.
2. Vérifiez les compteurs rx/tx pendant que vous générez du trafic.
3. Si le handshake est ancien : validez la reachabilité UDP (ISP, redirection de port, pare‑feu WAN).

Verdict : si le handshake est mort, votre goulot d’étranglement est la reachabilité sous‑jacente (chemin WAN, NAT, pare‑feu).

Deuxième étape : le routage pointe‑t‑il vers le tunnel ?

1. Vérifiez que les routes statiques existent et sont actives.
2. Depuis un hôte LAN, effectuez un traceroute vers l’IP LAN distante.
3. Sur le routeur, sniffez l’interface WG pour ce flux.

Verdict : si le handshake est bon mais le traceroute montre des sauts ISP, votre goulot est la politique de routage/NAT.

Troisième étape : le pare‑feu/NAT réécrit ou droppe ?

1. Vérifiez l’ordre NAT : le bypass accept doit être au‑dessus de la masquerade.
2. Vérifiez les compteurs des règles d’accept du pare‑feu.
3. Activez temporairement des logs ciblés de drops pour les deux sous‑réseaux LAN.

Verdict : si les paquets atteignent des logs de drop ou des compteurs de masquerade de façon inattendue, votre goulot est la politique (filter/NAT).

Quatrième étape : est‑ce un problème de MTU/performance ?

1. Ping avec DF et payloads plus grands.
2. Testez un flux TCP unique (copie de fichier ou iperf si disponible).
3. Si des applications intermittentes échouent : clamp MSS et retestez.

Verdict : si les petits pings fonctionnent mais que les plus gros échouent, votre goulot est un MTU en blackhole.

Erreurs courantes : symptôme → cause → correction

1) Le handshake est up, mais personne ne peut atteindre l’autre site

Symptôme : last-handshake est récent, mais ping/traceroute vers le LAN distant échoue.

Cause : route statique manquante, allowed-address erroné, ou masquerade NAT qui touche le trafic inter‑sites.

Correction : ajoutez/activez la route vers le LAN distant via WG ; assurez‑vous que le allowed-address du peer inclut le LAN distant ; ajoutez une règle de bypass NAT accept au‑dessus de la masquerade.

2) Une seule direction fonctionne (A→B marche, B→A échoue)

Symptôme : vous pouvez atteindre B depuis A, mais pas A depuis B.

Cause : routage asymétrique ou chemin de retour bloqué ; passerelle par défaut de l’hôte distante incorrecte ; règles forward manquantes d’un côté.

Correction : confirmez que les passerelles par défaut des hôtes de destination pointent vers le routeur du site ; vérifiez les règles forward accept dans les deux sens ; sniffez l’interface WG pour voir si le trafic de retour existe.

3) Certaines applications fonctionnent, d’autres bloquent (HTTPS, SMB, RDP surtout)

Symptôme : le DNS résout, les petits pings fonctionnent, mais les applications web timeout ou SMB se bloque.

Cause : MTU/PMTUD en blackhole ; messages de fragmentation bloqués en amont.

Correction : baissez le MTU WireGuard (commencez par 1420 puis ajustez) et/ou appliquez le MSS clamping sur les paquets SYN TCP forwardés.

4) Le tunnel se ferme après quelques minutes d’inactivité

Symptôme : le handshake devient ancien ; le trafic reprend seulement après qu’on « réessaie ».

Cause : expiration des mappings NAT du côté derrière NAT ; pas de keepalive.

Correction : définissez persistent-keepalive=25s sur le peer NATé ; vérifiez que l’UDP sortant est autorisé.

5) Le trafic inter‑sites est NATé et les ACL cassent

Symptôme : les serveurs distants voient le trafic provenant du routeur distant, pas de l’IP client réelle ; les règles d’accès échouent ou l’audit est inutile.

Cause : règle de masquerade générique qui match avant votre bypass.

Correction : ajoutez un srcnat action=accept pour le trafic LAN→LAN et placez‑le au‑dessus de la masquerade ; vérifiez les compteurs.

6) Vous pouvez pinguer les IP du tunnel mais pas les LAN distants

Symptôme : 10.99.0.1↔10.99.0.2 ping OK, mais 10.10.10.0/24↔10.20.20.0/24 échoue.

Cause : allowed-address inclut seulement les /32 du tunnel, pas les préfixes LAN ; ou la chaîne forward n’autorise pas le forwarding LAN.

Correction : incluez les sous‑réseaux LAN distants dans allowed-address ; ajoutez des règles forward accept LAN↔WG dans les deux sens.

7) CPU monte en flèche et le débit s’effondre pendant les transferts

Symptôme : de grosses copies de fichiers saturent le CPU d’un routeur ; la latence grimpe ; les utilisateurs se plaignent que l’internet « paraît lent » aussi.

Cause : modèle de routeur sous‑dimensionné, mauvaise configuration des queues/FastTrack, ou logging pare‑feu trop large.

Correction : désactivez les règles de debug log ; assurez‑vous de ne pas logger chaque paquet forward ; envisagez une montée en gamme hardware ou du shaping réfléchi (pas au pif).

Trois mini‑histoires d’entreprise (comment ça tourne mal)

Incident causé par une mauvaise hypothèse : « Le handshake signifie que c’est ok »

Une entreprise de taille moyenne a relié deux bureaux avec WireGuard sur MikroTik. L’admin a fait la validation classique :
le handshake est récent, donc le VPN est up. Il a annoncé le succès. Les gens ont commencé à mapper des lecteurs réseau.

En une heure, des tickets sont arrivés : certains postes pouvaient accéder au serveur de fichiers distant, d’autres non. Les postes « fonctionnels » étaient sur un VLAN
qui avait par hasard une politique pare‑feu permissive. Les autres étaient sur un VLAN restreint dont la chaîne forward n’incluait pas l’interface WireGuard.

L’admin a continué à tripoter les paramètres WireGuard. Rien n’a changé, car le tunnel n’était pas le problème. La preuve était là :
les compteurs peer augmentaient pendant les pings, mais les compteurs de la chaîne forward n’avaient pas bougé pour le trafic utilisateur réel.
Ils déboguaient la mauvaise couche parce qu’ils assumaient que le handshake équivalait à une connectivité bout à bout.

La correction a été banale : ajouter des règles forward explicites pour les sous‑réseaux LAN spécifiques vers et depuis l’interface WG, et les restreindre aux ports nécessaires.
Ensuite, la connectivité est devenue cohérente, et l’équipe sécurité a arrêté de surveiller anxieusement.

Optimisation qui a mal tourné : « FastTrack partout »

Une autre organisation avait une plainte de performance : les transferts entre bureaux étaient plus lents que prévu. Quelqu’un a proposé d’activer FastTrack largement
pour réduire la charge CPU et augmenter le débit. Ils l’ont fait dans la chaîne forward avec une règle large correspondant à la plupart des connexions établies.

Pendant une journée, tout semblait bien. Le CPU a chuté. Les graphiques se sont calmés. Puis les rapports étranges ont commencé :
certaines sessions HTTPS se bloquaient, particulièrement pour des applications utilisant des connexions longues. Les copies SMB démarraient vite puis se dégradaient.
Le helpdesk a classé ça comme « internet intermittent », qui est le jargon corporate pour « on ne sait pas ».

La cause : la règle FastTrack contournait des parties du pipeline pare‑feu/mangle sur lesquelles ils comptaient pour le MSS clamping et la comptabilité du trafic.
Certains flux passaient avec clamping, d’autres non, selon l’état de connexion et l’ordre des règles. Les performances sont devenues non déterministes.

Ils ont rollbacké FastTrack pour le trafic lié à WireGuard et l’ont gardé pour les flux NAT internet simples.
Le débit s’est stabilisé. La leçon n’était pas « FastTrack est mauvais ». La leçon était « sachez ce que vous contournez » et soyez disciplinés avec les exceptions.

Pratique ennuyeuse mais correcte qui a sauvé la journée : « Commenter, baseliner et mesurer »

Une troisième équipe avait une habitude propre : chaque changement de pare‑feu/NAT pour le VPN avait un préfixe de commentaire, et ils conservaient une petite capture de base de
l’état « sain » — temps de handshake, état des routes, et compteurs de règles pendant un test ping standard.

Un matin, le bureau B a perdu l’accès à l’ERP du bureau A. Le tunnel était up. Le routage semblait correct à première vue.
Au lieu d’essayer des corrections au hasard, l’ingénieur de garde a comparé les compteurs à la baseline : la règle de bypass NAT ne matchait plus.

Il s’est avéré qu’un « nettoyage » de routine la veille avait réordonné les règles NAT. La règle de masquerade avait été déplacée au‑dessus du bypass accept.
Tout « fonctionnait » encore pour certains flux, mais les ERP attendaient des IP clients réelles et ont commencé à refuser des sessions.

Parce que l’équipe avait des commentaires et des baselines, le diagnostic a pris quelques minutes. Ils ont restauré l’ordre NAT, ajouté un commentaire de garde sur la règle de masquerade,
et mis en place une petite politique de revue par les pairs pour les changements d’ordre de règles. Ce n’était pas glamour. Ça a aussi évité une classe de panne récurrente.

Blague #2 : L’appareil réseau le plus dangereux est celui étiqueté « temporaire », parce qu’il survivra à votre organigramme.

Listes de contrôle / plan pas à pas

Montée en charge pas à pas (deux bureaux)

1. Choisir les sous‑réseaux : confirmez que les LAN ne se chevauchent pas (10.10.10.0/24 et 10.20.20.0/24) et choisissez un tunnel /30 (10.99.0.0/30).
2. Mettre à jour RouterOS : les deux routeurs sur v7+ avec la même release majeure si possible.
3. Générer les clés sur chaque routeur ; échanger les clés publiques hors bande.
4. Créer les interfaces WG avec des noms explicites et MTU 1420.
5. Attribuer les IP du tunnel aux interfaces WG.
6. Configurer les peers :
   • Le peer du Bureau A inclut le /32 du tunnel du Bureau B et le /24 LAN du Bureau B.
   • Le peer du Bureau B inclut le /32 du tunnel du Bureau A et le /24 LAN du Bureau A.
   • Le Bureau B définit l’endpoint vers le Bureau A et le persistent keepalive si NATé.
7. Ajouter des routes statiques vers le LAN distant via l’interface WG.
8. Ajouter des règles pare‑feu :
   • Autoriser le port UDP sur la WAN du Bureau A.
   • Autoriser le forwarding LAN↔WG dans les deux sens.
9. Ajouter le bypass NAT : règles accept avant la masquerade.
10. Tester par couches :
    • Handshake
    • Ping des IP du tunnel
    • Ping d’un IP LAN distant depuis le routeur
    • Ping d’un hôte distant depuis un hôte LAN
    • Test MTU avec ping DF
11. Désactiver les règles de logging debug après validation.
12. Documenter l’état connu‑bon : routes, compteurs, cadence de handshake, et où le keepalive est configuré.

Checklist de changement (à chaque modification)

• Ce changement affecte‑t‑il l’ordre des règles NAT ou filter ? Si oui, validez que le bypass NAT match toujours.
• Changeons‑nous des définitions de sous‑réseau ? Si oui, mettez à jour allowed-address et les routes statiques sur les deux côtés.
• Avons‑nous introduit des sous‑réseaux qui se chevauchent via un nouveau VLAN ? Si oui, arrêtez et redesignez avant de déployer.
• Avons‑nous activé FastTrack ou de nouveaux mangle ? Si oui, retestez MTU/MSS et mesurez le débit.
• Avons‑nous changé l’ISP ou l’adressage WAN ? Si oui, validez l’endpoint et la reachabilité UDP immédiatement.

Checklist sécurité (hygiène minimale viable)

• Restreindre l’input au port UDP 13231 sur la WAN (Bureau A) et garder les autres inputs fermés.
• Restreindre les règles forward par sous‑réseaux (et même ports/services si possible).
• Garder les clés WireGuard hors des tickets et des logs de chat.
• Logger seulement ce dont vous avez besoin, et seulement quand nécessaire. « Logger tout » en permanence est un DoS autoinfligé.

FAQ

1) Dois‑je bridge les deux bureaux pour n’avoir « qu’un seul LAN » ?

Non, sauf si vous avez un besoin très spécifique et êtes prêt à assumer les conséquences broadcast et spanning‑tree.
Le mode routé est plus propre, débogable et évolutif opérationnellement.

2) Pourquoi ajoute‑t‑on les sous‑réseaux LAN distants dans allowed-address ?

Dans WireGuard, allowed-address agit comme une politique de routage/sélecteur : quels préfixes de destination sont considérés comme valides pour ce peer.
Si vous omettez le LAN, vous obtiendrez un handshake et peut‑être des pings du tunnel, mais pas de routage inter‑sites réel.

3) Ai‑je besoin de persistent-keepalive sur les deux côtés ?

Généralement seulement du côté derrière NAT (ou derrière des firewalls stateful agressifs). Si les deux côtés ont des IP publiques et un UDP stable,
vous pouvez souvent l’omettre. En cas de doute, mettez‑le seulement sur le côté NATé à 25 secondes.

4) Quel port devrais‑je utiliser pour WireGuard ?

N’importe quel port UDP que vous pouvez autoriser de façon fiable sur votre edge WAN. Choisissez‑en un, documentez‑le, et ne réutilisez pas des ports aléatoires pour différents VPNs.
La clarté opérationnelle vaut mieux que le camouflage astucieux.

5) Puis‑je exécuter plusieurs tunnels site‑à‑site sur un même routeur ?

Oui. Utilisez des interfaces séparées ou des configs peers bien gérées sur une interface. Gardez des noms stricts et un plan d’adressage cohérent.
Dès que vous perdez de vue quel peer possède quels sous‑réseaux, vous routrez le trafic au mauvais endroit.

6) Le handshake est récent mais rx augmente et tx non (ou l’inverse). Que signifie‑t‑ce ?

Vous avez un trafic unidirectionnel. Soit le chemin de retour est cassé (routage/passerelle par défaut), soit le pare‑feu droppe une direction.
Sniffez l’interface WG et vérifiez les compteurs de la chaîne forward pour voir où ça meurt.

7) Comment éviter les sous‑réseaux chevauchants quand l’entreprise acquiert un autre bureau ?

Préparez‑vous : maintenez un registre IPAM interne et réservez des plages par site. Si vous héritez d’un chevauchement, il faut renuméroter un côté
ou implémenter du NAT entre sites (qui est une dette opérationnelle). Renuméroter fait mal une fois ; NAT fait mal pour toujours.

8) Dois‑je NATer le trafic entre sites pour que ce soit « plus simple » ?

Évitez‑le. Le NAT cache les IP sources, casse les attentes des ACL, et rend le dépannage plus difficile.
N’utilisez le NAT inter‑sites qu’en solution temporaire de compatibilité (comme pour des sous‑réseaux chevauchants impossibles à corriger immédiatement), et prévoyez un plan de suppression.

9) Ai‑je besoin d’une QoS spéciale pour WireGuard site‑à‑site ?

Pas par défaut. Mesurez d’abord. Si la voix/vidéo ou des applications critiques souffrent lors de gros transferts, introduisez du shaping avec des classes claires et des limites.
Ne créez pas un nouveau goulot sans données de référence.

10) Quel est le meilleur indicateur de « santé » ?

Un handshake récent plus des compteurs de transfert qui augmentent de façon régulière pendant un test synthétique planifié (comme un ping plus une sonde TCP courte).
Le handshake seul n’est pas suffisant ; les compteurs seuls peuvent être obsolètes. Vous voulez les deux, observés dans le temps.

Conclusion : prochaines étapes que vous pouvez faire aujourd’hui

Si vous ne faites que trois choses après avoir lu ceci, faites celles‑ci :

1. Verrouillez un plan IP propre (LAN distincts, tunnel /30 séparé) et documentez‑le là où il ne disparaîtra pas.
2. Implémentez correctement le bypass NAT (règles accept au‑dessus de la masquerade) et vérifiez via les compteurs, pas l’espoir.
3. Adoptez l’ordre de diagnostic rapide : handshake → routage → pare‑feu/NAT → MTU. Ça vous empêche de déboguer la mauvaise couche.

Ensuite, planifiez une petite fenêtre de maintenance pour exécuter la section tâches opérationnelles comme répétition : capturez les sorties connues‑bonnes, confirmez les compteurs,
et testez le MTU. Le temps pour apprendre les bizarreries de votre réseau n’est pas pendant un appel d’incident avec cinq managers qui retiennent leur souffle.