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

Bonjour ,

J’ai aussi un routeur et ça me manque terriblement les routes statiques sur la Freebox . Pourtant ça ne doit pas être bien compliqué à rajouter.

un vrai routeur en fait ! sauf erreur d'autres FAI le font déjà !!!

En fait je ne comprend pas que ce soit pas deja implémenter ...
Y'a sans doute une raison, et j'aimerai la connaitre, car sur beaucoup de forum, c'est une demande d'evolution récurrente..

Si une ame charitable pouvait eclairer ma lanterne ..

Bonjour,

Free était bien vu par les technophiles pour sa box et service en avance sur les autres. IP fixe, reverse DNS, etc...

Quand je vois que même orange avec sa LiveBox il y a la possibilité d'ajouter des routes statiques on se pose des questions. Merci de combler entre autre se retard. :)

Bonjour,

En effet c'est une fonctionnalité basique dont l'absence sur la box la plus performante du marche est plus qu’étonnante !
Alors, quand est ce que la possibilité de rajouter des routes statiques sera t'elle implémentée sur la box ?

Bonjour,

Je m'etonne de ne voir aucune réponse / mise à jour de quelqu'un de free, ce ticket est ouvert depuis le 13/07/2013 .. soit plus de 6 mois..

Il est vraiment dommage que cette fonctionnalité n'existe pas, et bien que mon cas soit assez restreint, la fonctionnalité en elle meme est demandé par bon nombre d'utilisateurs.

Pourquoi cela n'a t-il pas été implementer et aura t-on une réponse un jour ?

Merci !

Un routeur sans config de route statique n'est pas un routeur...

Bonjour,

Plus d'un an que le ticket est ouvert !

Dommage effectivement que cette fonctionnalité ne soit pas mise en place, surtout que le routage statique est la base dans un routeur, et qu'en plus on peut le faire en IPv6

Il faut peut-être insisté lourdement pour qu'ils se réveillent !

Merci.

Bonjour,
J'aurais aussi besoin de tels réglages pour chez moi.
Une petite réponse serait appréciée ;)
Merci !

+1
Rien depuis 2013... Pourtant ce n'est sûrement pas compliqué à ajouter. J'ajouterai également la possibilité d'ajouter le next-hop plus souple pour l'ipv6

Idem pour moi.

Quand on a deux "zones" chez soi il est préférable de poser un second routeur plutôt que de tirer N câbles entre les deux points.
Un routage statique serait le bienvenu!

+1
Bonne année 2017 (soit 4 année après l'ouverture de ce feature request) !

un petit parser pour éviter un éventuel conflit avec les routes et ip déjà en dure (ie 192.168.027.xxx) et une interface light pour ajouter des routes statiques...

peut-être dans la V7 ? ;)

Toujours pas de route statique en IPv4..... Quelle plaie, même les Livebox Pro le font.

Le plus terrible, c'est que je suis en ZMD, et que je perd 80% du débit en bridge. Si j'avais une route statique, je pourrais laisser la FBX en routeur...

+1
L'ajout de routes statiques me semble obligatoire de nos jour, car nous sommes de plus en plus à utiliser un second routeur en extension de la freebox soit pour des raisons d'architecture du logement ou autres... De plus les serveurs NAS fleurissent pour le stockage redondant de nos milliards de photos, videos et autres productions et documents numériques des plus important ; l'intérêt d'avoir l'ensemble de notre réseau sur un routeur perso est donc bien avéré !
Après avoir expérimenté une coupure d'accès de ma freebox pendant 3 semaines, freebox bloquée en cours de synchro et donc plus de routeur freebox, si j'avais eu tout ce petit monde sur la freebox je n'aurais pas pu accéder à mes données perso sur le NAS durant 3 semaines !! Et ça Free ne le remboursera pas !
Je suis donc de ceux qui réclament avec insistance l'ajout de routes statiques permettant de profiter pleinement des services offerts par la freebox en ROUTEUR dans une architecture informatique qui se démocratise depuis 2010 selon les premiers forum clamant déjà cette fonction.
Espérant une intégration rapide, cordialement.

Bonjour,

Un petit up plus de quatre ans après l'ouverture de ce ticket.

Est-ce que quelqu'un sait si les informations mises ici sont remontées chez free ou si ça part directement à la poubelle ?

C'est du routage de gueule !
4 ans plus tard, cette fonctionnalité n'est toujours pas et aucun retour de Free !!!
A quoi sertie bugtrack ?!

A mon tour de poster un gros UP !

Quand je vois le nombre de fonctionnalités avancées de ouf que la box intègre et qu'un truc aussi basique que l'ajout de routes statiques n'est pas implémenté (bien que demandé depuis des années !!!), ça me rend dingue.

Si je puis me permettre un commentaire, avoir une une interface de gestion des routes me semble apporter bien plus de valeur ajoutée qu'une interfaces qui affichent les courbes de trafique de chaque port RJ45 de la box... Sans parler de celle qui permet de redémarrer un freeplug à distance... Et de celle qui gère la luminosité de l'afficheur, c'est comment dire...

Aller, un petit effort sur la roadmap 2018 ?

UP!!!

Bonjour,

Bientôt 2020 !
C'est abusé, j'ai du mal à y croire !
Les Freebox, souvent au top de la technologie n'ont pas la possibilité de faire un routage statique ?
C'est une blague !

Le premier billet date de 2013, nous sommes en fin 2019 soit 6 ans d'attente !

C'est un énorme UP là !

C'est quand vous voulez...

Cela me changerai bien la vie d'avoir du routage static… C'est sûr M. tout le monde n'en a pas forcément besoin mais si on commence à faire de la domotic ou de la sécurité, on se plug pas direct derrière la box...

+1

+1

Waouh ! C'est incroyable que ce ticket soit toujours ouvert plus de 7 ans apres le 1er post et qu'aucune implementation de cette fonctionnalite n'ait ete realise Du grand foutage ou plus exactement routage de gueule !!! Quand a moi c'est mon 3 posts sur ce ticket Faut se rendre a l'evidence, cette fonctionnalite sera implemente uniquement le jour ou Free (Iliad) rachetera France Telecom, c'est a dire JAMAIS !!!

