MikroTik IPsec IKEv2 entre bureaux : comment le rendre stable (et pourquoi il bascule)

Ce que le « basculement » signifie vraiment (et ce qu’il n’est pas)

Quand les gens disent qu’un tunnel IPsec « flappe », ils veulent généralement dire l’une des trois choses suivantes :

• Churn de SA IKE : le plan de contrôle IKEv2 se rétablit sans cesse. Vous verrez des négociations répétées « initiateur / répondant », des suppressions fréquentes, ou des timeouts DPD.
• Churn de Child SA : IKE reste établi, mais les SA ESP (données) sont renouvelées, supprimées ou remplacées trop souvent, rompant les flux longue durée.
• Blackholing du trafic : le tunnel est up, mais le trafic ne correspond pas à la politique de façon intermittente, les routes changent, le NAT intervient, ou le MTU casse certaines applications seulement.

Ne les traitez pas comme le même problème. Ils ont des signatures différentes, des causes racines différentes et des corrections différentes.
« Le tunnel est up » n’est pas un indicateur de succès. « Le trafic métier reste banal » l’est.

Aussi : si votre lien WAN tombe, votre VPN tombe. Ce n’est pas du « flapping », c’est de la physique. L’astuce est de faire en sorte que le VPN n’invente pas des coupures sur un WAN sain.

Faits et historique intéressants à connaître à 2 h du matin

1. IKEv2 a été conçu pour réduire la complexité par rapport à IKEv1, notamment autour du renouvellement et du NAT traversal, mais les implémentations diffèrent encore sur les comportements périphériques.
2. Le NAT traversal est plus ancien que la carrière de beaucoup d’ingénieurs : l’encapsulation UDP pour ESP (NAT-T) est devenue courante au début des années 2000 parce que les dispositifs NAT malmènent IPsec.
3. DPD existe parce que « idle » ne veut pas dire « sain ». Les middleboxes suppriment silencieusement l’état ; DPD est une façon contrôlée de le découvrir avant que les utilisateurs ne s’en aperçoivent.
4. Perfect Forward Secrecy (PFS) n’est pas gratuit : il ajoute de la charge CPU lors des renouvellements. Sur des routeurs modestes, des durées agressives peuvent devenir des pannes auto-infligées.
5. UDP 500/4500 n’est pas intrinsèquement peu fiable ; c’est juste le protocole le plus susceptible d’être « optimisé » par des firewalls stateful, des CGNAT et du matériel ISP.
6. La découverte du PMTU fonctionne « presque » depuis toujours. Le filtrage ICMP la casse encore, et l’encapsulation VPN agrandit le périmètre des dégâts.
7. RouterOS a fait évoluer significativement IPsec au fil des versions majeures ; le comportement autour des propositions, des identités et de l’accélération matérielle diffère selon la plateforme et la version.
8. Les collisions de rekey sont classiques : deux pairs renégocient simultanément, chacun pense avoir « gagné », et le trafic tombe jusqu’à ce que l’un fasse le ménage. Les piles modernes gèrent mieux mais pas parfaitement.

Une architecture de référence stable pour IKEv2 entre bureaux sur MikroTik

Choisissez un modèle : basé sur les politiques ou basé sur le routage. N’exécutez pas un hybride par accident.

MikroTik supporte l’IPsec basé sur des politiques (sélecteurs dans les politiques) et peut faire des conceptions basées sur le routage en utilisant des approches de type VTI selon la version de RouterOS et les fonctions disponibles.
Les histoires de basculement que j’ai vécues viennent généralement d’un « presque basé sur les politiques, mais on a ajouté une route ici, et maintenant la moitié des sous-réseaux fonctionne le mardi ».

Pour deux bureaux, le modèle basé sur les politiques peut suffire si vous avez des sous-réseaux stables et un petit nombre de sélecteurs. Il devient fragile lorsque :
vous ajoutez plus de sous-réseaux, vous avez du hairpin traffic, des plages chevauchantes, ou plusieurs WAN.
À ce stade, préférez une conception basée sur le routage quand c’est possible et maintenez un routage explicite.

Identité et adressage : évitez les conceptions « peu importe ce que l’ISP nous donne »

Si au moins un côté a une IP publique dynamique, vous pouvez quand même être stable, mais vous devez être délibéré :
utilisez des identités FQDN, un appariement strict des pairs, et une configuration propre côté répondant. Si vous pouvez acheter des IP statiques, faites-le. C’est moins cher que vos temps d’arrêt.

Crypto et durées : l’ennuyeux gagne

La base stable que j’utilise sauf exigence contraire :

