WireGuard sur un routeur : erreurs NAT qui coupent l’accès au LAN (et corrections)

Le modèle mental : d’abord routage, ensuite NAT

WireGuard est ennuyeux de la meilleure façon. C’est une interface point-à-point qui chiffre les paquets et les place sur une NIC virtuelle.
Tout le reste—qui peut atteindre quoi, comment les paquets reviennent, si les appareils LAN voient les vraies IP des clients—est décidé par la même vieille
table de routage et les mêmes règles de pare-feu que vous combattez depuis 2003.

Trois vérités qui expliquent 90 % des « VPN casse le LAN »

• AllowedIPs est du routage. Sur un peer, AllowedIPs est un sélecteur de route de politique et un filtre anti-usurpation. Ce n’est pas « un ACL ». Traitez-le comme une carte de routage.
• Le NAT cache les erreurs jusqu’à ce qu’il ne le fasse plus. Le masquerading du tunnel peut faire « fonctionner » le trafic de retour sans ajouter de routes, mais il casse la visibilité sur le LAN, les politiques entrantes et parfois même la connectivité.
• Les chemins de retour comptent plus que les chemins d’aller. La plupart des échecs sont dus au routage asymétrique : le paquet entre, la réponse sort par la mauvaise interface.

Quand vous exécutez WireGuard sur un routeur, vous combinez deux rôles : point de terminaison VPN et directeur de trafic.
Si vous faites du NAT sur la mauvaise liaison (ou pour les mauvais sous-réseaux), vous pouvez vous retrouver avec un tunnel qui fonctionne parfaitement tandis que le réseau se comporte comme hanté.

Ce que « accès LAN » signifie vraiment

Les gens disent « je ne peux pas accéder à mon LAN », mais ils veulent dire plusieurs choses distinctes :

• Impossible d’atteindre des IP LAN : ping vers 192.168.1.10 échoue depuis un client distant via le tunnel.
• Les IP LAN sont joignables mais les services échouent : SMB fonctionne de façon intermittente, mDNS/Bonjour ne fonctionne pas, découverte d’imprimante morte.
• Les appareils LAN ne peuvent pas joindre le client VPN : vous pouvez vous connecter au NAS, mais le NAS ne peut pas appeler votre laptop (fréquent avec les sauvegardes, agents de supervision, ou connexions inverses).
• Tout passe par le VPN et le LAN meurt : tunnel complet attrape le trafic RFC1918 et le route dans le tunnel, rendant les réseaux locaux injoignables.

Les corrections sont différentes. Si vous sautez directement à « ajouter masquerade », vous choisissez le coup rapide plutôt que la correction.
Parfois le NAT est nécessaire (surtout pour les clients road-warrior), mais vous devez comprendre ce que vous payez : observabilité, identité et politique.

Idée paraphrasée de John Allspaw : La fiabilité vient de la compréhension des modes de défaillance des systèmes, pas de prétendre qu’ils ne tomberont pas en panne.
Cela s’applique aussi au NAT WireGuard.

Blague n°1 : Le NAT, c’est comme un programme de protection des témoins pour les paquets. Super pour la confidentialité, terrible quand vous essayez d’interroger le témoin.

Faits et contexte : pourquoi cela se répète

Quelques faits courts et concrets aident à expliquer pourquoi WireGuard sur routeur + NAT devient un schéma d’incident récurrent :

1. Le NAT ne faisait pas partie du design original d’Internet. Il s’est répandu parce que l’IPv4 a manqué et parce qu’il rendait les déploiements « une IP publique » bon marché.
2. Le forwarding IP de Linux est désactivé par défaut. Le comportement de routeur est opt-in ; les tutoriels VPN qui l’ignorent créent la confusion « handshake mais pas de trafic ».
3. La config de WireGuard est volontairement minimale. Pas de « mode serveur » intégré, pas de push de routes, pas de bascules NAT magiques ; vous assemblez tout avec le routage et le pare-feu du système.
4. AllowedIPs fait double emploi comme route et filtre. Ce design empêche l’usurpation mais surprend ceux qui s’attendent à un push de routes façon OpenVPN.
5. Les routeurs grand public livrent souvent un NAT aide-agressif. Certains firmwares ajoutent des règles de masquerade de manière large ; cela peut NATer accidentellement du LAN-vers-LAN ou du tunnel-vers-LAN.
6. Le split-tunnel est la valeur par défaut, le full-tunnel est une arme. Dès que vous routez 0.0.0.0/0 vers le tunnel, vous entrez dans la gestion d’exceptions et du routage politique.
7. Les problèmes de MTU se sont intensifiés avec VPN-sur-CGNAT ISP. La découverte de MTU de chemin peut être peu fiable ; l’ICMP blackholé fait du « ça marche pour de petits pings » un symptôme classique.
8. Le double NAT est maintenant normal. Les utilisateurs domestiques sont souvent derrière le NAT de l’ISP plus leur propre NAT ; les VPN ajoutent une troisième couche de traduction si vous êtes imprudents.
9. Le NAT casse l’identité de bout en bout. Il complique la journalisation, les ACL et parfois les protocoles applicatifs qui embarquent des IP.

