Logs VPN qui comptent : trouver les causes de « won’t connect » dans les logs MikroTik/Linux

« VPN won’t connect » n’est pas un symptôme. C’est une plainte. Et la différence importe, parce que les plaintes sont escaladées ; les symptômes sont diagnostiqués.

Quand l’ordinateur du PDG ne peut pas se connecter depuis un Wi‑Fi d’hôtel qui bloque la moitié d’internet, vous n’avez pas besoin d’intuitions. Vous avez besoin des bons logs, des bonnes commandes, et d’un moyen rapide pour décider si vous faites face à un problème d’authentification, de routage, d’incompatibilité crypto, de NAT, de MTU, ou simplement à un blocage de pare‑feu.

Table des matières

• Quels logs importent réellement (et pourquoi la plupart n’en valent pas la peine)
• Playbook de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)
• Construire un modèle mental : où se trouve la vérité
• MikroTik : journalisation qui capte les échecs sans vous noyer
• Linux : journalctl, noyau et logs des démons VPN qui paient leur loyer
• Tâches pratiques (commandes + sorties + décisions)
• Motifs de logs qui correspondent à des causes réelles
• Erreurs courantes : symptôme → cause racine → correctif
• Checklists / plan pas à pas (workflow production)
• Trois mini‑histoires du monde corporate (anonymisées, réalistes)
• Faits intéressants & courte histoire (ce qui explique les douleurs d’aujourd’hui)
• FAQ
• Conclusion : étapes suivantes pour réduire les répétitions

Quels logs importent réellement (et pourquoi la plupart n’en valent pas la peine)

Le dépannage VPN est un jeu de latence : plus vous passez de temps à regarder du bruit de log non pertinent, plus vos utilisateurs restent hors ligne. Votre objectif est de rassembler juste assez de preuves pour choisir la bonne branche : auth vs crypto vs chemin réseau vs politique/routage.

Il n’y a que quelques catégories de logs qui répondent systématiquement à « pourquoi ça ne se connecte pas ? »

• Logs d’établissement de session : négociations IKE/IPsec, handshakes TLS, handshakes WireGuard. Ils vous disent « nous n’avons pas pu nous accorder » ou « nous n’avons jamais atteint le pair ».
• Logs d’authentification/autorisation : échecs nom d’utilisateur/mot de passe, validation de certificat, décisions EAP, réponses RADIUS. Ils vous disent « on a atteint la cible, mais elle a dit non ».
• Logs pare‑feu/NAT : drops et translations autour de UDP 500/4500, ESP, TCP 443/1194, etc. Ils vous disent « les paquets sont morts ici ».
• Logs de routage et de politique : quelles routes ont été installées, quels sélecteurs ont matché, quelles politiques ont été appliquées. Ils vous disent « connecté, mais inutile ».
• Logs noyau/pilote : problèmes de MTU, fragmentation, comportements d’offload étranges, interface qui flanche. Ils vous disent « la physique n’est pas d’accord avec votre configuration ».

Ce qui importe moins que ce que les gens pensent : le churn PPP « connecté/déconnecté » sans contexte, les messages génériques « peer not responding » sans corrélation d’captures de paquets, ou des logs méga‑debug collectés après coup sans horodatages alignés entre systèmes. Votre premier geste doit être de synchroniser l’heure, puis de filtrer à la minute de la panne.

Une heuristique fiable : quand un VPN « won’t connect », la cause est généralement visible dans une de ces places :

1. les logs côté client du démon VPN (ce qu’il a essayé)
2. les logs côté serveur du démon VPN (ce qu’il a rejeté ou n’a jamais vu)
3. les logs de bord réseau (ce qui a été bloqué ou altéré)

Obtenez ces trois vues, alignez les horodatages, et l’histoire s’écrira d’elle‑même.

Playbook de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Premier : confirmer le chemin (est‑ce que quelque chose atteint quelque chose ?)

• Sur MikroTik : recherchez les drops de pare‑feu sur les ports/protocoles VPN et les tentatives d’initiation IKE.
• Sur Linux : cherchez des paquets entrants sur l’interface attendue, puis vérifiez si le démon VPN a loggé une nouvelle tentative de handshake.

Décision : si vous ne voyez aucun trafic au niveau du serveur/routeur pendant la fenêtre de tentative, vous ne dépannez pas la crypto. Vous dépannez la reachabilité (routage, pare‑feu, FAI, politique Wi‑Fi d’hôtel).

Deuxième : classer l’échec (auth vs négociation vs politique)

• Échecs d’auth : « AUTH_FAILED », « no shared key found », « EAP failure », « bad username or password », « certificate verify failed ».
• Échecs de négociation : « no proposal chosen », « invalid KE payload », « TS_UNACCEPTABLE », « encryption algorithm not supported ».
• Échecs de politique/routage : tunnel up mais pas de routes, mauvais sélecteurs, trafic qui ne matche pas la politique, mauvais paramètres de split‑tunnel.