• IKE (Phase 1) : AES-256, SHA-256, groupe DH 14+ (ou groupes ECP si les deux côtés les gèrent bien)
• ESP (Phase 2) : AES-256-GCM si supporté bout en bout ; sinon AES-256 + SHA-256
• Durées : pas « aussi courtes que possible ». Visez des valeurs sensées (heures, pas minutes), alignées des deux côtés.
• PFS : activez si vous avez la CPU pour le supporter ; sinon désactivez et compensez par des durées IKE plus longues et une crypto IKE forte.

Votre tunnel ne doit pas se renégocier si souvent que le routeur passe sa journée à négocier au lieu de transférer des paquets.

NAT et règles firewall : rendez le plan de contrôle ennuyeux

Autorisez UDP 500 et UDP 4500 en entrée, et autorisez ESP si vous n’utilisez pas NAT-T (la plupart utilisent NAT-T). Assurez-vous que vos règles NAT ne traduisent pas le trafic qui devrait être protégé.
Un tunnel stable meurt souvent parce qu’une règle NAT « aidante » fait du masquerade au passage vers le tunnel.

MTU/MSS : traitez-le comme une dépendance de première classe

Le surcoût d’encapsulation signifie que votre MTU effectif est plus petit. Si vous ne le prévoyez pas, vous obtenez un échec sélectif : le web marche, les copies de fichiers rampent, le RDP saccade,
et quelqu’un blâme « l’ISP ». C’est presque toujours MTU plus ICMP bloqué.

Pourquoi IKEv2 sur MikroTik bascule : les vrais modes de défaillance

1) Timeouts d’état NAT et changements de port (surtout derrière un CGNAT)

IKEv2 via NAT-T fonctionne sur UDP 4500. Beaucoup de dispositifs NAT éliminent l’état UDP agressivement, surtout quand c’est « idle ».
Quand le mapping change, le pair envoie des paquets vers un port mort et vous obtenez des échecs DPD ou des SA bloqués.
Si vous êtes derrière un CGNAT, c’est pire : le NAT n’est même pas le vôtre à configurer.

Correction : assurez-vous que les keepalives NAT sont activés et que DPD est raisonnable. Ne mettez pas DPD en « mode marteau » à moins d’apprécier les tempêtes de renégociation auto-induites.

2) Collisions de renouvellement et durées mal alignées

Si les deux côtés renégocient en même temps (ou si les durées ne s’alignent pas bien), vous pouvez vous retrouver avec des Child SA remplacées d’une manière qui interrompt les flux.
Le symptôme est « toutes les X minutes, les connexions sont réinitialisées », souvent trop régulières pour être une coïncidence.

Correction : alignez les durées, considérez des marges de renouvellement, et évitez des durées extrêmement courtes. Mesurez aussi la CPU pendant le renouvellement — sur des MikroTik modestes, ça compte.

3) Mismatch de proposition qui n’apparaît qu’au renouvellement

La négociation initiale peut réussir avec un sous-ensemble commun d’algorithmes, mais le renouvellement peut sélectionner un ordre de proposition différent ou toucher un cas limite. Ensuite ça échoue et retombe,
ou ça supprime et renégocie. Cela ressemble à une instabilité aléatoire, parce que c’est lié au temps.

Correction : définissez explicitement les propositions sur les deux côtés. Ne comptez pas sur le « par défaut ». Les valeurs par défaut changent entre les versions de RouterOS et les familles matérielles.

4) Problèmes MTU/fragmentation (messages IKE et plan de données)

Les messages IKEv2 peuvent être volumineux, surtout avec des certificats, plusieurs propositions ou des vendor IDs.
Si la fragmentation UDP est bloquée quelque part, la poignée de main peut échouer de façon intermittente.
Ensuite le plan de données a le classique problème « les gros paquets meurent » si PMTUD est cassé.

Correction : gardez la config crypto légère, autorisez la fragmentation si nécessaire, et clamppez le MSS sur les flux TCP pour éviter de dépendre de PMTUD.

5) Dérive des routes ou des sélecteurs de politique

Les tunnels basés sur les politiques dépendent des sélecteurs. Vous ajoutez un nouveau sous-réseau sur un site et oubliez de l’ajouter sur l’autre ? Le tunnel se lève toujours, mais le trafic vers ce sous-réseau échoue.
Pire : si vous avez des politiques qui se chevauchent, le trafic peut matcher la mauvaise et déclencher des installations de SA « inattendues ».

Correction : gardez les sélecteurs symétriques, maintenez l’ordre des politiques intentionnel, et consignez les drops sur la chaîne forward pour voir ce qui est réellement bloqué.

6) Règles firewall presque correctes

« On autorise UDP 500 et 4500. » Super. Autorisez-vous established/related ? Autorisez-vous le trafic policy IPsec dans la chaîne forward ?
Avez-vous placé une règle fasttrack devant les exceptions IPsec ?

RouterOS peut fasttracker le trafic d’une manière qui évite le traitement IPsec si on ne l’exempte pas. Cela peut créer des trous noirs qui ressemblent à des basculements de tunnel.