Checklist de diagnostic rapide

Quand l’accès LAN casse, ne « tentez pas des bricolages aléatoires de pare-feu ». Faites ceci dans l’ordre. L’objectif est d’identifier la couche problématique :
chiffrement/handshake WireGuard, routage, NAT ou filtrage.

Premier : prouvez que le tunnel est vivant (plan de contrôle)

• Vérifiez l’heure du handshake et les compteurs de transfert sur le routeur.
• Confirmez que le client a une route pour le LAN (split tunnel) ou au moins une route par défaut (full tunnel).

Deuxième : prouvez que le forwarding de base fonctionne (plan données)

• Depuis le client, pinguez l’IP LAN du routeur et l’IP du tunnel.
• Depuis le routeur, pinguez un hôte LAN en utilisant l’IP source du tunnel (ou utilisez tcpdump pour voir les paquets entrer et sortir).

Troisième : validez les chemins de retour (c’est là que ça casse généralement)

• Sur l’hôte LAN (ou la passerelle LAN), vérifiez qu’il dispose d’une route vers le sous-réseau client WireGuard.
• S’il n’en a pas, décidez : ajouter des routes (correct) ou faire du NAT sélectif (compromis acceptable).

Quatrième : vérifiez la politique de pare-feu et la portée du NAT

• Confirmez que les règles de forwarding autorisent wg0 → br-lan et br-lan → wg0.
• Confirmez que le NAT n’est appliqué que là où c’est nécessaire (généralement wg0 → wan pour le full tunnel, pas wg0 → lan sauf si vous cachez intentionnellement les clients).

Cinquième : MTU et DNS (le bac « tout est instable »)

• Si les petits paquets fonctionnent mais que les grosses connexions stagnent, testez la MTU.
• Si « accès LAN » signifie en réalité « les noms ne se résolvent pas », inspectez le DNS et le split DNS.

Tâches pratiques : commandes, sorties, décisions

Ce sont les tâches que je lance réellement pendant les incidents. Chacune inclut : commande, sortie réaliste, ce que cela signifie, et quelle décision prendre ensuite.
Les exemples supposent un routeur basé sur Linux (userland Debian/OpenWrt-like). Traduisez pour votre plateforme si nécessaire, mais conservez la logique.

Task 1: Check WireGuard handshake and counters

cr0x@server:~$ sudo wg show
interface: wg0
  public key: oR7...routerpub...
  listening port: 51820

peer: k9T...clientpub...
  endpoint: 198.51.100.23:53312
  allowed ips: 10.6.0.2/32
  latest handshake: 42 seconds ago
  transfer: 18.34 MiB received, 22.91 MiB sent
  persistent keepalive: every 25 seconds

Ce que cela signifie : Le handshake est récent, les compteurs bougent. Le crypto et le chemin UDP sont corrects.

Décision : Arrêtez d’accuser « WireGuard ne marche pas ». Passez au routage/forwarding/NAT.

Task 2: Confirm the router has the expected tunnel address

cr0x@server:~$ ip -brief address show dev wg0
wg0             UP             10.6.0.1/24

Ce que cela signifie : L’interface est up et a une adresse. Si elle est DOWN ou sans IP, corrigez la configuration de l’interface avant tout.

Décision : Si l’adresse est incorrecte (ex. /32 au lieu de /24), corrigez et redémarrez l’interface.

Task 3: Verify IP forwarding is enabled

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Ce que cela signifie : Le routeur se comporte comme un hôte. Les paquets ne seront pas transférés entre wg0 et LAN/WAN.

Décision : Activez le forwarding et persistez la configuration.

Task 4: Enable forwarding (temporary + persistent)

cr0x@server:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Ce que cela signifie : Le forwarding est activé maintenant ; retestez le trafic immédiatement.

Décision : Si cela corrige le problème, persistez dans /etc/sysctl.conf ou équivalent et auditez pourquoi c’était désactivé.

Task 5: Check routes on the router (main table)

cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan0
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1
192.168.50.0/24 dev br-lan proto kernel scope link src 192.168.50.1

Ce que cela signifie : Le routeur connaît les deux réseaux. Bien. Si le sous-réseau LAN manque, votre bridge LAN n’est pas configuré. Si la route wg0 manque, WireGuard n’a pas appliqué l’adresse.

Décision : Si les routes semblent correctes, concentrez-vous sur le pare-feu et la portée NAT.

Task 6: Check policy routing rules (full tunnel setups often add these)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.6.0.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Ce que cela signifie : Le trafic sourcé du sous-réseau WireGuard utilise la table 100. C’est courant quand on force les clients VPN à sortir vers le WAN ou un autre uplink.

Décision : Si l’accès LAN casse seulement pour les clients VPN, la table 100 pourrait manquer d’une route vers 192.168.50.0/24 (ou elle l’envoie vers le WAN). Inspectez la table 100 ensuite.

Task 7: Inspect the alternate routing table

cr0x@server:~$ ip route show table 100
default via 203.0.113.1 dev wan0

Ce que cela signifie : Pour le trafic issu du VPN, tout—y compris le sous-réseau LAN—suit la route par défaut vers wan0. Cela isole ou détourne l’accès LAN.

Décision : Ajoutez une route explicite vers le LAN dans la table 100, ou corrigez votre règle de politique pour que les destinations LAN utilisent la table main.

Task 8: Add LAN route to policy table (example fix)

cr0x@server:~$ sudo ip route add 192.168.50.0/24 dev br-lan table 100

Ce que cela signifie : Maintenant le trafic client VPN destiné au LAN reste local.

Décision : Retestez. Si cela corrige, persistez la route via le système de configuration du routeur.

Task 9: Confirm the client is actually routing LAN via the tunnel

cr0x@server:~$ ip route get 192.168.50.10
192.168.50.10 via 10.6.0.1 dev wg0 src 10.6.0.2 uid 1000
    cache

Ce que cela signifie : Le client enverra le trafic LAN vers wg0. S’il indique dev wlan0 ou votre interface normale, la configuration AllowedIPs/split-tunnel du client est incorrecte.

Décision : Corrigez la config du client (AllowedIPs doit inclure les sous-réseaux LAN à atteindre) avant de modifier le NAT du routeur.

Task 10: Watch packets enter wg0 and leave toward LAN

cr0x@server:~$ sudo tcpdump -ni wg0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:01:10.112233 IP 10.6.0.2 > 192.168.50.10: ICMP echo request, id 4421, seq 1, length 64

Ce que cela signifie : Le routeur reçoit le ping depuis le tunnel.

Décision : Si vous le voyez sur wg0 mais pas sur le LAN, votre forwarding/pare-feu bloque. Si vous le voyez sur le LAN mais pas de réponse, c’est un problème de chemin de retour.

Task 11: Confirm it leaves via the LAN interface

cr0x@server:~$ sudo tcpdump -ni br-lan icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112987 IP 10.6.0.2 > 192.168.50.10: ICMP echo request, id 4421, seq 1, length 64

Ce que cela signifie : Le forwarding fonctionne au moins dans un sens : wg0 → LAN.

Décision : Si aucune réponse n’arrive sur wg0, l’hôte LAN ne sait pas comment retourner vers 10.6.0.0/24 (ou un pare-feu le bloque). Décidez d’ajouter des routes ou de faire du NAT.

Task 12: Check NAT rules (iptables legacy example)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o wan0 -j MASQUERADE
-A POSTROUTING -o br-lan -j MASQUERADE

Ce que cela signifie : Cette seconde règle est suspecte : masquerader vers br-lan signifie que les paquets envoyés dans le LAN auront leur source NATée sur l’IP LAN du routeur. Vos hôtes LAN ne verront jamais la vraie IP du client VPN.

Décision : Si votre objectif est « les clients VPN sont des membres à part entière du LAN », supprimez cette règle. Si votre objectif est « accéder au LAN sans changer les routes LAN », alors conservez-la—mais comprenez le coût et restreignez-la.

Task 13: Remove overly broad masquerade (dangerous if you rely on it)

cr0x@server:~$ sudo iptables -t nat -D POSTROUTING -o br-lan -j MASQUERADE

Ce que cela signifie : Le trafic VPN→LAN préservera désormais les IP sources (10.6.0.x). Le routage de retour doit être correct.

Décision : Si les choses cassent après cela, vous avez prouvé que vous dépendiez du NAT pour masquer des routes manquantes. Corrigez le routage correctement.