Décision : choisissez le correctif le plus petit possible : une seule chaîne d’identité, une suite de chiffrement, un seul sélecteur de sous‑réseau, une règle de pare‑feu.

Troisième : éliminer les tueurs silencieux (temps, MTU, NAT‑T)

• Heure : la validation des certificats et les durées de vie IKE s’écroulent quand les horloges dérivent.
• MTU : « se connecte » mais bloque ; le web marche mais SMB plante ; les gros paquets disparaissent.
• Traversal NAT : UDP 500 marche jusqu’à l’apparition d’un NAT ; UDP 4500 bloqué ; ESP altéré.

Décision : si les symptômes varient selon les réseaux (le domicile marche, l’hôtel échoue), suspectez MTU/NAT/ports bloqués avant de réécrire le VPN.

Idée paraphrasée (attribuée) : « L’espoir n’est pas une stratégie. » — Edsger W. Dijkstra (idée paraphrasée)

Construire un modèle mental : où se trouve la vérité

Le dépannage VPN échoue quand vous traitez les logs comme un album de découpures. Traitez‑les comme une trace de transaction distribuée : chaque composant enregistre une vue partielle, et le recoupement est là où la causalité émerge.

Pour une configuration d’accès distant typique (client ↔ internet ↔ MikroTik ↔ endpoint Linux VPN ou services), vos sources de données sont :

• Logs client : vous disent ce que le client a proposé, ce qu’il attendait, et ce qu’il a considéré comme fatal.
• Logs MikroTik : vous parlent d’IKE, L2TP/PPP, des décisions du pare‑feu, et du comportement NAT en bordure.
• Logs du démon VPN Linux : strongSwan, OpenVPN, outils WireGuard ; vous disent les raisons au niveau protocole.
• Noyau Linux + netfilter : paquets droppés, anomalies conntrack/NAT, indices MTU/fragmentation.
• Logs AAA : décisions RADIUS/LDAP ou base d’utilisateurs locale.

L’alignement des horloges compte plus que vous ne le souhaitez. Si le MikroTik a 90 secondes de décalage et que votre hôte Linux est synchronisé via NTP, vous « prouverez » la mauvaise chose. Corrigez l’heure d’abord, puis poursuivez les fantômes.

MikroTik : journalisation qui capte les échecs sans vous noyer

MikroTik peut être merveilleusement franc. Il vous dira « no proposal chosen » et vous pourrez rentrer tôt chez vous. Ou il dira « peer not responding » et vous gaspillerez deux heures à moins de corréler avec les compteurs de pare‑feu et le flux de paquets.

Que faut‑il activer (et laisser désactivé)

Activez les logs qui capturent :

• ipsec : détails de négociation au niveau info (et temporairement en debug pour une source unique)
• l2tp, ppp : pour l’authentification et l’établissement de session (si vous utilisez des éléments L2TP/PPTP/PPPoE)
• pare‑feu : pour les drops sur les chaînes pertinentes (limité, avec rate‑limit, et ciblé)

Évitez de laisser le debug complet activé en permanence. Les logs debug sont comme la caféine : utiles en cas de besoin, puis vous vous demandez pourquoi votre cœur s’emballe et votre stockage est plein.

À quoi ressemble un bon output dans les logs MikroTik

Pour IPsec/IKEv2, le « bon » inclut souvent :

• peer initie
• proposition acceptée
• SA établie
• politiques installées

Pour L2TP/IPsec, vous voulez voir :

• IPsec établi en premier
• puis le canal de contrôle L2TP qui monte
• puis l’auth PPP qui réussit

Si vous ne voyez que la première moitié, vous savez où viser.

Linux : journalctl, noyau et logs des démons VPN qui paient leur loyer

Linux vous donne plus de visibilité que vous ne méritez. L’astuce n’est pas de collecter les logs ; c’est de poser des questions ciblées.

Sources de logs qui comptent

• journal systemd via journalctl (la plupart des distributions)
• /var/log/auth.log ou /var/log/secure (PAM, SSH, certains hooks d’auth VPN)
• Logs strongSwan (démon charon)
• Logs OpenVPN (sortie de l’unité service ou fichier de log)
• Logs noyau pour xfrm/IPsec, WireGuard, drops netfilter

Quand c’est possible, routez les logs de service dans journald et utilisez le filtrage structuré par unité. Grepper des fichiers plats fonctionne, mais nous sommes en 2025 ; on peut faire mieux.

Tâches pratiques (commandes + sorties + décisions)

Voici les tâches que j’exécute réellement quand un VPN ne se connecte pas. Chaque tâche inclut une commande, à quoi ressemble une sortie typique, et la décision que vous en tirez.

Task 1: Confirm system time alignment (Linux)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 15:40:11 UTC
           Universal time: Sun 2025-12-28 15:40:11 UTC
                 RTC time: Sun 2025-12-28 15:40:11
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : « System clock synchronized: yes » est ce que vous voulez. Les VPN basés sur certificats échoueront de façon stupide si l’heure est incorrecte.