+1 c'est présent sur le plus basic des routeurs mais absent des Freebox

Je rejoint encore la demande, elle est importante aujourd'hui ! Pouvez-vous l'ajouter dans votre branche d'évolution :)

C'est quelque chose qui est demandé depuis la freebox révolution.
La possibilité d'ajouter des routes à la freebox, que ce soit statique ou dynamique, mais ça manque cruellement à ce routeur.
Car la en l'occurrence la box fait switch, elle fait modem, elle fait du NAT (nos IP privés sont translaté vers notre IP Public) mais elle ne fait pas de routage à proprement parler.
Techniquement, c'est un abus de langage de la part de Free de parler de routeur ici, et légalement ça doit pas être mieux.

c'est pourtant une fonctionnalité basique de routeur
pour gérer des sous réseaux privés et séparer les différents services, c'est une fonctionnalité indispensable

c'est une fonctionnalité attendue de longue date. sauf erreur de ma part la seule solution actuellement est de "double nater" routeur → lan fbx → ip pub

+1... Mon cas de figure :

Delta⇒routeur mikrotik⇒lan.

En ipv6 pas de problème, je peux faire communiquer les équipements reliés à la delta avec ceux derrière mon routeur (avec la délégation de préfixe en place je suppose).
Par contre en ipv4, évidemment la delta ne sait pas comment joindre le reseau derrière le routeur. Ou il faudrait que je leur change la passerelle pour la faire pointer vers le routeur, mais l'accès à Internet s'en retrouve compliqué...

Up !

+1 up .....

Up!
Cette fonctionnalité est un gros manque

Toujours rien depuis mon message d'octobre 2019...

Pour ceux qui ont la freebox delta avec la possibilité de monter des machines virtuelles depuis l'interface, vous pouvez router le trafic vers une vm et ajouter une route statique à la table de routage de l'instance de VM. Dans mon cas, une VM sous debian sur la freebox et un routeur turris omnia derrière ma freebox.

route add -net 192.168.9.0 netmask 255.255.255.0 gw 192.168.1.11 dev eth0

192.168.5.0: Réseau de mon autre routeur
255.255.255.0: Masque de ce réseau
192.168.1.11: IP Attribuée à mon routeur par la freebox
eth0: Interface physique de la machine virtuelle reliée à la freebox

C'est pas exactement ce qu'on aimerait faire mais ça peut permettre de contourner le soucis pour certaines applications, si ça peut en aider quelques uns...

Edit: 192.168.5.0 à remplacer par 192.168.9.0 pour le réseau de mon autre routeur

Pas pu tester avec un VM car j'ai qu'une V6.
Cette fonctionnalité me manque énormément.
Je ne comprend pas Free de ne pas répondre et de ne pas mettre cette fonctionnalité.
Qu'ils ne veulent pas le faire OK mais au moins de le dire, mais bon on dirait qu'ils le dirons pas sous peines de voir xxxx Abonnées partir
Mais il est clair que si cela n'est pas mis en place je n'hésiterais pas à partir.

Pas pu tester avec un VM car j'ai qu'une V6.
Cette fonctionnalité me manque énormément.
Je ne comprend pas Free de ne pas répondre et de ne pas mettre cette fonctionnalité.
Qu'ils ne veulent pas le faire OK mais au moins de le dire, mais bon on dirait qu'ils le dirons pas sous peines de voir xxxx Abonnées partir
Mais il est clair que si cela n'est pas mis en place je n'hésiterais pas à partir.

Je suis d’accord avec les autres commentaires.
Sur un routeur digne de ce nom, on doit être capable de :
- définir des routes statiques en plus des routes dynamiques
- pouvoir déclarer des VLAN sur les liaisons externes privées
- faire du relais DHCP entre différentes interfaces
- définir des règles de NAT en ipv4 (SBAT, DBAT, ou MASQUERADE)

Oula, on va se calmer… Autant je veux bien que les routes statiques soient quelque chose de basique et le fait qu’on puisse pas les changer malgré qu’on puisse faire du next hop en IPv6 est stupide, autant ça reste un routeur grand public, les VLAN et autres règles de routage avancé n’ont rien à y faire et vont juste rajouter des “pannes” supplémentaires inutiles pour le pélos qui va farfouiller sans connaître.

+1 avec Albirew

@rjose : Sinon une VM de type gateway pour vos infra derrière elle et un :
iptable -t nat -A POSTROUTING -j MASQUERADE -o “votre interface vers FreeBox”
Celle qui contient IP “FreeBOX”

A+

+1 sa ouvrirais plein de possibilités

+1 quand vous voulez

+1

+1 UP ! pas plus compliqué que de router les segments IPv6 supplémentaires !limitez le au RFC1918 si vous voulez mais please faites quelque chose !

Up ! Up !

Up

Merci @lduboin pour la réouverture de cet important ticket !

Pourriez-vous regarder ces tickets là s'il vous plaît ?

Liés au routage en très grande partie :

Routage statique Freebox ↔ routeur interne
- https://dev.freebox.fr/bugs/task/37545

[Tous les Freebox Server] Règles sortantes (LAN → WAN)… - https://dev.freebox.fr/bugs/task/25271

Routage VPN impossible
- https://dev.freebox.fr/bugs/task/20993

Router le trafic des machines du LAN sur le VPN
- https://dev.freebox.fr/bugs/task/14610

Réseaux Wi-Fi uniquement dans un tunnel VPN (sans accès au réseau local / Freebox)
- https://dev.freebox.fr/bugs/task/31667

Personnalisation/Délégation reverse IPv6
- https://dev.freebox.fr/bugs/task/12749

Désactiver les "router advertisement" si Next Hop pour le premier subnet (IPv6)
- https://dev.freebox.fr/bugs/task/19192

Agrégation 4G + xDSL propager NAT ou session
- https://dev.freebox.fr/bugs/task/24728

OpenVPN bridgé : routage du trafic Internet (hors réseau local freebox)
- https://dev.freebox.fr/bugs/task/28385

réél routage ou maintiens de toutes les fonctionnalités en bridge
- https://dev.freebox.fr/bugs/task/28679

