- État Nouveau
- Pourcentage achevé
- Type Anomalie
- Catégorie LAN
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Moyenne
- Priorité Très Basse
- Basée sur la version 3.1.7
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes 6
- Privée
Concerne le projet: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Ouverte par gcolpart - 21/11/2015
Ouverte par gcolpart - 21/11/2015
FS#19192 - Désactiver les "router advertisement" si Next Hop pour le premier subnet (IPv6)
Bonjour,
En cas d’utilisation d’IPv6 avec un routeur derrière la Freebox, on peut définir un Next Hop vers ce routeur.
Comme indiqué dans les paramètres de la Freebox, si l’on définit un Next Hop pour le 1er subnet, cela désactive son annonce :
Attention si vous configurez un Next Hop pour le premier subnet, il ne sera plus annoncé par la Freebox sur votre réseau
Néanmoins cela ne désactive pas les router advertisement ; voici un exemple de trames envoyées par la Freebox :
14:43:50.425321 IP6 fe80::f6ca:e5ff:fe40:XXXX > ip6-allnodes: ICMP6, router advertisement, length 32 0x0000: 3333 0000 0001 f4ca e540 XXXX 86dd 6000 0x0010: 0000 0020 3aff fe80 0000 0000 0000 f6ca 0x0020: e5ff fe40 7b61 ff02 0000 0000 0000 0000 0x0030: 0000 0000 0001 8600 7d73 4000 0708 0000 0x0040: 0000 0000 0000 0501 0000 0000 05c8 0101 0x0050: f4ca e540 7b61
Pourriez-vous désactiver également les router advertisement lorsque l’on configure un Next Hop sur le 1er subnet ?
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
J'avais le même problème, et je l'ai résolu en rajoutant l'option "AdvDefaultPreference high;" dans l'interface dans radvd.conf
Ca permet de prendre le pas sur l'annonce de la freebox
Ce problème semble toujours exister.
Par contre, j'ai enlevé le nexthop, cliqué sur appliquer, puis je l'ai remis, et ca a réglé le probleme (la freebox n'envoie plus de RA).
Mais cela va-t-il durer ?
Je suis curieux de voir si ca revient au prochain reboot... ou a la prochaine mise a jour...
Personnellement, je considère ce bug particulièrement critique, car quand c'est la Freebox qui annonce le préfixe, du coup il n'y a aucun filtrage possible. D'ou le fait que j'utilise un routeur/firewall externe, mais si on ne peut pas compter sur le fait que la Freebox cesse d'envoyer des RA quand on lui configure un nexthop pour le premier préfixe, c'est difficile de se sentir en sécurité...
Bonjour,
Le problème est toujours présent et persiste même en passant la priorité des ra du next hop à high
user@pc ~ $ rdisc6 eth0
Solicitation de ff02::2 (ff02::2) sur eth0...
Limite de saut (TTL) : 64 ( 0x40)
Conf. d’adresse par DHCP : Non
Autres réglages par DHCP : Non
Préférence du routeur : élevé
Durée de vie du routeur : 1800 (0x00000708) secondes
Temps d’atteinte : non indiqué (0x00000000)
Temps de retransmission : non indiqué (0x00000000)
Préfixe : 2a01:e34:ec88:4430::/64
Adresse source de lien : DE:AD:BE:EF:00:01
de fe80::dead:beaf
Limite de saut (TTL) : 64 ( 0x40)
Conf. d’adresse par DHCP : Non
Autres réglages par DHCP : Non
Préférence du routeur : moyen
Durée de vie du routeur : 1800 (0x00000708) secondes
Temps d’atteinte : non indiqué (0x00000000)
Temps de retransmission : non indiqué (0x00000000)
MTU : 1480 octets (valide)
Adresse source de lien : 00:24:D4:AE:AB:CD
de fe80::224:d4ff:feae:abcd
Une correction peut elle être envisagée lors d'une prochaine mise à jour du freebox server ?
En l'absence d'un Firewall configurable dans la box, ce bug est *franchement* problématique pour qui veut utiliser IPv6 tout en étant en sécurité.
On attend que quelqu'un scanne les prefixes IPv6 d'Iliad, récupere des choses personnelles d'abonnés Freebox et s'amuse a publier le resultat de ses recherches dans la presse pour régler le problème ?
Une solution rapide serait appréciable, ca fait deja longtemps que ça traine
Bonjour,
Très bien le nouveau firmware 3.5.1 pour la freebox server, de nouvelles fonctionnalité intéressantes, etc... mais pas de correction du bug en question... Est il au moins prévu de le résoudre un jour ? Si ce n'est pas le cas autant retirer tout simplement la possibilité d'ajouter des next hop sur le routage IPv6..
Problème toujours présent à ce jour, ce qui fait qu'en pratique on ne peut pas utiliser l'IPv6 avec le WiFi du Freebox Server si le next hop du subnet par défaut est redirigé vers un firewall – ce qui est indispensable dans la mesure où le Freebox server ne fournit par lui-même aucune possibilité de filtrer le trafic IPv6 entrant.
Avez-vous du neuf en 2019 ?
il faut malheureusement croire que non... tout du moins pour l'instant..
Quelqu'un peu indiquer si ce bug est également présent sur la Delta ? cela serait intéressant..
Par ailleurs, il faut noter que l'ensemble des Freebox Server n'ont pas de pare-feu (firewall) pour l'IPv6, donc aucune sécurité, je vous invite à voter ce bug également en urgence le bug de 2011 (le temps passe vite) : https://dev.freebox.fr/bugs/task/4110.
Et il faut aussi noter que selon les dernières informations, il ne sera bientôt plus possible de désactiver l'IPv6.
Autrement dit, sans solution de filtrage interne a la Freebox, et sans possibilité de désactiver les RA correctement, il va devenir compliqué de se protéger correctement...
j'ai l'impression que le problème a été corrigé avec le firmware 4.0.5 fraîchement sortit et qui rend impossible la désactivation d'ipv6.
Quelqu'un pour confirmer la résolution de ce bug vieux de presque 4 ans ? \o/
en ce qui concerne la possibilité de filtrer l'ipv6 en entrée sur la freebox c'est une autre affaire....
Attention, il n'y a pas de pare-feu (firewall) en IPv6.
A vous de voter urgemment pour ce bug historique: https://dev.freebox.fr/bugs/task/4110.
Des nouvelles à propos de ce ticket (Désactiver les "router advertisement" si Next Hop pour le premier subnet (IPv6)) ?
Demande de pare-feu manquant en IPv6 : https://dev.freebox.fr/bugs/task/4110
Demande de reverse DNS en IPv6 : https://dev.freebox.fr/bugs/task/12749
16 avril 2019 à 12:57, le changement : IPv6 par défaut.
→ https://dev.freebox.fr/blog/?p=5382
"Note additionnelle:
L'IPv6 est délivré aujourd'hui sous forme de tunnel (6RD) au dessus l'IPv4 (dit natif). En raison des évolutions internes de notre réseau, le système va progressivement être inversé, et c'est désormais l'IPv6 qui sera natif, et l'IPv4 délivré sous forme de tunnel.
Pour cette raison, désactiver l'IPv6 complètement sur une Freebox revient à potentiellement diminuer les performances réseaux, donc nous enlevons la possibilité de désactiver celui-ci globalement. Cette fonction avait été introduite il y a plus de 10 ans au même moment que la fonction IPv6 de la Freebox, afin d'éviter les problèmes d'interopérabilité avec les systèmes d'exploitation de l'époque.
Notez qu'il est toujours possible de désactiver l'IPv6 sur le périphérique lui-même."
Pour info : Attention : Pare-feu (firewall) pas complet du tout lorsqu'il est activé.
"Cochez cette case si vous souhaitez que votre Freebox filtre le traffic entrant inconnu."
Aucun paramétrage de réglages.
4 juin 2019 à 11:05 : Arrivée d'un firewall IPv6
→ https://dev.freebox.fr/blog/?p=5416
"Firewall IPv6. Désactivé par défaut, en fonction des retours il est possible qu’il soit activé par défaut dans le futur (seulement pour les abonnés qui n’auront pas modifié leur configuration)."
Nous sommes en août 2020, est-ce possible d'avoir des retours sur ce ticket, aucun changement ?
Bonjour,
J'ai le même bug en 2022 avec la Freebox Delta.
Configurer un nexthop pour la première /64 (la principale) désactive bien l'annonce du Préfix en lui-même, mais ne désactive pas les RA émis par la Freebox. (Le Préfix n'est plus dans le RA, mais le RA est émis quand même)
Cela est très problématique, car la Freebox n'annonce pas de Préfix, MAIS s'annonce en RA comme étant une "default gateway". Elle demande donc aux machines du segment réseau local de lui donner leurs paquets.
Cela est complètement incohérent avec le but initial de définir un nexthop pour la /64 principale.
Il s'agit donc clairement d'un bug.
Car définir un nexthop pour la /64 principale veut forcément dire qu'on va mettre en place nous-même nos propres RA sur une autre machine.
On ne souhaite donc pas qu'une compétition s'installe entre deux RA qui veulent chacun que les machines du segment local leur donnent leurs paquets.
Une solution temporaire (un hack) pour contourner côté client le temps que le bug soit fixé, est de définir la preference de son RA en HIGH (celui de la Freebox est en MEDIUM).
Mais, cela suppose que le soft network utilisé sur nos machines fonctionne bien. :D
systemd-networkd en version 251 a malheureusement un bug qui fait qu'il n'honore pas les différences de preference entre les RA, il ajoute toutes les routes en ECMP, et donc la machine va utiliser parfois l'une parfois l'autre, quand bien même j'ai forcé mon RA en HIGH, il rentre quand même en compétition avec le RA de Free.
systemd va bientôt fixer le bug de son côté.
Mais il reste Free…