7) Capacité et performance : le tunnel est stable, pas le routeur

Sous pression CPU, les keepalives et sondes DPD sont retardés. Puis les peers se déclarent morts et renégocient.
Sur le papier la bande passante est correcte ; en réalité le routeur chiffre, met en file et fait firewall/NAT sans accélération.

Correction : mesurez la CPU pendant les pics, vérifiez le support d’accélération matérielle, simplifiez les règles, et arrêtez de re-négocier toutes les quelques minutes.

Blague #1 : IPsec n’est pas capricieux ; il est simplement très honnête sur chaque petit mensonge que votre réseau lui raconte.

Mode opératoire de diagnostic rapide (premier/deuxième/troisième)

Quand un tunnel « flappe », ne commencez pas par changer la crypto. Commencez par prouver quelle couche est instable.
Voici l’ordre de triage rapide qui fait gagner du temps et évite les superstitions.

Premier : prouvez que le WAN est assez stable pour UDP 4500

• Vérifiez les erreurs/drops d’interface, événements link up/down.
• Vérifiez si l’IP publique change (IP dynamique, reconnect PPPoE, bascule LTE).
• Mesurez la perte de paquets et le jitter vers l’IP publique du pair sur la durée.

Second : prouvez la santé du plan de contrôle IKE

• Surveillez l’âge des IKE SA, les événements de re-négociation, les timeouts DPD.
• Cherchez les messages répétitifs « no proposal chosen », « auth failed », « peer not responding ».
• Confirmez la détection NAT-T et la constance des ports.

Troisième : prouvez la justesse du plan de données

• Vérifiez que les politiques/sélecteurs correspondent au trafic réel.
• Confirmez que le routage envoie les bons sous-réseaux vers IPsec.
• Validez MTU/MSS avec des tests de charge réels (ne faites pas confiance aux pings par défaut).
• Cherchez si fasttrack/NAT interfèrent.

Quatrième : ne tenez compte de la crypto et des durées qu’ensuite

Si le WAN et les politiques sont propres, alors peaufinez les propositions, le PFS, les durées et les marges de re-négociation.
Faire cela plus tôt est la façon dont les gens obtiennent des configs qui « fonctionnent parfois ».

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

Ces tâches sont écrites comme un runbook d’astreinte : lancez une commande, interprétez la sortie, puis prenez une décision.
Les commandes sont montrées comme si exécutées depuis un jump host Linux qui peut SSHer dans les deux MikroTiks. Adaptez les noms d’hôtes.

Task 1: Confirm RouterOS version and platform (behavior varies)

cr0x@server:~$ ssh admin@mtk-office-a '/system/resource/print'
                   uptime: 2w1d3h
                  version: 7.15.3 (stable)
               build-time: 2025-08-01 10:12:45
              free-memory: 312.4MiB
             total-memory: 512.0MiB
                      cpu: ARM
                cpu-count: 4
            cpu-frequency: 1400MHz
                 cpu-load: 18%

Ce que cela signifie : la version majeure/minor de RouterOS affecte les détails de la pile IPsec et les valeurs par défaut. La CPU et la mémoire vous indiquent si vous êtes près des limites.

Décision : Si les versions diffèrent largement entre sites, alignez-les. Si la charge CPU monte lors des pertes, vous avez un problème de capacité, pas un problème crypto.

Task 2: Check link stability and WAN IP churn

cr0x@server:~$ ssh admin@mtk-office-a '/ip/address/print where interface~"wan"'
 #   ADDRESS            NETWORK         INTERFACE
 0   203.0.113.10/24    203.0.113.0     wan1

cr0x@server:~$ ssh admin@mtk-office-a '/log/print where message~"link down|link up|pppoe"'
 0 time=2025-12-27 10:12:01 topics=interface,info message=wan1 link down
 1 time=2025-12-27 10:12:05 topics=interface,info message=wan1 link up (speed 1G, full duplex)

Ce que cela signifie : si l’interface WAN rebondit, IPsec en est une victime collatérale. Le tunnel n’est pas « en train de flapper » ; c’est l’ISP.

Décision : Réparez le lien physique/l’ISP d’abord. Si l’IP change fréquemment, préférez une identité FQDN ou un workflow DDNS et vérifiez l’appariement des peers.

Task 3: Check IPsec peers and see if NAT-T is used

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/peer/print detail'
 0 name="office-b" address=198.51.100.20/32 local-address=203.0.113.10
   exchange-mode=ike2 send-initial-contact=yes nat-traversal=yes
   dpd-interval=10s dpd-maximum-failures=3 profile=ike2-prof

Ce que cela signifie : NAT traversal activé est typiquement correct. L’intervalle DPD et le nombre d’échecs définissent la vélocité de déclaration d’un pair comme mort.