Task 14: Add a proper LAN route on the LAN gateway (example)

cr0x@server:~$ sudo ip route add 10.6.0.0/24 via 192.168.50.1

Ce que cela signifie : Les appareils LAN utilisant cette passerelle peuvent maintenant retourner le trafic vers le sous-réseau WireGuard via le routeur.

Décision : Si vous ne pouvez pas ajouter des routes sur chaque appareil LAN, ajoutez-la sur la passerelle par défaut (ou utilisez l’option DHCP 121/routes statiques sans classe) pour que les clients l’apprennent automatiquement.

Task 15: Inspect nftables ruleset (modern routers often use nft)

cr0x@server:~$ sudo nft list ruleset
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "wg0" oifname "br-lan" accept
    iifname "br-lan" oifname "wg0" ct state established,related accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wan0" masquerade
  }
}

Ce que cela signifie : La chaîne forward autorise wg0 → LAN, mais le LAN → wg0 n’autorise que established/related. Cela bloque les connexions initiées par le LAN vers les clients VPN (et casse certains protocoles qui ne paraissent pas « établis » comme vous l’attendez).

Décision : Décidez si vous voulez des initiations LAN → VPN. Si oui, ajoutez un accept explicite pour iif br-lan oif wg0 avec des restrictions appropriées.

Task 16: Test MTU if you see “works for ping, fails for apps”

cr0x@server:~$ ping -M do -s 1420 192.168.50.10 -c 2
PING 192.168.50.10 (192.168.50.10) 1420(1448) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 192.168.50.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms

Ce que cela signifie : Votre chemin ne supporte pas cette taille avec DF activé. Vous avez besoin d’une MTU tunnel plus basse ou d’un clamp MSS.

Décision : Diminuez la MTU de WireGuard (ex. 1280–1380 selon le WAN) et retestez avec des tailles incrémentales.

Blague n°2 : Le paquet était trop gros pour le tunnel, comme un ingénieur stockage qui essaie de coller « juste un jeu de données de plus » sur un pool plein.

Erreurs courantes : symptômes → cause → correction

Cette section est opinionnée parce qu’elle doit l’être. Ce sont les erreurs qui reviennent sans cesse dans les tickets et les writeups home-lab.
Chacune inclut le symptôme que vous verrez, la cause réelle, et une correction qui n’engendre pas l’incident suivant.

1) « Le handshake marche, mais je ne peux pinguer aucun hôte LAN »

Symptôme : wg show montre un handshake récent ; les compteurs de trafic augmentent ; les IP LAN ne répondent pas.

Cause réelle : Route de retour manquante du LAN vers le sous-réseau client WireGuard (10.6.0.0/24, 10.0.0.0/24, etc.).

Correction : Ajoutez une route sur la passerelle LAN pointant le sous-réseau WireGuard vers l’IP LAN du routeur. Si c’est impossible, faites un NAT sélectif pour wg0 → LAN, limité au sous-réseau LAN seulement.

2) « L’accès LAN marche, mais les appareils LAN voient tout venir du routeur »

Symptôme : Les logs du NAS montrent source IP = 192.168.50.1 pour tous les clients VPN ; les ACL par client échouent.

Cause réelle : Masquerade appliqué sur wg0 → LAN (POSTROUTING sur br-lan). Vous avez transformé les clients distants en « le routeur ».

Correction : Supprimez le NAT pour le trafic vers le LAN ; ajoutez un routage correct. Si vous devez NATer, restreignez-le à un petit ensemble d’appareils legacy et documentez-le.

3) « J’ai activé le full tunnel, maintenant l’accès réseau local du client est cassé »

Symptôme : Le client ne peut plus atteindre 192.168.0.1 sur le Wi‑Fi local après avoir mis AllowedIPs = 0.0.0.0/0.

Cause réelle : Le full tunnel détourne toutes les routes IPv4, y compris les RFC1918. Le client essaie d’atteindre la passerelle locale via le tunnel.

Correction : Utilisez le split tunnel (ne routez que ce dont vous avez besoin), ou ajoutez des routes « contournant le LAN local » explicitement sur le client. Sur certains clients c’est « exclure les IP privées », sur d’autres vous ajoutez des routes manuelles.

4) « Certains services fonctionnent, mais SMB/RDP est instable ou se bloque »

Symptôme : Le ping marche, le petit HTTP marche, mais les gros transferts s’arrêtent ou le remote desktop gèle.