Décision : Si non synchronisé, corrigez NTP avant de dépanner le VPN. Sinon vous lirez mal les erreurs de certificat et les fenêtres de replay.

Task 2: Check whether packets arrive at the Linux server during an attempt

cr0x@server:~$ sudo tcpdump -ni eth0 'udp port 500 or udp port 4500 or proto 50' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:41:02.101234 IP 198.51.100.23.55231 > 203.0.113.10.500: isakmp: phase 1 I ident
15:41:02.105991 IP 203.0.113.10.500 > 198.51.100.23.55231: isakmp: phase 1 R ident
15:41:03.220110 IP 198.51.100.23.55231 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xcafebabe,seq=0x1)

Sens : Vous avez de la reachabilité et de l’activité NAT‑T. Si c’est silencieux, le souci est en amont : pare‑feu, routage, FAI, ou le client n’a jamais envoyé.

Décision : Si aucun paquet n’arrive, arrêtez de bidouiller les chiffrements. Commencez par vérifier les ACL, le NAT, et si le client pointe la bonne IP.

Task 3: strongSwan IKEv2 logs for handshake failure classification

cr0x@server:~$ sudo journalctl -u strongswan --since "15:40" --no-pager
Dec 28 15:41:02 server charon[1123]: 09[IKE] received IKE_SA_INIT request from 198.51.100.23[55231]
Dec 28 15:41:02 server charon[1123]: 09[IKE] no proposal chosen
Dec 28 15:41:02 server charon[1123]: 09[IKE] sending NO_PROPOSAL_CHOSEN notify to 198.51.100.23[55231]

Sens : Mismatch crypto. Le pair a proposé des algorithmes que vous n’acceptez pas (ou inversement).

Décision : Alignez les propositions. N’« ouvrez tout » pas en permanence ; ajoutez la suite minimale compatible et planifiez un nettoyage.

Task 4: strongSwan “authentication failed” vs “not found”

cr0x@server:~$ sudo journalctl -u strongswan --since "15:40" --no-pager | tail -n 6
Dec 28 15:41:22 server charon[1123]: 11[IKE] authentication of 'vpnuser' with EAP failed
Dec 28 15:41:22 server charon[1123]: 11[IKE] sending AUTHENTICATION_FAILED notify
Dec 28 15:41:22 server charon[1123]: 11[IKE] IKE_SA closed

Sens : Le chemin réseau est OK ; les identifiants ou l’intégration AAA ne le sont pas.

Décision : Arrêtez de regarder les règles de pare‑feu. Vérifiez RADIUS/LDAP, les secrets utilisateur, et la compatibilité des méthodes EAP.

Task 5: WireGuard handshake status (Linux)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 7E8sN8ZQk0yqJfYHk2m2pX1G4vQn4w2XhQ0v0n0n0n0=
  listening port: 51820

peer: GkYp9q3yR1l4tD0Nw7xqzK9uJm9c0q0H0e0o0r0e0r0=
  endpoint: 198.51.100.23:60211
  allowed ips: 10.66.66.2/32
  latest handshake: 2 minutes, 11 seconds ago
  transfer: 18.32 MiB received, 22.10 MiB sent
  persistent keepalive: every 25 seconds

Sens : Si « latest handshake » est « never », vous avez un problème de reachabilité, de ports bloqués, ou de clés incorrectes.

Décision : Si un handshake existe mais que le trafic ne circule pas, concentrez‑vous sur AllowedIPs, le routage et le pare‑feu. Si aucun handshake, vérifiez la reachabilité UDP et les clés.

Task 6: WireGuard kernel log hints (Linux)

cr0x@server:~$ sudo journalctl -k --since "15:00" --no-pager | grep -i wireguard | tail
Dec 28 15:12:01 server kernel: wireguard: wg0: Handshake for peer 1 (198.51.100.23:60211) did not complete after 5 seconds, retrying (try 2)
Dec 28 15:12:06 server kernel: wireguard: wg0: No response from peer 1 (198.51.100.23:60211), retrying (try 3)

Sens : Les paquets sortants partent ; les réponses ne reviennent pas. Classique casse‑tête NAT/pare‑feu/forwarding.

Décision : Vérifiez le filtrage amont, les mappings NAT, et si l’IP/port d’endpoint est correct.

Task 7: OpenVPN service logs (Linux)

cr0x@server:~$ sudo journalctl -u openvpn-server@server --since "15:40" --no-pager
Dec 28 15:41:10 server openvpn[2210]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 28 15:41:10 server openvpn[2210]: TLS Error: TLS handshake failed

Sens : Habituellement pas un problème de certificat ; c’est plutôt de la reachabilité (port TCP/UDP bloqué) ou du routage asymétrique. Parfois c’est le MTU.

Décision : Vérifiez l’exposition du port et si les paquets atteignent le démon. S’ils le font, regardez ensuite mismatch de chiffrement et paramètres TLS client/serveur.

