Auteur Sujet: Problème de routage de 1.1.1.1 sur 192.168.1.1 (Lu 1098 fois)

jimmy · « **le:** 23 septembre 2025 à 23:22:52 »

Bonjour,

J’utilise depuis longtemps les resolvers DNS over Http de cloudfare : 1.1.1.1 et 1.0.0.1
Depuis la fin d’après-midi du 23/sept j’ai des problèmes de DNS sur tout mes PC.
Les deux symptômes les plus évidents (et qui persistes) sont :

1) Quand j’utilise la page de test de cloudfare https://one.one.one.one/help/
La connectivité pour 1.1.1.1 est à NO et celle pour 1.0.0.1 est YES

2) Si je fais un trace route vers 1.1.1.1 la réponse est un seul hop, et un ping trés court, comme si ma box était la destination finale !

Code: [Sélectionner]

>tracert 1.1.1.1
Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:
  1     1 ms    <1 ms    <1 ms  one.one.one.one [1.1.1.1]
Trace complete.

> ping 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time<1ms TTL=64
Reply from 1.1.1.1: bytes=32 time<1ms TTL=64
Reply from 1.1.1.1: bytes=32 time<1ms TTL=64
Reply from 1.1.1.1: bytes=32 time<1ms TTL=64

Alors que pour l'autre resolver 1.0.0.1 le traceroute et le ping sont normaux:

Code: [Sélectionner]

> tracert 1.0.0.1
Tracing route to one.one.one.one [1.0.0.1]
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     2 ms     2 ms     2 ms  80.10.4.13
  3     3 ms     4 ms     4 ms  ae119-0.nctou202.rbci.orange.net [193.253.84.130]
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6    16 ms    16 ms    16 ms  193.251.240.27
  7    24 ms    19 ms    20 ms  193.251.150.166
  8    17 ms    16 ms    16 ms  141.101.67.115
  9    16 ms    16 ms    15 ms  one.one.one.one [1.0.0.1]

>ping 1.0.0.1
Pinging 1.0.0.1 with 32 bytes of data:
Reply from 1.0.0.1: bytes=32 time=16ms TTL=56
Reply from 1.0.0.1: bytes=32 time=15ms TTL=56
Reply from 1.0.0.1: bytes=32 time=16ms TTL=56
Reply from 1.0.0.1: bytes=32 time=16ms TTL=56

Enfin, en utilisant l’url https://1.1.1.1/test j'ai obtenue l'erreur SEC_ERROR_UNKNOWN_ISSUER. Le chaîne de certificats refusée par le navigateur est en fait la même que celle pour https://192.168.1.1/

Tout cela confirme bien que 1.1.1.1 est routé sur la box !!

J'ai bien sûr vérifier le system32/drivers/etc/hosts de chaque PC, j'ai testé avec plusieurs navigateurs, j'ai désactivé le mode CGN au niveaux de la box (on sait jamais...), j'ai rebooté tout le monde (PC et Box) mais le problème persiste ...
~~Le seul changement est que https://1.1.1.1/test ne donne plus SEC_ERROR_UNKNOWN_ISSUER mais juste "Secure Connection Failed"~~ En fait le SEC_ERROR_UNKNOWN_ISSUER disparaît car j'ai accepté le risque et donc le navigateur continue en ignorant le problème de certificat.

Si c'est un problème de routage entre Orange et Cloudfare je ne devrais pas être le seul à être impacté.
D’où ce message pour savoir si je suis seul, et obtenir vos avis éclairés sur les causes possibles de ce problème.

Notes:
- Le site https://www.cloudflarestatus.com/ ne montre aucun problème en France pour le 23/sept/2025
- [UPDATE] A la fin de cette page https://developers.cloudflare.com/1.1.1.1/troubleshooting/ le cas du traceroute qui s’arrête au premier saut est évoqué. Une route statique au niveau de la box/routeur en serait la cause.
- Version du firmware de ma livebox: G06.R05.C03_16

Merci.

MaxLebled · « **Réponse #1 le:** 24 septembre 2025 à 00:08:50 »

Un lien avec ce problème de longue date ? https://lafibre.info/orange-les-news/acces-a-1-1-1-1-via-livebox-4/

hwti · « **Réponse #2 le:** 24 septembre 2025 à 00:46:29 »

Citation de: MaxLebled le 24 septembre 2025 à 00:08:50