Décision : Si vous voyez nat-traversal=no alors qu’un côté est derrière un NAT, corrigez-le. Si DPD est trop agressif pour votre WAN, adoucissez-le.

Task 4: Inspect active SAs and look for churn timing

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/active-peers/print detail'
 0 ike2=yes name="office-b" state=established
   local-address=203.0.113.10 remote-address=198.51.100.20
   side=initiator nat-traversal=yes
   uptime=00:43:12 last-dpd=00:00:07

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/installed-sa/print detail'
 0 spi=0xC1A2B3C4 src-address=203.0.113.10 dst-address=198.51.100.20
   state=mature auth-algorithm=sha256 enc-algorithm=aes-256-gcm
   lifetime=00:58:21 expires-in=00:01:39

Ce que cela signifie : si les SA expirent et se réinstallent constamment, vous avez probablement des durées trop courtes ou une instabilité de renouvellement.

Décision : Si les rekeys surviennent plus souvent que toutes les heures pour un tunnel bureau-à-bureau basique, revisitez les durées et le PFS.

Task 5: Enable focused IPsec debug logging briefly (then turn it off)

cr0x@server:~$ ssh admin@mtk-office-a '/system/logging/add topics=ipsec,debug action=memory'
cr0x@server:~$ ssh admin@mtk-office-a '/log/print where topics~"ipsec"'
 0 time=2025-12-28 09:14:02 topics=ipsec,debug message=initiating IKE_SA to 198.51.100.20
 1 time=2025-12-28 09:14:02 topics=ipsec,debug message=IKE_SA established
 2 time=2025-12-28 09:15:33 topics=ipsec,debug message=DPD timeout, peer not responding
 3 time=2025-12-28 09:15:33 topics=ipsec,debug message=deleting IKE_SA

Ce que cela signifie : le log montre la cause côté contrôle : ici ce sont des timeouts DPD, pas des propositions.

Décision : Si des timeouts DPD surviennent alors que le WAN est stable, suspectez l’expiration de l’état NAT, un filtrage en amont, ou un délai CPU.

Task 6: Validate firewall allows IKEv2 and NAT-T to the router

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print where chain="input"'
 0 chain=input action=accept connection-state=established,related
 1 chain=input action=accept protocol=udp dst-port=500,4500
 2 chain=input action=drop in-interface=wan1

Ce que cela signifie : UDP 500/4500 autorisés avant le drop. Bien. Si ces règles sont après un drop, vous avez fabriqué un presse-papier en forme de VPN.

Décision : Assurez-vous que les règles d’acceptation sont au-dessus des drops. Si vous utilisez des address-lists, restreignez-les aux IP des peers pour l’hygiène.

Task 7: Detect fasttrack interfering with IPsec

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print where action~"fasttrack"'
 0 chain=forward action=fasttrack-connection connection-state=established,related

Ce que cela signifie : une règle fasttrack générique peut contourner le traitement IPsec à moins que vous n’exemptiez les flux IPsec.

Décision : Ajoutez une exception pour le trafic ipsec-policy=in,ipsec avant fasttrack, ou désactivez fasttrack si vous le pouvez.

Task 8: Confirm NAT rules don’t NAT protected subnets

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/nat/print'
 0 chain=srcnat action=masquerade out-interface=wan1
 1 chain=srcnat action=accept ipsec-policy=out,ipsec
 2 chain=srcnat action=masquerade src-address=10.10.0.0/16 out-interface=wan1

Ce que cela signifie : la règle 1 est l’acceptation critique « ne pas NATer IPsec ». Sans elle, une partie du trafic peut être NATée et ne plus correspondre aux sélecteurs.

Décision : Assurez-vous que la règle d’accept existe et est au-dessus des masquerade. Si vous voyez du masquerade toucher le trafic VPN, corrigez l’ordre.

Task 9: Verify policy selectors match both directions

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/policy/print detail'
 0 src-address=10.10.10.0/24 dst-address=10.20.10.0/24 action=encrypt
   tunnel=yes peer=office-b proposal=esp-prof

cr0x@server:~$ ssh admin@mtk-office-b '/ip/ipsec/policy/print detail'
 0 src-address=10.20.10.0/24 dst-address=10.10.10.0/24 action=encrypt
   tunnel=yes peer=office-a proposal=esp-prof

Ce que cela signifie : la symétrie importe. Si Office B a 10.10.0.0/16 tandis qu’Office A utilise 10.10.10.0/24, vous aurez une atteignabilité partielle et des installations de SA déroutantes.

Décision : Normalisez les sélecteurs. Si vous avez besoin de nombreux sous-réseaux, envisagez de consolider les sélecteurs soigneusement ou de passer à une approche basée sur le routage pour réduire la prolifération des politiques.

