Je fais appel à la communauté car je cherche à résoudre un problème qui semble être constaté depuis peu chez un certain nombre de clients Free.

Lorsqu'un routeur est utilisé entre la freebox server et la box TV (freebox pop), le flux ne semble plus passer, avec à la clef une erreur #1014.

Je comprends que c'est en lien avec une évolution Free qui impose un adressage IP V6 de la freebox pop qui n'etait pas obligatoire jusque là pour avoir le flux TV mais qui semble impératif maintenant.

Je creuse plusieurs forums/articles mais mes connaissances en infra réseau restant limitées, et encore plus quand il s'agit d'IP V6, je fais appel à vous pour savoir s'il existe une solution qui est décrite avec un RT2600ac (je trouve des infos pour d'autres routeurs, mais j'ai du mal à appliquer sur un RT2600ac)

Mes sources

• https://lafibre.info/remplacer-freebox/erreur-dash1014-dns-depuis-mi-mars-2026-en-freebox-ultra-bridge-routeur-tiers/

• https://lafibre.info/remplacer-freebox/freebox-pop-ucg-ultra-configuration-ipv6-pour-player-popoqee/12/

• https://blog.kulakowski.fr/post/openwrt-derriere-une-freebox-ipv6-dmz-et-bridge

Quelle serait la configuration à appliquer sur mon routeur RT2600ac qui se trouve entre ma freebox en DMZ et ma box TV?

Je précise que ma box TV est connectée en WIFI et que je ne peux pas faire de connexion filaire entre mon RT2600ac et ma box TV.

Une solution peu elegante que j'utilise pour le moment est d'avoir 2 wifi actifs:

• le wifi de la box free, uniquement utilisé pour la box TV

• le wifi du RT2600ac pour tous les autres périphériques de la maison

Je voudrais retrouver une config qui me permette de tout faire passer via le wifi du RT2600ac.

Merci pour votre aide :)

Hello !

T'as essayé d'activer le relais DHCP en IPv6 dans les paramètres de connexion du RT2600AC ?

A l'époque ou j'avais un RT6600AX en DMZ derrière ma freebox pop, ce paramètre m'avais permis très simplement d'avoir de l'IPV6 sur tous les appareils placés derrière le routeur Synology.

Bonjour @church

merci pour ta suggestion.

j'ai continué à creuser un peu et j'ai fini pas tomber sur cet article:

https://www.forum-nas.fr/threads/comment-bien-configurer-le-rt2600ac-les-nas-les-conteneurs-docker-en-ipv6-et-garder-oqee-fonctionnel-sur-lappletv.19027/page-2

En activant simplement "relais IPV6", et sans évolution sur mes regles de pare-feu cela semble resoudre le probleme "erreur 1014" et le flux TV transite à nouveau dans ma config actuelle (freebox server en DMZ -> RT2600ac -> freebox pop TV)

... par contre j'ai du mal à savoir ce qui se cache exactement derrière ce principe de relais IPV6 et si c'est bien safe pour mon reseau local... la simplicité de la solution me laisse songeur par rapport à l'ensemble des posts que j'ai pu consulter...

Rien de sensible pour ton réseau domestique : avec ce paramètre c'est la Freebox qui fait serveur DHCPv6 et le RT2600AC ne fait que relayer l'attribution des IPV6 aux périphériques compatibles du réseau local.

Active éventuellement les pare-feu ipv4 et ipv6 de la freebox et je pense que tu es tranquille.

Si tu veux une gestion à 100% via ton routeur Synology, te passer de la DMZ, il te faut alors privilégier le mode bridge de la freebox :

https://assistance.free.fr/articles/747

C'est la configuration que j'ai retenue pour gérer intégralement mon réseau depuis une passerelle Ubiquiti et avoir de l'IPV6 sur tous mes VLAN (délégation de prefixes via Next Hop depuis l'interface de la Freebox). L'application Free TV fonctionne sur tous les lecteurs multimédia (Shield TV, FireTV Stick Amazon, TV connectées). Je n'ai pas le Player TV Free.

merci @church !

Bonjour,