Task 8: Confirm Linux is listening on the expected ports

cr0x@server:~$ sudo ss -lunpt | egrep ':(500|4500|1194|51820)\b'
udp   UNCONN 0      0            0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1123,fd=14))
udp   UNCONN 0      0            0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1123,fd=13))
udp   UNCONN 0      0            0.0.0.0:51820     0.0.0.0:*    users:(("wg-quick",pid=1300,fd=6))
udp   UNCONN 0      0            0.0.0.0:1194      0.0.0.0:*    users:(("openvpn",pid=2210,fd=5))

Sens : Si le service n’écoute pas, votre pare‑feu peut être parfait et rien ne fonctionnera.

Décision : Si manquant, corrigez la config/service au démarrage avant de toucher les équipements réseau.

Task 9: Check netfilter policy (Linux) without guessing

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport { 500, 4500, 51820, 1194 } accept
    ip protocol icmp accept
    counter drop
  }
}

Sens : Policy drop est acceptable si vous autorisez explicitement les ports/protocoles VPN. Si vous oubliez UDP/4500, IKEv2 derrière NAT échouera de la façon la plus agaçante.

Décision : Si les accept manquent, ajoutez‑les ; si présents, arrêtez de blâmer le pare‑feu Linux et remontez vers l’extérieur.

Task 10: Confirm IP forwarding and XFRM policy health for IPsec

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0

Sens : Pour site‑à‑site ou accès distant routé, le forwarding compte. Certaines configurations « se connectent » mais ne passent pas le trafic si le forwarding est désactivé.

Décision : Si forwarding est off et que vous attendez du routage, activez‑le et vérifiez les règles de chaîne forward du pare‑feu.

Task 11: Inspect IPsec SAs on Linux (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-ikev2: #12, ESTABLISHED, IKEv2, 3c1f0b1f2d3e4a5b_i* 2a1b3c4d5e6f7a8b_r
  local  '203.0.113.10' @ 203.0.113.10[4500]
  remote '198.51.100.23' @ 198.51.100.23[60211]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
  established 98s ago
  vpn-ikev2{21}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c1234567_i c89abcde_o
  vpn-ikev2{21}:   10.10.10.0/24 === 10.66.66.2/32

Sens : « ESTABLISHED » plus « INSTALLED » vous dit que Phase 1 et Phase 2 sont actives. Si le trafic échoue encore, vous regardez du routage, du pare‑feu ou un mismatch de sélecteurs.

Décision : Si aucun CHILD_SA n’est installé, corrigez les traffic selectors/proposals. Si installé, tracez le flux de paquets après déchiffrement.

Task 12: MikroTik: see IPsec peers and active SAs

cr0x@server:~$ ssh admin@mtk-edge 'ip ipsec active-peers print; ip ipsec installed-sa print'
 0  address=198.51.100.23 port=60211 state=established phase1-established=yes
 0  spi=0xcafebabe src-address=203.0.113.1 dst-address=198.51.100.23 state=mature
    auth-algorithm=sha256 enc-algorithm=aes-gcm enc-key-size=256

Sens : Peer established + SA installée signifie que le bord voit un vrai tunnel, pas juste de l’optimisme.

Décision : Si le peer n’est pas établi, travaillez la négociation/auth. Si établi mais aucun trafic, inspectez les routes, exemptions NAT, et règles forward du pare‑feu.

Task 13: MikroTik: turn on targeted logging for IPsec and PPP (temporarily)

cr0x@server:~$ ssh admin@mtk-edge '/system logging add topics=ipsec,debug action=memory; /system logging add topics=ppp,info action=memory; /log print where topics~"ipsec|ppp"'
15:44:01 ipsec,debug initiate new phase 1 (Identity_Protection): 198.51.100.23[60211]<=>203.0.113.1[500]
15:44:02 ipsec,error no proposal chosen
15:44:03 ppp,info <l2tp-user> disconnected

Sens : « no proposal chosen » est un mismatch crypto immédiat. Les déconnexions PPP ensuite sont collatérales.

Décision : Corrigez l’alignement des propositions IPsec d’abord. Ne poursuivez pas le PPP tant que la couche IPsec n’est pas stable.

Task 14: MikroTik: check firewall counters for VPN ports

cr0x@server:~$ ssh admin@mtk-edge '/ip firewall filter print stats where chain=input and (protocol=udp and (dst-port=500 or dst-port=4500))'
 0    chain=input action=accept protocol=udp dst-port=500,4500 in-interface=WAN packets=1823 bytes=219120
 1    chain=input action=drop in-interface=WAN packets=44 bytes=3520

Sens : Vous avez des accepts et quelques drops. La question est : ces drops sont‑ils votre VPN, ou du bruit de fond ?

Décision : Si les accepts sont à zéro pendant une tentative, le trafic n’arrive pas ou ne matche pas la règle. Si les drops montent pendant les tentatives, ajoutez un accept spécifique avant le drop.

Task 15: Confirm MTU path symptoms with ping DF (Linux)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.66.66.2
PING 10.66.66.2 (10.66.66.2) 1372(1400) bytes of data.
From 10.10.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)
From 10.10.10.1 icmp_seq=2 Frag needed and DF set (mtu = 1420)
From 10.10.10.1 icmp_seq=3 Frag needed and DF set (mtu = 1420)

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

