La Fibre
Datacenter et équipements réseaux => Routeurs => 
Ubiquiti => Discussion démarrée par: OptiNAS le 23 juillet 2026 à 04:19:16
-
Bonjour,
J'essaie de remplacer complètement une Freebox Pro par un Ubiquiti UDM Pro Max sur une offre Free Pro Fibre 7 Gbit/s.
Mon objectif est de conserver uniquement le matériel optique nécessaire et supprimer la Freebox Pro.
Topologie Actuelle :
Fibre opérateur
│
Boîtier optique blanc (arrivée fibre)
│
Boîtier noir Free (ONU)
│ (SFP+ DAC)
Freebox Pro
│
UDM Pro Max
Mon objectif est :
Fibre
│
Boîtier noir Free (ONU)
│
UDM Pro Max
(idéalement supprimer également le boîtier noir si un ONT/XGS-PON compatible est possible, mais ce n'est pas le sujet principal ici)
---
Matériel utilisé
- Free Pro Fibre 7 Gbit/s
- Freebox Pro
- ONU noir Free
- UDM Pro Max
- USW-Pro-HD utilisé comme TAP / miroir
- Wireshark
---
J'utilise le switch comme miroir :
Port 23
PC + Wireshark
Mirror RX/TX des ports 25 et 26
Port 25
ONU Free
Port 26
Freebox
ou
UDM suivant les essais
---
Informations récupérées
MAC WAN Freebox
dc:XX:XX:XX:XX:00
IPv4 publique
45.XX.XX.11
Routeur IPv6 Free
MAC : 78:XX:XX:XX:XX:e8
IPv6 link-local : feXX::XXXX:XXXX:XXXX:42XX
---
Analyse Wireshark
VLAN IPv6 :
Les Router Advertisement arrivent exclusivement sur : VLAN 836
On voit :
Router Advertisement
Router Solicitation
Neighbor Solicitation
Le Router Advertisement indique :
Managed = 0
Other = 0
Donc pas de DHCPv6 stateful.
---
DHCPv6
Filtre : dhcpv6
Résultat : Aucun paquet
---
IPv4
Le trafic destiné à l'IPv4 publique : 45.XX.XX.11
circule sur : VLAN 301
---
Donc actuellement mes captures montrent :
VLAN 836
→ IPv6
→ Router Advertisement
→ Router Solicitation
VLAN 301
→ IPv4 publique
---
Tests effectués sur l'UDM :
VLAN 301
- DHCP
- IPv4 over IPv6
- DS-Lite
- MAP-E
- SLAAC
- DHCPv6
Résultat : Aucune IP
---
VLAN 836
Même chose :
- SLAAC
- Single Network
- Prefix Delegation
- DHCP
- IPv4 over IPv6
- MAP-E
- DS-Lite
Résultat : Aucune IP WAN
---
Clonage MAC
J'ai cloné la MAC WAN de la Freebox : dc:XX:XX:XX:XX:00
En branchant uniquement l'UDM (Freebox totalement débranchée), Wireshark montre que les Router Solicitation partent avec la bonne adresse MAC
Donc le clonage MAC semble bien pris en compte.
---
Ce que je vois avec l'UDM :
- Reçoit les Router Advertisement
- émet des Router Solicitation
- Voit le VLAN
- Ne reçoit aucune adresse IPv6 globale
- Aucune IPv4
---
Je me demande donc si la Freebox Pro réalise ensuite une étape supplémentaire.
- 4rd Free ?
- MAP-E propriétaire ?
- Autre mécanisme spécifique Free Pro ?
- Double interface WAN interne (VLAN 301 + VLAN 836) ?
---
Ce que je cherche :
Remplacer complètement la Freebox Pro (et potentiellement de son boitier ONU XGS-PON externe)
Je cherche donc à comprendre :
- Quel est exactement le rôle du VLAN 301
- Quel est exactement le rôle du VLAN 836
- Comment la Freebox obtient son IPv4
- Si quelqu'un a déjà réussi à remplacer une Freebox Pro par un routeur tiers (Linux, MikroTik, VyOS, UDM, etc.).
Merci d'avance pour votre aide.
-
Bonjour,
Ton analyse est déjà très propre et, à mon avis, tu as suffisamment avancé pour écarter un simple problème de VLAN ou de clonage de MAC.
Il faut cependant bien séparer deux couches qui sont souvent mélangées dans ce type de remplacement :
- La couche optique/PON : ONU, enregistrement auprès de l’OLT, OMCI, GEM ports et translation des VLAN.
- La couche IP opérateur : IPv6 WAN, IPv4, routage, tunnel éventuel, provisioning et mécanismes spécifiques à la Freebox Pro.
Dans ta situation actuelle, le boîtier ONU Free est déjà synchronisé et transmet bien du trafic Ethernet à l’UDM. Ton blocage se situe donc principalement dans la seconde couche.
1. Ce que tes captures permettent déjà d’affirmer
Le fait que l’UDM reçoive des Router Advertisement sur le VLAN 836 démontre que :
- l’ONU est opérationnel ;
- le chemin optique est établi ;
- le VLAN 836 arrive correctement jusqu’à l’UDM ;
- le clonage de MAC n’est pas totalement rejeté par l’infrastructure ;
- le voisin IPv6 amont est au moins joignable au niveau Ethernet/ICMPv6.
En revanche, les champs suivants du Router Advertisement :
Managed Address Configuration : 0
Other Configuration : 0
ne signifient pas que l’UDM doit automatiquement recevoir une IPv6 globale.
Ils indiquent seulement que le routeur amont ne demande pas d’utiliser DHCPv6 pour fournir l’adresse ou d’autres paramètres.
Pour savoir si SLAAC est réellement possible, il faut ouvrir complètement le paquet RA et regarder la présence d’une option :
ICMPv6 Prefix Information
et notamment :
Autonomous address-configuration flag : 1
Prefix length : généralement /64
Valid lifetime : non nul
Preferred lifetime : non nul
Si le RA ne contient aucun Prefix Information Option, ou si le flag Autonomous vaut 0, l’UDM ne peut pas fabriquer d’adresse IPv6 globale par SLAAC.
Le RA peut alors uniquement servir à fournir :
- une route par défaut ;
- l’adresse link-local du routeur amont ;
- une MTU ;
- des DNS via RDNSS ;
- éventuellement des routes supplémentaires.
Une adresse link-local et une route par défaut ne suffisent pas nécessairement à construire la connectivité attendue par Free Pro.
2. Le VLAN 301 ne fournit probablement pas une IPv4 par DHCP classique
Le fait de voir des paquets destinés à ton IPv4 publique sur le VLAN 301 est très intéressant, mais ne permet pas encore de conclure que le VLAN 301 fonctionne comme un WAN DHCPv4 classique.
Il faut vérifier précisément comment ces paquets sont transportés.
Dans Wireshark, regarde si le paquet visible sur le VLAN 301 est :
- un véritable paquet Ethernet IPv4 avec un EtherType 0x0800 ;
- ou un paquet IPv4 encapsulé dans IPv6, avec un champ IPv6 Next Header égal à 4.
Dans le deuxième cas, il s’agit d’IP-in-IP, c’est-à-dire d’IPv4 transportée dans IPv6.
Attention également à ne pas appeler automatiquement cela MAP-E ou 4rd. Le simple fait de voir du protocole IP numéro 4 démontre une encapsulation IPv4 dans IPv6, mais pas nécessairement l’utilisation complète de MAP-E ou de 4rd.
S’il s’agit au contraire de véritables trames IPv4 directement présentes sur le VLAN 301, il faudra examiner :
- l’adresse MAC source et destination ;
- la présence ou non d’ARP ;
- la passerelle utilisée ;
- le masque associé à l’IPv4 publique ;
- la présence éventuelle d’une route host /32 ;
- les éventuels DHCP Discover émis par la Freebox ;
- les options DHCP transmises par la Freebox.
Une IPv4 publique peut parfaitement être provisionnée statiquement dans la Freebox sans qu’aucun DHCP Offer ne soit visible au démarrage normal.
3. Le point essentiel : faire une capture depuis un démarrage totalement à froid
Une capture réalisée sur une Freebox déjà provisionnée peut manquer l’étape la plus importante.
La Freebox peut conserver dans sa configuration persistante :
- son préfixe IPv6 ;
- son IPv6 WAN ;
- son IPv4 publique ;
- l’adresse de la passerelle ;
- les paramètres du tunnel IPv4 ;
- un identifiant de session ;
- des informations téléchargées depuis les serveurs de configuration Free Pro.
Je referais donc une capture en démarrant l’enregistrement avant la mise sous tension de l’ONU et de la Freebox Pro.
L’ordre serait :
1. ONU et Freebox éteints
2. Démarrage de la capture sur le port miroir
3. Mise sous tension de l’ONU
4. Attente de sa synchronisation
5. Mise sous tension de la Freebox Pro
6. Capture pendant au moins 10 à 15 minutes
Il faut capturer sans filtre, puis filtrer après coup.
Filtres Wireshark intéressants :
vlan
arp
bootp
dhcpv6
icmpv6
pppoed || pppoes
ip.proto == 4
ipv6.nxt == 4
dns
tls.handshake.extensions_server_name
Et pour isoler les VLAN :
vlan.id == 301
vlan.id == 836
vlan.id == 302
vlan.id == 303
vlan.id == 4001
Des analyses historiques de Freebox Pro avaient également identifié des communications vers des services du type :
cfg.freepro.com
fmw.freepro.com
tlm.freepro.com
Il serait intéressant de vérifier si ces destinations existent toujours sur ta nouvelle offre et, surtout, ce qui se passe juste avant et juste après ces connexions.
Même si les échanges applicatifs sont chiffrés, la chronologie DNS/TLS peut révéler que la Freebox télécharge sa configuration IP après avoir obtenu une connectivité IPv6 minimale.
4. Hypothèse raisonnable sur les VLAN 836 et 301
À ce stade, je considérerais l’architecture suivante comme une hypothèse de travail, et non comme une certitude :
VLAN 836
IPv6 de transport ou de contrôle
Router Advertisement
Routeur amont accessible en link-local
Éventuelle IPv6 WAN configurée ou dérivée
Éventuel accès au provisioning Free Pro
VLAN 301
Service IPv4
IPv4 publique routée ou encapsulée
Paramètres éventuellement récupérés par la Freebox
Il est également possible que la Freebox utilise réellement deux interfaces WAN internes :
- une interface IPv6 sur le VLAN 836 ;
- une interface IPv4 ou un tunnel sur le VLAN 301.
Mais il faut le confirmer par la capture.
Les anciennes analyses Free Pro plaçaient plutôt le service principal sur le VLAN 301 avec une IPv4 transportée dans IPv6 et un préfixe IPv6 routé. Ton observation actuelle peut donc correspondre :
- à une évolution de l’architecture Free Pro ;
- à une différence liée à l’offre XGS-PON 7 Gbit/s ;
- à une translation réalisée par l’ONU ;
- à une séparation plus récente entre les interfaces de service ;
- ou simplement à une interprétation incomplète des paquets capturés.
Il ne faut donc pas appliquer directement les recettes destinées aux Freebox grand public ou aux anciens accès Free 10G-EPON.
Free Pro n’utilise pas nécessairement exactement la même collecte ni le même provisioning qu’une offre Free résidentielle.
5. Pourquoi les options de l’UDM ne donnent rien
Les options UniFi :
- DS-Lite ;
- MAP-E ;
- IPv4 over IPv6 ;
- SLAAC ;
- DHCPv6 ;
- Prefix Delegation ;
ne sont pas des mécanismes universels capables de détecter automatiquement n’importe quelle architecture opérateur.
Par exemple :
- DS-Lite nécessite une IPv6 WAN fonctionnelle et une adresse AFTR ;
- MAP-E nécessite des règles de mapping compatibles avec l’implémentation supportée par UniFi ;
- SLAAC nécessite un préfixe annoncé avec le flag Autonomous ;
- Prefix Delegation nécessite normalement un échange DHCPv6-PD ;
- un tunnel IPIP spécifique nécessite une IPv6 source, une IPv6 de destination et des routes explicitement définies.
UniFi sait aujourd’hui gérer certains cas d’IPv4 sur IPv6, mais cela ne signifie pas que l’UDM sait reproduire un mécanisme Free Pro propriétaire ou semi-propriétaire.
En particulier, l’interface UniFi n’est pas conçue pour créer librement :
- plusieurs sous-interfaces WAN indépendantes sur un même port ;
- un tunnel IPIP IPv4 dans IPv6 entièrement personnalisé ;
- une IPv6 WAN statique avec une passerelle link-local spécifique ;
- des règles de routage avancées entre plusieurs VLAN opérateur ;
- une IPv4 publique /32 routée par un tunnel personnalisé ;
- un mécanisme de provisioning propre à la Freebox.
Il est donc tout à fait possible que le remplacement soit techniquement réalisable avec Linux, VyOS ou MikroTik, mais pas directement depuis l’interface de l’UDM Pro Max.
6. Le clonage de MAC peut être nécessaire sans être suffisant
Tu as bien confirmé que les Router Solicitation utilisent la MAC clonée. C’est un bon point.
Mais la Freebox peut également utiliser :
- une IPv6 construite à partir de sa MAC ;
- une IPv6 configurée statiquement ;
- un DUID propre pour DHCPv6, même si aucun échange n’est visible actuellement ;
- un identifiant transmis lors du provisioning ;
- une adresse source précise attendue par le routeur amont ;
- une session entretenue périodiquement ;
- un Neighbor Advertisement particulier ;
- une configuration persistante déjà récupérée précédemment.
Il faut également comparer l’adresse IPv6 link-local utilisée par la Freebox et celle générée par l’UDM.
Cloner l’adresse MAC Ethernet ne garantit pas toujours que le routeur tiers utilisera exactement la même adresse link-local IPv6, notamment selon l’utilisation d’EUI-64, d’adresses stables ou d’un identifiant généré par le système.
7. Le meilleur chemin de résolution : conserver d’abord l’ONU Free
Je te conseille vraiment de découper le projet en deux étapes.
Étape 1 : remplacer uniquement la Freebox Pro
Topologie :
Fibre
|
ONU Free
|
Routeur Linux / VyOS / MikroTik
|
UDM Pro Max
L’équipement intermédiaire servirait à :
- terminer les VLAN 301 et 836 ;
- reproduire l’adressage IPv6 de la Freebox ;
- créer l’éventuel tunnel IPv4 dans IPv6 ;
- gérer les routes spécifiques ;
- présenter ensuite une connexion plus classique à l’UDM.
Un Linux avec deux interfaces 10 Gbit/s, ou une machine avec une interface SFP+ et une interface Ethernet 10G, serait probablement le meilleur outil de laboratoire.
Cela permettrait de tester librement :
- les VLAN ;
- les adresses IPv6 statiques ;
- les routes via une passerelle link-local ;
- IPIP ;
- le proxy NDP ;
- les MTU ;
- les tables de routage multiples.
Une fois la connexion fonctionnelle sous Linux ou VyOS, il sera possible de déterminer si la configuration peut être adaptée à MikroTik ou directement à UniFi.
Étape 2 : remplacer éventuellement l’ONU Free
Ce n’est qu’une fois la couche IP parfaitement comprise que je tenterais le remplacement de l’ONU par un WAS-110.
8. Ce qu’apporterait réellement un WAS-110
Le WAS-110 peut remplacer la fonction optique XGS-PON de l’ONU externe, à condition de reproduire correctement l’identité attendue par l’OLT :
- Vendor ID ;
- numéro de série PON ;
- Equipment ID ;
- version matérielle ;
- versions logicielles active et passive ;
- PLOAM password si utilisé ;
- LOID si utilisé ;
- paramètres OMCI ;
- mapping des GEM ports et des VLAN.
L’objectif serait d’obtenir un état :
O5 / O5.1
puis de vérifier dans les tables OMCI que les VLAN et les services sont correctement créés.
Mais le WAS-110 ne remplace que l’ONU.
Il ne reproduira pas automatiquement :
- le provisioning IP de la Freebox ;
- les deux éventuelles interfaces WAN ;
- le tunnel IPv4 dans IPv6 ;
- la récupération du préfixe ;
- la configuration téléchargée depuis Free Pro ;
- la logique de routage de la Freebox.
Mon propre retour d’expérience avec un WAS-110 sur une ligne SFR XGS-PON m’a appris un point important : obtenir O5/O5.1 et être correctement reconnu par l’OLT ne garantit absolument pas que le service IP fonctionnera.
Sur une ligne PON, il y a au minimum deux validations indépendantes :
Enregistrement PON réussi
!=
Service IP opérationnel
On peut être parfaitement enregistré auprès de l’OLT, recevoir les ordres OMCI et voir les VLAN, tout en n’obtenant aucun DHCP ou aucune connectivité IP parce que l’identité du CPE, le provisioning ou les paramètres de service ne sont pas encore reproduits.
Dans ton cas, remplacer immédiatement l’ONU Free par un WAS-110 ajouterait donc une seconde inconnue alors que le mécanisme IP Free Pro n’est pas encore identifié.
9. Test Linux minimal que je réaliserais
Avec l’ONU Free toujours en place, je brancherais temporairement une machine Linux directement derrière lui.
Exemple de création des VLAN :
ip link set dev enp1s0 address dc:XX:XX:XX:XX:00
ip link set dev enp1s0 up
ip link add link enp1s0 name enp1s0.301 type vlan id 301
ip link add link enp1s0 name enp1s0.836 type vlan id 836
ip link set dev enp1s0.301 up
ip link set dev enp1s0.836 up
Capture complète :
tcpdump -eni enp1s0 -s0 -w freepro-test.pcap
Affichage des Router Advertisement :
rdisc6 enp1s0.836
Affichage des voisins et routes :
ip -6 neigh show dev enp1s0.836
ip -6 route show
ip -6 address show dev enp1s0.836
DHCPv4 en mode très verbeux sur le VLAN 301 :
dhclient -4 -v enp1s0.301
DHCPv6, uniquement pour confirmer définitivement son absence :
dhclient -6 -v enp1s0.836
Il faudra évidemment éviter de lancer simultanément la Freebox et la machine de test avec la même MAC.
Ce test permettra de savoir si le blocage vient réellement du réseau Free Pro ou simplement du comportement limité de la pile WAN UniFi.
10. Les informations les plus utiles à publier maintenant
Pour poursuivre proprement l’analyse, il faudrait idéalement fournir :
- le détail complet du Router Advertisement reçu sur le VLAN 836 ;
- les Prefix Information Options éventuelles ;
- la valeur Router Lifetime ;
- la MTU annoncée ;
- les éventuelles Route Information Options ;
- la MAC et l’IPv6 link-local du routeur amont ;
- un exemple complet d’un paquet IPv4 vu sur le VLAN 301 ;
- la confirmation qu’il s’agit d’IPv4 natif ou d’IPv4 encapsulé ;
- les paquets ARP présents sur le VLAN 301 ;
- les éventuels DHCP Discover émis par la Freebox ;
- les options contenues dans ces DHCP Discover ;
- la chronologie complète du démarrage à froid ;
- la liste de tous les VLAN réellement observés ;
- la différence entre une capture Freebox connectée et une capture UDM connecté.
En masquant les adresses publiques et les identifiants sensibles, un extrait PCAP contenant uniquement le démarrage WAN serait beaucoup plus parlant que des captures d’écran.
Conclusion
À mon avis :
- le boîtier ONU Free n’est pas actuellement le problème ;
- le VLAN 836 fournit au minimum une connectivité IPv6 locale et une route amont ;
- les flags M=0/O=0 ne prouvent pas qu’une adresse SLAAC doit être attribuée ;
- le VLAN 301 transporte bien le service IPv4, mais son mécanisme d’activation reste à déterminer ;
- la Freebox récupère ou possède probablement des paramètres supplémentaires que l’UDM ne connaît pas ;
- le clonage de MAC est nécessaire, mais probablement insuffisant ;
- l’UDM Pro Max ne semble pas suffisamment flexible pour reproduire directement un tunnel ou un routage Free Pro non standard ;
- la prochaine étape logique est un test avec Linux, VyOS ou MikroTik en conservant l’ONU Free ;
- le WAS-110 sera pertinent ensuite, uniquement pour supprimer l’ONU, une fois la couche IP entièrement fonctionnelle.
Je commencerais donc par obtenir une connectivité IPv6 complète sous Linux sur le VLAN 836, puis par reproduire exactement l’adressage et les routes observés sur la Freebox. Ensuite seulement, j’analyserais la construction de l’IPv4 sur le VLAN 301.
Tu es clairement arrivé au point où une capture complète de démarrage de la Freebox devrait permettre de débloquer l’analyse.