Paramétrage wireguard
brupala Messages postés 115288 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
je viens de créer un serveur wireguard avec 3 clients.
je souhaiterais les faire communiquer non pas derrière une box mais en 4G.
le serveur est en partage de connection avec le serveur.
lorsque mon téléphone se connecte au VPN son addresse change bien mais impossible d'échanger de la DATA.
J'ai aussi créé un client pour un PC en partage de co lui aussi mais la requete de ping ne passe pas.
auriez vous une solution à m'apporter?
- Paramétrage wireguard
- Paramétrage double écran - Guide
- Parametrage chromecast - Guide
- Paramétrage de word - Guide
- Windscribe wireguard - Guide
- Paramétrage sms sfr - Guide
13 réponses
Bonjour Henri, bonjour brupala
mon OS est Windows.
mon serveur est configuré sur un PC WINDOWS
Voici la config:
[Interface]
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ListenPort = 51820
Address = 2.2.2.1/24
[Peer]
PublicKey = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
AllowedIPs = 2.2.2.2/24
[Peer]
PublicKey = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
AllowedIPs = 2.2.2.3/24
[Peer]
PublicKey = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
AllowedIPs = 2.2.2.4/24
voici la config d'un de mes clients:
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 2.2.2.3/24
DNS = 8.8.8.8, 1.1.1.1
[Peer]
PublicKey = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
AllowedIPs = 0.0.0.0/0, 2.2.2.0/24
Endpoint = wgds.mywire.org:8245
PersistentKeepalive = 25
j'ai créé un nom de domaine pour résoudre le pb d'IP dynamique.
mon client quand il se connecte reconnait bien l'adresse ip publique de mon serveur.
le problème est que je dois pouvoir me déplacer avec mon serveur et je travaille donc en partage de connexion entre mon serveur et mon téléphone portable, je suis donc en wifi et non pas derrière un routeur...
Quand mon client se connecte le journal me donne ça
2025-12-12 10:15:30.850667: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
Merci d'avance
Modifié pour retirer les clé publiques
Salut,
tu peux expliquer mieux ceci:
"le serveur est en partage de connection avec le serveur."
Aussi, "les faire communiquer" qui, les mobiles ensemble ?
ou les relier à internet ?
Tu veux pinguer quoi en fait ?
fais voir ta configuration client et serveur en retirant les clés, au moins en partie.
Le serveur écrit dans le journal
2025-12-12 10:05:25.366740: [TUN] [SERVEUR] No valid endpoint has been configured or discovered for peer 3
Quand je connecte le client
OK,
tu as remis le même port à listen sur le serveur et endpoint sur le client ?
aussi, c'est peut-etre le nat de ta box si tu résous toujours par le dyndns, ça peut être un problème de hairpin nat dans ta box, qui en général ne sont pas prévues pour ça, il vaudrait mieux que tu testes sans le nom dns dans endpoint, mais l'adresse locale du serveur à la place, pour avoir déjà une config qui fonctionne en local avant de passer aux acrobaties sur réseau mobile.
Il est aussi possible que le fournisseur de service (mobile ou fixe) bloque les connexion VPN de Wireguard (le réseau de l'entreprise dans laquelle je suis en fait partie) ou qu'il y a un conflit d'adresses IP (car tu te trouve sur un réseau qui fourni une IP similaire à celle qui tu essayes d'obtenir via ton VPN).
J'ai aussi modifié ton message pour retirer les clé publiques.
J'ai juste regardé les IP et là déjà je bloque (je ferai un autre message pour les autres sujets).
Pourquoi tu utilise une IP en 2.* qui est une IP publique ?
Préfères utiliser des IP internes en 192.168.X.Y/24 ou 172.16-31.x.y/20 ou 10.0.0.0/8 ?
https://en.wikipedia.org/wiki/Private_network
Et par expérience, il faut mettre tes IP distantes interne en /32 si il n'y a qu'une cible :
Serveur :
IP locale : 10.0.0.250/32
Peer1 -> 10.0.0.1/32
Peer2 -> 10.0.0.2/32
...
Côté client :
IP locale : 10.0.0.X/32
Server -> 10.0.0.0/24
Sinon, une fois connecté quand tu va tenter de joindre un autre client sur le réseau, si le serveur voit qu'il doit envoyer à 2.2.2.2, il peut prendre n'importe lequel des clients, car le /24 autorise le passage.
Je ne sais pas si c'est volontaire, mais le fait d'indiquer 0.0.0.0/0 dans le AllowedIPs dispense de mettre les autres et surtout force la sortie de toute connexion internet via le serveur (tel un VPN commercial qui te change l'IP vu des serveurs web).
Si c'est juste pour du "local", contentes-toi juste de mettre 10.0.0.0/24 par exemple.
Salut,
tu peux mettre /32 en allowed ip si le client n'a pas d'autre adresse interne ou si il ne connecte pas un réseau au VPN, mais en adresse dans le VPN, ça n'est pas une bonne idée je pense, c'est plus sécure car ça empêche la communication avec les autres clients du vpn, mais bon le routage se fait plutôt par allowed ip:
https://www.procustodibus.com/blog/2021/01/wireguard-endpoints-and-ip-addresses/
Oui, il est possible de mettre /24, mais il faut que la partie réseau soit différente, dans la configuration fournie :
AllowedIPs = 2.2.2.2/24
AllowedIPs = 2.2.2.3/24
AllowedIPs = 2.2.2.4/24
Tous les clients sont sur le même réseau, de fait, Wireguard redirigera dans un seul client tous les trafic à destination de ces IPs.
Mais par exemple :
AllowedIPs = 2.2.2.1/24
AllowedIPs = 2.2.3.1/24
AllowedIPs = 2.2.4.1/24
Serait valide, car la partie réseau est différente.
En fait,
il faudrait se référer à ce qu'indique ip route et qui est déduit de ce que fournit allowedip et qui doit évoluer à chaque connexion d'un nouveau client.
Bonjour,
Donc vous pensez que si je mets mes peers dans des plages d'adresse différentes cela pourrait fonctionner ? J'ai choisi 2.2.2.x car j'avais déjà essayé 192.168.100.xxx mais ça ne marchait pas, je voulais éliminer cette piste. Je vais donc mettre mon serveur en /32 dans un premier temps pour voir et ensuite changer les peers de plan d'adressage comme tu me l'as conseillé. Je ne travaille plus avec mon domaine mais bien en direct avec mon ip publique.
En tout cas merci beaucoup pour votre aide !????
Dans un premier temps, mets toutes les adresses en /32.
Car si tu mets /24, ça signifie que tu assignes 256 adresses (dans les faits 254, mais bon les détails ...) au peer concerné.
Je ne sais pas si tu as compris que ce signifie de /24 ou /32 (tu peux poser la question si besoin), mais c'est utilisé par Wireguard pour savoir où router quel paquet.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre questionOui, je m'y connais un peu en masque de sous-réseau. Je vais essayer de mettre toutes les adresses de mes peers en/32, dans le fichier du serveur ainsi que dans les fichiers des clients.
Le port peut-etre n'importe quoi (éviter les well-known quand même, ça ne peut apporter que des ennuis), le choisir entre 32000 et 65000 de préférence, ce qui compte c'est qu'il soit le même côté serveur (paramètre listen) et client dans son paramètre endpoint. Il faut qu'il soit bien sûr dans la plage affectée par le FAI en cas de CGNat côté serveur, et un port forwarding configurable sur la box (ça exclut donc le partage de connexion mobile), il faut aussi qu'il soit autorisé en UDP dans les parefeu sur le chemin aussi bien en ipv4 qu'en ipv6.
Sur réseau mobile, il peut aussi y avoir à réduire la MTU (à cause de certaines méthodes de transport ipv4 dans ipv6 des opérateurs), ça devient complexe à ce niveau avec la transition ipv6, c'est pour ça que internet dans un réseau mobile, ça n'est pas tout à fait internet.
Salut,
je pense que les adresses ça ne mange pas de pain, surtout le masque, le vrai routage de wireguard se faisant en fait sur la clé publique à ce que j'ai compris (il est particulier, oui). Par contre les adresses hors client ou serveur VPN doivent être dans le paramètre AllowedIp pour être routables en destination et autorisées en source.
Salut,
Je ne comprends pas très bien ta phrase
Par contre les adresses hors client ou serveur VPN doivent être dans le paramètre AllowedIp pour être routables en destination et autorisées en source.
Pourrais tu m'éclairer un peu s'il te plaît ?
Salut,
voici ce que j'ai en log coté serveur:
2025-12-15 09:21:26.234783: [MGR] [SERVEUR] Tunnel service tracker finished
2025-12-15 09:21:28.378956: [TUN] [SERVEUR] Starting WireGuard/0.5.3 (Windows 10.0.26200; amd64)
2025-12-15 09:21:28.383378: [TUN] [SERVEUR] Watching network interfaces
2025-12-15 09:21:28.401196: [TUN] [SERVEUR] Resolving DNS names
2025-12-15 09:21:28.401196: [TUN] [SERVEUR] Creating network adapter
2025-12-15 09:21:29.217421: [TUN] [SERVEUR] Using existing driver 0.10
2025-12-15 09:21:29.251215: [TUN] [SERVEUR] Creating adapter
2025-12-15 09:21:31.126674: [TUN] [SERVEUR] Using WireGuardNT/0.10
2025-12-15 09:21:31.126674: [TUN] [SERVEUR] Enabling firewall rules
2025-12-15 09:21:30.540937: [TUN] [SERVEUR] Interface created
2025-12-15 09:21:40.450727: [TUN] [SERVEUR] Dropping privileges
2025-12-15 09:21:40.469085: [TUN] [SERVEUR] Setting interface configuration
2025-12-15 09:21:40.469085: [TUN] [SERVEUR] Peer 1 created
2025-12-15 09:21:40.469876: [TUN] [SERVEUR] Peer 2 created
2025-12-15 09:21:40.469876: [TUN] [SERVEUR] Peer 3 created
2025-12-15 09:21:40.504966: [TUN] [SERVEUR] Monitoring MTU of default v4 routes
2025-12-15 09:21:40.504966: [TUN] [SERVEUR] Interface up
2025-12-15 09:21:40.627711: [TUN] [SERVEUR] Setting device v4 addresses
2025-12-15 09:21:41.097537: [TUN] [SERVEUR] Startup complete
2025-12-15 09:21:48.551326: [TUN] [SERVEUR] Monitoring MTU of default v6 routes
2025-12-15 09:21:48.566242: [TUN] [SERVEUR] Setting device v6 addresses
tout me semble donc OK de ce coté là, je n'ai plus le pb de création de endpoint sur les peers
En revanche voici ce que j'ai coté client:
2025-12-12 10:14:24.544862: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:14:29.599425: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:14:29.599425: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:14:34.733911: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:14:34.733978: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:14:39.826048: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:14:39.826048: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:14:44.872623: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:14:44.872623: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:14:49.918594: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:14:49.918594: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:14:54.966023: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:14:54.966023: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:00.112776: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:15:00.112776: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:05.143742: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:15:05.143742: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:10.252799: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:15:10.252799: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:15.397827: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:15:15.397827: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:20.546448: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:15:20.546448: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:25.715386: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 3)
2025-12-12 10:15:25.715386: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
2025-12-12 10:15:30.850667: [TUN] [CLIENT3] Handshake for peer 1 (80.214.102.11:8245) did not complete after 5 seconds, retrying (try 2)
2025-12-12 10:15:30.850667: [TUN] [CLIENT3] Sending handshake initiation to peer 1 (80.214.102.11:8245)
on dirait que le client ne voit pas le serveur...
je peux vous poster mes conf si vous le souhaitez.
Merci d'avance.
Bon, j'ai résolu mon problème en mettant une IP fixe sur ma carte wifi au lieu d'être en DHCP, et je mets cette adresse en Endpoint sur mon client. Ça fonctionne sur mon PC ainsi que sur Android après avoir changé son adresse IP.
C'est pas très propre mais ça fonctionne...
En revanche je perds la connexion internet quand le VPN tourne c'est dommage...
Il doit y avoir un paramétrage côté serveur VPN pour partager la connexion internet avec les clients
OK,
on est d'accord que tu testes en réseau local wifi là ?
Quand tu dis que tu perds l'accès internet quand le vpn est connecté, tu parles côté client ou côté serveur ?
Si tu veux garder l'accès internet sur le client, il faut supprimer la route par défaut 0.0.0.0/0 dans les allowedip, ne garder que les 2.2.2.0/24,
pour qu'internet passe par le serveur, il faut rajouter du nat sur le serveur dans ce cas et natter les adresses du vpn vers l'adresse du serveur sur la lan, sur windows, c'est peu paramétrable, il faut en gros un partage de connexion (ICS) du lan vers le tunnel vpn, par contre ce go.gol de windows va installer aussi un serveur dhcp et va modifier l'adressage du vpn en 192.168.137.x
ça n'est pas un windows serveur que tu as ?
Ca a fonctionné sur PC entre 2 partage de connexion sur PC mais dès qu'on passe en 4G ca ne passe plus...
C'est quand même étrange qu'un VPN ne fonctionne pas sous 4G alors qu'il est bien configuré pour passer en partage de connexion
ça fonctionnait en partage de connexion wifi donc ?
Je te l'ai déjà dit plusieurs fois: un réseau mobile, ce n'est pas tout à fait internet, surtout en ce moment en cours de migration en full ipv6 des réseaux mobiles (et fibre à suivre).
Tu pourrais tester en ipv6 au niveau du endpoint, il me semble que ton dyndns résolvait en ipv4 et ipv6, ce qui me surprend énormément d'ailleurs car je n'ai pas vu de dyndns en ipv6 (qui gère les AAAA) encore.
ah si, apparemment, il y en a maintenant:
Oui, il existe des services de **DynDNS (Dynamic DNS)** pour **IPv6**, bien que leur disponibilité et leur utilisation soient moins courantes que pour IPv4, en raison de la nature différente de l’adressage IPv6.
### Contexte :
- **IPv6** est conçu pour offrir une quantité quasi illimitée d’adresses uniques, ce qui réduit la nécessité de partage d’adresses (comme avec le NAT en IPv4).
- Cependant, **les adresses IPv6 peuvent aussi être dynamiques** (surtout chez les particuliers), notamment si elles sont attribuées via SLAAC ou DHCPv6 avec un préfixe changeant.
### Solutions DynDNS pour IPv6 :
1. **Services tiers** :
- **DynDNS (dyn.com)** : propose le support IPv6.
- **No-IP** : supporte les mises à jour DNS pour les adresses IPv6.
- **DuckDNS** : supporte IPv6 (via l’API ou les clients).
- **Cloudflare** : permet de mettre à jour dynamiquement les enregistrements AAAA via son API.
- **Infomaniak** : propose un service de **DNS dynamique pour IPv6** dans son offre d’hébergement (via l’interface de gestion DNS).
2. **Clients de mise à jour** :
- **ddclient** (Linux) : supporte IPv6.
- **inadyn** : compatible IPv6.
- **Cloudflare DDNS script** (Python, Bash, etc.) : peut être configuré pour IPv6.
### Recommandation :
Si vous utilisez **Infomaniak**, vérifiez dans votre interface de gestion DNS si l’option “DNS dynamique” est activée pour IPv6 — c’est souvent disponible pour les domaines hébergés.
---
✅ **Conclusion** : Oui, des solutions DynDNS pour IPv6 existent, mais elles nécessitent un client ou un script capable de détecter et de mettre à jour l’adresse IPv6 publique dynamique.
> *Note : Cette réponse est basée sur des connaissances techniques courantes et ne nécessite pas de recherche web, car il s’agit d’un concept technique stable et documenté.*
Bonjour,
merci pour cette réponse qui reste un peu obscure pour moi. Personnellement j'utilise DYNU qui m'a fourni le nom de domaine.
mais même quand je mets l'adresse IP publique trouvée sur internet ça ne fonctionne toujours pas... toujours le même problème de poignée de main.
et la conf qui fonctionnait sur PC (que j'ai perdue car changée) en partage de co n'est pas acceptée par l'application mobile qui est mon but final.
en effet j'ai besoin que le VPN fonctionne sur téléphone mobile.
Bonjour,
en fait le pare feu est configuré, j'ai bien l'adresse de mon endpoint qui apparait en IPV6 sur mon client mais toujours le même message de handshake failed...
j'ai vu que c'était un problème récurrent en fouillant sur le net mais je n'ai pas trouvé de réponse.
on me parle de MTU, je ne vois pas de quoi il s'agit.
j'ai vu ce champ dans mon client pour mobile mais ne sais pas comment le définir dans le serveur.
je viens d'acheter un petit routeur wifi où j'ai mis mon adressage en ip fixe et non en DHCP, mais pas de résultat pour autant....
Salut,
la MTU, c'est la taille maximum en octets d'un paquet IP sur une portion de liaison, par exemple sur un réseau ethernet classique c'est 1500, c'est diminué au fur et à mesure des encapsulations dans différents tunnels, suivant l'entête ajouté
sur un vpn wireguard, il est défini à 1420 à la base, je crois, si un paquet dépasse la MTU, il est fragmenté par le routeur en IPV4 ou renégocié par l'émetteur en IPV6 (qui ne fragmente pas).
Wireguard le définit comme un paramètre de la rubrique interface de la configuration.
La valeur minimale pour ipV6 est de 1280 octets.
Si ça ne pase pas à 1420, tu peux essayer avec 1400 ou 1380 si la connexion mobile passait par un tunnel DS-LITE.
Plus la valeur est grande meilleur est le débit, car il faut moins de paquets pour la même quantité de données bien sûr.
Salut,
je reviens sur ton sujet pour une suggestion car je pense toujours qu'il est difficile de configurer l'accès à un serveur relié à l'internet par un réseau mobile.
Une bonne solution serait de faire ton petit cloud et de louer un serveur (virtuel ou en dur si tu as plus les moyens) chez un hébergeur, et d'installer dessus un petit serveur VPN Wireguard qui permettrait de réunir tous tes PC à distance qu'ils soient sur ligne fixe ou via réseau mobile dans un petit réseau privé façon Hamachi , mais avec l'énorme avantage c'est qu'avec ton propre serveur, il n'y a que toi qui voit tes données passer.
Un logiciel comme pivpn permet de créer un serveur vpn très facilement, les pc clients gardant leur accès à l'internet, via le vpn ou directement si besoin.
Les différents clients sont joignables par leur adresse ip (V4 ou V6) privées sur leurs VPN.
un petit VPS c'est à partir de quelques euros par mois et certains peuvent être facturés à l'heure.
De plus, quand j'essaie de me connecter le journal de mon serveur m'envoie ce message:
2025-12-12 10:05:25.366740: [TUN] [SERVEUR] No valid endpoint has been configured or discovered for peer 3
Pourtant il me semble qu'il est bien paramétré...
Salut,
il n'y a pas besoin de endpoint pour le client dans la config du serveur, vu que c'est le client qui va se connecter, les public key suffisent à les reconnaitre, d'ailleurs, si tu les as affichées en entier ici, tu devrais demander via le bouton signaler à un modérateur de modifier ton post pour qu'ils n'apparaissent pas en entier. Nicolas qui doit suivre cette discussion pourrait le faire.
Pourquoi le port ne correspond pas ?
tu as 8245 côté client et 51820 sur le serveur, ça ne peut pas fonctionner comme ça.
Mais le plus gros problème est sans doute que tu mettes le serveur derrière une connexion mobile, même avec un dyndns, ça n'ouvrira pas le port côté réseau mobile, un réseau mobile ce n'est pas tout à fait internet.
Même si ton dns wgds.mywire.org a l'air de résoudre en ipv6, je ne suis pas certain que ton opérateur mobile (Bouygues) ouvre le parefeu ipv6 et en ipv4, forcément c'est une ip partagée derrière un CGNat.
Ce qui est bizarre c'est vois bien mon client... J'ai déjà essayé avec le même port mais le problème reste le même... Sûrement que tu as raison ça doit venir du CGNAT
Si j'achète un routeur wifi pense tu que ça puisse résoudre le problème ?
Avec un routeur, non je ne crois pas, c'est la carte SIM et son contrat le problème, il faudrait un vrai contrat B2B avec Bouygues.
Tu dis tu vois le client sur le serveur, de quelle façon ?