Task 10: Observe drops and policy matches using counters

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print stats where chain="forward"'
 0 chain=forward action=accept ipsec-policy=in,ipsec packet-count=124992 byte-count=98311234
 1 chain=forward action=accept ipsec-policy=out,ipsec packet-count=121887 byte-count=96733122
 2 chain=forward action=drop in-interface=wan1 packet-count=22 byte-count=1452

Ce que cela signifie : le trafic policy IPsec est accepté et compté. Si les compteurs restent à zéro alors que les utilisateurs se plaignent, le trafic ne correspond pas à la politique (routage, NAT ou sélecteurs).

Décision : Si les compteurs d’accept IPsec n’incrémentent pas, arrêtez de bidouiller IPsec et corrigez le routage/NAT/adresses.

Task 11: MTU reality check with a “do not fragment” ping

cr0x@server:~$ ping -M do -s 1472 10.20.10.10 -c 3
PING 10.20.10.10 (10.20.10.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460

--- 10.20.10.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Ce que cela signifie : le PMTU du chemin est plus petit que prévu. Sur VPN, c’est normal — mais il faut en tenir compte pour TCP.

Décision : Clamppez le MSS TCP sur le MikroTik pour le trafic entrant dans le tunnel, ou ajustez les MTU d’interface si vous contrôlez le chemin.

Task 12: Check for IKE fragmentation or large handshake issues (symptom-driven)

cr0x@server:~$ ssh admin@mtk-office-a '/log/print where message~"fragment|too large|invalid"'
 0 time=2025-12-28 08:01:19 topics=ipsec,debug message=received packet too large, dropping
 1 time=2025-12-28 08:01:19 topics=ipsec,debug message=peer not responding

Ce que cela signifie : certains réseaux bloquent les fragments UDP. De gros messages IKE peuvent mourir en transit, provoquant des échecs de négociation intermittents.

Décision : Réduisez la profusion de propositions, envisagez PSK plutôt que des chaînes de certificats quand approprié, et assurez-vous que les dispositifs en amont ne bloquent pas les fragments.

Task 13: Measure CPU and interrupt pressure during renegotiation

cr0x@server:~$ ssh admin@mtk-office-a '/tool/profile'
name                    cpu        memory
firewall                22%        0 B
ipsec                   31%        0 B
ethernet                6%         0 B
management              2%         0 B

Ce que cela signifie : IPsec consommant un tiers de la CPU n’est pas automatiquement mauvais, mais si cela monte à 90 % lors des pics, DPD et les timers de re-négociation deviennent imprécis.

Décision : Si IPsec est un consommateur majeur de CPU et que vous voyez des basculements, augmentez les durées, réduisez le coût PFS, activez l’offload matériel si supporté, ou améliorez le matériel.

Task 14: Verify routing to remote subnets (don’t assume)

cr0x@server:~$ ssh admin@mtk-office-a '/ip/route/print where dst-address=10.20.10.0/24'
 0 dst-address=10.20.10.0/24 gateway=ipsec policy distance=1 scope=30 target-scope=10

Ce que cela signifie : selon la conception, vous pouvez voir du routage piloté par politique sans routes explicites, ou vous pouvez compter sur des routes. Ce que vous ne pouvez pas compter sur, ce sont les impressions.

Décision : Si des routes pointent ailleurs (route par défaut, mauvais gateway, mauvais VRF), le tunnel peut être « up » tandis que le trafic part vers Internet et meurt.

Task 15: Capture packets to prove if you’re losing IKE or ESP

cr0x@server:~$ ssh admin@mtk-office-a '/tool/sniffer/quick interface=wan1 ip-protocol=udp port=500,4500'
 0  2025-12-28 09:21:11 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92
 1  2025-12-28 09:21:21 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92
 2  2025-12-28 09:21:31 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92

Ce que cela signifie : vous voyez des keepalives/DPD sortants, mais voyez-vous des réponses ? Si non, c’est filtrage en amont, état NAT, ou le distant est mort.

Décision : Si l’outbound existe mais pas l’inbound, arrêtez de reconfigurer le routeur local. Prouvez le chemin ou que le côté distant droppe.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait deux bureaux et un tunnel IKEv2 « simple ». Il a fonctionné pendant des mois, puis a commencé à tomber tous les après-midis. Le helpdesk accusait l’ISP,
l’équipe réseau pointait IPsec, et la sécurité accusait « quelqu’un qui change la crypto ».

L’hypothèse erronée était subtile : ils supposaient que « pas de trafic » signifie « pas de problèmes ». En réalité, le tunnel était majoritairement inactif jusqu’à ce que le personnel commence à utiliser une nouvelle application SaaS
qui générait des rafales périodiques et de longues fenêtres d’inactivité. L’appareil NAT de l’ISP avait un timeout UDP agressif. Le mapping NAT pour UDP 4500 expirait pendant l’inactivité,
puis le paquet suivant sortait avec un nouveau port source. Le pair continuait d’envoyer vers l’ancien mapping jusqu’à ce que DPD déclare le peer mort.

Les logs répétaient l’histoire : timeout DPD, suppression IKE SA, renégociation. Mais tout le monde ne regardait que pendant le moment où c’était « de nouveau up », voyait des SA établies,
et passait à autre chose.

La correction a été ennuyeuse : activer les keepalives NAT réguliers (et arrêter de les désactiver « pour réduire le bruit »), assouplir DPD pour tolérer le jitter bref, et définir des durées pour que les rekeys ne surviennent pas
lors des sauvegardes quotidiennes. Le tunnel est redevenu invisible, ce qui est le meilleur type de VPN.

Mini-récit 2 : l’optimisation qui a mal tourné

Un autre atelier avait un firewall RouterOS avec fasttrack activé. Ils en étaient fiers. Le débit était excellent, la CPU basse, les graphiques beaux.
Puis ils sont passés d’IKEv1 à IKEv2 et ont soudain eu du trafic unilatéral intermittent. Le tunnel ne « tombait » jamais, mais les transferts de fichiers se bloquaient et la VoIP devenait robotique pendant 10–30 secondes aléatoires.

L’« optimisation » était fasttrack sur established/related sans exception pour IPsec. Certains flux étaient fasttrackés d’une manière qui contournait les vérifications de politique nécessaires au chiffrement/déchiffrement.
En effet, certains paquets prenaient la voie rapide droit dans un mur.

Ils ont essayé de corriger en changeant la crypto. Puis en modifiant les durées. Puis en changeant le matériel. Classique. Rien de tout cela n’aide si le firewall saute la partie où il décide que le trafic appartient à IPsec.

La correction a été chirurgicale : insérer une règle accept pour ipsec-policy=in,ipsec et ipsec-policy=out,ipsec avant fasttrack, et s’assurer que les NAT avaient une acceptation top-level si ipsec-policy=out,ipsec.
Le débit a légèrement baissé. La stabilité a fortement augmenté. Tout le monde a fait comme si c’était prévu depuis le départ.

Mini-récit 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise distribuée avait trois petits bureaux et un site « hub ». Chaque bureau utilisait un ISP différent, et un bureau était sur LTE en secours.
Les problèmes VPN étaient attendus ; personne ne s’attendait à pouvoir les diagnostiquer rapidement.

La pratique ennuyeuse : ils avaient un runbook standardisé et un nommage cohérent. Les peers étaient nommés par site, les propositions identiques sur les routeurs, les durées alignées,
et ils centralisaient les logs IPsec avec suffisamment de debug pour être utiles sans être un feu d’artifice.

Un jour, un bureau a commencé à flapper après une maintenance ISP. L’ingénieur d’astreinte n’a pas deviné. Il a vérifié les logs WAN, sans changement de lien. Il a vérifié les logs IPsec,
a vu des timeouts DPD avec un nouveau motif. Il a lancé un sniffer et a confirmé des UDP 4500 sortants sans réponses entrantes. La conclusion a été immédiate : problème de chemin en amont, pas de microTik.

Ils ont escaladé avec des preuves : horodatages, résumés de capture, et clair « on envoie, on ne reçoit pas ». L’ISP a corrigé une règle stateful cassée à son edge. Le VPN a été stable.
Personne n’a dû rétrograder un firmware à minuit. Personne n’a eu à « juste redémarrer ». L’ennuyeux a gagné.

Erreurs courantes : symptôme → cause racine → correction

1) Le tunnel se renégocie toutes les quelques minutes comme une horloge