Redirection de port non affecté à la bonne IP si deux carte réseaux sont connectés à la freebox
- https://dev.freebox.fr/bugs/task/32921

Vlan Support + Routage
- https://dev.freebox.fr/bugs/task/38699

impossibilité d'utiliser le LAN si la connexion Internet n'est pas établie
- https://dev.freebox.fr/bugs/task/39805

Communication Impossible entre 2 freeBox
- https://dev.freebox.fr/bugs/task/39890

Route statique personnalisé V4
- https://dev.freebox.fr/bugs/task/39957

Mise en place d'un accès pour ajout de route
- https://dev.freebox.fr/bugs/task/40184

Routage avancé (tables de routage, VLAN)
- https://dev.freebox.fr/bugs/task/40212

Pb de routage VPN IKEv2 IPv4
- https://dev.freebox.fr/bugs/task/40223

Routeurs avec sous-réseaux et VLAN
- https://dev.freebox.fr/bugs/task/40532

Routage dns
- https://dev.freebox.fr/bugs/task/39547

VLAN sur Freebox Ultra
- https://dev.freebox.fr/bugs/task/39060

Route Static
- https://dev.freebox.fr/bugs/task/38922

Mode Bridge non fonctionnel
- https://dev.freebox.fr/bugs/task/34313

Incohérence entre les adresses MAC des répéteurs et déconnexions
- https://dev.freebox.fr/bugs/task/34245

Serveur VPN
- https://dev.freebox.fr/bugs/task/36677

IPv6 : en effet, je veux un /60
- https://dev.freebox.fr/bugs/task/39327

Ouverture des ports sur IPv6 (avec pare-feu activé)
- https://dev.freebox.fr/bugs/task/39597

IPv6 - UPnP IGD Pinholes / Ouverture de ports
- https://dev.freebox.fr/bugs/task/37515

Filtrage firewall IPv6 et délégation /64
- https://dev.freebox.fr/bugs/task/38438

Ajout de fonctionnalités pour la configuration IPV6
- https://dev.freebox.fr/bugs/task/36087

Bonjour

En + du routage static il faudrait pouvoir monter les ports du switch en L3 et supporter au moins 1 protocole de routage dynamique type BGP pour annoncer / apprendre des tables de routage complète (v4/v6)

Un ptit `frr` ça fait tout le boulot et c'est vraiment pas compliqué à déployer.

Et comme pour Wireguard, le user aurait juste à pousser son fichier de configuration, par exemple pour une ultra avec backup 4G:

Fichier global:

 
! Main FRR configuration
frr version 9.0
frr defaults traditional
hostname Freebox-XXXXXX
log syslog informational
service integrated-vtysh-config
 
! Include modular configs
include /etc/frr/conf.d/
line vty
!

Fichier user:

! Zebra and interface configuration
ip forwarding
 
! LACP bond0
interface mgig1
 no shutdown
!
interface mgig2
 no shutdown
!
interface bond0
 ip address 192.168.10.1/24
 ipv6 address fd00:10::1/64
 lacp rate fast
 lacp mode active
 bond slaves mgig1 mgig2
!
! Free mgig ports
interface mgig3
 ip address 192.168.30.1/24
 ipv6 address fd00:30::1/64
 no shutdown
!
interface mgig4
 ip address 192.168.40.1/24
 ipv6 address fd00:40::1/64
 no shutdown
!
interface 10g-lan
 ip address 192.168.20.1/24
 ipv6 address fd00:20::1/64
!
! WANs
interface 10g-wan
 ip address 82.64.x.y/32
 ipv6 address 2a01:e0a:xxxx:xxa0::2/128
!
interface lte0
 ip address 82.65.a.b/32
 ipv6 address 2a01:e0a:xxxx:xxa0::3/128
!
 
! BGP configuration
router bgp 65001
 bgp router-id 1.1.1.1
 
 ! eBGP neighbors (IPv4 + IPv6)
 neighbor 82.64.x.z remote-as 12322
 neighbor 82.64.x.z description ISP-10G
 neighbor 82.64.x.z update-source 10g-wan
 
 neighbor 2a01:e00::1 remote-as 12322
 neighbor 2a01:e00::1 description ISP-10G-IPv6
 neighbor 2a01:e00::1 update-source 10g-wan
 
 neighbor 82.65.a.c remote-as 12322
 neighbor 82.65.a.c description ISP-LTE
 neighbor 82.65.a.c update-source lte0
 neighbor 2a01:e10::1 remote-as 12322
 neighbor 2a01:e10::1 description ISP-LTE-IPv6
 neighbor 2a01:e10::1 update-source lte0
 
 ! iBGP neighbor (To local router)
 neighbor 192.168.10.254 remote-as 65001
 neighbor 192.168.10.254 description FortiGate-iBGP
 neighbor fd00:10::254 remote-as 65001
 neighbor fd00:10::254 description FortiGate-iBGP-IPv6
 
 ! IPv4 address-family
 address-family ipv4 unicast
  network 192.168.10.0/24
  network 192.168.20.0/24
  network 192.168.30.0/24
  network 192.168.40.0/24
  neighbor 82.64.x.z activate
  neighbor 82.65.a.c activate
  neighbor 192.168.10.254 activate
  redistribute connected
 exit-address-family
 
 ! IPv6 address-family
 address-family ipv6 unicast
  ! Only advertise the first /64
  network 2a01:e0a:xxxx:xxa0::/64
  network fd00:10::/64
  network fd00:20::/64
  network fd00:30::/64
  network fd00:40::/64
  neighbor 2a01:e00::1 activate
  neighbor 2a01:e10::1 activate
  neighbor fd00:10::254 activate
  redistribute connected
 exit-address-family

En gros c'est vraiment pas compliqué…
Merci

Cordialement
nbanba

J'ajoute mon vote.

Je ne suis pas sur les réseaux asociaux mais, quelqu'un qui s'y trouve (avec un brin de visibilité) ne pourrait-il pas apostropher XN à l'occasion d'une prochaine publication en mode auto-satisfaction ?

