Pourquoi mon tunnel WireGuard ne route plus rien sur un serveur qui héberge Docker ou Coolify ?

Coolify et Docker créent des bridges dans 10.0.0.0/16. Si vous configurez WireGuard sur 10.0.0.1/24, deux interfaces se disputent la même IP et le routage casse silencieusement. Vérifiez toujours ip route avant de lancer un installeur VPN pour repérer le conflit.

Quel subnet choisir pour un VPN WireGuard afin d’éviter un conflit avec Docker ?

Évitez 10.0.0.0/24, l’exemple par défaut partout, car il chevauche les bridges Docker. Préférez 10.8.0.0/24 (l’autre classique hérité d’OpenVPN, qu’aucun outil moderne n’utilise) ou mieux 100.64.0.0/10, la plage CGNAT réservée par l’IANA donc sans collision RFC1918.

Pourquoi nmcli refuse d’importer mon fichier .conf WireGuard avec une erreur sur le nom d’interface ?

NetworkManager utilise le nom du fichier (sans le .conf) comme nom d’interface réseau Linux, limité à 15 caractères (IFNAMSIZ - 1). Un nom comme client1-split-tunnel fait 20 caractères et est rejeté. Renommez le fichier en quelque chose de court comme wg-srv-s.conf et l’import passe.

Pourquoi OpenVPN s’importe sans problème dans NetworkManager mais pas WireGuard ?

OpenVPN crée une interface tun0 standard indépendante du nom du fichier, donc NetworkManager accepte n’importe quel nom. WireGuard est différent : NM nomme l’interface noyau d’après le fichier, ce qui impose la limite de 15 caractères alphanumériques plus tiret.

WireGuard sur Coolify : 2 pièges en 30 minutes

Dimanche soir : « tiens, je vais setup WireGuard sur mon serveur OVH pour accéder à mes services internes depuis l’extérieur ». Estimation : 15 min. Réalité : 30, à cause de deux trucs évitables.

Piège 1 : conflit subnet avec Docker

Mon script d’install configure le tunnel sur 10.0.0.0/24 (serveur en 10.0.0.1). Subnet RFC1918 le plus classique pour un VPN, exemple par défaut partout en ligne.

$ ip route | grep '10\.'
10.0.0.0/24 dev docker0 src 10.0.0.1     ← AÏE
10.0.1.0/24 dev br-142c0c14d09b ...
10.0.2.0/24 dev br-491228d2d7bd ...
10.0.3.0/24 dev br-973ead3565ba ...

Mon serveur héberge Coolify, qui crée des bridges Docker dans 10.0.0.0/16. WireGuard sur 10.0.0.1/24 → deux interfaces se disputent la même IP, le routage casse silencieusement.

Fix : changer VPN_SUBNET="10.0.0" en VPN_SUBNET="10.8.0" dans le script. La plage 10.8.0.0/24 est l’autre classique de la culture VPN (héritée d’OpenVPN), aucun outil moderne ne l’utilise par défaut.

Mais nécessite de toujours vérifier ip route avant de lancer un installeur VPN. Pareil pour Tailscale, ZeroTier, IPSec — le sub 100.64.0.0/10 (CGNAT) est plus sûr car réservé par l’IANA pour des usages sans collision RFC1918.

Piège 2 : NetworkManager qui refuse l’import

WireGuard up, je veux importer le client dans NetworkManager pour avoir le toggle dans l’applet GNOME.

$ nmcli connection import type wireguard file client1-split-tunnel.conf
Erreur : n'a pas pu importer « client1-split-tunnel.conf » :
Le fichier de configuration WireGuard doit correspondre à un nom d'interface valide suivie par ".conf".

Message cryptique. La doc nmcli aussi. Quelle contrainte exacte ?

NetworkManager utilise le nom de fichier (sans .conf) comme nom d’interface réseau Linux. Limité à 15 chars (IFNAMSIZ - 1). client1-split-tunnel fait 20 chars → refusé.

$ cp client1-split-tunnel.conf wg-srv-s.conf
$ nmcli connection import type wireguard file wg-srv-s.conf
Connexion « wg-srv-s » ajoutée avec succès.

Avec un nom court (10 chars), import OK. La connexion apparaît dans GNOME settings → Network → VPN.

OpenVPN n’a pas ce souci : NM accepte tout nom car la connexion crée une tun0 standard, indépendante du nom. WireGuard est différent : NM nomme l’interface noyau wireguard d’après le fichier.

Lessons learned

ip route avant un install VPN. Docker, Coolify, K3s prennent dans 10.0.0.0/8. 100.64.0.0/10 (CGNAT) est le plus safe.
Le .conf WireGuard = nom d’interface Linux dans NM. 15 chars max, alphanumeric + tiret.
Split + full tunnel comme connexions distinctes : wg-srv-s.conf (quotidien), wg-srv-f.conf (wifi public).
iptables-persistent sinon le port UDP disparaît au reboot.

WireGuard sur Coolify : 2 pièges en 30 minutes

Piège 1 : conflit subnet avec Docker

Piège 2 : NetworkManager qui refuse l’import

Lessons learned

Questions fréquentes