DHCPv6 et Freebox

J’utilise une connexion IPv6 native fournie par ma freebox et j’ai voulu configurer un serveur DHCPv6 pour attribuer des paramètres réseaux additionnels à certains postes et permettre la mise à jour automatique du DNS pour y renseigner les noms et les adresses IPv6 des postes.

Problématique

La freebox s’annonce régulièrement (toutes les 5 minutes) sur le réseau IPv6 pour permettre la configuration stateless (certainement un démon radvd). Malheureusement les bits ManagedFlag et OtherConfigFlag (souvent appelée M et O) sont à 0 dans les trames d’annonce (cf RFC 2462). Cela signifie que le routeur préconise aux postes clients de ne pas utiliser de configuration statefull (donc pas de DHCPv6).

Firewall Linux avec pont logiciel pour traiter les flux IPv6

Firewall Linux avec pont logiciel pour traiter les flux IPv6

Dès l’arrivée du protocole IPv6 dans nos freebox j’ai opté pour une configuration de type broute sous Linux telle que proposée sur cet autre site. Je trouve cette solution élégante et elle permet d’utiliser les règles ip6table pour filtrer le trafic et faire office de puissant firewall IPv6. Les annonces de routeur de la freebox traversent donc le pont broute. J’ai pensé à plusieurs scénarios :

  • Bloquer les annonces routeur et installer mon propre démon radvd sur le firewall à destination de l’intranet. Pas terrible car je dois fournir en dur l’adresse de lien local de la freebox en tant que routeur par défaut. Plus rien ne marche si on change de freebox car cette adresse de lien local est calculée à partir de l’adresse mac de la freebox.
  • Forcer les clients à faire des requêtes DHCPv6. Pas toujours proposé dans les OS.
  • Modifier les annonces routeur de la freebox au vol pour forcer à 1 ces deux bits. C’est la solution retenue. Les machines qui ne savent pas faire de requêtes DHCPv6 continuent à s’auto configurer (Windows XP par exemple) tandis que celles qui savent utiliseront ce service (Windows Vista ou Seven par exemple).

Prérequis

Solution

L’opération consiste à créer une règle dans ip6tables qui va rediriger les paquets d’annonce de la freebox à travers un filtre de type NFQUEUE. Ce filtre modifie le paquet en forçant à 1 les deux bits en question. Le checksum du paquet est corrigé en conséquent et le paquet poursuit sa route dans l’intranet.

Création du pont broute. On considère qu’il n’y a qu’un seul routeur et que le risque de bouclage est nul : on peut désactiver le spanning tree protocol (STP).

brctl addbr br0
brctl stp br0 off

Association des interfaces physiques

brctl addif br0 eth0
brctl addif br0 eth1

Filtrage pour n’accepter que le trafic IPv6 dans le pont

ebtables -t broute -A BROUTING -p ! ipv6 -j DROP

Activation de l’interface sur le pont. En mode stateless, c’est maintenant que l’interface va recevoir son IPv6 en autoconfiguration.

ifconfig br0 up

Création d’une règle de filtrage des paquets d’annonce de routeur. Le numéro de file 134 est totalement arbitraire.

ip6tables -t filter -A FORWARD -p icmpv6 --icmpv6-type router-advertise -j NFQUEUE --queue-num 134

Lancer le démon de traitement des paquets transmis à la file 134. Tant que le démon ne sera pas lancé, aucune trame d’annonce routeur ne passera par le pont.

nfq_rad 134

Voila ! Il ne vous reste plus qu’à configurer un serveur DHCPv6 pour répondre aux requêtes des postes Windows Vista ou Seven présents dans votre réseau par exemple. Vous pouvez utiliser la solution DHCP v4.0 ou plus de l’ISC.

Téléchargements

Code source du démon de filtrage des annonces routeur : Télécharger “nfq_rad-1.0.tar.gz” nfq_rad-1.0.tar.gz – 10,40 Ko

Considérez ce code source comme étant un proof of concept. Il fonctionne avec les trames actuellement diffusées par la freebox mais la modification des trames est plutôt brutale, la position des bits à modifier dans la trame est codée en dur dans le code.