Parce qu'à ce niveau de silence radio, ce n'est plus du routage de gueule, c'est de l'irrespect.

Bonjour,
Je soutiens également cette demande de pouvoir déclarer des routes statiques (ce qui est possible chez la concurrence …)
Cordialement,
Chorons

Bonjour,

Merci pour l'implémentation du routage statique avec le firmware 4.10.1, c'est une évolution très attendue.

Cependant, après test sur Freebox Ultra, la fonctionnalité semble limitée aux destinations en 192.168.x.x uniquement. Les préfixes appartenant aux plages RFC1918 172.16.0.0/12 et 10.0.0.0/8 sont rejetés avec l'erreur « Route IPv4 invalide », même lorsque la passerelle est connue et joignable.

Tests effectués :
- Préfixe 172.16.1.0/24, passerelle 192.168.1.253 : rejeté (« Route IPv4 invalide »)
- Préfixe 10.1.1.252/30, passerelle 192.168.1.253 : rejeté (« Route IPv4 invalide »)
- Préfixe 192.168.45.0/24, passerelle 192.168.1.253 : accepté sans erreur

La passerelle 192.168.1.253 est bien présente dans la table ARP de la Freebox (apparaît dans le sélecteur d'hôtes connus lors de la configuration d'une route).

La restriction aux seuls préfixes 192.168.x.x rend la fonctionnalité inutilisable pour les architectures utilisant les plages 172.16.x.x ou 10.x.x.x derrière un routeur/pare-feu interne, ce qui représente probablement la majorité des cas d'usage justifiant cette feature.

Pourriez-vous étendre la validation des préfixes à l'ensemble des plages RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) ?

Cordialement

Bonjour

@lduboin

Déjà un grand MERCI !

Par contre, ok pour le premier /16 sur 172.16.0.0/12 mais SVP pas tout le 10.0.0.0/8 sans quoi ça risque d'être peu utilisable ce qui serait sincèrement dommage…

Une exclusion dynamique du /32 utilisé par la box dans le 10/8 pourrait peut-être être suffisante (voir en plus la GW /32 du subnet), mais pas tout le 10/8 SVP

idée que j'utilise régulièrement dans ce cas:
- Isolation du LAN dans une VRF supportant la full rfc1918 ou dans un 'network namespace' (netns)
- Isolation du WAN dans une autre VRF apprenant full_table!rfc1918
- création d'un LEAK entre VRF / netns pour sortir depuis le LAN vers la VRF internet et réciproquement (sur les netns / vrf une 'veth pair' fait très bien le job avec un /30 pour les IP dans chaque VRF)
- 0.0.0.0/0 du LAN ayant pour gateway l'IP de la 'veth' de la VRF / netns WAN

Merci d'avance
Cordialement

Bonjour,

Merci beaucoup pour cette intégration qui était devenue inespérée.

J'espère également, de toute force, que l'interdiction de destinations "utilisées par la box" va être gérée plus finement.

Hello,

Good je peux enfin me débarrasser du double nat :)

Par contre je rencontre un bug d'affichage sur firefox et chrome : quelle que soit la taille de fenêtre "Routage" la liste déroulante peux afficher uniquement deux lignes.

De plus il serait intéressant de pouvoir configurer le 192.168.0.0/16 et de ne pas être obligé de mettre tout les /24 que l'on a…

@lduboin

Merci pour la réponse rapide.

Cependant, bloquer l'intégralité de 172.16.0.0/12 et 10.0.0.0/8 au motif que la box utilise certaines adresses dans ces plages est une approche disproportionnée. Ces deux plages représentent plusieurs millions d'adresses RFC1918 légitimes dont la quasi-totalité n'entre pas en conflit avec les adresses internes de la box.

La solution standard dans ce cas est une vérification de collision au moment de l'ajout de la route : si le préfixe configuré chevauche une adresse effectivement utilisée par la box, on refuse la route. Si ce n'est pas le cas, on l'accepte. Bloquer des plages entières est un raccourci d'implémentation, pas une contrainte technique.

Comme le suggère nbanba dans ses commentaires, une exclusion dynamique du /32 spécifique utilisé par la box suffirait à éviter tout conflit.

Espérons ne pas devoir attendre 13 ans de plus pour avoir le support complet des plages RFC1918.

Cordialement

Hello,

Effectivement, c'est une évolution bienvenue mais c'est malheureusement plutôt limitatif en termes 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

Ayant des 10.0.x.x/24 et 172.16.x.x/24 ce n'est que partiellement intéressant dans mon cas.
Moins gênant pour moi mais cela empêche aussi l'ajout du 192.168.0.0/16 à cause du réseau VPN/WiFi guest (il faudrait vérifier que ces services soient inactifs pour l'autoriser mais sans doute plus contraignant en termes de développement).

Pour le bug de @lnicolas83, on ne voit en effet que 2 lignes mais il y a un "ascenseur" sur la droite pour voir plus bas : est-ce possible d'avoir quelques lignes de plus ?

Il y a également un autre "bug" : quand on ajoute un subnet interdit, on a le message mais il est quand-même ajouté à la liste et empêche tout ajout tant qu'on a pas refermé la fenêtre "routage" ou édité/supprimé ce subnet.

Merci :)

Salut,

Elle marche toujours chez vous la DMZ ? Quand je l'active, je fais appliquer, mais ça reste vide :/

@lduboin,

Avant les critiques acerbes, les "Ah bah enfin !!!" etc… ;)
Merci !!!!
C'est vrai que ce fil discussion tournait à l'humour noir, et c'est d'autant plus satisfaisant de voir apparaître cette correction (oui, pour les gens d'ici, c'est une correction, pas une évolution) après tout ce temps :)

Bon, alors oui, en effet, il se trouve que j'ai pour ma part besoin de plages en 10.0.0.0 *ET* 172.16.0.0 :D

Donc prochain firmware ?

Bonjour et merci pour cette fonctionalité utile, je citerais entre autre que ça facilite la possibilité de rajouter un petit pare-feu sans prétention exclusivement pour isoler des objects connectés de la vie courante devenus un peu trop bavards.

Je remarque que des redirection ICMP sont envoyées, ce qui à mon avis une bonne chose, mais sont-elles désactivables ?

En effet on a été un peu trop précautionneux concernant ces préfixes.

Cette précaution pourrait être levée pour résoudre #20190 aussi ?

Vous pouvez consulter la documentation pour connaître la liste de tous les préfixes interdits.

La documentation sur https://dev.freebox.fr/sdk/os/ dite « documentation complète de l'API FreeboxOS » ne mentionne pas la méthode Route mais la documentation de l'API de Freebox OS disponible sur l'interface web de la FreeBOX la mentionne. Quelle est la documentation de référence ?

Merci beaucoup pour la réactivité et la transparence sur le sujet. C'est rassurant de voir qu'un retour technique constructif est pris en compte aussi rapidement.

13 ans pour la feature, 21 heures pour corriger l'implémentation, respect pour la seconde partie. :)

Impatient de tester la 4.10.2 !

Cordialement

@Squallqt: Si la plage 10.0.0.0/8 est exclue, c'est la grosse douche froide. La fonctionnalité réseau basique et essentielle, attendue depuis le début, arrive enfin et on apprend, juste après, qu'elle est castrée et ne pourra pas couvrir ce qu'on en attend en premier sur le réseau local !

Les bras m'en tombent

@stratic : bonne nouvelle, lduboin a déjà répondu plus haut (commentaire #193383). Le fix couvre bien les deux plages, sa réponse vise explicitement les préfixes mentionnés dans le thread, dont le 10.0.0.0/8. Ce sera disponible dans la 4.10.2.

On peut dire Merci Free. :)

Je faisait partie des utilisateurs bêta sur la 4.9.x et il semble que mon update soit bloqué. Le passage en 4.10.x ne se fait pas chez moi, malgré 2 reboots je suis toujours en 4.9.19-r2 sur Fbx Ultra

Très bonne nouvelle les routes statiques, merci.

Et du NAT sur plusieurs plages d'IP c'est pas possible ? Dire à la Freebox tel port externe va vers tel port interne sur ce réseau ou cet autre réseau (selon les routes statiques paramétrées)

A mon avis beaucoup de geeks aimeraient éviter un double NAT :)

@lduboin : un grand merci pour toutes les modifications / corrections.

Bonjour,
J'utilise le serveur VPN WIREGUARD pour connecter à distance un routeur GL-AXT1800 à mon réseau domestique.
Ce routeur me permet de disposer d'une connexion à distance à mon réseau domestique pour tous les appareils qui sont connectés à ce routeur, sans nécessiter de configuration client Wireguard au niveau de chacun d'eux.
Ce routeur distant me permet de disposer en outre d'un tunnel séparé pour tout le trafic internet, distinct du tunnel domestique (j'ai pour cela supprimé l'adresse 0.0.0.0/0 du fichier de configuration WireGuard initialement créé par le configurateur de la Freebox pour ce client GL-AXT1800)
Ce client utilise l'adresse 192.168.27.72 sur le Freebox serveur
Le réseau distant du GL-AXT1800 a pour passerelle 192.168.8.1 et distribue les adresses 192.168.8.0/24
Quand le routeur GL-AXT1800 est connecté au serveur VPN de la Freebox, le ping fonctionne sans problème depuis n'importe quel appareil sur le réseau 192.168.8.0/24 vers n'importe quelle adresse du réseau domestique 192.168.x.0/24 (et aussi 192.168.27.72), mais l'inverse échoue systématiquement. Je souhaitais pouvoir accéder depuis mon réseau domestique à des équipements domotiques connectés à mon réseau distant et cela s'avérait donc impossible.
Avec la dernière mise à jour, je pensais pouvoir résoudre le problème en ajoutant une route 192.168.8.0/24 avec comme passerelle 192.168.27.72, (l'adresse du client VPN du GL-AXT1800), mais alors que la passerelle avec l'adresse du VPN du GL-AXT1800 est bien proposée dans la liste, l'ajout de la route n'est pas accepté…La route est cependant ajoutée dans la liste des routes quand on finit par annuler le dialogue de configuration, mais reste inopérante et les ping depuis 192.168.94.0/24 vers 192.168.8.0/24 ne fonctionne toujours pas…

Mon objectif est-il irréaliste et/ou des évolutions/correctifs sont-ils à attendre ?

Et du NAT sur plusieurs plages d'IP c'est pas possible ? Dire à la Freebox tel port externe va vers tel port interne sur ce réseau ou cet autre réseau (selon les routes statiques paramétrées)

Comme sur le schéma "Routing" sur cette page : https://medium.com/@gmanual/double-nat-explained-and-possible-solutions-8b41b6c651bd

@lduboin

C'est très dommage quand le client VPN est un routeur distant.

L'alternative pour moi sera d'utiliser un routeur TP-LINK BE35 existant sur mon réseau domestique et disposant d'un serveur VPN autorisant cette fonctionnalité site à site. Une redirection de port sur le freebox server me permettra d'envoyer la demande de connexion VPN du routeur distant vers le serveur VPN de ce routeur domestique (en lieu et place du serveur VPN freebox) qui lui autorisera la route inverse domestique vers distant.

Vraiment dommage que cela ne soit pas possible avec le serveur VPN de la Freebox…

Bonjour

@lduboin

> Et du NAT sur plusieurs plages d'IP c'est pas possible ? Dire à la Freebox tel port externe va vers tel port interne sur ce réseau ou cet autre réseau (selon les routes statiques paramétrées)
> @jonatl08 Ça pourrait en effet être pratique. Je vous invite à ouvrir un autre ticket.

Pour ma part je pense qu'il faut en premier permettre de monter les ports du switch en L3 sur des subnets distincts, et pouvoir créer des sous interfaces (vlan) sous les ports physiques du switch.

Il ne s'agit pas de réinventer la roue, le feu ou la relativité restreinte, mais d'utiliser en interne dans la Freebox une technologie offrant ces fonctionnalités comme par exemple: FRR (Free Range Routing : https://frrouting.org/) dont l'implémentation permettrait aux utilisateurs de "tout faire", à savoir :
- monter les ports en L3,
- créer des interfaces vlan,
- configurer des agrégations de ports (LACP)
- implémenter un protocole de routage dynamique sur le réseau local (iBGP)
- utiliser une syntaxe 'cisco like' pour la gestion des fonctionnalités réseaux
- … bref, tout ce qui manque aujourd'hui sur les Freebox…

L'utilisateur avancé intéressé par ces features n'aurait qu'a poster son fichier de configuration, comme c'est déjà le cas pour la configuration des VPN WireGuard dans la freebox.

Pour exemple cf ce poste: https://dev.freebox.fr/bugs/task/12869#comment192203

En vous remerciant d'avance
Cordialement
nbanba

Je pose la question à tout hasard, si un dev est OK pour apporter la réponse :).

Est-ce que la Freebox (Delta dans mon cas) gère l'offload vers les routes statiques ?

J'ai fait le test entre une VM dans le subnet Freebox et une VM dans un subnet local (route ajoutée sur la FBX), avec ICMP redirect bloqué et j'obtiens quasiment 8 Gbps.

Cela laisserait donc penser qu'il y a bien de l'offload ou alors que le CPU est suffisamment costaud pour gérer du 8 Gbps même si ça semble moins évident.

Auquel cas ça permettrait bien de pouvoir supprimer le NAT entre le routeur et la Freebox une fois la 4.10.2 déployée (et tous les subnets accessibles).

D'ailleurs si vous souhaitez déployer une pré-version pour vérifier que cela n'apporte pas de bugs autres je suis partant pour tester.

Merci :)