Cause réelle : Problème MTU/PMTUD. Le overhead du tunnel pousse les paquets au-dessus de la MTU du chemin ; les ICMP fragmentation-needed sont bloqués par le pare-feu de quelqu’un.

Correction : Baissez la MTU de WireGuard (commencez vers 1380, descendez jusqu’à 1280 si nécessaire) ou appliquez un clamp TCP MSS sur le routeur pour les flux traversant wg0.

5) « Un seul VLAN fonctionne via le VPN ; les autres VLANs sont morts »

Symptôme : On peut atteindre 192.168.50.0/24 mais pas 192.168.60.0/24.

Cause réelle : AllowedIPs sur le peer client ou serveur n’inclut pas tous les préfixes LAN, ou les règles de pare-feu n’autorisent qu’une interface/zone.

Correction : Ajoutez les sous-réseaux VLAN manquants à AllowedIPs sur le client et assurez-vous que le routeur forwarde wg0 vers les interfaces VLAN.

6) « Les clients VPN peuvent atteindre le LAN, mais le LAN ne peut pas atteindre les clients VPN »

Symptôme : Le client distant peut SSHer dans le NAS, mais le NAS ne peut pas se connecter en retour au client pour un callback inverse.

Cause réelle : La politique de forward n’autorise que les flux établis du LAN vers wg0, ou le NAT cache le client et casse l’initiation entrante.

Correction : Autorisez LAN → wg0 où nécessaire, ou gardez-le bloqué volontairement et acceptez que le VPN soit uniquement initié par le client. Ne bloquez pas accidentellement puis ne vous étonnez pas que les sauvegardes ne poussent pas.

7) « Le DNS marche pour Internet, mais les noms internes ne se résolvent pas »

Symptôme : nas.lan échoue mais 1.1.1.1 fonctionne parfaitement.

Cause réelle : Le client utilise un DNS public via le tunnel ; pas de split DNS ; domaines de recherche manquants. Les gens appellent ça « accès LAN » mais c’est de la résolution de noms.

Correction : Poussez/utilisez le DNS interne pour le domaine LAN quand vous êtes en VPN. Si vous exécutez un full tunnel, utilisez le résolveur du routeur ; si split, configurez le DNS par domaine si le client le permet.

8) « Ça marchait hier, maintenant ça marche plus, et rien n’a changé (en théorie) »

Symptôme : Échec soudain après reboot de l’ISP ou du routeur ; les handshakes sont toujours présents.

Cause réelle : IP WAN dynamique changée et le peer endpoint n’est pas mis à jour, ou l’état NAT/conntrack a été réinitialisé et révèle un routage asymétrique que le NAT masquait.

Correction : Assurez des keepalives pour les clients road-warrior, envisagez des stratégies de mise à jour dynamique d’endpoint, et corrigez le routage pour ne pas dépendre d’un état conntrack obsolète.

Trois micro-récits d’entreprise depuis les tranchées NAT

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé WireGuard sur un routeur de succursale pour que les ingénieurs d’astreinte accèdent aux outils internes pendant un déménagement de bureau.
La personne qui l’a construit a supposé « les clients VPN doivent ressembler à s’ils sont sur le LAN ». But raisonnable, mauvaise implémentation.

Ils ont activé une règle de masquerade large pour tout ce qui venait de wg0 et allait vers le bridge LAN. Ça a « corrigé » la joignabilité immédiatement.
Les ingénieurs pouvaient atteindre Jira, Grafana et le serveur de fichiers. Tout le monde a fait la fête et est passé à autre chose.

Deux semaines plus tard, la sécurité a demandé pourquoi les logs du serveur de fichiers montraient le routeur comme source pour chaque session VPN.
Puis les opérations ont remarqué que le rate limiting se déclenchait contre l’IP LAN du routeur, pas contre les vraies IP clients.
Quelques ACL internes supposées être « admins seulement » sont devenues « n’importe quel utilisateur VPN » parce que l’ACL était basée sur l’IP source et le routeur était sur la allowlist.

L’incident n’était pas une « insécurité WireGuard ». C’était l’effondrement d’identité causé par le NAT.
La correction était ennuyeuse : supprimer le NAT wg0→LAN, ajouter une route pour le sous-réseau VPN sur la passerelle LAN, et mettre à jour la politique de pare-feu pour autoriser explicitement les flux voulus.
Après ça, les logs et les ACL ont recommencé à avoir du sens, ce qui est une étrange forme de joie.

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait un accès distant plus rapide pour les développeurs. Quelqu’un avait lu que « le NAT est coûteux » et a essayé d’optimiser en évitant conntrack.
Ils ont implémenté du policy routing pour que le trafic client VPN utilise une table spéciale et contourne certaines chaînes de pare-feu, en attendant une latence plus faible.