Un lien avec ce problème de longue date ? https://lafibre.info/orange-les-news/acces-a-1-1-1-1-via-livebox-4/

Oui, mais normalement c'était contourné (mais pas pour l'ICMP).

Après vérification, sur une LB5 avec firmware G06.R05.C03_16 :
- http://1.1.1.1 reçoit une réponse vide
- https://1.1.1.1 utilise le certificat de la Livebox, et donne une réponse vide
- DNS (1.1.1.1 UDP et TCP 53) OK
- DoT (1.1.1.1 TCP 853) OK
- DoH sur https://one.one.one.one/dns-query : potentiellement aléatoire, puisque c'est la Livebox qui répond si l'IP 1.1.1.1 est choisie
- DoH sur https://cloudflare-dns.com/dns-query : OK (puisque les IP sont différentes, il n'y a pas 1.1.1.1)

Donc ça a dû être cassé pour les ports 80 et 443 lors d'une mise à jour.

Citation de: jimmy le 23 septembre 2025 à 23:22:52

J’utilise depuis longtemps les resolvers DNS over Http de cloudfare : 1.1.1.1 et 1.0.0.1

Comment exactement ?
Ce n'est pas forcément pareil si on parle du réglage dans un navigateur, ou au niveau des DNS systèmes (qui sont peut-être du DNS simple, et pas du DoH).

jimmy · « **Réponse #3 le:** 24 septembre 2025 à 11:42:04 »

Un grand merci pour vos réponses qui montrent que le problème est au niveau de ma LiveBox 5, connu depuis 2018 sur la LiveBox 4 et donc qu'il ne sera pas résolu demain...

@hwti: J'utilise DoH aussi bien au niveau de l'OS (Windows & Linux) qu'au niveau de Firefox réglé sur 'Protection maximale' (Windows et Linux)

A la lumière de vos réponses j'ai investigué un peu plus:

1/ En plus de la paire (1.1.1.1 , 1.0.0.1) Cloudfare propose aussi des versions Family plus ou moins 'filtrées' sur (1.1.1.2 , 1.0.0.2) et (1.1.1.3 , 1.0.0.3).
Pour moi, les versions 1.0.0.x sont joignables : https://1.0.0.1/ https://1.0.0.2/ https://1.0.0.3/
mais pas les versions 1.1.1.x : https://1.1.1.1/ https://1.1.1.2/ https://1.1.1.3/
Ce qui laisse penser que ce n'est pas juste 1.1.1.1 qui est détourné par la LiveBox.