@lduboin : je viens de passer en 4.10.2 mais j'ai toujours les mêmes bugs :

- Tableau routage toujours sur 2 lignes.
- Lors de l'ajout d'un 172.16 ou d'un 10.0 j'ai le message "Erreur lors de la configuration des routes statiques : Route IPv4 invalide" (mais elles n'apparaissent plus dans le tableau à présent).

Le bug d'affichage de version est lui bien corrigé.

Merci.

En fait si : "mais elles n'apparaissent plus dans le tableau à présent".

https://i.ibb.co/6chLJHyv/Fbx01.jpg https://i.ibb.co/vx2gBTDc/Fbx02.jpg

J'ai tenté de supprimer complètement la table de routage mais pas de changement.

@lduboin

Tests effectués sur Freebox Ultra en version 4.10.2.

Le correctif annoncé au commentaire #193383 ne semble pas effectif ou reste incomplet. La plage RFC1918 172.16.0.0/12 ainsi que le bloc 10.0.0.0/8 restent entièrement bloqués par l'API backend.

Résultats obtenus :

  Autorisés :

      172.15.1.0/24 (Hors RFC1918) : accepté

      172.32.1.0/24 (Hors RFC1918) : accepté

  Refusés (« Route IPv4 invalide ») :

      172.16.1.0/24

      172.17.1.0/24

      172.31.1.0/24

      10.1.1.0/24

La logique de validation actuelle continue de bloquer des supernets RFC1918 entiers au lieu de se limiter aux seules adresses strictement réservées par le système de la box (comme le /32 ou le subnet de la gateway). L'impossibilité d'utiliser ces plages privées standards paralyse l'intérêt de la fonctionnalité pour les architectures réseau locales un peu avancées (derrière un firewall/routeur dédié).

Pouvez-vous vérifier si le correctif backend a bien été poussé dans cette release 4.10.2 ?

Cordialement.

@lduboin : ah OK, on y croyait à fond.
On patiente du coup :).

Merci du retour.

@lduboin : au top !
Ca fonctionne nickel de mon côté. Goodbye les règles de NAT sur le routeur.

Merci !!

@lduboin : je retire ce que j'ai dit : ça fonctionne pour l'ajout dans l'interface mais ça ne fonctionne pas derrière sur les équipements en 10.x et 172.x.

J'ai ajouté 172.16.1.0/24, 172.16.5.0/24 et 10.0.150.0/24 sans soucis mais je n'arrive pas à avoir accès à Internet sur ces subnets (je ne vois pas le retour).

Je me demande s'il n'y aurait pas une règle de NAT/Masquerade ou du genre sur la Freebox qui restreindrait à 192.168.x.x. (car c'est OK sur 192.168.10.0/24 et 192.168.100.0/24) ?

J'ai laissé un ping continu vers 212.27.48.10 depuis 172.16.5.1, 172.16.1.101 et 10.0.50.101 si ça peut vous aider à analyser.

23:40:49.007864 IP 172.16.1.101 > 212.27.48.10: ICMP echo request, id 1, seq 111, length 40
23:40:49.082289 IP 10.0.50.101 > 212.27.48.10: ICMP echo request, id 677, seq 112, length 64
23:40:49.381587 IP 172.16.5.1 > 212.27.48.10: ICMP echo request, id 18, seq 363, length 64
23:40:50.106210 IP 10.0.50.101 > 212.27.48.10: ICMP echo request, id 677, seq 113, length 64
23:40:50.405641 IP 172.16.5.1 > 212.27.48.10: ICMP echo request, id 18, seq 364, length 64

@Mac de ma Freebox : 70:FC:8F:50:42:7C

Merci :).

Correction : "J'ai ajouté 172.16.1.0/24, 172.16.5.0/24 et 10.0.50.0/24 " (mais le 150 y est aussi).

je viens de tester en mode bourrin, le 172.16.0.0/16 fonctionne bien, et les IP répondent bien au ping, donc isokay de mon coté…

@Albirew : l'accès vers internet fonctionne ? J'ai aussi testé le 172.16.0.0/16 (et /12) et j'ai systématiquement le même résultat : je vois bien le flux sortir sur l'interface FTTH du routeur avec son hostname (donc plus de NAT actif) mais je n'ai jamais le retour.

Par contre sur les interfaces en 192.168.x.x tout fonctionne comme prévu.

J'ai du mal à penser que ça vienne de ma config car si je reboote la Freebox, le backup 4G fonctionne parfaitement sur ces subnets (configuré exactement pareil sauf que la passerelle est le routeur 4G qui a lui aussi les routes statiques).