Isolé, le changement semblait propre. Le tunnel est resté up. Les benchmarks de débit vers Internet ont un peu amélioré.
Puis une chose complètement différente a cassé : l’accès au Git interne sur le VLAN LAN est devenu intermittent, mais seulement pour certains développeurs.

Le coupable était la table de politique manquant une route spécifique pour un des sous-réseaux internes.
Le trafic de 10.6.0.0/24 vers 192.168.70.0/24 a suivi la route par défaut de la policy vers l’interface WAN.
Les réponses ne sont jamais revenues, parce que ces paquets n’auraient jamais dû quitter le bâtiment.

L’« optimisation » a créé un univers de routage parallèle qui a dérivé de la réalité. La correction était aussi ennuyeuse : répliquer les routes LAN requises dans la table de policy,
ajouter un test de régression qui validait la joignabilité pour chaque préfixe interne, et arrêter de traiter le policy routing comme une astuce perf que l’on peut déployer un vendredi.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une troisième équipe gérait une flotte de petits routeurs pour des sites distants, tous administrés de la même façon. Leur template WireGuard n’incluait jamais le masquerade wg0→LAN.
À la place, chaque passerelle de site portait une route statique pour le sous-réseau client VPN vers le routeur, et le DHCP distribuait des routes sans classe quand nécessaire.

C’était peu glamour. Cela exigeait de tenir un inventaire des sous-réseaux existants et de s’assurer que les templates ne divergeaient pas.
Mais cela signifiait que les paquets préservaient l’identité source de bout en bout. La journalisation était précise. La politique de pare-feu avait du sens.

Lors d’une panne ISP chaotique sur un site, ils ont dû basculer provisoirement l’egress VPN vers une liaison de secours.
Parce que leur design ne dépendait pas d’astuces NAT pour l’accès LAN, le changement portait surtout sur les routes par défaut et le failover.
L’accès interne a continué à fonctionner pendant que l’uplink fluctua. L’astreinte a pu dormir.

La leçon : la correction scale. Les « solutions rapides » aussi, mais dans l’autre sens.

Schémas qui fonctionnent réellement (et pourquoi)

Schéma A : Routez correctement (préféré)

Si votre objectif est une vraie appartenance au LAN—les clients ont des IP de tunnel stables, vous voulez de la journalisation et des ACL par client—faites du routage, pas du NAT.
Cela signifie :

• Les clients WireGuard vivent dans un sous-réseau dédié (ex. 10.6.0.0/24).
• Le routeur connaît à la fois les sous-réseaux LAN et VPN (il le fait par défaut si configuré).
• La passerelle LAN a une route de retour vers le sous-réseau WireGuard via le routeur.
• Le pare-feu autorise les flux voulus ; refuse le reste.

C’est la seule approche qui rend identité, monitoring et debug sensés. Si vous administrez des réseaux pour vivre, choisissez cela sauf raison forte de ne pas le faire.

Schéma B : NAT sélectif pour LAN legacy (compromis acceptable)

Parfois vous ne pouvez pas ajouter de routes sur la passerelle LAN. Peut-être c’est une brique fournie par l’ISP, peut-être un réseau géré que vous ne contrôlez pas,
peut-être que le LAN est un zoo d’appareils statiques que vous ne pouvez pas toucher.

Dans ce cas, le NAT peut être un outil pragmatique—mais limitez sa portée :

• NAT uniquement du sous-réseau WireGuard vers des préfixes LAN spécifiques.
• Ne pas masquerader tout le trafic wg0 dans toutes les directions.
• Gardez une liste des appareils/sous-réseaux qui dépendent de cela pour pouvoir revenir en arrière plus tard.

L’objectif est d’éviter le syndrome « tous les clients VPN deviennent le routeur », et d’éviter le NAT LAN-à-LAN involontaire.

Schéma C : Full tunnel sur un routeur (puissant, mais vous vous engagez)

Le full tunnel, c’est quand les clients routent 0.0.0.0/0 (et parfois ::/0) vers wg0. Sur un routeur, cela signifie généralement que vous voulez que les clients distants utilisent votre egress domestique/entreprise
(pour confiance, géolocalisation, filtrage de contenu, ou parce que le Wi‑Fi de l’hôtel est maudit).

Le full tunnel nécessite presque toujours du NAT sur l’egress WAN, car vous envoyez des adresses privées du tunnel vers Internet. Mais ce NAT appartient à wg0→WAN, pas wg0→LAN.
De plus, le full tunnel introduit ces exigences récurrentes :