Sens : Vous dépassez la MTU du chemin. L’encapsulation VPN ajoute de l’overhead, ce qui est courant, et cela peut ressembler à « se connecte mais rien ne marche ».

Décision : Réduisez la MTU du tunnel, clamppez le TCP MSS, ou corrigez le blocage PMTUD. Ne vous contentez pas de « désactiver DF partout » et d’appeler ça une solution.

Blague #1 : Les problèmes de MTU sont le seul bug réseau qui peut faire « fonctionner » un VPN et pourtant ruiner votre week‑end.

Motifs de logs qui correspondent à des causes réelles

Motif : « no proposal chosen » (IKE/IPsec)

Signifie généralement : mismatch dans chiffrement/intégrité/PRF/groupe DH, ou vous mélangez des hypothèses IKEv1 dans une config IKEv2.

Que faire : Comparez les propositions offertes par le client et l’ensemble accepté par le serveur. Sur MikroTik, vérifiez les paramètres de proposal IPsec ; sur strongSwan, vérifiez les définitions ike= et esp=. Rendez temporairement un côté plus permissif, puis resserrez.

Motif : « AUTHENTICATION_FAILED »

Signifie généralement : identifiants erronés, chaîne d’identité incorrecte, mismatch de certificat, ou politique RADIUS rejetant l’utilisateur.

Que faire : Vérifiez l’ID présenté par le client (FQDN/email/DN) et ce que le serveur attend. Dans les setups à certificats, vérifiez EKU, SAN, et la chaîne de confiance. En EAP, confirmez la compatibilité des méthodes (EAP‑MSCHAPv2 vs EAP‑TLS).

Motif : « peer not responding » / timeouts

Signifie généralement : les paquets ne reviennent pas. Blocages pare‑feu, NAT défaillant, mauvaise IP de destination, routage asymétrique, ou UDP 4500 bloqué.

Que faire : Capturez les paquets des deux côtés. Si vous voyez des paquets sortants mais pas entrants, montez dans la couche réseau. Si vous voyez des entrants et que le démon reste silencieux, vous atteignez peut‑être le mauvais hôte/port ou le pare‑feu/SELinux local les consomme.

Motif : tunnel up, but « no traffic »

Signifie généralement : mauvais routage/AllowedIPs/sélecteurs, exemption NAT manquante, ou chaîne forward du pare‑feu bloquant le trafic post‑décryptage.

Que faire : Pour IPsec, inspectez les policies/sélecteurs installés. Pour WireGuard, vérifiez AllowedIPs des deux côtés et confirmez l’existence des routes. Ensuite tracez avec tcpdump sur l’interface interne, pas seulement sur le WAN.

Motif : connectivité intermittente selon le réseau

Signifie généralement : cas limites de traversal NAT, MTU/PMTUD, ou portails captifs qui bloquent l’UDP.

Que faire : Forcez NAT‑T (si approprié), testez des ports/protocoles alternatifs (par ex. OpenVPN sur TCP 443), et clamppez MSS. Les logs vous montreront timeouts et retransmissions ; votre travail est de les relier à l’environnement réseau.

Erreurs courantes : symptôme → cause racine → fix

1) Symptom: « works at home, fails on hotel Wi‑Fi »

Cause racine : UDP bloqué ou altéré ; NAT‑T UDP 4500 bloqué ; portail captif ; ou politiques de pare‑feu strictes.

Fix : Proposez un fallback basé sur TCP (souvent TCP 443), assurez‑vous que NAT‑T est activé pour IPsec, et logguez les drops de pare‑feu sur l’entrée WAN pour les ports VPN.

2) Symptom: « IKE_SA establishes, but no internal access »

Cause racine : routes manquantes, mauvais traffic selectors, exemption NAT manquante, ou drop en chaîne forward.

Fix : Vérifiez les CHILD_SA installés et leurs sélecteurs, ajoutez des routes, ajoutez des règles d’accept explicites post‑décryptage, et assurez‑vous de ne pas NATer le trafic qui devrait être protégé.

3) Symptom: « authentication failed » right after negotiation

Cause racine : mauvaise identité (IDi/IDr), mauvais EAP, RADIUS rejette, chaîne de confiance de certificat incomplète.

Fix : Loggez l’identité présentée, alignez les paramètres ID, validez la chaîne de certificats sur le serveur, et vérifiez les logs AAA pour la raison du rejet.

4) Symptom: OpenVPN « TLS handshake failed » but port is open

Cause racine : mismatch TLS client/serveur (tls‑crypt/tls‑auth), mismatch de chiffrement, ou MTU causant la perte de fragments du handshake.