2/ Sous Windows 11, tracert (qui utilise de l'ICMP) donne ceci:
- Pour 1.1.1.0 que des timeout à chaque étape (la box ne figure pas dans la liste)
- pour 1.1.1.1 s’arrête à la box
- Pour 1.1.1.2 continue au delà de la box mais avec des timeout après la box
- Pour 1.1.1.3 comme pour 1.1.1.0
- Pour 1.1.1.4 et les suivantes fonctionnent normalement jusque chez cloudfare
- Pour 1.0.0.x fonctionnent normalement jusque chez cloudfare
Sous Linux,
- traceroute (qui utilise par défaut l'UDP) fonctionne normalement avec toutes les ip 1.1.1.x et 1.0.0.x (y compris donc 1.1.1.1)
- traceroute -T -p xxxx (utilisation de tcp sur le port xxx) et traceroute -I (utilisation de icmp) donnent les mêmes résultats que tracert de Windows.
En tcp, seuls les ports 80 et 443 semblent concernés. Avec, par exemple, 8080 ou 853 ou 88, on va bien jusque chez cloudfare.

Il y donc, au niveau de la LiveBox, un traitement particulier pour le subnet 1.1.1.0/30 au niveau ICMP et HTTP(S) mais pas au niveau UDP.
Ce sont donc les 3 services DoH de cloudfare qui sont impactés.

Je ne pense pas qu'il y ai grand chose à faire de notre coté si ce n'est faire remonter l'info à CloudFare (comme ils le suggèrent à la fin de https://developers.cloudflare.com/1.1.1.1/troubleshooting/) et s'en plaindre à Orange... Mais il y a plus de chances de voir cloudfare dupliquer ses services sur 1.1.1.{11/12/13} que Orange revoir son design...

Qu'en est il des livebox 6 et 7 sur ce point ?

buddy · « **Réponse #4 le:** 24 septembre 2025 à 12:06:21 »

Salut,

sur une livebox 7 (pro), le traceroute sous windows va bien jusqu'à chez CloudFare)
Firmware : Version G07.R02.C02_26

jimmy · « **Réponse #5 le:** 24 septembre 2025 à 12:16:41 »

Bonjour buddy,
Le ping n'est pas toujours représentatif de ce qui se passe au niveau tcp/https
Si vous cliquez sur ce lien https://1.1.1.1/help qu’obtenez vous ?
et si ça ne marche pas qu'obtenez vous avec https://1.0.0.1/help ?

kgersen · « **Réponse #6 le:** 24 septembre 2025 à 13:53:58 »

traceroute (Linux) a une option -T pour utiliser TCP : sudo traceroute -T -p 443 1.1.1.1

si pas Linux, nmap (multiplateform) a une option pour faire un traceroute aussi (nmap -Pn --traceroute -p 443 1.1.1.1)

buddy · « **Réponse #7 le:** 24 septembre 2025 à 14:33:06 »

Citation de: jimmy le 24 septembre 2025 à 12:16:41

Bonjour buddy,
Le ping n'est pas toujours représentatif de ce qui se passe au niveau tcp/https
Si vous cliquez sur ce lien https://1.1.1.1/help qu’obtenez vous ?
et si ça ne marche pas qu'obtenez vous avec https://1.0.0.1/help ?

J'ai bien la page de one.one.one.one sur https://1.1.1.1/help

Citer

Debug Information
Connected to 1.1.1.1   No
Using DNS over HTTPS (DoH)   No
Using DNS over TLS (DoT)   No
Using DNS over WARP   No
AS Name   i3D.net B.V
AS Number   49544
Cloudflare Data Center   MRS
Connectivity to Resolver IP Addresses
1.1.1.1   Yes
1.0.0.1   Yes
2606:4700:4700::1111   No
2606:4700:4700::1001   No

NB : je ne comprends pas pourquoi il m'affiche ça, je suis bien derrière une livebox pro (mais pas avec les DNS Orange).
AS Name i3D.net B.V
AS Number 49544

jimmy · « **Réponse #8 le:** 24 septembre 2025 à 14:42:49 »

Citer

Code: [Sélectionner]
Connectivity to Resolver IP Addresses 1.1.1.1 Yes 1.0.0.1 Yes

La livebox 7 (G07.R02.C02_26) n'a donc pas de problème avec 1.1.1.1
Merci Buddy.

buddy · « **Réponse #9 le:** 24 septembre 2025 à 15:07:25 »

Je m'avance peut être, mais pour moi le bug (non accessible des DNS sur 1.1.1.1) avait été corrigé partout, et c'est la dernière mise à jour du firmware qui a réintroduit le bug sur la LB5 manifestement.

~~NB : j'ai le bug sur une autre livebox Pro (firmware : G06.R05.C03_16 ) Je ne sais plus si c'est une livebox 5 ou 6. (elle a été changé récemment suite à une panne et je ne suis pas sur place).~~

Code: [Sélectionner]

 https://1.1.1.1/help
Connecting to 1.1.1.1:443... connected.
ERROR: cannot verify 1.1.1.1's certificate, issued by 'CN=Orange Devices Generic27 CA,O=Orange,C=FR':

[/s]
edit2 : c'est la même que la tienne.

acut3 · « **Réponse #10 le:** 24 septembre 2025 à 16:23:46 »

Je ne pourrai pas creuser car j'ai une LB7 dorénavant, mais la LB4 configure en interne une interface avec l'IP 1.1.1.1/30, utilisée pour le "Quantenna control channel" (Quantenna, c'est le chip wifi). Normalement cette interface est sur un VLAN différent (vlan id 2), mais il y a tout de même fort à parier que vos problèmes soient d'une manière ou d'une autre liée à ça. Rien de tel sur la LB7.

hwti · « **Réponse #11 le:** 24 septembre 2025 à 22:04:11 »

Oui, le SoC Quantenna n'est présent que sur les LB4 et LB5.
Il impose l'utilisation des adresses 1.1.1.1 / 1.1.1.2.

Comme l'ICMP n'a jamais fonctionné, je suppose que le contournement effectué l'a été via des règles iptables, plutôt que d'isoler totalement ce réseau de gestion avec des tables de routages dédiées ou des namespaces.
Peut-être que celle port les ports 80 et 443 a sauté.