• Exceptions LAN : assurez-vous que les préfixes internes continuent de routage localement (surtout si vous utilisez des tables de policy routing).
• Stratégie DNS : DNS interne pour les noms internes ; décidez si vous résolvez via le routeur ou via du split DNS.
• Ajustement MTU : plus de sauts, plus d’encapsulation, plus de risques de problèmes PMTUD.

Où les gens se trompent : confondre « le rendre joignable » et « le rendre correct »

Le NAT est séduisant parce qu’il peut faire revenir les paquets sans toucher le LAN. Mais quand vous NATez le tunnel vers le LAN, vous réécrivez l’histoire que racontent vos paquets.
Tout en aval—logs, ACL, limites de débit, traces applicatives—voit maintenant « le routeur l’a fait ».

Si vous faites cela à la maison et que vous vous en fichez, très bien. Si c’est au travail et que vous tenez à l’attribution, n’en faites pas.

Listes de contrôle / plan étape par étape

Étape par étape : restaurer l’accès LAN sans NAT cargo-cult

1. Confirmer handshake et compteurs : wg show doit afficher un handshake récent et des transferts non nuls. Sinon, corrigez endpoints/clefs/UDP reachability.
2. Vérifier le forwarding du routeur : activez net.ipv4.ip_forward=1. Si l’IPv6 est impliqué, activez aussi le forwarding IPv6 volontairement.
3. Confirmer l’intention de routage du client : AllowedIPs du client doit inclure les sous-réseaux LAN que vous voulez atteindre (split tunnel) ou 0.0.0.0/0 (full tunnel).
4. Confirmer les routes du routeur : le routeur doit avoir des routes connectées pour LAN et wg0. Si vous utilisez du policy routing, confirmez que ces tables incluent aussi les routes LAN.
5. Prouver le flux de paquets avec tcpdump : voyez des paquets ICMP/TCP sur wg0 et br-lan. S’il ne traverse pas, c’est pare-feu/forwarding.
6. Corriger le chemin de retour correctement : ajoutez une route pour le sous-réseau WireGuard sur la passerelle LAN pointant vers le routeur. Préférez le faire une fois sur la passerelle, pas sur chaque hôte.
7. Ce n’est qu’ensuite que vous considérez le NAT : si vous ne pouvez vraiment pas corriger le routage, ajoutez une règle NAT ciblée du sous-réseau wg0 vers le sous-réseau LAN, pas un masquerade large.
8. Verrouillez la politique de pare-feu : autorisez seulement les protocoles nécessaires de wg0 vers le LAN ; envisagez de bloquer le mouvement latéral par défaut.
9. Validez la MTU : testez les gros paquets et ajustez MTU/MSS si nécessaire.
10. Documentez : incluez quels sous-réseaux existent, où le NAT est appliqué (si c’est le cas), et ce que « fonctionner » signifie (tests à exécuter).

Checklist décisionnelle : devez-vous NAT VPN→LAN ?

• Contrôlez-vous la passerelle LAN ? Si oui, routez-le. Si non, le NAT peut être votre seule option.
• Avez-vous besoin d’attribution par client sur les systèmes LAN ? Si oui, ne faites pas de NAT wg0→LAN.
• Attendez-vous des connexions initiées par le LAN vers les clients VPN ? Si oui, le routage est bien plus simple que NAT + redirections de ports + tristesse.
• Cela est-il temporaire ? Si vous devez NATer, traitez-le comme une dette technique avec un plan de sortie.

Tests de régression (à exécuter après chaque modification)

Faites de ces tests un réflexe musculaire. Ils attrapent la plupart des régressions :

• Depuis le client VPN : pingez l’IP LAN du routeur, pingez un hôte LAN, connectez-vous à un service TCP (SSH/HTTPS/SMB).
• Depuis le routeur : pingez un hôte LAN, pingez l’IP tunnel du client VPN.
• Depuis un hôte LAN : pingez l’IP tunnel du client VPN (si vous voulez LAN→VPN), ou confirmez que c’est bloqué (si vous ne le voulez pas).
• Vérifiez les logs : confirmez que le service LAN voit l’IP source du client VPN (si design routage) ou voit le routeur (si design NAT, intentionnel).

FAQ

1) Pourquoi WireGuard « se connecte » mais le trafic LAN ne circule pas ?