6 réflexions sur « DHCPv6 et Freebox »

  1. Billet très intéressant! Dans le cas d’un poste client Windows qui possède les 2 protocoles,(IPV4 et IPV6), quel est celui qui est prioritaire? Par exemple: je charge un site web, accessible à la fois sur IPV4/6, par quel chemin passent les trames?

    Meilleures salutations.

    • Dans le cas d’un client ayant la double connectivité, le resolveur (la partie de l’OS qui permet de traduire les noms d’hôte en adresse IP) doit récupérer en premier l’enregistrement AAAA (adresse IPv6) des DNS, s’il n’en trouve pas il recherche l’enregistrement A (Adresse IPv4). Donc, pour résumer, si un serveur est accessible en IPv6 et en IPv4 c’est le protocole IPv6 qui est préféré. Toutefois le résolveur n’est pas idiot, il ne cherchera l’adresse Ipv6 que si le programme qui l’a sollicité lui a explicitement dit qu’il est capable de comprendre les adresses IPv6.

  2. Bonjour
    est-ce que le tunnel est obligatoire pour accéder au site IPv6 relier par une infrastructeur réseau IPv4;
    quel mode de tunnel préféré entre statique et automatique.

    • Un tunnel est aujourd’hui nécessaire si votre fournisseur d’accès ne vous donne pas une connectivité IPv6 directe. Avec une freebox dégroupée, pas besoin de tunnel (un fait c’est la freebox qui gère le tunnel mais ça c’est free qui s’en occupe pour vous). Avec un autre type d’abonnement le tunnel est nécessaire. Les tunnels automatiques (6to4) ne peuvent fonctionner que si votre fournisseur d’accès dispose d’une tête de tunnel configurée pour 6to4 ce qui est rarement le cas. Ensuite peut se poser le problème du chemin de retour si la tête de tunnel ne renseigne pas correctement tous les préfixes qu’il sait router. Aujourd’hui la configuration la plus stable sera le tunnel statique, il en existe plusieurs avec leurs avantages et inconvénients. Certains demandent à utiliser une adresse IPv4 statique pour vous identifier, d’autre utilisent un système propriétaire d’authentification et permettent d’utiliser des adresses Ipv4 dynamiques. Vérifier qu’il existe une tête de tunnel pas trop éloignée de votre connexion car utiliser un tunnel ajoutera un temps de latence fixe qui dépend de la longueur du tunnel au réseau IPv6.

  3. INFORMATION IMPORTANTE: si comme moi vous utilisez un brigde pour filtrer votre trafic IPv6 la table FORWARD de ip6table ne fonctionne plus depuis le noyau linux 2.6.38.4
    En fouillance sur ce qui a été modifié entre la 2.6.38.3 et la 2.6.38.4 j’ai identifié le patch qui pose problème(commit référencé 5f1c356a3fadc0c19922d660da723b79bcc9aad7
    dans le GIT du kernel linux « bridge: Reset IPCB when entering IP stack on NF_FORWARD« ) :

    --- a/net/bridge/br_netfilter.c
    +++ b/net/bridge/br_netfilter.c
    @@ -741,6 +741,9 @@ static unsigned int br_nf_forward_ip(unsigned int hook, struct sk_buff *skb,
                    nf_bridge->mask |= BRNF_PKT_TYPE;
            }
     
    +       if (br_parse_ip_options(skb))
    +               return NF_DROP;
    +
            /* The physdev module checks on this */
            nf_bridge->mask |= BRNF_BRIDGED;
            nf_bridge->physoutdev = skb->dev;
    

    il suffit d’éditer le fichier net/bridge/br_netfilter.c des sources du kernel et de retirer les lignes qui apparaissent ci-dessus avec un + puis de recompiler le noyau.

    En espérant que cela sera corrigé dans les futures versions du noyau.

    A l’heure où j’écris ce commentaire, le noyau linux en est à la version 2.6.38.6 et le problème est y est toujours présent.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *