La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus Free => Discussion démarrée par: mrSnoopy le 11 novembre 2019 à 14:06:34
-
Je viens de m'apercevoir que l'interface de la freebox (mini4k 4.0.6 dans mon cas) ne propose pas la saisie d'une route statique, si l'on souhaite par exemple installer un routeur (sans NAT) derriere la box. Il ya t'il des solutions a ce probleme majeur ?? je ne comprend pas bien pourquoi une fonctionnalité aussi basique n'est pas presente dans une box qui propose bien d'autres services qui eux pour le coup ne sont pas essentiels comme le client / serveur vpn, partages windows, airmedia etc etc
Y a t'il quelque chose à faire ?
-
Euh, j'ai du mal à comprendre.
C'est complètement bancal d'utiliser une "route statique" alors qu'on peut faire du Bridge sur la Freebox.
-
J'utilise le bridge actuellement mais cette config n'est pas du tout bancal au contraire, cela permettrait d'utiliser le processeur de la box pour effectuer le NAT tout en protegant le reseau lan derriere via un firewall sur le routeur (je bloque tout en outbound par defaut, sauf quelques services et j'utilise squid) qui serait lui dechargé de la translation d'adresse et qui ne ferait que router et filtrer. Et ca permettrait aussi de contourner le bug du mode bridge qui me fait perdre la connection internet aleatoirement (probleme connu apparement); je pourrais aussi d'utiliser les autres port rj45 de la box pour certaines fonctionnalités.
-
Le mode bridge est déjà utilisé par moins d'1% des abonnés (source mbizon sur ce forum), alors implèmenter un autre mécanisme comme celui ci n'a aucune chance d'aboutir. Mieux vaut bypasser complètement la box si tu veux faire ce genre de choses.
-
Ca n'a rien a voir avec le mode bridge, puisqu'en l'occurence, la freebox reste en mode routeur, comme elle l'est par defaut...
Quand a bypasser la box, c'est pas faisable ou tres compliqué à faire, d'autant plus si l'on souhaite garder la telephonie et/ou la tv
c'est sur que de permettre aux utilisateur de lancer la commande ip route add ca doit etre vraiment compliquer pour les devs freebox, m'enfin j'aimerais bien en connaitre la raison
-
Si c'était si simple, ça se saurait ;)
Et ça a tout à voir avec le mode bridge, puisque les deux ont un usage similaire (sinon, IPv6 ça marche bien :) )
-
Hey !
« la Freebox utilise déjà la majorité des classe d'IP dites "privée" pour son routage interne. »
Source : https://dev.freebox.fr/bugs/task/3916
Merci internet :)
-
Hey !
« la Freebox utilise déjà la majorité des classe d'IP dites "privée" pour son routage interne. »
Source : https://dev.freebox.fr/bugs/task/3916
Merci internet :)
Désolé pour le déterrage de topic, mais après avoir fait le tour d'a peu près partout, vu que le sujet était fermé/réouvert sans cess sur le bugtracker, je tombe sur cette réponse. Ca veut dire quoi au juste ? c'est un troll des devs ? Je suis passé de SFR à Free, je ne veux pas sacrifier les outils gagnés avec la freebox (notamment le wireguard intégré et le wifi6) en la mettant en Bridge derrière mon vieux N600... Mais mon homelab a grandi et ma segmentation reseau se retrouve avec des besoins multiples de sortir sur le net. j'ai un switch chinois L2.5 (vendu L3 mais il ne gère pas le NAT) et me voila fort dépourvu
-
Désolé pour le déterrage de topic, mais après avoir fait le tour d'a peu près partout, vu que le sujet était fermé/réouvert sans cess sur le bugtracker, je tombe sur cette réponse. Ca veut dire quoi au juste ? c'est un troll des devs ? Je suis passé de SFR à Free, je ne veux pas sacrifier les outils gagnés avec la freebox (notamment le wireguard intégré et le wifi6) en la mettant en Bridge derrière mon vieux N600... Mais mon homelab a grandi et ma segmentation reseau se retrouve avec des besoins multiples de sortir sur le net. j'ai un switch chinois L2.5 (vendu L3 mais il ne gère pas le NAT) et me voila fort dépourvu
Que la freebox ne propose pas et ne proposera sans doute jamais de routage statique ipv4.
L'explication technique donnée est que la freebox ( et sans doute une partie du réseau historique free pour certaines fonctions ) utilisent déjà un grand nombre des réseaux privés RFC 1918.
C'est sans doute de moins en moins vrai avec la bascule progressive du réseau free en ipv6 natif, mais je doute qu'ils développent cela après 20 ans+ de freebox sans cette fonction de routage statique.
Un exemple, le player de la freebox v6 qui accède à la tv sur un vlan ipv4, et désormais sur les box modernes, c'est je crois du ipv6. Mais vu la diversité du parc de box adsl, v6, pop, ultra... la contrainte du réseau ipv4 privé dispo trop réduit est surement encore la sur une partie des anciennes box.
-
L'explication technique donnée est que la freebox ( et sans doute une partie du réseau historique free pour certaines fonctions ) utilisent déjà un grand nombre des réseaux privés RFC 1918
Explication erronée :
- Ce n'est pas grave si il y'a un overlap entre le réseau interne et un subnet d'interco
- il existe d'autres préfixes que ceux de la RFC1918
- on pourrait même utiliser le bloc de base en 192.168
La vraie raison est simple : ça ne sert à rien en IPv4 et le fonctionnement du mode bridge est grosso modo identique à une "route statique"
-
Après 20 ans d'attente, free l'a fait !
Mise à jour du Freebox Server (Revolution/Pop/Delta/Ultra) 4.10.1
La mise à jour est disponible depuis le 06 mai à 15h00. Pour en profiter, veuillez redémarrer le Freebox Server.
Nouveautés
Il est maintenant possible de configurer des routes statiques depuis freeboxos (FS#12869, FS#38922, FS#39957)
https://dev.freebox.fr/blog/?p=22462 (https://dev.freebox.fr/blog/?p=22462)
-
Une fonction qui manquait sur la freebox, meme pour une box grand public.
Mise à jour du Freebox Server (Revolution/Pop/Delta/Ultra) 4.10.1
La mise à jour est disponible depuis le 06 mai à 15h00. Pour en profiter, veuillez redémarrer le Freebox Server.
Nouveautés
Il est maintenant possible de configurer des routes statiques depuis freeboxos (FS#12869, FS#38922, FS#39957)
https://dev.freebox.fr/blog/?p=22462 (https://dev.freebox.fr/blog/?p=22462)
Je n'ai pas testé.
-
Quels sont les cas d'usage de cette fonctionnalité ? N'est-ce utile qu'aux utilisateurs en mode bridge ?
-
Très bon nouvelle , bravo free :)
-
Quels sont les cas d'usage de cette fonctionnalité ? N'est-ce utile qu'aux utilisateurs en mode bridge ?
Ça permet d'atteindre un autre LAN avec du routage sans NAT. Typiquement, si tu colle un autre routeur dans le LAN FB sans la mettre en bridge, pas besoin de mettre celui-ci en NAT côté WAN. Par ex 192.168.0.0/24 de la FB pourra atteindre 192.168.1.0/24 de manière directe et vice versa.
Cas d'utilisation chez moi :
-pouvoir joindre les machines d'un autre LAN via VPN
-2nd routeur avec WAN 4G relié à mon LAN principal
J'ai des tonnes de routes statiques, aussi bien en IPv4 qu'IPv6.
Exemple (LAN 4G vers LAN derrière VPN) : traceroute 192.168.2.1
traceroute to bt.adc.lan (192.168.2.1), 30 hops max, 60 byte packets
1 _gateway (192.168.9.1) 0.160 ms 0.148 ms 0.159 ms
2 rpi.lpa.lan (192.168.1.10) 2.708 ms 2.994 ms 3.255 ms
3 172.16.2.1 (172.16.2.1) 43.065 ms 43.493 ms 46.063 ms
4 192.168.2.1 (192.168.2.1) 50.192 ms 50.217 ms 53.153 ms
-
Quels sont les cas d'usage de cette fonctionnalité ? N'est-ce utile qu'aux utilisateurs en mode bridge ?
Non, c'est une fonction uniquement utile en mode routeur ( en bridge, c'est le routeur additionnel qui gère les routes).
Dans mon cas d'usage, 2 lans connecté par un vpn.
Le fait de rajouter des routes permet aux 2 lans de se parler. Dans mon cas, backup croisés entre les réseaux.
Coté freebox en mode routeur, je devais ajouter les routes statiques directement au niveau de chaque pcs du lan et ce nétait pas possible sur certains équipements (tv par ex). Désormais, on le fait une seule fois sur la box.
Je n'ai pas encore testé, mais on pourrait imaginer de connecter une smartv/player coté lan 1, pour lire des vidéos sur un nas de l'autre coté lan 2.
-
C'est assez limité (et ça le restera probablement à mon avis) en terme de routes :
10.0.0.0/8 : Reserved for internal use
172.16.0.0/12 : Reserved for internal use
192.168.27.0/24 : Reserved for VPN and guest WIFI addresses
On ne peut donc ajouter que du 192.168.x.x sauf .27 et impossible d'ajouter 192.168.0.0/16 non plus pour la même raison.
Le ticket du bugtracker pour ceux qui veulent suivre :
https://dev.freebox.fr/bugs/task/12869
-
Salut,
elle sait nater les adresses d'autres subnets que son lan ?
c'était vrai avec les adresses des vpn, mais c'est sa cuisine,
ça n'est pas forcément lié au routage.
Certains ont l'air de dire que oui en parlant de supprimer le double nat.
-
Je vois pas trop l'intérêt, mais c'est toujours cool d'avoir des nouvelles fonctions :)
-
Salut,
elle sait nater les adresses d'autres subnets que son lan ?
ça n'est pas forcément lié au routage.
Certains ont l'air de dire que oui en parlant de supprimer le double nat.
Si on tente d'ajouter une redirection de port vers une IP autre que le subnet de la Freebox ce n'est pas possible.
Ca ne résout pas tout mais ça permet effectivement de ne plus avoir le double NAT.
J'ai fait le test rapidement et sur l'interface du routeur qui est rattachée à la Freebox on voit bien les @IP/DNS des machines et non plus l'@IP du routeur.
Ceci étant, la restriction aux 192.168.x.x me contraint à laisser de toute façon le double NAT.
-
Je vois pas trop l'intérêt, mais c'est toujours cool d'avoir des nouvelles fonctions :)
l'intérêt c'est comme tous les routeurs: avoir plusieurs lan pour segmenter les domaines de broadcast/multicast.
Peu utilisé chez les clients domestiques pas trop geekés, c'est vrai.
-
Non...
La Freebox ne gère ni les VLAN, ni de multiples clients DHCP, donc tu n'as aucune segmentation supplémentaire avec cette fonction. Il faut toujours ajouter un autre routeur et le mode bridge suffit toujours pour ça :)
-
Qu'est ce que c'est ça ?
pas besoin de vlan, il y a 4 ports, moins sur la pop c'est vrai, et pas besoin de dhcp multilan, les adresses statiques, ça existe encore.
on parle de rajouter des un ou des routeurs là, qui puissent échanger entre leurs lan via la Freebox, pour avoir accès à internet en même temps.
-
Donc tu mets plusieurs routeurs, dans le même LAN et ensuite tu viens parler de segmentation ?
C'est curieux ma foi. Cette fonction ne semble définitivement n'être indispensable qu'à des gens qui font du réseau n'importe comment
-
C'est curieux ma foi. Cette fonction ne semble définitivement n'être indispensable qu'à des gens qui font du réseau n'importe comment
Je vois pas trop l'intérêt, mais c'est toujours cool d'avoir des nouvelles fonctions :)
Je ne l'aurais pas mieux dit. Depuis la disponibilité hier, j'ai beau chercher je ne vois pas, sauf pour des trucs très mal foutu...
à part peut-être le cas de figure du VPN, bien qu'en toute logique cela ne devrait pas être nécéssaire vu que la table de routage est au courant du traffic dans les 2 sens normalement :o
-
Ben oui, franchement, je dis pas ça en mode "j'ai raison et le monde a tort" mais j'ai beau me creuser la tête, je ne vois pas un seul cas d'usage qui ne relèverait pas d'un design bancal. A la rigueur le seul que je vois c'est de ne pas vouloir bridger la box tout en mettant derrière un routeur qu'on ne veut pas laisser NATer.
Mais je pense à ce sujet qu'il y'a une hallucination collective sur les effets délétères du double NAT qui ne pose en réalité aucun souci tant sur le plan du design que sur le plan des performances.
Bref, bridgez votre box, c'est mieux quand même :)
-
Donc tu mets plusieurs routeurs, dans le même LAN et ensuite tu viens parler de segmentation ?
C'est curieux ma foi. Cette fonction ne semble définitivement n'être indispensable qu'à des gens qui font du réseau n'importe comment
imagine 3 routeurs reliés à la freebox par leur wan, je veux faire communiquer leurs lans avec celui de la box sans forwarder ...
C'est vrai que leurs lan peuvent communiquer directement entre eux, mais le lan de la box ne peut pas parce qu'il n'a pas de route, et je ne parle pas des vpn qui arrivent sur la box, c'est basique, non ?
Encore heureusement qu'on avait le routage de sept /64 ipv6 par la délégation de préfixe.
Le bridge ne permet de mettre qu'un seul routeur sur le lan de la box, du moins en ipv4, en ipv6, je ne sais pas si Free va déléguer 3 préfixes directement.
-
Ben oui, franchement, je dis pas ça en mode "j'ai raison et le monde a tort" mais j'ai beau me creuser la tête, je ne vois pas un seul cas d'usage qui ne relèverait pas d'un design bancal. A la rigueur le seul que je vois c'est de ne pas vouloir bridger la box tout en mettant derrière un routeur qu'on ne veut pas laisser NATer.
Mais je pense à ce sujet qu'il y'a une hallucination collective sur les effets délétères du double NAT qui ne pose en réalité aucun souci tant sur le plan du design que sur le plan des performances.
Bref, bridgez votre box, c'est mieux quand même :)
Yes je pense que les gens en voyant la news pensaient qu'il était désormais possible faire des réseaux distincts derrière chaque interface (c'est ce que j'ai pensé en voyant routage, tout en buggant en imaginant les perfs sachant que c'est un switch), mais non en effet ce n'est juste l'ajout du route statique pour éviter le double NAT.
Et dans ce cas je suis d'accord autant balancer la Freebox en Bridge.
Ici deux lignes en Bridge avec un CCR2004-1G-12S+2XS et un UDM Pro RAS.
-
imagine 3 routeurs reliés à la freebox par leur wan
J'imagine pas le cas d'usage pratique à faire une telle cochonceté derrière une freebox, non.
-
J'imagine pas le cas d'usage pratique à faire une telle cochonceté derrière une freebox, non.
Derrière une FB ou un routeur dont on a le contrôle ?
Car c'est exactement ce que je fais chez moi. J'ai 5 LAN distincts et autant de routes statiques sur mon routeur principal. Je vois pas vraiment comment faire autrement. Me mettre à OSPF ?
-
Derrière une FB ou un routeur dont on a le contrôle ?
Car c'est exactement ce que je fais chez moi. J'ai 5 LAN distincts et autant de routes statiques sur mon routeur principal. Je vois pas vraiment comment faire autrement. Me mettre à OSPF ?
Faire 5 réseaux sur 5 interfaces distinctes avec le routeur ? Et gérer le filtrage avec le FW intégré au routeur.
-
Faire 5 réseaux sur 5 interfaces distinctes avec le routeur ? Et gérer le filtrage avec le FW intégré au routeur.
Toute la problématique des trucs qui se montent au fur et à mesure, sans règles strictes au départ, avec peut-être pas exactement la formation qu'il faudrait et enfin souvent avec des moyens volontairement (ou pas?) limités?
C'est une question, hein! Pas un jugement! ;)
-
Faire 5 réseaux sur 5 interfaces distinctes avec le routeur ? Et gérer le filtrage avec le FW intégré au routeur.
Les LAN ne sont pas tous locaux, j'en ai 3 distants. J'aurais pu presque tout centraliser effectivement, mais ça n'aurait pas empêché les routes statiques pour joindre les autres derrière le VPN. J'ai préféré déléguer à un autre routeur le VPN pour avoir le moins de choses possible à reconfigurer sur mon routeur principal en cas de pépin. Le second LAN local est aussi géré par ce même routeur. Est aussi venu se greffer récemment un 3ème routeur pour mon accès 4G (ça fait donc 6 LAN).
En gros ça fait :
192.168.1.0 ← LAN Principal
192.168.3.0 ← LAN 2
192.168.9.0 ← LAN 4G
↓
↓ VPN 172.16.2.0/24
↓
192.168.2.0
192.168.4.0
192.168.5.0
-
Ben oui, franchement, je dis pas ça en mode "j'ai raison et le monde a tort" mais j'ai beau me creuser la tête, je ne vois pas un seul cas d'usage qui ne relèverait pas d'un design bancal. A la rigueur le seul que je vois c'est de ne pas vouloir bridger la box tout en mettant derrière un routeur qu'on ne veut pas laisser NATer.
Pour ma part, un coté lan 1 avec une box en bridge et un openwrt qui héberge un serveur VPN.
De l'autre coté, un lan 2, une freebox4k en mode routeur ou je ne vais/peux pas imposer l'ajout d'un routeur.
Un petit nas qui héberge aussi le client VPN, et qui sert de passerelle pour ce lan 2 vers l'autre lan 1 à travers le VPN. Donc une route statique, m'aurait rendu service au lieu de le faire sur les postes clients.
Design bancal, sans doute oui en 2026, mais ca a été mis en place à une époque ou on n'avait pas le client/serveur vpn dans la box ( et je crois une freebox v5 à la place de la 4k).
-
J'imagine pas le cas d'usage pratique à faire une telle cochonceté derrière une freebox, non.
c'est sûr qu'il serait mieux d'avoir un gros routeur avec plusieurs LAN derrière la box en bridge, mais si on veut garder par exemple le wifi sur la box et qu'on a un switch L3 en routeur local, on doit garder la box en routeur, il y avait aussi les histoires de TV et téléphonie coupés en mode bridge, je ne sais pas si c'est toujours vrai, mais ça peut être un handicap sur une box domestique.
Bref, ces critiques sont dans le vide, une box est normalement un routeur et doit savoir router plusieurs réseaux externes, pas seulement son ou ses LAN.
Un routeur d'accès de base du commerce le ferait et pas une box ? c'est idiot,
n'importe quelle machine sait configurer des routes statiques et pas une box ?
-
c'est sûr qu'il serait mieux d'avoir un gros routeur avec plusieurs LAN derrière la box en bridge, mais si on veut garder par exemple le wifi sur la box et qu'on a un switch L3 en routeur local, on doit garder la box en routeur, il y avait aussi les histoires de TV et téléphonie coupés en mode bridge, je ne sais pas si c'est toujours vrai, mais ça peut être un handicap sur une box domestique.
Bref, ces critiques sont dans le vide, une box est normalement un routeur et doit savoir router plusieurs réseaux externes, pas seulement son ou ses LAN.
Un routeur d'accès de base du commerce le ferait et pas une box ? c'est idiot,
n'importe quelle machine sait configurer des routes statiques et pas une box ?
C'est moins vrai pour les players récents comme la Pop qui ont simplement besoin d'IPv6 mais effectivement il y avait certaines contraintes :
Les services UPnP A/V, UPnP IGD, proxy WOL, SeedBox et votre réseau Wi-Fi sont désactivés.
Vos Player TV ne sont plus accessibles sur le LAN (uniquement pour le FreeStore et le navigateur internet) et la TNT est inaccessible en multiposte.
Les services de découverte (mDNS) des partages macOS sont inopérants.
Le partage Windows du Server internet n'est plus accessible.
Pour ma part j'utilise la Freebox en mode routeur car j'ai 2 routeurs derrière (un à l'étage et un au RDJ, en actif/passif avec VIP et réplication des sessions, des baux DHCP...) et si je passe en bridge, je ne vois pas comment je peux gérer le second alors que l'IP publique est sur le premier ? Peut-être que je rate quelque chose ? Là je peux mettre à jour, redémarrer, etc. sans que personne ne se rende compte de quoique ce soit.
Ce qui m'embête plus c'est l'absence de spanning-tree, ça contraint à n'utiliser qu'un port de la Freebox. Si le switch (ou le câble DAC) sur lequel elle est connectée a un souci je perds complètement l'accès par la liaison FTTH. Ça continue certes à fonctionner par le backup 4G mais bon.
On peut se dire que c'est useless pour la maison (ce qui n'est sans doute pas complètement faux) mais ça permet aussi de toucher à des choses qu'on n'a pas forcément l'occasion de voir ailleurs.
-
C'est moins vrai pour les players récents comme la Pop qui ont simplement besoin d'IPv6 mais effectivement il y avait certaines contraintes :
Les services UPnP A/V, UPnP IGD, proxy WOL, SeedBox et votre réseau Wi-Fi sont désactivés.
Vos Player TV ne sont plus accessibles sur le LAN (uniquement pour le FreeStore et le navigateur internet) et la TNT est inaccessible en multiposte.
Les services de découverte (mDNS) des partages macOS sont inopérants.
Le partage Windows du Server internet n'est plus accessible.
Pour ma part j'utilise la Freebox en mode routeur car j'ai 2 routeurs derrière (un à l'étage et un au RDJ, en actif/passif avec VIP et réplication des sessions, des baux DHCP...) et si je passe en bridge, je ne vois pas comment je peux gérer le second alors que l'IP publique est sur le premier ? Peut-être que je rate quelque chose ? Là je peux mettre à jour, redémarrer, etc. sans que personne ne se rende compte de quoique ce soit.
Ce qui m'embête plus c'est l'absence de spanning-tree, ça contraint à n'utiliser qu'un port de la Freebox. Si le switch (ou le câble DAC) sur lequel elle est connectée a un souci je perds complètement l'accès par la liaison FTTH. Ça continue certes à fonctionner par le backup 4G mais bon.
On peut se dire que c'est useless pour la maison (ce qui n'est sans doute pas complètement faux) mais ça permet aussi de toucher à des choses qu'on n'a pas forcément l'occasion de voir ailleurs.
Clairement, avec la box en bridge, c'est un routeur relié à la box et lui seul, tout le reste, éventuellement d'autres routeurs est relié à ce premier.
-
Dans ma cas, je trouve utile de laisser le freebox geré la maison et la famille, et de mon coté je peu facilement acceder mon lab/playground depuis la wifi/vpn de la freebox.
(https://i.imgur.com/gBchjpf.png)
-
Clairement, avec la box en bridge, c'est un routeur relié à la box et lui seul, tout le reste, éventuellement d'autres routeurs est relié à ce premier.
C'est ce que j'ai, et je préfère 1000x gérer le routage (inter VLAN, point de terminaison VPN et 2 autres tunnels) avec mon routeur plutôt qu'avec la Freebox. Mais c'est valable pour tous les opérateurs, si on fait partie du public qui a besoin de routes statiques, à mon avis, on fait bien mieux d'utiliser son propre routeur et de mettre la Freebox en mode pont si chez Free.
-
C'est ce que j'ai, et je préfère 1000x gérer le routage (inter VLAN, point de terminaison VPN et 2 autres tunnels) avec mon routeur plutôt qu'avec la Freebox. Mais c'est valable pour tous les opérateurs, si on fait partie du public qui a besoin de routes statiques, à mon avis, on fait bien mieux d'utiliser son propre routeur et de mettre la Freebox en mode pont si chez Free.
Si tu n'as pas besoin du lan et du wifi de la box .
-
Le seul désavantage technique est un routage asymétrique avec potentiellement une dégradation des performances (routage CPU au lieu de l’accélération HW) dans le sens Ouest/Est.
Je m'explique: le LAN de la Freebox devient en plus d'un réseau d'accès un réseau d'interco pour le routeur secondaire.
Donc les machines qui sont sur le LAN Freebox qui tente de joindre une machine derrière le routeur secondaire vont envoyer leur traffic à la Freebox qui va peut être émettre un ICMP Redirect puis va envoyer le traffic au routeur secondaire qui va faire son travail.
Dans le sens retour, on saute l'étape Freebox.
Est-ce grave ?
Cela dépends fortement de l'hypothèse sur la perte de l'accel HW.
Si elle est incorrect alors c'est franchement trivial.
Sur le terrain, il existe un nombre impressionnant d'entreprise qui sont dans la même situation avec leur routeur MPLS.
Maintenant passons à la partie plus sociale du cadre domestique.
Je connais pas mal de {net/sys}admin qui n'ont pas envie de travailler une fois à la maison.
Si leur enfant a envie de faire joujou avec le réseau, ils n'ont pas forcement envie de devoir déployer un nouveau routeur Internet pour la maison et faire du NAT en interne serait dommage.
-
Le seul désavantage technique est un routage asymétrique avec potentiellement une dégradation des performances (routage CPU au lieu de l’accélération HW) dans le sens Ouest/Est.
Je m'explique: le LAN de la Freebox devient en plus d'un réseau d'accès un réseau d'interco pour le routeur secondaire.
Donc les machines qui sont sur le LAN Freebox qui tente de joindre une machine derrière le routeur secondaire vont envoyer leur traffic à la Freebox qui va peut être émettre un ICMP Redirect puis va envoyer le traffic au routeur secondaire qui va faire son travail.
Dans le sens retour, on saute l'étape Freebox.
Est-ce grave ?
Cela dépends fortement de l'hypothèse sur la perte de l'accel HW.
Si elle est incorrect alors c'est franchement trivial.
Sur le terrain, il existe un nombre impressionnant d'entreprise qui sont dans la même situation avec leur routeur MPLS.
Maintenant passons à la partie plus sociale du cadre domestique.
Je connais pas mal de {net/sys}admin qui n'ont pas envie de travailler une fois à la maison.
Si leur enfant a envie de faire joujou avec le réseau, ils n'ont pas forcement envie de devoir déployer un nouveau routeur Internet pour la maison et faire du NAT en interne serait dommage.
Tu parles d'un backup wan via un routeur externe relié à la fbx ?
ça n'était pas tellement le sujet, je pense et je doute que la fbx ait la capacité de le gérer de cette façon, il faudrait qu'elle soit informée d'un accès internet sur un autre routeur, je ne vois pas comment dans l'état actuel de mes connaissances de la fbx, ele le fait déjà difficilement en gérant le backup elle même, apparemment ...
-
Tu parles d'un backup wan via un routeur externe relié à la fbx ?
Non. Est-ce que tu peut m'expliquer ce qui t'a amener à penser à çà dans mon message ?
-
En parlant des ICMP redirect, y'a aussi le cas où ils sont bien émis mais visiblement ignorés par certaines machines, surtout les smartphones, heureusement que c'est pas là qu'on a besoin de débit.
-
L'ICMP redirect est une vulnérabilité potentielle, ce n'est pas étonnant et c'est préférable.
-
C'est vrai, j'y pensais plus.
Heureusement qu'il reste la possibilité de pousser des routes par DHCP, encore faut-il que ça soit présent dans le discover (et c'est toujours pas le cas d'android...). Ou en dernier recours à la main..
-
Non. Est-ce que tu peut m'expliquer ce qui t'a amener à penser à çà dans mon message ?
Les icmp redirect évidemment,
si la destination est sa route par défaut, elle route, si elle est informée d'une autre, par je ne sais quel moyen, elle indique l'autre passerelle.
si la destination est l'autre réseau local et qu'elle ne connait pas la route, il n'y a aucune raison qu'elle envoie un redirect, elle balance sur sa route par défaut, tout court.
Si elle connait la route (la passerelle en fait) de cette route statique, elle envoie à la passerelle indiquée, sans considérer si la source est locale ou pas.
ça fait une trame inutile sur le lan, d'accord, mais bon, toutes les machines ne connaissent qu'une passerelle par défaut généralement.
Typiquement les redirect ne sont utilisés que sur une erreur de masque dans un réseau et qu'une machine s'adresse à sa passerelle alors qu'elle devrait adresser la machine directement, ou en période de transition quand on divise un réseau en plusieurs sous réseaux.
-
Je vois toujours pas comment cela t'a amené à parler d'un routeur backup wan.
Pour revenir sur le sujet des ICMP redirect, il reste des machines qui l'accepte donc elles vont ajouter une route /32 vers la bonne passerelle.
Ce qui va "résoudre" l'asymétrie de routage au bout de quelques trames.
Quelqu'un a une FreeBox et un génerateur de paquet afin de tester si elle offload bien les flux vers les routes statiques ?
-
Je vois toujours pas comment cela t'a amené à parler d'un routeur backup wan.
Pour revenir sur le sujet des ICMP redirect, il reste des machines qui l'accepte donc elles vont ajouter une route /32 vers la bonne passerelle.
Ce qui va "résoudre" l'asymétrie de routage au bout de quelques trames.
Quelqu'un a une FreeBox et un génerateur de paquet afin de tester si elle offload bien les flux vers les routes statiques ?
oui, pardon,
en relisant ton message 41, je constate que j'avais lu de travers et imaginé un routage vers wan, alors que non, tu as raison, une route statique directe sur la source aurait été plus propre, mais du moment que la box route quand même, c'est le principal.
-
Je vois toujours pas comment cela t'a amené à parler d'un routeur backup wan.
Pour revenir sur le sujet des ICMP redirect, il reste des machines qui l'accepte donc elles vont ajouter une route /32 vers la bonne passerelle.
Ce qui va "résoudre" l'asymétrie de routage au bout de quelques trames.
Quelqu'un a une FreeBox et un génerateur de paquet afin de tester si elle offload bien les flux vers les routes statiques ?
Je ne suis pas sûr qu'on puisse vérifier ça simplement. Il faudrait pouvoir accéder à la Freebox pour pouvoir lancer des outils locaux et vérifier notamment la charge CPU.
J'ai fait le test de supprimer les règles de NAT du routeur derrière et ajouter la route statique sur la Freebox et j'obtiens un débit normal mais ça ne prouve pas grand chose :
iperf3 -c ping.online.net -p 5208 -P1 -t 15 -R
Connecting to host ping.online.net, port 5208
Reverse mode, remote host ping.online.net is sending
[ 5] local 192.168.10.2 port 34034 connected to 51.158.1.21 port 5208
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 706 MBytes 5.92 Gbits/sec
[ 5] 1.00-2.00 sec 855 MBytes 7.17 Gbits/sec
[ 5] 2.00-3.00 sec 844 MBytes 7.08 Gbits/sec
[ 5] 3.00-4.00 sec 826 MBytes 6.93 Gbits/sec
[ 5] 4.00-5.00 sec 851 MBytes 7.14 Gbits/sec
[ 5] 5.00-6.00 sec 838 MBytes 7.03 Gbits/sec
[ 5] 6.00-7.00 sec 876 MBytes 7.35 Gbits/sec
[ 5] 7.00-8.00 sec 839 MBytes 7.03 Gbits/sec
[ 5] 8.00-9.00 sec 832 MBytes 6.98 Gbits/sec
[ 5] 9.00-10.00 sec 824 MBytes 6.91 Gbits/sec
[ 5] 10.00-11.00 sec 644 MBytes 5.41 Gbits/sec
[ 5] 11.00-12.00 sec 835 MBytes 6.99 Gbits/sec
[ 5] 12.00-13.00 sec 824 MBytes 6.91 Gbits/sec
[ 5] 13.00-14.00 sec 864 MBytes 7.25 Gbits/sec
[ 5] 14.00-15.00 sec 835 MBytes 7.00 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-15.04 sec 12.1 GBytes 6.91 Gbits/sec 180258 sender
[ 5] 0.00-15.00 sec 12.0 GBytes 6.88 Gbits/sec receiver
Sur l'interface WAN du routeur on voit bien le hostname du client et non plus la passerelle :
12:15:11.780982 IP 51.158.1.21.5208 > xxxx.yyyy.lan.52096: Flags [.], seq 2190866521:2190876657, ack 38, win 8, options [nop,nop,TS val 904245968 ecr 2381116567], length 10136
12:15:11.781104 IP xxxx.yyyy.lan.52096 > 51.158.1.21.5208: Flags [R], seq 2759547502, win 0, length 0
Edit : avec le NAT actif :
iperf3 -c ping.online.net -p 5208 -P1 -t 15 -R
Connecting to host ping.online.net, port 5208
Reverse mode, remote host ping.online.net is sending
[ 5] local 192.168.10.2 port 39690 connected to 51.158.1.21 port 5208
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 777 MBytes 6.51 Gbits/sec
[ 5] 1.00-2.00 sec 836 MBytes 7.01 Gbits/sec
[ 5] 2.00-3.00 sec 839 MBytes 7.04 Gbits/sec
[ 5] 3.00-4.00 sec 818 MBytes 6.86 Gbits/sec
[ 5] 4.00-5.00 sec 834 MBytes 7.00 Gbits/sec
[ 5] 5.00-6.00 sec 834 MBytes 7.00 Gbits/sec
[ 5] 6.00-7.00 sec 827 MBytes 6.94 Gbits/sec
[ 5] 7.00-8.00 sec 828 MBytes 6.94 Gbits/sec
[ 5] 8.00-9.00 sec 779 MBytes 6.54 Gbits/sec
[ 5] 9.00-10.00 sec 813 MBytes 6.82 Gbits/sec
[ 5] 10.00-11.00 sec 645 MBytes 5.41 Gbits/sec
[ 5] 11.00-12.00 sec 830 MBytes 6.96 Gbits/sec
[ 5] 12.00-13.00 sec 825 MBytes 6.92 Gbits/sec
[ 5] 13.00-14.00 sec 833 MBytes 6.99 Gbits/sec
[ 5] 14.00-15.00 sec 818 MBytes 6.86 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-15.04 sec 11.9 GBytes 6.82 Gbits/sec 101126 sender
[ 5] 0.00-15.00 sec 11.9 GBytes 6.79 Gbits/sec receiver
12:18:56.656764 IP 192.168.200.254.39690 > 51.158.1.21.5208: Flags [.], ack 3271692817, win 21746, options [nop,nop,TS val 2381341465 ecr 904470846], length 0
12:18:56.656767 IP 51.158.1.21.5208 > 192.168.200.254.39690: Flags [P.], seq 3271692817:3271694265, ack 38, win 8, options [nop,nop,TS val 904470846 ecr 2381341445], length 1448
-
Ce qu'il faudrait aussi essayer c'est un test de débit en interne en bloquant les ICMP redirect. Dans la direction FB > routeur. Le client envoie tout à la FB qui redirige sur le routeur.
On verrait au moins si elle supporte les 2,5 Gbps si jamais c'est pas offload.
Y'a pas une genre de moniteur système pour voir la charge CPU ? Il me semblait pourtant avoir vu un truc ou je confonds avec la température...
-
Ce qu'il faudrait aussi essayer c'est un test de débit en interne en bloquant les ICMP redirect. Dans la direction FB > routeur. Le client envoie tout à la FB qui redirige sur le routeur.
On verrait au moins si elle supporte les 2,5 Gbps si jamais c'est pas offload.
Y'a pas une genre de moniteur système pour voir la charge CPU ? Il me semblait pourtant avoir vu un truc ou je confonds avec la température...
Je n'arrive pas franchement à voir comment on peut faire sans outil ni accès à la Freebox. Si t'as des idées je suis preneur.
Il faudrait un iperf3 ou du genre mais il n'y a pas.
J'ai désactivé le "send-redirects" sur mon routeur VyOS et refait un iperf3 depuis un client dont la route existe sur la fbx (client > routeur > fbx) mais j'ai toujours le même résultat (débit max).
Il n'y a pas de courbes CPU, uniquement température et débit.
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.04 sec 52.4 GBytes 7.50 Gbits/sec 522467 sender
[ 5] 0.00-60.00 sec 52.3 GBytes 7.49 Gbits/sec receiver
-
Je n'arrive pas franchement à voir comment on peut faire sans outil ni accès à la Freebox. Si t'as des idées je suis preneur.
Il faudrait un iperf3 ou du genre mais il n'y a pas.
On utilise pas la Freebox : un test iperf entre un client win/linux sur le subnet freebox, vers le subnet du routeur. Et le client côté FB bloque les ICMP redirect.
-
On utilise pas la Freebox : un test iperf entre un client win/linux sur le subnet freebox, vers le subnet du routeur. Et le client côté FB bloque les ICMP redirect.
Bon je pense avoir réussi après pas mal d'essais.
- VM Linux en 192.168.200.4 (subnet Freebox) avec la Freebox en gateway et send|accept_redirect à 0.
- VM Linux en 192.168.10.5 (subnet local, route ajoutée sur la Freebox).
J'ai fait pas mal de tests et je voyais bien sur les ports de switches les flux iperf3 entre les switches, les Proxmox, le routeur mais pas sur la Freebox ce qui indiquait que cela ne transitait pas par elle.
J'ai fini par réussir (sans doute un redirect non bloqué initialement) et là je vois bien le port de la Freebox (côté switch).
(https://i.ibb.co/CKyJHGJR/Sw-Fbx-Vyos.jpg)
J'obtiens quasi 8 Gbps :
iperf3 -c 192.168.200.4 -R
Connecting to host 192.168.200.4, port 5201
Reverse mode, remote host 192.168.200.4 is sending
[ 5] local 192.168.10.5 port 32934 connected to 192.168.200.4 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 884 MBytes 7.41 Gbits/sec
[ 5] 1.00-2.00 sec 908 MBytes 7.61 Gbits/sec
[ 5] 2.00-3.00 sec 890 MBytes 7.47 Gbits/sec
[ 5] 3.00-4.00 sec 880 MBytes 7.38 Gbits/sec
[ 5] 4.00-5.00 sec 892 MBytes 7.49 Gbits/sec
[ 5] 5.00-6.00 sec 890 MBytes 7.46 Gbits/sec
[ 5] 6.00-7.00 sec 891 MBytes 7.47 Gbits/sec
[ 5] 7.00-8.00 sec 886 MBytes 7.43 Gbits/sec
[ 5] 8.00-9.00 sec 893 MBytes 7.50 Gbits/sec
[ 5] 9.00-10.00 sec 878 MBytes 7.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 8.69 GBytes 7.46 Gbits/sec 2154 sender
[ 5] 0.00-10.00 sec 8.68 GBytes 7.46 Gbits/sec receiver
Si je teste sans passer par la Freebox on voit que j'ai plus de débit :
iperf3 -c 172.16.5.2 -R
Connecting to host 172.16.5.2, port 5201
Reverse mode, remote host 172.16.5.2 is sending
[ 5] local 192.168.10.5 port 55192 connected to 172.16.5.2 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 1.05 GBytes 9.05 Gbits/sec
[ 5] 1.00-2.00 sec 1.08 GBytes 9.30 Gbits/sec
[ 5] 2.00-3.00 sec 1.07 GBytes 9.22 Gbits/sec
[ 5] 3.00-4.00 sec 1.06 GBytes 9.15 Gbits/sec
[ 5] 4.00-5.00 sec 1.08 GBytes 9.31 Gbits/sec
[ 5] 5.00-6.00 sec 1.05 GBytes 9.04 Gbits/sec
[ 5] 6.00-7.00 sec 1.07 GBytes 9.17 Gbits/sec
[ 5] 7.00-8.00 sec 1.08 GBytes 9.29 Gbits/sec
[ 5] 8.00-9.00 sec 1.07 GBytes 9.17 Gbits/sec
[ 5] 9.00-10.00 sec 1.08 GBytes 9.31 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 10.7 GBytes 9.21 Gbits/sec 209 sender
[ 5] 0.00-10.00 sec 10.7 GBytes 9.20 Gbits/sec receiver
Est-ce qu'on peut vraiment conclure ?
Pas sûr en fait : soit la Freebox gère bien l'offload soit son CPU est suffisant pour supporter 8 Gbits/s sans firewalling etc. ?
On voit bien que le CPU "chauffe" quand ça transite par la Freebox :
(https://i.ibb.co/mVqcxhKH/Temp-Cpu-Fbx.jpg)
-
Si ça offload pas, c'est impressionnant en tout cas.
Après quand on voit que Qualcomm annonce 16 Gbps sur la fiche produit (même ça mesure pas la même chose), y'a plutôt intérêt à ce que ça marche !
-
Si ça offload pas, c'est impressionnant en tout cas.
Après quand on voit que Qualcomm annonce 16 Gbps sur la fiche produit (même ça mesure pas la même chose), y'a plutôt intérêt à ce que ça marche !
J'ai une Delta, pas une Ultra.
Je ne crois pas que ce soit du Qualcomm dessus (Marvell ?).
A mon avis il y a de l'offload car je ne suis pas sûr que son CPU qui date de 2017 ou 2018 soit capable de gérer du 8 Gbps "si facilement".
-
Oui la delta c'est du Marvell. Et c'est même bien plus que le Qualcomm, puisque ils annoncent 24 Gbps !
Après, vu que l'accélérateur est aussi intégré difficile de savoir lequel travaille sans graph CPU.
-
Ah ouais impressionnant !
J'ai posé la question sur le bugtracker. Pas sûr qu'on obtienne une réponse mais on verra :).
-
C'est assez limité (et ça le restera probablement à mon avis) en terme de routes :
10.0.0.0/8 : Reserved for internal use
172.16.0.0/12 : Reserved for internal use
192.168.27.0/24 : Reserved for VPN and guest WIFI addresses
On ne peut donc ajouter que du 192.168.x.x sauf .27 et impossible d'ajouter 192.168.0.0/16 non plus pour la même raison.
Le ticket du bugtracker pour ceux qui veulent suivre :
https://dev.freebox.fr/bugs/task/12869
Salut,
la limitation sur les réseaux RFC 1918 a été levée, au moins en partie avec le firmware 4.11.1 .
Cdlt
-
Salut,
la limitation sur les réseaux RFC 1918 a été levée, au moins en partie avec le firmware 4.11.1 .
Cdlt
Tout à fait, ça fonctionne nickel pour ma part.
-
Salut,
la limitation sur les réseaux RFC 1918 a été levée, au moins en partie avec le firmware 4.11.1 .
Cdlt
Salut,
on sait quelles plages ne sont pas utilisables, si l'ancienne liste n'a plus cours ?
je suppose que celle affectée d'office aux vpn (192.168.27.0/24) n'est pas utilisable.
Quoique, ça devrait être l'inverse: la box devrait choisir ses adresses vpn en fonction des plages connues en lan, pas imposer les siennes, voire même encore mieux le client les choisir lui même.
-
Salut,
on sait quelles plages ne sont pas utilisables, si l'ancienne liste n'a plus cours ?
je suppose que celle affectée d'office aux vpn (192.168.27.0/24) n'est pas utilisable.
Quoique, ça devrait être l'inverse: la box devrait choisir ses adresses vpn en fonction des plages connues en lan, pas imposer les siennes, voire même encore mieux le client les choisir lui même.
Hello,
D'après la doc de l'API, il ne reste que celles-ci :
127.0.0.0/8 Loopback network
169.254.0.0/16 Link-local addresses
224.0.0.0/4 IANA: multicast
192.168.27.0/24 Used for VPN and guest WIFI addresses
Après tests, j'ai cru que ça fonctionnait bien et en fait non... Mes subnets en 172.x et 10.x n'arrivent pas à accéder à Internet.
Soit ce n'est pas si simple côté routage sur la Freebox soit il y a une restriction 192.168.x côté NAT/masquerade pour l'accès externe.
J'ai complété le ticket sur le bugtracker, plus qu'à espérer qu'il y ait une solution.
-
Bon bah réponse des dév : routage possible que sur le LAN.
Impossible donc de retirer le double NAT si on a des subnets 10.x ou 172.x (sauf à changer les @IP des équipements).
Fausse joie pour ma part :(.
-
Bon bah réponse des dév : routage possible que sur le LAN.
Impossible donc de retirer le double NAT si on a des subnets 10.x ou 172.x (sauf à changer les @IP des équipements).
Fausse joie pour ma part :(.
probablement que rajouter deux règles nat pour prendre en compte les sources 10.0.0.0/8 et 172.16.0.0/12, ça n'est pas sorcier, mais bon, encore une fois, ça pourrait être accessible à l'utilisateur la plage des sources à nater, tant que c'est des rfc1918.
Bon après, tout le bloc 192.168.0.0/16, ou presque, ça donne déjà pas mal d'air et il vaut mieux se focaliser sur ipv6, dont le routage pourrait être amélioré aussi dans la box dans le sens d'une délégation de préfixe plus large et automatique ainsi que l'intégration des ULA en local, avec pourquoi pas, du npt66 pour gérer du backup de liens.
-
Je ne sais pas si c'est ça que tu entends par "plus large" mais on devrait pouvoir déléguer au moins une partie de l'autre moitié du /60. On ne me fera pas gober que la Freebox a besoin de 8 /64 pour ses usages internes.
-
Je ne sais pas si c'est ça que tu entends par "plus large" mais on devrait pouvoir déléguer au moins une partie de l'autre moitié du /60. On ne me fera pas gober que la Freebox a besoin de 8 /64 pour ses usages internes.
surtout que d'autres FAI proposent des /56 sur leurs accès, mais complètement inutilisables sur les box, au mieux deux /64, il faut un routeur externe pour en profiter
Leurs huit /64 réservés pour la box, c'est un peu comme le coup de la plage 10.0.0.0/8 bloquée en usage interne, surtout que les FAI ont les 4 millions d'adresses privées du bloc 100.64.0.0/10 pour leurs usages propres, mais c'est vrai que sur des gros CGNAT, ça peut être vite consommé sur ce satané ipv4.