Fix : Comparez les configs ; simplifiez temporairement vers un chiffrement/TLS connu comme bon, puis réintroduisez le durcissement. Vérifiez MTU et fragmentation.

5) Symptom: WireGuard « latest handshake: never »

Cause racine : mauvais endpoint, UDP bloqué, clé publique incorrecte, ou NAT nécessitant un keepalive persistant.

Fix : Vérifiez clés et endpoint ; ajoutez keepalive pour les clients derrière NAT ; confirmez la reachabilité UDP avec tcpdump.

6) Symptom: VPN connects, browsing works, file shares time out

Cause racine : problèmes MTU/MSS. Les petits paquets passent ; les gros paquets meurent.

Fix : Clamppez le TCP MSS sur l’interface de tunnel/au bord, réduisez la MTU, et assurez‑vous que l’ICMP « frag needed » n’est pas bloqué.

7) Symptom: L2TP/IPsec connects for some users, others fail

Cause racine : secrets PPP par utilisateur, mismatch de profils, différences d’attributs RADIUS, ou exhaustion du pool d’adresses.

Fix : Vérifiez les logs d’auth PPP, la disponibilité du pool IP, standardisez les profils, et comparez les réponses AAA.

8) Symptom: site-to-site IPsec flaps every few minutes

Cause racine : mismatch DPD, mismatch de timing de rekey, timeouts de mapping NAT, ou lien WAN instable.

Fix : Alignez les lifetimes et paramètres DPD ; vérifiez les erreurs WAN ; envisagez des keepalives ; logguez les événements de rekey et corrélez avec l’état des interfaces.

Checklists / plan pas à pas (workflow production)

Checklist A: the 10-minute triage (don’t be clever yet)

1. Obtenez la fenêtre temporelle exacte de l’échec et le type de réseau client (domicile/cellulaire/hôtel).
2. Confirmez que le DNS résout vers l’IP publique attendue (évitez les pièges « mauvaise destination »).
3. Vérifiez que le serveur/routeur et le Linux sont synchronisés.
4. Sur Linux, lancez tcpdump pour UDP 500/4500 (ou le port pertinent) pendant une nouvelle tentative.
5. Sur MikroTik, vérifiez les compteurs de pare‑feu et les logs IPsec/PPP pour la même minute.
6. Classifiez : aucun trafic, échec de négociation, échec d’auth, ou « up mais pas de données ».
7. Choisissez une hypothèse et testez‑la avec un seul changement ou une seule commande.

Checklist B: negotiation/auth deep-dive (when packets do arrive)

1. Extrait la chaîne d’erreur exacte des logs du démon VPN (NO_PROPOSAL_CHOSEN, AUTHENTICATION_FAILED, TS_UNACCEPTABLE).
2. Listez les proposals configurés sur le serveur et comparez‑les avec la suite supportée par le client.
3. Validez la chaîne de certificats, les expirations et les champs d’identité (SAN, CN selon le cas).
4. Vérifiez les logs AAA (RADIUS/LDAP) pour les raisons de rejet ; ne devinez pas.
5. Re‑testez. Si l’erreur change, vous avez progressé. Si elle ne change pas, vous n’avez pas avancé.

Checklist C: “connected but nothing works” (the sneaky one)

1. Confirmez que la SA est établie et que les sélecteurs correspondent aux sous‑réseaux attendus.
2. Confirmez que les routes existent des deux côtés (et sur le client pour le split tunnel).
3. Confirmez que le pare‑feu autorise le trafic post‑décryptage (chaîne forward, pas seulement input).
4. Confirmez l’exemption NAT pour les sous‑réseaux VPN (ne NATez pas intra‑VPN sauf si c’est voulu).
5. Testez la MTU avec ping DF ou clamppez MSS et retestez.

Blague #2 : Le VPN n’est pas « en panne ». Il pratique simplement le chaos engineering sans vous prévenir.

Trois mini‑histoires du monde corporate (anonymisées, réalistes)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Le helpdesk a escaladé une « panne VPN » à 8:17. Le symptôme était clair : un groupe d’utilisateurs distants ne pouvait pas se connecter, et ceux qui y arrivaient étaient majoritairement sur des connexions domestiques. Les utilisateurs cellulaires étaient OK. Tout le monde a blâmé les certificats parce que quelqu’un avait renouvelé « quelque chose » la semaine précédente.

La première mauvaise hypothèse : « Si certains utilisateurs peuvent se connecter, le serveur VPN est sain. » C’est réconfortant émotionnellement et parfois vrai, mais c’est aussi la façon de manquer des échecs dépendants du chemin comme le filtrage UDP et les quirks NAT‑T. La seconde mauvaise hypothèse : « Si c’est IPsec, c’est forcément crypto. » Non. IPsec est souvent une politique réseau déguisée en crypto.