• Symptôme : coupures prévisibles toutes les 5–30 minutes ; les logs montrent des cycles rekey/delete.
• Cause racine : durées très courtes, collisions de rekey, ou pics CPU pendant les rekeys.
• Correction : augmentez les lifetimes IKE/ESP, alignez-les des deux côtés, réduisez le coût PFS si nécessaire, et assurez-vous que les jeux de propositions sont explicites et identiques.

2) « Peer not responding » mais le WAN a l’air OK

• Symptôme : timeouts DPD ; le tunnel se rétablit vite ; les utilisateurs subissent de brèves coupures.
• Cause racine : expiration du mapping NAT ou filtrage en amont intermittant de UDP 4500.
• Correction : activez les keepalives, ajustez DPD à la réalité du WAN, évitez le double-NAT quand possible, et prouvez la perte de paquets avec un sniffer.

3) Le tunnel est up, mais certains sous-réseaux marchent et d’autres non

• Symptôme : un VLAN atteint le site distant ; un autre ne l’atteint pas ; des SA existent.
• Cause racine : mismatch de sélecteur, politiques manquantes, ou NAT qui traduit un sous-réseau.
• Correction : rendez les sélecteurs symétriques ; ajoutez les politiques manquantes ; ajoutez ipsec-policy=out,ipsec en acceptation NAT au-dessus du masquerade.

