Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour

Malheureusement ce ticket vient s'ajouter à de nombreux tickets similaires déjà ouverts sur ce forum et non traités.

Je pense que ma réponse ne va pas vous convenir.

Si comme moi vous avez besoin d'ouvrir des ports en IPv6 et de faire du NAT par exemple entre des IPv6 locales sur la classe fc00/7 ou fd00/8 et un ou plusieurs pool public /64 V6 du /61 disponible pour le client sur la box, la seule solution aujourd'hui est de désactiver la case bloque tout nommée à tord "firewall Ipv6" et de déléguer la gestion des IPv6 à un routeur tiers derrière la box (un firewall de préférence)

Pour ça, configurez un Next-Hop à destination du routeur pour chaque bloc /64 que vous voudrez gérer avec le routeur (configurer les 8 subnets est en général une bonne idée), puis configurez le routeur en fonction.

Attention, si vous faites ça, vous devrez considérer le segment OSI-L2 local derrière la box comme du réseau publique (même pour l'IPv4) car physiquement ce segment portera un bout d'internet jusqu'à votre routeur (on ne peut pas aujourd'hui configurer les ports du switch de la box pour isoler les flux V4 / V6 sur des interfaces physiques différentes et de toute manière, le chipset qui gère le switch de la box est le même pour tous les ports).

De ce fait et pour exemple, chez moi le subnet IPv4 local (rfc1918) porté derrière la box jusqu'au firewall qui est le Next-Hop de tous les subnets IPv6 publiques est lui aussi considéré comme un subnet publique (en terme de sécurité) et à part les firewalls, aucune machine n'y est connecté et ce subnet rfc1918 est considéré et configuré sur les firewalls comme du WAN et non comme du LAN.
(cela n'a pas que des désavantages, sur l'interface physique du firewall 2 vlans supplémentaires sont portés 1 pour la DMZ externe et 1 pour la DMZ interne et les VM de la freebox delta ont chacune 1 ou plusieurs interfaces dans 1 de ces DMZ et ne sont pas connus au niveau OSI-L3 de la Freebox elle même)
À noter également que dans cette configuration, la freebox ne doit plus être la gateway d'aucune machine du LAN si ce n'est les firewalls/routeurs qui doivent assurer cette tâche.
Les fonctionnalités DHCP, WIFI, UPnP … de la freebox ne peuvent donc plus être utilisées et doivent être assurer par les firewalls/routeurs et des AP wifi différentes.
Le NAS peut contiunuer d'être utilisé de manière sécurisée en posant dessus des images LUKS que l'on monte comme des disques durs supplémentaires sur les machines derrière les firewalls / routers

Attention, une telle configuration nécessite :
1) du matériel pro (firewall, switchs manageables, contrôleur et AP wifi, onduleur…)
2) des compétences avancées en réseau
3) une bonne maîtrise de la sécurité des systèmes d'information
4) une bonne capacité à debug
5) d'être maintenue dans le temps

Autrement dit, ceux dont le réseau n'est pas le métier et qui ne manipulent pas correctement la stack IP du noyaux Linux ou encore dm-crypt (pour le NAS), cette configuration n'est pas pour vous.

Cordialement
nbanba

Bonjour,

Je viens tout juste d'arriver chez Free, qui est un l'opérateur le plus geek des 4, et je suis estomaqué de voir qu'il n'est pas possible de faire des ouvertures de port IPv6 que n'importe quelle livebox 4 ou bbox est capable de faire.

Donc dans un réseau domestique si on a le malheur de vouloir exposer le port d'un NAS ou d'un simple service HTTP en IPv6 et bien il faut désactiver le firewall et donc exposer toutes les machines, les éventuels services internes, les VMs etc.

C'est décevant et incompréhensible.

J'ai trouvé une alternative plus simple que déployer un routeur et tout le merdier qui va avec mais qui a ses limites.
Il est possible d'assigner directement une machine à un des préfixes secondaires (configurer une ip fixe + indiquer l'ip LL de la freebox comme gateway) et de ne cocher l'option du pare feu que pour le préfixe principal et pas les seconds.

Avantage : c'est simple

