La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: rosperceau le 28 juin 2026 à 22:45:48
-
Bonjour,
J'ai une Freebox Pop en fibre en mode routeur. J'ai branché en ethernet un "single board computer" (odroid, simili-raspberrypi), lequel sert de serveur Wireguard. Mes clients VPN (android) arrivent à accéder à l'Internet public et à mon odroid.
Je cherche en IPv6 à ce que mes clients VPN puissent accéder aux machines du réseau local. Problème: si le trafic (ex: ping) arrive bien d'un client VPN à une machine desktop (en wi-fi), les réponses n'arrivent pas au client VPN. En fait ça semble ne pas passer de l’odroid vers la machine desktop, cela semble se perdre au niveau de la Freebox. Pour le moment je n'ai réussi qu'avec une bidouille, et je cherche si il y a une manière propre.
Je ne suis pas admin réseau de métier.
La topologie de mon réseau (IPs fictives) est:
- Sous-réseau IPv6 de mon abonnement: 2a01:aaaa:bbbb:cc20:0:0:0:0/61
- Sous-réseau principal associé à la Freebox: 2a01:aaaa:bbbb:cc20:0:0:0:0/64
- IP Freebox: 2a01:aaaa:bbbb:cc20::1:
- Desktop en wi-fi: 2a01:aaaa:bbbb:cc20:1111:222:3333:4444
- Odroid en ethernet: 2a01:aaaa:bbbb:cc20:5555:6666:7777:8888
- Sous-réseau dédié à mon routeur: 2a01:aaaa:bbbb:cc21:0:0:0:0
- Odroid sur ce 2nd réseau: 2a01:aaaa:bbbb:cc21::1
- Client-VPN-1 sur ce 2nd réseau: 2a01:aaaa:bbbb:cc21::1:1
Problème:
- Si je fais un ping de mon téléphone (en 5G) vers "Desktop", ça répond
- Si j'active le client Wireguard sur le téléphone, alors je n'ai pas de réponse. Avec Wireshark sur ce Desktop, je vois que les packets ICMP6 arrivent et que des réponses sont envoyées.
- Bidouille crade et pas générique pour que ça marche: sur Desktop, exécuter /sbin/ip -6 route add SOUS_RESEAU_VPN/64 via IPV6_PUBLIQUE_DU_ODROID (et pour être honnête, je ne comprends que superficiellement ce que je fais)
.
Ma conf:
- Dans l'admin Freebox, pour la conf IPv6, pour le 1er préfixe secondaire (2a01:aaaa:bbbb:cc21:0:0:0:0), j'ai mis l'IPv6 link-local de mon odroid (fe80::…)
- Dans /etc/sysctl.conf:
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.wg0.proxy_ndp=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.wg0.accept_ra=2- Dans /etc/wireguard/wg0.conf
[Interface]
# private address for my vpn-server, on the interface wg0 dedicated to it
Address = 172.16.0.1/24
Address = 2a01:aaaa:bbbb:cc21::1/64
Table = off
SaveConfig = false
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ufw route allow in on %i to any
PostUp = ip6tables -A FORWARD -i wg0 -o %i -j ACCEPT;
PostUp = ip6tables -A FORWARD -i %i -j ACCEPT;
PostUp = ip -6 neighbor add proxy 2a01:aaaa:bbbb:cc21::1:1 dev wg0
PostUp = ip -6 neighbor add proxy 2a01:aaaa:bbbb:cc21::1:2 dev wg0
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ufw route delete allow in on %i to any
PostDown = ip6tables -D FORWARD -i wg0 -o %i -j ACCEPT;
PostDown = ip6tables -D FORWARD -i %i -j ACCEPT;
PostDown = ip -6 neighbor del proxy 2a01:aaaa:bbbb:cc21::1:1 dev wg0
PostDown = ip -6 neighbor del proxy 2a01:aaaa:bbbb:cc21::1:2 dev wg0
ListenPort = 51820
PrivateKey = THE_SERVER_PRIVATE_KEY
[Peer]
PublicKey = PEER_1_PUBLIC_KEY
AllowedIPs = 172.16.0.2/32, 2a01:aaaa:bbbb:cc21::1:1/128
[Peer]
PublicKey = PEER_2_PUBLIC_KEY
AllowedIPs = 172.16.0.3/32, 2a01:aaaa:bbbb:cc21::1:2/128
[Interface]
Address = 172.16.0.2/32, 2a01:aaaa:bbbb:cc21::1:1/128
DNS = 192.168.1.254
ListenPort = 51820
PrivateKey = PEER_1_PRIVATE_KEY
[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = MY_PUBLIC_FREEBOX_IPV4:VPN_PORT
PublicKey = THE_SERVER_PUBLIC_KEY
Je suis un débutant de l'IPv6, et j'essaie d'interpréter ce qui se passe:
- Si mon téléphone est sur l'Internet public, lorsqu'il communique avec Desktop, le trafic arrive bien jusqu'à la Freebox, qui le relaie sur le sous-réseau qu'elle gère et donc vers Desktop. Et quand le trafic repart (ex: réponse à un ping), la Freebox sait vers où le renvoyer
- Si mon téléphone est sur l'Internet public, lorsqu'il communique avec un client VPN, le trafic arrive bien jusqu'à la Freebox, qui le relaie sur le sous-réseau du VPN via mon odroid, qui le relaie vers le client VPN. Et quand le trafic repart, le trafic trouve son chemin jusqu'au téléphone
- Mais quand c'est un client VPN qui fait un ping vers Desktop, les packets ICMP6 (idem avec ssh), le client envoie à d’odroid, qui l’envoie à la Freebox, qui voit qu’il faut l’envoyer vers une machine Ethernet du réseau principal. Et quand le desktop répond, je suppose que ça passe par la Freebox, mais ça n’arrive pas ensuite à l’odroid. Sur mon desktop, je vois avec Wireshark que les paquets arrivent et que les réponses sont envoyées sur la liaison Wi-Fi. Mais sur l’odroid, avec tcpdump, je ne vois pas de réponse arriver.
- J’ai 2 hypothèses: soit la Freebox n’arrive pas à router depuis le réseau principal vers un réseau secondaire IPv6. Ou alors (plausible car je ne suis pas connaisseur) c’est moi qui ignore un concept d’IPv6 et de routage et donc qui ait mal configuré
Verriez-vous si j’ai loupé un concept basique dans ma config?
(en vrai, je vivrais très bien sans, c’est principalement pour expérimenter)
-
Tu dédie un /64 a ton réseau vpn donc a priori pas besoin de ndpproxy.
Retire déjà tout référence a NDPProxy et ip6tables (et ip -6) dans tes conf (sysctl et wg0.conf)
-
Merci, j'ai enlevé cela, et même si ça ne résout pas le problème, le comportement n'a pas changé et ça simplifie la conf.
-
apres y'a les regles de firewall a peut-etre conserver si celui ci est bloquant par défaut:
donc les 2 regles:
PostUp = ip6tables -A FORWARD -i wg0 -o %i -j ACCEPT;
PostUp = ip6tables -A FORWARD -i %i -j ACCEPT;
Quand tu parles de Desktop c'est une machine Windows ou Linux ?
cette machine arrive t'elle a ping 2a01:aaaa:bbbb:cc21::1 ?
En principe la freebox (qui est la passerelle par défaut) doit renvoyer un redirect sur l'ip lan (link-local) de l'odroid quand on veut joindre le réseau cc21::/64. Si ce n'est pas gerer par la freebox (visible via une capture des icmpv6) il faut dans ce cas que l'odroid annonce cette route sur le lan (mais pas en route par défaut). Pour ce faire il faut configurer un démon radvd dessus avec annonce d'AdvDefaultLifetime a 0.
un truc du genre pour /etc/radvd.conf
interface eth0 # ajuster a l'interface lan du odroid
{
AdvSendAdvert on; # la machine va annonce des routes
AdvDefaultLifetime 0; # important: indique que ce routeur n'est pas une gateway (route par défaut)
prefix 2001:aaaa:bbbb:cc21::/64 # annonce le prefix /64 utilisé pour wireguard
{
AdvOnLink off; # important : indique que les IP sur /64 ne sont pas forcement directement joignable sur l'interface
AdvAutonomous off; # important pour que les postes du LAN ne se configurent pas un IPv6 sur ce 64
};
};
il y a d'autres paramètres notamment pour le timing d'annonce (voir man radvd.conf). mais en théorie ce n'est pas necessaire si la Freebox envoi des "ICMPv6 redirects" quand on veut joindre ce /64.
-
Super, merci beaucoup! Je testerai ça je pense ce week-end (et j'en profiterai pour lire sur ce sujet). Dans mes captures, j'ai vu passer des paquets "redirect", mais ma mémoire est floue la dessus.
-
Pardon j'ai oublié de répondre, la machine desktop (en Wi-Fi) est du Linux. Le odroid est aussi du Linux.
-
En Wifi j'ai vu des cas ou les machines ignorent les icmp redirects pour raison de sécurité (notamment Windows sur les réseaux Wifi configurés en 'public').
Si ton desktop Linux ne change pas de réseau wifi et qu'il ignore les redirects tu peux éventuellement relaxer cela (net.ipv6.conf.all.accept_redirects ou y'a peut-etre une config dynamique via un network manager dispatcher script (nmcli par exemple) suivant la distribution Linux).
Mais faut être sur avant qu'il reçoit bien des redirects.
-
Désolé pour la réponse tardive. Depuis, j’ai lu sur des concepts de base (comment marche SLAAC, les différents messages ICMPv6).
Quand tu parles de Desktop c'est une machine Windows ou Linux ?
cette machine arrive t'elle a ping 2a01:aaaa:bbbb:cc21::1 ?
Non. (NB: les résultats suivants sont obtenus après avoir installé radvd, je n’ai pas réessayé sans)
Quand je fais un "ping6" depuis la machine desktop Linux vers le client VPN, cela ne "fonctionne pas". Avec Wireshark sur ce desktop, je vois:
- Le paquet ICMPv6 "ping request" qui part du desktop vers le `2a01:aaaa:bbbb:cc21::1`.
- Le desktop reçoit ensuite un ICMPv6 "redirect", qui vient d’une adresse "link local" qui n’est pas celle du la Freebox en tant que route IPv6, mais qui lui ressemble (dans `fe80::1234:xxxx:xxxx:5678`, les parties "1234" et "5678" seraient identiques). Wireshark me dit que la source du redirect est "FreeboxSas…". Dans le paquet, la valeur de "target" est l’adresse "link local" de mon odroid (que je n’ai pas mise dans radvd). La valeur "destination" est la destination de ping que j’ai demandée (l’adresse en `::1` ou bien en `::1:2` qui est un autre client VPN)
Et sur l’odroid, avec tcpdump, je ne vois rien arriver depuis desktop.
Mais si je fais un ping depuis le client VPN vers le desktop, alors je vois bien l’odroid relayer le ping qu’il reçoit sur l’interface VPN sur l’interface ethernet. Puis le desktop le reçoit, répond, puis reçoit un "redirect". Mais odroid ne voit jamais arriver la réponse de ping du desktop. Et le desktop n’envoie pas de message ICMPv6 sur l’adresse link-local donnée par le "redirect".
Bref, ça ne communique pas que dans le sens desktop -> préfixe-vpn.
J’ai noté que le desktop reçoit également des paquets "redirect", quand c’est le client VPN qui fait un ping vers lui,
Également, quand je fais un "rdisc6 wlp38s0" ("wlp38s0" est mon interface wi-fi sur le desktop), ça me renvoie 2 entrées: une pour le préfixe principale et associé à l’adresse "local-link" de la Freebox, l’autre pour le 2ème préfixe associé à l’adresse link-local de l’odroid.
Je continuerai mes investigations (de loisir) sûrement ce week-end. J’essaierai de comprendre comment marche le mécanisme de redirect (actuellement, je ne vois pas sur le desktop de "route" ou de "neighbour" ajouté dynamiquement pour mon préfixe VPN suite à un redirect), même en activant "accept_redirects" pour all ou l’interface wi-fi. Le ticket https://dev.freebox.fr/bugs/task/36624 (https://dev.freebox.fr/bugs/task/36624) de Free semble ressembler un peu (sauf que moi c’est l’inverse: le trafic "préfixe secondaire" vers "1er préfixe" n’a pas l’air de passer).