4) Le web fonctionne, les gros transferts échouent, RDP est instable

• Symptôme : petits paquets passent ; gros paquets stallent ; timeouts intermittents.
• Cause racine : échec MTU/PMTUD dû à l’overhead d’encapsulation et aux messages ICMP fragmentation-needed bloqués.
• Correction : clamppez le MSS TCP sur le trafic VPN ; autorisez les types ICMP nécessaires ; testez avec des pings DF et des tailles de charge réelles.

5) Ça marche jusqu’à ce que vous activiez fasttrack, puis des ruptures « aléatoires »

• Symptôme : le tunnel reste établi, mais le plan de données devient intermittent, souvent unidirectionnel.
• Cause racine : fasttrack contourne le traitement nécessaire pour le trafic policy IPsec.
• Correction : ajoutez des règles explicites d’acceptation pour le trafic policy IPsec avant fasttrack ou désactivez fasttrack.

6) La négociation échoue seulement après une mise à jour de firmware

• Symptôme : « no proposal chosen », « auth failed », ou nouveau comportement autour des durées.
• Cause racine : les valeurs par défaut ont changé, l’ordre des algorithmes a changé, ou des chiffrements ont été retirés.
• Correction : figez les propositions et profils explicitement ; alignez les versions ; testez le comportement de rekey avant de déployer en production.

7) Une seule direction passe le trafic

• Symptôme : Office A atteint B ; B n’atteint pas A, ou inversement.
• Cause racine : sélecteurs asymétriques, asymétrie de routage, ou règles forward manquantes acceptant le policy IPsec.
• Correction : assurez-vous que les deux directions ont des politiques correspondantes ; vérifiez les routes ; ajoutez des règles forward accept pour ipsec-policy in/out.

Blague #2 : la façon la plus rapide de « fixer » un VPN est de déclarer qu’il « fonctionne comme prévu » et d’aller déjeuner — jusqu’à ce que le CFO essaie d’imprimer.

Listes de contrôle / plan étape par étape pour la stabilité

Étape 1 : standardiser et documenter le contrat du tunnel

• Listez les sous-réseaux locaux/distants, y compris la croissance future.
• Choisissez sciemment basé sur les politiques ou basé sur le routage.
• Choisissez la suite crypto et les durées ; écrivez-les.
• Nommez les objets de façon cohérente : peers, identités, propositions, politiques.

Étape 2 : rendez le plan de contrôle résilient

• Autorisez UDP 500 et 4500 vers le routeur depuis le peer.
• Activez NAT-T sauf si vous pouvez garantir qu’il n’y a pas de NAT sur le chemin.
• Réglez DPD pour détecter une vraie panne sans paniquer au moindre jitter.
• Alignez les lifetimes IKE et ESP ; évitez les durées « minuscule ».

Étape 3 : rendez le plan de données explicite

• Ajoutez des règles forward pour accepter ipsec-policy=in,ipsec et ipsec-policy=out,ipsec.
• Ajoutez une exemption NAT : chain=srcnat action=accept ipsec-policy=out,ipsec au-dessus de tout masquerade.
• Vérifiez que les sélecteurs de politique correspondent exactement des deux côtés.
• Privilégiez des plages RFC1918 non chevauchantes entre sites.

Étape 4 : corrigez MTU/MSS avant que les utilisateurs ne le découvrent

• Testez le PMTU avec des pings DF.
• Clampez le MSS TCP pour le trafic entrant dans le tunnel (valeur courante : 1360–1400 ; mesurez, ne devinez pas).
• Autorisez les messages ICMP fragmentation-needed si votre posture de sécurité le permet.

Étape 5 : surveillez ce qui compte

• Consignez les événements IPsec (pas le debug complet en permanence) et conservez les horodatages.
• Graphiquez la CPU, les drops/erreurs d’interface, et le nombre de SA IPsec dans le temps.
• Alertez sur les ré-établissements fréquents, pas seulement « tunnel down ».

Étape 6 : discipline opérationnelle pour les changements

• Mettez à jour RouterOS dans une fenêtre contrôlée ; gardez les deux extrémités compatibles.
• Changez une variable à la fois : DPD, durées, propositions, règles NAT.
• Après tout changement, forcez un test de rekey et validez le trafic pour tous les sous-réseaux.

Un principe de fiabilité qui vaut la peine d’être repris

Idée à paraphraser : John Ousterhout soutenait que la complexité est l’ennemie de la fiabilité ; les systèmes plus simples échouent de moins de façons surprenantes.

FAQ

1) Dois-je utiliser IKEv2 ou IKEv1 sur MikroTik pour du site-à-site ?