le mode "relais IPV6" était un peu trop limitant vis à vis de mes attentes: j'ai fini par arriver à une configuration qui répond à mes besoins, à savoir:

• un réseau A: dédié TV, uniquement en Wifi et IPV6 -> résout complètement le problème erreur #1014 sur freebox pop😀

  • le mode opératoire pour configurer IPV6 est très bien décrit dans ce post https://www.nas-forum.com/forum/topic/49966-configuration-ipv6-sur-rt1900ac-avec-freebox/#findComment-1319374614

• un réseau B: filaire/wifi, en IPV4, pour tous les autres périphériques

• pas d'isolement de ces 2 réseaux car j'ai besoin que mon serveur Plex sur réseau B puisse communiquer avec la box TV qui se trouve sur le réseau A: des règles pare-feu permettent de ne laisser passer que le strict nécessaire en ces 2 réseaux

• mise à jour des paramètres DNS server sur SRM en lien avec le reseau dedié TV et la plage d'adresses IP associée

Seul point qu'il me reste à traiter est le temps de chargement des chaines TV un peu long, de l'ordre de 10 secondes aujourd'hui : j'ai cru comprendre qu"il était possible d'améliorer cela: https://lafibre.info/remplacer-freebox/freebox-pop-ucg-ultra-configuration-ipv6-pour-player-popoqee/12/

Extrait
Analyse du lag
Avant l'ajout de l'entrée DNS : latence de +/- 10 secondes. Après l'ajout : +/- 3/4 secondes. J'ai fait des captures Wireshark pour éliminer le délai restant. Voici la séquence exacte observée :

1. Le player envoie une requête DNS AAAA pour mafreebox.freebox.fr afin d'obtenir l'adresse IPv6 de la box - c'est l'étape d'authentification réseau Free

2. Le player tente une connexion TCP vers la box sur le port RTSP 554 - c'est un vestige du protocole historique Free TV (les chaînes étaient autrefois distribuées en multicast IPTV directement depuis la box). En mode bridge, la box ne sert plus de contenu vidéo et ne répond pas sur ce port en IPv6

3. ~1 seconde plus tard, pas de réponse : le player envoie une retransmission TCP

4. ~2 secondes plus tard : le firewall renvoie un ICMPv6 "Destination Unreachable" signalant que la connexion RTSP est impossible

5. Le player abandonne la tentative RTSP et enchaîne sur les connexions OQEE

6. Requêtes DNS sur license.oqee.net et api.oqee.net - le player obtient des enregistrements A et AAAA pour ces serveurs

7. Connexion HTTPS vers api.oqee.net (2a01:e0f:1:9000::67) - récupération du manifeste de la chaîne et du token d'accès

8. Requête DNS sur time.akamai.com - synchronisation horaire, nécessaire pour la validation des tokens DRM et la synchronisation des flux live

9. Le player initie le streaming vers 2a01:e00:0:ffff::f5 - une adresse Anycast du réseau CDN Free/Proxad (2a01:e00::/32). Certains segments transitent également par Akamai (2a02:26f0::/32), un CDN tiers utilisé par Free pour la distribution de contenu. Le player n'obtient pas cette adresse via DNS - c'est le serveur api.oqee.net qui la fournit dans la réponse du manifeste (HLS/DASH). Le trafic est routé vers le point de présence Free le plus proche

10. La vidéo est lancée

Le fix final
Le délai résiduel de 3-4 secondes vient des étapes 2-4 : le player attend la réponse RTSP qui ne viendra jamais. La solution est d'ajouter une règle Reject (pas Block) sur le firewall pour le port 554 vers la box :
Reject | IPv6 | TCP | LAN net IPv6 | IP_GUA_Freebox | port 554
La distinction Block vs Reject est capitale : Block droppe le paquet silencieusement et le player attend le timeout TCP complet (~3 secondes). Reject envoie immédiatement un TCP RST, le player comprend instantanément que ce port n'est pas disponible et passe à l'étape suivante en quelques millisecondes.
Résultat : le lag restant disparaît complètement

Si quelqu'un sait comment transposer ça sur SRM, je suis preneur 😀