Nous avons lancé tcpdump sur l’endpoint Linux : rien n’est arrivé sur UDP 4500 pendant les tentatives de panne. Les compteurs MikroTik pour UDP 4500 en entrée étaient aussi plats, tandis que UDP 500 était en pic. Voilà l’indice : les clients derrière NAT commencent sur UDP 500 puis passent à UDP 4500 pour NAT‑T. Ils restaient bloqués à la porte.

La cause était ennuyeuse : un template de pare‑feu déployé en amont autorisait UDP 500 mais pas UDP 4500. Le template avait « IPsec » dans le nom, donc tout le monde a supposé qu’il était complet. Nous avons ajouté UDP 4500, vu les logs strongSwan passer de timeouts à SA établies, et l’incident s’est clos.

Le post‑mortem n’a pas été « souvenez‑vous de UDP 4500 ». Il a été : ne jamais diagnostiquer un « won’t connect » sans d’abord prouver que le trafic atteint le dispositif sur le port dont il a réellement besoin.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une équipe réseau a décidé de « réduire le bruit des logs » sur un edge MikroTik en désactivant la majorité des logs liés au VPN et en se reposant sur un syslog central Linux depuis la couche applicative. La motivation était compréhensible : budget de stockage, fatigue d’alertes, et un tableau de bord qui ressemblait à un sismographe.

Deux semaines plus tard, un déploiement IKEv2 commençait à échouer pour une population cliente spécifique. L’endpoint Linux montrait des « received packet with unknown SPI » sporadiques et des échecs AUTH occasionnels. Mais il n’y avait pas de motif cohérent, et nous n’avions pas de logs bord pour nous dire si le trafic était NATé, droppé, ou traduit bizarroïde.

Nous avons réactivé la journalisation IPsec ciblée sur MikroTik et ajouté une règle de pare‑feu avec compteurs pour UDP 500/4500. En quelques minutes l’histoire est apparue : une règle NAT faisait du hairpin sur certaines plages source différemment, provoquant des changements de ports source en plein handshake. strongSwan traitait ces changements comme suspects, et les handshakes mouraient de façon intermittente.

L’« optimisation » avait désactivé les logs qui vous disent ce que le bord fait aux paquets. Le correctif n’a pas été « activer tous les logs ». Le correctif a été une journalisation disciplinée : petite, ciblée, limitée dans le temps, plus des compteurs persistants.

Ensuite, l’équipe a réduit le bruit mais a préservé la capacité à reconstruire une panne. C’est la différence entre observabilité et thésaurisation.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation a fait quelque chose d’impopulaire : elle a standardisé le triage des pannes VPN dans un petit runbook. Chaque incident commençait par les mêmes trois captures : horodatage client, compteurs edge, logs démon serveur. Ils appliquaient aussi NTP sur chaque MikroTik et chaque hôte Linux, et le testaients mensuellement comme des adultes.

Quand un « VPN won’t connect » a frappé pendant une démo fournisseur, ils n’ont pas cherché le blâme. Ils ont aligné les horodatages et regardé la fenêtre de recoupement. Le bord montrait des paquets UDP 500 entrants acceptés, puis rien sur UDP 4500. Le tcpdump serveur montrait la même chose. Ça a réduit le diagnostic au filtrage amont ou à la politique réseau client.

Le user était sur un Wi‑Fi invité qui bloquait UDP 4500. L’étape suivante du runbook était un fallback documenté : OpenVPN sur TCP 443, avec un filtre de logs explicite pour confirmer un handshake TLS. Ils ont changé de profil, vu « TLS negotiation succeeded », et la démo s’est poursuivie avec seulement une légère montée d’adrénaline.

La pratique qui a sauvé n’était pas sophistiquée. C’était d’avoir un chemin de secours et l’habitude de confirmer la reachabilité des paquets avant de réécrire les configs. L’ennuyeux gagne. Vous pouvez l’encadrer et le coller au bureau, de préférence au‑dessus de la machine à espresso.

Faits intéressants & courte histoire (ce qui explique les douleurs d’aujourd’hui)

• Le coup d’envoi IPsec en entreprise remonte aux années 1990, quand la « sécurité au niveau réseau » semblait simplifier tout. Ce n’est pas arrivé, mais cela a standardisé beaucoup de vocabulaire VPN.
• IKEv2 (mi‑2000s) a été conçu pour réparer la complexité d’IKEv1 et améliorer la mobilité et le NAT traversal, mais il dépend toujours fortement des proposals et des identités correctes.
• Le NAT n’a pas été conçu pour IPsec. ESP (protocole 50) n’a pas de ports, ce qui rend les dispositifs NAT classiques maladroits ; NAT‑T a encapsulé ESP dans UDP 4500 comme patch pragmatique.
• Les VPN de l’ère PPP (L2TP/PPTP) ont perduré parce qu’ils étaient faciles à déployer, pas parce qu’ils étaient excellents. Les logs montrent encore des échecs PPP sans rapport avec la crypto.
• WireGuard est devenu mainstream en restant volontairement minimal : moins de réglages, moins de modes hérités, et donc moins d’erreurs de négociation « mystère » — quand il échoue, il échoue clairement.
• OpenVPN a popularisé le « VPN sur TCP/443 » comme tactique de survie pour les réseaux restrictifs, même si TCP‑sur‑TCP peut être un piège de performance.
• La douleur MTU s’est aggravée à mesure que le chiffrement est devenu par défaut : chaque couche d’encapsulation vole des octets, et les réseaux modernes bloquent souvent l’ICMP nécessaire au PMTUD.
• Les pratiques de journalisation ont changé avec systemd : journald a rendu plus simple le filtrage par unité et par fenêtre temporelle, ce dont le dépannage VPN a exactement besoin.