On le voit bien ici : https://i.ibb.co/LdNdySwX/ping-Fbx.jpg Dès que le failover rebascule sur la Freebox plus d'accès web.

Tout fonctionne pour ma part, merci pour cette feature ! :)

@lduboin: Merci pour vos récentes améliorations et la mise à jour de Dnsmasq qui corrige des CVEs comme indiqué ici par exemple : https://dev.freebox.fr/bugs/index.php?do=details&task_id=34522

Pourriez-vous regarder l'ensemble des liens dans ce commentaire svp ?
- https://dev.freebox.fr/bugs/task/12869#comment192195

VLAN, VPN, Route, IPv6, Bridge, …

Certains tickets sont la continuité de ce qui vient d'être fait en 4.11.1.

Je vous remercie d'avance.

J'ai beau retourner le problème dans tous les sens, je retombe toujours sur la même chose : pour moi c'est la Freebox qui empêche les 172.x et 10.x de sortir.
Soit on n'a pas le même usage (subnets → routeur → fbx | 4g) soit le double NAT n'a pas été retiré de votre côté.

Je joins bien les réseaux depuis le subnet Freebox (et l'inverse) ça on est d'accord ça fonctionne :

Depuis 172.16.5.x vers subnet Freebox :

ping 192.168.200.240
PING 192.168.200.240 (192.168.200.240) 56(84) bytes of data.
64 bytes from 192.168.200.240: icmp_seq=1 ttl=62 time=0.645 ms
64 bytes from 192.168.200.240: icmp_seq=2 ttl=62 time=0.572 ms

Depuis subnet Freebox vers 172.16.5.x :

 ping 172.16.5.1
PING 172.16.5.1 (172.16.5.1): 56 data bytes
64 bytes from 172.16.5.1: seq=0 ttl=63 time=0.876 ms
64 bytes from 172.16.5.1: seq=1 ttl=63 time=1.074 ms

Par contre impossible de sortir sur Internet.

J'ai fait des tests directement depuis le routeur, le firewall laisse tout passer pour être sûr (on voit d'ailleurs la même chose entre un 192.168 et 172.16) :

May 21 13:10:00 vyos-1 kernel: [ipv4-NAM-VIRT-RULES-default-R]IN=eth0.5 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=172.16.5.1 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=62038 DF PROTO=ICMP TYPE=8 CODE=0 ID=35 SEQ=1456 MARK=0xc9 
May 21 13:10:00 vyos-1 kernel: [ipv4-NAM-FTTH-OUT-default-R]IN=eth0.5 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=172.16.5.1 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=62038 DF PROTO=ICMP TYPE=8 CODE=0 ID=35 SEQ=1456 MARK=0xc9 
May 21 13:10:00 vyos-1 kernel: [ipv4-NAM-VIRT-RULES-default-R]IN=eth0.5 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=172.16.5.1 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=62041 DF PROTO=ICMP TYPE=8 CODE=0 ID=35 SEQ=1457 MARK=0xc9 
May 21 13:10:00 vyos-1 kernel: [ipv4-NAM-FTTH-OUT-default-R]IN=eth0.5 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=172.16.5.1 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=62041 DF PROTO=ICMP TYPE=8 CODE=0 ID=35 SEQ=1457 MARK=0xc9 


May 21 13:11:05 vyos-1 kernel: [ipv4-NAM-LAN-RULES-default-R]IN=eth0.10 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=192.168.10.2 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=51854 DF PROTO=ICMP TYPE=8 CODE=0 ID=50 SEQ=568 MARK=0xc9 
May 21 13:11:05 vyos-1 kernel: [ipv4-NAM-FTTH-OUT-default-R]IN=eth0.10 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=192.168.10.2 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=51854 DF PROTO=ICMP TYPE=8 CODE=0 ID=50 SEQ=568 MARK=0xc9 
May 21 13:11:05 vyos-1 kernel: [ipv4-NAM-LAN-RULES-default-R]IN=eth0.10 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=192.168.10.2 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=51856 DF PROTO=ICMP TYPE=8 CODE=0 ID=50 SEQ=569 MARK=0xc9 
May 21 13:11:05 vyos-1 kernel: [ipv4-NAM-FTTH-OUT-default-R]IN=eth0.10 OUT=eth0.200 MAC=xx:xx:xx:xx SRC=192.168.10.2 DST=212.27.48.10 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=51856 DF PROTO=ICMP TYPE=8 CODE=0 ID=50 SEQ=569 MARK=0xc9 

Si on teste de sortir depuis les 192.168.x.X c'est OK :

ping -I 192.168.10.254 212.27.48.10
PING 212.27.48.10 (212.27.48.10) from 192.168.10.254 : 56(84) bytes of data.
64 bytes from 212.27.48.10: icmp_seq=1 ttl=59 time=11.0 ms
64 bytes from 212.27.48.10: icmp_seq=2 ttl=59 time=10.1 ms
--- 212.27.48.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.132/10.572/11.013/0.440 ms

ping -I 192.168.100.254 212.27.48.10
PING 212.27.48.10 (212.27.48.10) from 192.168.100.254 : 56(84) bytes of data.
64 bytes from 212.27.48.10: icmp_seq=1 ttl=59 time=10.4 ms
64 bytes from 212.27.48.10: icmp_seq=2 ttl=59 time=10.3 ms
--- 212.27.48.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.314/10.360/10.407/0.046 ms

ping -I 192.168.250.254 212.27.48.10
PING 212.27.48.10 (212.27.48.10) from 192.168.250.254 : 56(84) bytes of data.
64 bytes from 212.27.48.10: icmp_seq=1 ttl=59 time=10.9 ms
64 bytes from 212.27.48.10: icmp_seq=2 ttl=59 time=10.5 ms
--- 212.27.48.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 10.454/10.679/10.904/0.225 ms

Par contre depuis des 10.x ou 172.x c'est NON OK :

ping -I 172.16.1.254 212.27.48.10
PING 212.27.48.10 (212.27.48.10) from 172.16.1.254 : 56(84) bytes of data.
--- 212.27.48.10 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