Utilisez IKEv2 sauf si vous avez un pair legacy qui impose IKEv1. IKEv2 se comporte généralement mieux pour NAT traversal et la logique de re-négociation.
La stabilité dépend encore plus du chemin réseau et de la discipline de configuration que du numéro de version.

2) Quels réglages DPD devrais-je utiliser pour éviter le flapping ?

Commencez conservateur : intervalle DPD autour de 10–30 secondes et échecs maximum autour de 3–5, puis ajustez selon le comportement du WAN.
Si vous le rendez trop agressif sur un lien bruyant, vous dites au routeur de rompre la relation pour de petits retards.

3) Mon tunnel est établi mais le trafic ne passe pas. Où regarder en premier ?

Vérifiez les exemptions NAT et les règles forward-chain du firewall pour le trafic policy IPsec. Ensuite vérifiez que les sélecteurs/politiques correspondent des deux côtés.
Après cela, regardez le routage et les sous-réseaux chevauchants.

4) Dois-je autoriser ESP (protocole 50) dans le firewall ?

Si vous utilisez NAT-T (UDP 4500), ESP est encapsulé dans UDP et vous avez généralement seulement besoin d’UDP 500/4500.
Si NAT-T est désactivé et qu’il n’y a pas de NAT sur le chemin, alors oui, ESP doit être autorisé.

5) Comment savoir si le MTU est mon problème ?

Si les petits pings passent mais les gros transferts calment, suspectez le MTU. Prouvez-le avec des pings DF et ajustez le MSS TCP.
Vérifiez aussi si ICMP fragmentation-needed est bloqué quelque part entre les sites.

6) Dois-je activer le PFS ?

Si vous avez de la marge CPU et des exigences de conformité/sécurité, activez-le. Si votre MikroTik est petit et déjà chargé,
PFS plus des durées courtes peut provoquer des tempêtes de rekey. La sécurité est une propriété du système ; la stabilité compte aussi.

7) Pourquoi ça bascule plus pendant les heures de pointe ?

Les heures de pointe corrèlent avec la charge CPU, la pression sur les files et la congestion WAN. Si les timers IPsec (DPD, rekey) sont retardés, les peers se déclarent défaillants.
Vérifiez /tool/profile, les drops d’interface, et si votre routeur fait trop de choses (NAT, firewall, queues) en plus du chiffrement.

8) Le fasttrack peut-il rester activé avec IPsec ?

Parfois, mais vous devez ajouter des exceptions pour que le trafic policy IPsec ne soit pas fasttracké d’une manière qui contourne le traitement.
Si vous ne pouvez pas raisonner sur l’ordre des règles sous stress, désactivez fasttrack et récupérez des performances avec du meilleur matériel.

9) « send-initial-contact=yes » est-ce bien ou mal ?

Généralement bon pour nettoyer les SA obsolètes sur le répondant quand l’initiateur se reconnecte (surtout après un changement d’IP).
En scénarios multi-peer ou HA, cela peut supprimer des SA que vous ne vouliez pas toucher. Utilisez-le quand vous savez qui est autorisé à se connecter sous cette identité.

10) Quelle est la façon la plus simple de réduire les coupures liées au rekey ?

Alignez les durées, gardez le jeu de propositions petit et explicite, et ne renégociez pas trop fréquemment. Puis confirmez la marge CPU pendant le rekey.
Le rekey doit être un non-événement, pas un exercice de coupure.

Conclusion : prochaines étapes qui réduisent réellement les basculements

Un IKEv2 stable entre bureaux n’est pas magique. C’est une chaîne de vérités ennuyeuses :
le WAN doit être assez stable, le NAT doit garder l’état, les règles firewall/NAT doivent respecter IPsec, les sélecteurs doivent correspondre, et le MTU doit être traité de façon proactive.
Si vous soignez ces éléments, la crypto devient un choix de politique plutôt qu’une roue de la fortune de dépannage.

Prochaines étapes pratiques :

1. Exécutez le playbook de diagnostic rapide et classez le problème : WAN, plan de contrôle ou plan de données.
2. Figez les propositions et les durées explicitement des deux côtés ; arrêtez de compter sur les valeurs par défaut.
3. Ajoutez et vérifiez les règles d’exemption NAT et les règles forward accept IPsec ; vérifiez les compteurs.
4. Testez le MTU avec des pings DF et clamppez le MSS pour que les applications arrêtent d’apprendre le MTU à la dure.
5. Mesurez la CPU pendant les pics et pendant les rekeys ; si vous êtes près des limites, ajustez les durées ou upgradez le matériel.
6. Conservez les logs juste assez longtemps pour attraper les basculements, et gardez un nommage cohérent pour que votre futur vous puisse analyser rapidement la situation.

Votre objectif n’est pas un tunnel qui peut se connecter. Votre objectif est un tunnel dont personne ne se soucie. C’est la définition production-grade de « stable ».