inconvénients :
- ça occupe un préfixe entier et il n'y en a que quelques uns
- tout le serveur est exposé et pas un ou plusieurs ports
- le routage ne nécessite aucune règle et pourtant sous Linux la stack ipv6 (noyau 6.10) a l'air d'ignorer les ICMP redirect (car la freebox qui est la gw par défaut répond aux machines du préfixe principal qu'il y a un chemin plus court vers le serveur ce qui est logique vu que tout est sur le même segment réseau, le comportement est donc normal) mais c'est facilement contournable en attribuant également une IP du préfixe principal au serveur, c'est du bricolage mais ça fonctionne

Un peu plus d'infos vis à vis du 3ème point évoqué en inconvénient, il est possible d'envoyer des router advertisement et donc que le serveur devienne administrativement un routeur et d'y rajouter la route vers sa propre IP (genre XX:XX:XX::XX/128) quoi. Ca fonctionne bien, tous les hôtes du segment sont au courant et il n'y a donc plus besoin de rajouter une seconde IP qui ferait parti du préfixe principal.
Par contre ça a (encore) un inconvénient : tous les hôtes du segment connaissent donc 2 routeurs et j'ai l'impression qu'en IPv6 un RA=route par défaut, il semble impossible d'indiquer que le routeur ne route pas vers le monde entier. Et donc quand les hôtes tentent de passer par lui pour aller sur internet, le serveur répond par un ICMP redirect.

Je ne sais pas si c'est tellement plus propre en fait.

Bonsoir

Pour rendre les choses + propres si vous maitrisez un peu 'iproute2', 'nftables' et éventuellement 'frr' sous Linux, vous pourriez créer plusieurs "network namespaces" sur votre serveur et en utiliser 1 comme routeur et les autres pour héberger vos services.

(root@server# ip netns add namespace0; ip netns add namespace1; …; ip netns exec namespaceN ip link add … ; ip netns exec namespaceN ip address add 10.0.x.y/vw dev <interface>; ip netns exec namespaceN ip route add … ; … ; …)

Pour router entre les namespaces et pour utiliser 1 namespace comme 'router principale' utilisez des interface "macvlan"
Si vous créez beaucoup de namespaces et besoin de routage dynamique, massif ou complexe, utilisez "frr" dans les différents namespaces pour monter des sessions BGP entre les namespaces ou pour communiquer les routes du namespaces principale qui vous sert de routeur pour les autres namespaces aux autres routeurs du réseau.

Si vous avez 1 switch mangeable et que vous mettez en trunk le port du switch sur lequel est connecté la freebox et laissez passer plusieurs vlans tagged sur ce port, idem sur les ports connectés au serveur, vous avez la possibilité de monter des interfaces vlans dans les namespaces afin de mettre certains namespaces dans certains vlans et aussi de faire porter tous les vlans dans 1 des namespaces que vous pourrez utiliser comme routeur/firewall pour distribuer et filtrer le trafic avec des outils comme "frr" et "nftables"

Avec iproute2 + nftables, les possibilités sont grandes…

Cordialement
nbanba

Bonjour nbanba,

L'usage des namespace et macvlan (= bridge simplifié) est effectivement possible mais finalement s'éloigne du besoin initial qui est d'avoir une IP d'un préfixe secondaire (rappel, il s'agit juste d'un serveur simple qui n'a pas vocation à être routeur) joignable par les autres hôtes ayant une IP du préfixe principal avec toutes les machines dans le même segment donc sans routage nécessaire.

Je continue à creuser car en principe ICMP redirect sert à ce genre de cas.

Florent

Bonjour

Je proposais les namespaces pour isoler le second router (le serveur transformé en router) et lui permettre de faire également du nat et du filtrage.

De mon côté j'utilise de "vrai routers physiques" pour porter les prefix secondaires (et primaires) puis je fais du nat entre les ipv6 publiques et des ipv6 locales sur fd00/8 portées par les machines derrière les router (firewall).

Dans votre cas, si vous changez le masque en /61 sur toutes les machines, vous devriez obtenir quelque chose de proche du schéma suivant : https://www.cisco.com/c/dam/en/us/support/docs/ios-nx-os-software/nx-os-software/213841-understanding-icmp-redirect-messages-00.png

Après comment la box se comporte, je n'ai pas testé.

Cependant avec la dualité publique ipv6 / private ipv4 sur le segment L2 présent derrière la freebox, perso je préfère tout envoyer vers 1 firewall (ipv4 privé+ v6 publique) et considérer ce segment comme du réseau publique même pour les ipv4 rfc1918 utilisées entre la box et les firewalls.

Cordialement
nbanba

Bonjour

Aussi pour définir la priorité des gateway quand plusieurs router sont présents sur le même segments, vous pouvez utiliser l option de radvd :

AdvDefaultPreference low|medium|high
The preference associated with the default router, as either "low", "medium", or "high".

Default: medium

Cordialement
nbanba

Bonjour Nbanba,

Justement le serveur qui est associé au 2ème préfixe ne doit pas agir comme un routeur (ce n'est pas sa vocation et il n'aurait aucun intérêt en tant que routeur si ce n'est s'annoncer lui même car il ne routera pas vers internet). Par ailleurs en le testant en mode routeur (avec les RA, ce que j'ai finalement désactivé) j'avais bien setté la preference à low (la freebox s'annonce à medium comme un peu tous les routeurs je pense) mais j'ai l'impression que c'est +/- pris en compte par les différentes stacks IPv6, en tout cas je n'ai pas vu de différence de métrique sous Linux et les différents hôtes voulaient passer par lui 1 fois sur 2.

En ce qui concerne le schéma, je suis plus proche de https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/xe-3s/ip6b-xe-3s-book/ip6-icmp-redir-xe.pdf page 3. Je viens de tester avec la stack IPv6 windows 10 et même réaction à savoir que le redirect est ignoré. Il doit y avoir une subtilité dans l'histoire que j'ignore.

https://datatracker.ietf.org/doc/html/rfc1122#section-3.2.2.2 indique : "A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-) net through which the Redirect arrived [INTRO:2, Appendix A], or if the source of the Redirect is not the current first-hop gateway for the specified destination (see Section 3.3.1)."
Ce qui est le cas car effectivement la nouvelle gateway (qui du coup n'est pas une gw/routeur mais un simple hôte ne s'annonçant pas comme routeur) se situe sur le préfixe 2 et non le 1, donc pas le même réseau. Et c'est là où je me rends compte que c'est très emmerdant de partager un même segment mais des réseaux différents, d'ailleurs j'en viens à me demander l'intérêt de la freebox d'envoyer un redirect puisque du coup il sera toujours droppé si j'interprète bien la RFC.

C'est pas très grave, je vais rester avec une IP secondaire appartenant au premier préfixe pour que les tous les hôtes puissent bénéficier des services du serveur et une IP principale appartenant au second préfixe pour l'ouverture sur internet.

C'est quand même dommage d'avoir tout ce capharnaüm juste parce qu'on ne peut pas ouvrir des ports dans le firewall IPv6, je n'en reviens toujours pas.

Bonjour

Merci pour votre retour, complet et documenté.

En effet, j'interprète la RFC comme vous le packets doit être discarded.

Cependant avez vous essayé de changer les mask ?
Un /60 est routé sur la connexion, la première ip du /60 est pour la freebox, la dernière pour le player et les 8 premiers prefixes /64 dispo pour le user.

En mettant /60 ou /61 les machines seront techniquement sur le même subnet (pas prefixe) et le redirect ne sera peut-être pas discarded ?
(Après il faut certainement forcer le mask à la main sur les machines utilisant SLAAC et les RA de la freebox qui ne sont pas tunable)
Si pas déjà fait à votre place je essayerai de voir si c'est faisable et si ça fonctionne.

D'autre part je vous l'accorde le fait de ne pas pouvoir simplement ouvrir de ports par ipv6 est à mes yeux un des manque majeurs de Free qui depuis quelques années est un opérateur grand public plus du tout geek justement à cause de ça !
En témoigne malheureusrment les nombreux tickets ouverts sur ce forum depuis plus de 10 ans a ce sujet et au sujet de la délégation reverse DNS ipv6 (et les/mes nombreuses réponses des utilisateurs eberlués par ces manquements complètement ignorés par l'operateur Free depuis plus de 10 ans…)

En 2024, les geek devraient venir faire un tour ici avant de souscrire chez Free (certaines livebox d'il y a 5 ans sont beaucoup + évoluées niveau réseau notamment en donnant l'accès à la table de routage v4/v6, en permettant d'ouvrir des ports en ipv4+6 (avec gestion de pool v6) et en permettant les interco vpn site-to-site, etc. soit la base pour un routeur)…
Bref, pour moi Free est super en retard niveau réseau ⇒ probablement un des moins geek des 4 opérateurs, le contraire est une légende en 2024.

Cordialement
nbanba

Effectivement ce serait possible mais l'objectif étant que tous les hôtes du préfixe principal n'aient pas à changer leur conf (car tout ne m'appartient pas et il y a des windows, des téléphones etc.), de plus ce n'est jamais une grande idée d'utiliser un préfixe autre que /64 en IPv6 à cause de SLAAC (mais pas uniquement je crois qu'il y a des trucs en multicast qui merdent quand on est pas en /64).

En tout cas merci pour vos éclaircissements et effectivement après quelques recherches j'ai retrouvé des posts similaires et, malheureusement, souvent anciens.

Je reste quand même fort étonné que Free propose des fonctionnalités avancées comme customiser le reverse IPv4 (la dernière fois que j'en ai eu besoin c'était pour la réputation d'IP en auto hébergement du mail, ça doit faire 15 ans), customiser le serveur DNS annoncé ou bien la délégation de préfixe (je me demande quelle infime part des abonnés s'en sert réellement à part quelques utilisateurs avertis comme nous) mais pas d'ouverture de ports, c'est lunaire.
IPv6 n'est pas prêt de devenir la stack principale avec des outils comme ça.

Par ailleurs nous sommes complètement tributaires des routeurs fournis par les opérateurs à cause de leurs technologies *PON custom contrairement à nos amis belges, quel gâchis quand même.

Florent

Bonjour

Je partage votre point de vue et la possibilité de faire tourner des vm dans les box est une bonne idée, mais si c'est pour y installer un "vrai router" par manquements de fonctionnalités élémentaires dans les freebox, ce n'est finalement pas terrible !

Aussi je partage le point sur le *PON… D'ailleurs connaissez-vous cet ONU ?
https://hack-gpon.org/xgs/ont-fs-XGS-ONU-25-20NI/ Il supporte normalement le 10G-EPON de Free, mais pour le moment je n'ai pas encore pu investir suffisamment de temps pour réussir à faire fonctionner la connexion direct dans un de mes fortigate ou de mes nexus 9k.

Par contre, j'ai délégué un max de fonctionnalités aux firewalls et je n'utilise plus que quelques pourcents de ma Freebox. Dommage mais pas le choix quand on a besoin d'exploiter ipv4+6 de la même manière et qu'on veut maîtriser le contenu des tables de routages des différents routers du réseau et les gérer de manière centrale avec iBGP.

Cordialement
nbanba

Le problème de placer un équipement en aval est de voir le débit étranglé par un seul port. En l’occurrence la freebox pop offre un 2.5gbps, ce qui ne représente plus que la moitié de la ligne qui est en 5gbps, c'est quand même dommage.
Il doit certainement exister des routeurs multi-wan afin de récupérer le débit des autres ports mais c'est encore du bricolage, par ailleurs je ne sais pas trop comment réagirait la freebox et de toute manière ça ne permet pas une véritable agrégation (mais peut être suffisant s'il y a plusieurs consommateurs et non un seul).

En ce qui concerne l'ONU je ne me prononcerai pas car je connais mal le L1 mais de ce que j'ai pu lire sur lafibre.info une partie de l'ONU serait déportée dans la box. Je ne sais pas s'il s'agit d'une délégation matérielle ou d'un simple chargement de conf mais dans tous les cas on est face à une boite noire. Par ailleurs il faut être sûr de pouvoir modifier son numéro de série ET de récupérer le S/N actuel car les opérateurs whitelist les ONUs.
Je me souviens avoir reçu un ONU pour une livebox et le type qui l'avait configuré s'était planté, j'ai donc dû contacter le support et leur filer le S/N pour qu'ils l'associent à mon abonnement.
Bref, personne ne semble avoir réussi pour l'instant.

En tout cas, tout cela me convint dans le choix d'aller plus tard chez ovh fibre qui propose un abonnement nu sans matériel imposé.

Florent

Bonjour

Justement avec cet onu ou un autre le but est de bypass totalement la box… Faire fonctionner la connexion sans la freebox et ses chipsets bcm55030 est donc le challenge (qui semble légal de surcroît au même titre que le mode bridge)

Le truc qui ralenti mes tests est Justement l'authentification et le spoofing de l'association de l ONU en lieu et place de la box. C'est d'ailleurs limite du hack…

Me concernant mon besoin domestique est d'avoir une connexion @ 10g brut la plus simple et "vierge de tout service" possible, distribuée par plusieurs peers/transitaires au travers desquels je puisse annoncer mes propres subnets publiques ipv4 + ipv6 (en portant la full-view v4/v6 localement et en annonçant de manière conditionnelle mes subnet sur tel peer ou tel autre transitaire).

En regardant le marché seul des opérateurs corporate ou alternatifs permettent de répondre à ce type de besoin ce qui est bien malheureux : c'est pourtant de l'internet ultra basique, no service et quand on achète une connexion internet, on devrait pouvoir avoir le service brut et la possibilité de créer son propre peering sans dépendre des infrastructures verrouillées des opérateurs grand public.

Bref, si j'arrive à monter le lien direct sur 1 de mes firewalls avec cet ONU, je posterai ici.

Cordialement
nbanba

Yep j'avais bien compris l'idée, et bien si ça fonctionne il y aura un certain nombre d'heureux à mon avis.

Sinon bonne nouvelle, j'ai finalement réussi à faire une configuration totalement propre ! En fait la piste d'agir en routeur pour s'auto-annoncer sans pour autant être un routeur par défaut était la bonne. L'astuce consiste à indiquer un lifetime à 0 (https://networkengineering.stackexchange.com/questions/76771/is-it-possible-to-do-slaac-with-route-advertisement-without-default-route), confirmé par https://datatracker.ietf.org/doc/html/rfc4861#section-4.2 : "The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields.".
→ Je me disais bien aussi, comment pouvait on envisager que tout routeur soit automatiquement une route par défaut.. Dire que j'ai vu ce paramètre plusieurs fois mais que je n'y ai pas prêté attention.

Florent

Bonjour

Super que vous ayez réussi !

Et merci d'avoir poster ici là solution qui servira probablement à d'autres (l'échange est intéressant)

Cordialement
nbanba