Le handshake prouve seulement l’établissement de la session cryptographique. Le trafic de données nécessite encore le forwarding IP, des routes correctes et la permission du pare-feu.
Le plus souvent le chemin d’aller fonctionne mais la route de retour du LAN vers le sous-réseau VPN est manquante.

2) Est-ce que AllowedIPs est une règle de pare-feu ?

Pas vraiment. Il se comporte comme un sélecteur de routage (quelles destinations vont vers ce peer) et un filtre source (quelles adresses source sont acceptées depuis ce peer).
Traitez-le comme une politique de routage, puis utilisez le pare-feu réel pour le contrôle d’accès.

3) Dois-je masquerader le trafic WireGuard ?

Le masquerade est généralement correct pour wg0→WAN quand on utilise un egress full tunnel. Masquerader wg0→LAN est habituellement un palliatif pour des routes manquantes.
Utilisez le routage si possible ; utilisez le NAT ciblé seulement si nécessaire.

4) Mon LAN est 192.168.1.0/24 et le réseau distant est aussi 192.168.1.0/24. Et maintenant ?

Les sous-réseaux qui se chevauchent sont une impasse de routage. Il faut renuméroter un côté, ou NATer un côté dans une plage non chevauchante, ou utiliser des proxys applicatifs.
Si c’est un VPN site-à-site, planifiez un projet de renumérotation et arrêtez de prétendre que ça n’arrivera pas.

5) Pourquoi puis-je atteindre des IPs mais pas des noms d’hôtes ?

C’est du DNS, pas du routage. Votre client peut utiliser un DNS public ou n’a pas le domaine de recherche LAN.
Configurez le client VPN pour utiliser votre DNS interne (ou exécutez un résolveur sur le routeur) et assurez-vous que les zones internes sont atteignables.

6) Comment autoriser les clients VPN à accéder à un seul hôte LAN (comme un NAS) et rien d’autre ?

Routez correctement (pas de NAT), puis appliquez des règles de pare-feu : autorisez wg0 vers l’IP/ports du NAS, refusez wg0 vers le reste du LAN.
Le faire avec du NAT rend l’audit plus difficile et peut créer des accès accidentels via les privilèges du routeur.

7) Pourquoi le trafic échoue seulement pour de gros téléchargements ou copies de fichiers ?

Problèmes MTU/PMTUD. Le chemin ne peut pas transporter de gros paquets encapsulés, et les ICMP « fragmentation needed » peuvent être bloqués.
Baissez la MTU de WireGuard ou appliquez un clamp TCP MSS sur le routeur pour le trafic traversant wg0.

8) Quelle est la façon la plus propre d’éviter d’ajouter des routes sur chaque appareil LAN ?

Ajoutez une route sur la passerelle par défaut LAN vers le sous-réseau WireGuard via le routeur. Si votre LAN a plusieurs passerelles/VLANs, mettez la route dans le cœur L3.
Pour les endpoints, les routes statiques DHCP sans classe peuvent aider, mais la route sur la passerelle est la plus simple.

9) Dois-je autoriser le forwarding br-lan → wg0 ?

Seulement si vous voulez des connexions initiées par le LAN vers les clients VPN. Beaucoup de configurations bloquent cela volontairement pour la sécurité.
Mais soyez explicite : si vous le bloquez, documentez que le VPN est uniquement initié par le client afin que personne ne perde un weekend à déboguer des « callbacks cassés ».

Prochaines actions à faire aujourd’hui

Si votre configuration actuelle « marche » seulement parce que vous masqueradez wg0 dans le LAN, vous êtes à une modification d’une panne étrange ou d’un mystère de logs.
Corrigez-le sérieusement.

1. Auditez la portée du NAT : assurez-vous que le masquerade existe pour wg0→WAN si nécessaire, et retirez le masquerade wg0→LAN sauf si c’est un compromis explicite et documenté.
2. Rendez le routage de retour correct : ajoutez la route du sous-réseau WireGuard sur la passerelle LAN et vérifiez avec un ping côté LAN vers une IP client VPN.
3. Validez avec des captures de paquets : tcpdump sur wg0 et le LAN pour prouver où le paquet s’arrête.
4. Décidez de votre posture sécurité : le LAN est-il autorisé à initier vers les clients VPN ? Si oui, autorisez-le soigneusement ; si non, bloquez-le clairement et intentionnellement.
5. Rédigez un runbook d’une page : incluez vos sous-réseaux, où le NAT existe, et trois tests de régression. Le vous du futur sera moins en colère.

Faites ces choses, et WireGuard redeviendra ce qu’il doit être : une interface chiffrée simple, pas un exercice récurrent d’interprétation du NAT.