FAQ

1) Si le VPN « won’t connect », où regarder en premier : client, MikroTik, ou Linux ?

Commencez où vous pouvez prouver l’arrivée des paquets. Si vous contrôlez le serveur, lancez tcpdump et vérifiez les logs du démon. Si vous ne voyez pas de paquets, pivotez vers l’edge MikroTik et le chemin en amont.

2) Pourquoi je vois des paquets UDP 500 mais pas UDP 4500 ?

Beaucoup de clients commencent IKE sur UDP 500 puis passent à UDP 4500 quand un NAT est détecté. L’absence d’UDP 4500 signifie généralement une politique de pare‑feu ou un filtrage en amont, pas un problème crypto.

3) Que signifie réellement « no proposal chosen » ?

Les pairs n’ont pas pu s’accorder sur les algorithmes (chiffrement/intégrité/PRF/groupe DH) pour IKE ou ESP. Corrigez en alignant les jeux de proposals ; n’activez pas au hasard des suites héritées sans comprendre le risque.

4) Le tunnel s’établit, mais les sous‑réseaux internes sont inaccessibles. Est‑ce encore un problème VPN ?

Oui, mais ce n’est pas un problème de handshake. C’est du routage, des règles forward du pare‑feu, des exemptions NAT, ou des traffic selectors/AllowedIPs. Vérifiez les SA et les routes, puis tracez le trafic après décryptage.

5) Pourquoi WireGuard affiche des handshakes mais toujours pas de trafic ?

Généralement AllowedIPs ou routage. Un handshake prouve seulement les clés et la reachabilité ; il ne prouve pas que vous routez les bons sous‑réseaux dans le tunnel ou que le pare‑feu les autorise.

6) Quelle est la façon la plus rapide de confirmer qu’un pare‑feu Linux ne bloque pas le VPN ?

Inspectez le ruleset (nft list ruleset) et confirmez des accept explicites pour les ports/protocoles VPN, plus des compteurs si possible. Ne « flush » pas iptables en production à moins d’aimer rédiger des rapports d’incident.

7) Dois‑je activer le debug en permanence sur MikroTik et strongSwan ?

Non. Activez le debug ciblé brièvement, de préférence limité par fenêtre temporelle et IP source si possible, puis désactivez‑le. Conservez des logs info légers et des compteurs en permanence.

8) Comment savoir que c’est la MTU ?

Signe classique : les petites requêtes fonctionnent, les gros transferts bloquent ; certaines applis connectent, d’autres plantent. Confirmez avec des pings DF et en clampant MSS. Les logs montrent souvent des retransmissions/timeouts, pas « MTU » en clair.

9) Si OpenVPN sur TCP 443 marche partout, dois‑je l’utiliser systématiquement ?

C’est un fallback utile, pas toujours la solution principale. TCP‑sur‑TCP peut exploser la performance en cas de perte. Utilisez‑le pour franchir des réseaux restrictifs et mesurez avant de standardiser.

10) Quelle habitude unique réduit le plus les incidents VPN ?

La discipline des horodatages : NTP partout et l’habitude de collecter l’heure de tentative client, les compteurs edge, et les logs démon serveur pour la même minute.

Conclusion : étapes suivantes pour réduire les répétitions

Cessez de traiter « VPN won’t connect » comme une énigme. Traitez‑le comme une petite enquête avec collecte de preuves et logique de branchement.

1. Standardisez le playbook rapide (arrivée des paquets → classer l’erreur → vérifier l’heure/MTU/NAT‑T) et faites‑en la réponse par défaut.
2. Gardez une journalisation ciblée toujours active : logs IPsec info MikroTik, compteurs pare‑feu pour les ports VPN, et logs des démons Linux dans journald.
3. Pratiquez un chemin de secours pour les réseaux restrictifs (souvent TCP 443) et testez‑le périodiquement.
4. Faites de MTU/MSS un contrôle de première classe pour les incidents « se connecte mais inutilisable » — parce que ça arrive sans cesse et faire semblant que non n’aide pas.

Quand vous pouvez répondre « les paquets sont-ils arrivés ? » et « quelle erreur exacte s’est déclenchée ? » en moins de cinq minutes, les incidents VPN passent du drame à la maintenance de routine. C’est l’objectif : moins d’héros, plus de disponibilité.