ping -I 172.16.5.254 212.27.48.10
PING 212.27.48.10 (212.27.48.10) from 172.16.5.254 : 56(84) bytes of data.
--- 212.27.48.10 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8232ms

ping -I 10.0.50.254 212.27.48.10
PING 212.27.48.10 (212.27.48.10) from 10.0.50.254 : 56(84) bytes of data.
--- 212.27.48.10 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2076ms

Je peux tout à fait me tromper mais je pense qu'il manque une configuration sur la Freebox pour les autres réseaux que les 192.168.x.x (NAT/Masquerade ?).

Je plussoie le commentaire de @Neustradamus (https://https://dev.freebox.fr/bugs/user/25431) ci-avant :

Pourriez-vous regarder l'ensemble des liens dans ce commentaire svp ?
- https://dev.freebox.fr/bugs/task/12869#comment192195 VLAN, VPN, Route, IPv6, Bridge, …

et en particulier https://https://dev.freebox.fr/bugs/task/20993 qui correspond exactement à mon souci décrit ci-avant https://https://dev.freebox.fr/bugs/task/12869#comment193411 pour une liaison site à site entre mon subnet freebox domicile 192.168.94.x avec la passerelle freebox server 192.168.94.254, et un routeur distant, passerelle 192.168.8.1 pour réseau 192.168.8.x connecté en client VPN (192.168.27.72) sur le serveur VPN du freebox server.

Je ne suis pas du tout spécialiste en matière de routage mais j'ai du mal à concevoir une impossibilité à réaliser cette liaison site à site via un tunnel VPN…

Je rappelle que quand le routeur distant est connecté en VPN sur le freebox server (client 192.168.27.72), tous les équipements connectés sur le réseau distant peuvent accéder (ping) à tous les équipements du réseau domestique du freebox server (et ceci sans nécessiter de configuration client VPN individuelle, c'est tout l'intérêt…), mais qu'il est par contre impossible d'accéder au routeur distant 192.168.8.1 (via 192.168.27.72), ni donc à aucun des équipements connectés sur son réseau 192.168.8.x, à partir d'un quelconque équipement du réseau domestique 192.168.94.x …

Exemple pratique envisagé : un serveur home assistant sur réseau domestique souhaitant accéder à des équipements connectés au réseau distant avec communication passant par le tunnel VPN entre les deux réseaux…

NB : Errata sur les liens : Deux https:// ont été mis par l'éditeur de message :( ⇒ en supprimer un. Pas vu comment corriger le message…)

@lduboin

Je n'avais pas vu les choses sous cet angle…

J'ai naïvement pensé que ça ne poserait pas de soucis de mettre en place une règle de masquerade pour les sources 10.x et 172.x sur les interfaces LAN de la Freebox mais ne connaissant pas son fonctionnement interne il semblerait que cela ne soit pas si simple .

Impossible du coup de retirer le double NAT, à moins de changer le plan d'adressage de mes subnets (pas super envie).

Dommage car cela permettait, notamment dans ntopng, de voir les hôtes à l'origine des flux et non plus l'IP du routeur.

Je croise les doigts pour que cela puisse évoluer, même si cela semble peu probable :(.

Merci de cette réponse en tout cas.

Salut,

ravi de voir que les choses ont bougé sur ce ticket.

Par contre, j'ai eu un problème en essayant de me servir de la fonction routage :

J'ai ajouté une route, mais celle-ci n'a pas eu d'effet.
Du coup j'ai redémarré la box pour être sûr.
Et depuis, ma connexion internet ne marche plus!

La box passe une minute sur l'étape 6 mais atteint l'horloge.
Le portail d'admin web dit ça :

Services

Connexion internet : Connexion indisponible
Authentification : Non
Téléphone : Service téléphonique non configuré

État Internet

État de la connexion Internet
État de la connexion : Déconnecté
Type de connexion : xDSL

Sur l'afficheur, l'état du lien FTTH est "UP" :
Média: FTTH
Type: Ethernet
Connecté

Et je vois une IP (10.125.*.*)

J'ai désactivé et retiré les routes réseau, mais la situation reste la même.

Ça pourrait être uniquement lié à ma ligne, mais ça pourrait aussi être un bogue de routage, non ?

Je suis en 4.11.1 sur un serveur mini-4k.

Ok, je suis à présent convaincu que c'est lié à la fonction de routage.

La freebox répond au ping sur son IP publique depuis internet.
L'IP sur l'afficheur est une adresse privée de classe A.

Le LAN est toujours sur l'adresse de classe C historique (192.168.0.0/24), mais son traffic ne sort plus vers internet !

Aurais-je fait une mauvaise manip' ou est-ce un bug du dernier firmware ?
J'ai juste ajouté puis retiré des adresses de routages (la table est vide à présent).

Comment faire pour rétablir le routage ?

Ok, j'ai pu me sauver moi-même juste en manipulant la table de routage.
Mais le comportement est aléatoire:

J'ai ajouté une règle pour router le LAN vers la freebox : Ça remarche.
Je remet des règles vers d'autres LAN de classe C : Ça re-pète
Je les retire : Ça reste K.O.
Je retire la règle du LAN : Ça re-marche

@ldubois

C'est assez étrange, le réseau était K.O. quand j'ai supprimé toutes les règles la première fois (tableau vide) ça ne marchait toujours pas. Mais à la fin je l'ai refait une seconde fois et ça marchait.

Si bien que je pense qu'il y a un état caché hors de l'UI.

Voici de mémoire la séquence observée (redémarrage box après chaque modification) :
+ 192.168.1.0/24 → 192.168.0.243
⇒ K.O.
- 192.168.1.0/24 → 192.168.0.243
⇒ K.O.
+ 192.168.0.0/24 → 192.168.0.254
⇒ O.K.
+ 192.168.1.0/24 → 192.168.0.243
+ 192.168.2.0/24 → 192.168.0.241
⇒ K.O.
- 192.168.1.0/24 → 192.168.0.243
- 192.168.2.0/24 → 192.168.0.241
⇒ K.O.
- 192.168.0.0/24 → 192.168.0.254
⇒ O.K.

Comme vous voyez, le statut a été différent pour un même état de la table de routage à différents moments.