Blocage ping en partage de connexion youprice (orange)
PascalHarbo Messages postés 3 Statut Membre -
Bonjour à tous,
Je rencontre un problème réseau assez spécifique en utilisant mon Samsung S24 Ultra en mode point d’accès mobile avec une SIM YouPrice (réseau Orange). J’ai également une eSIM Prixtel (réseau SFR), ce qui m’a permis de comparer les comportements.
???? Constat :
- Avec Prixtel (SFR) : le ping vers
github.comfonctionne parfaitement depuis mon PC connecté en Wi-Fi au téléphone. - Avec YouPrice (Orange) : le ping échoue systématiquement, que ce soit en IPv6 (adresse NAT64 du type
64:ff9b::...) ou en IPv4 (140.82.121.3).
???? Tests effectués :
ping github.com→ échec avec YouPrice, réponse avec Prixtel.ping -4 github.com→ échec avec YouPrice malgré résolution correcte.tracert github.com→ paquets perdus après le 6e saut (vers NAT64).https://github.comdans le navigateur → fonctionne, mais l’accès direct à l’IP déclenche une erreur SSL (normal).ipconfig→ le PC reçoit bien une IPv4 privée (10.x.x.x) et une IPv6 globale.
???? Hypothèse :
YouPrice semble utiliser une connectivité IPv6-only avec NAT64/DNS64, mais le relais NAT64 bloque ou ne traduit pas correctement les paquets ICMP (ping). Le partage de connexion Android pourrait aussi être en cause (filtrage ou mauvaise gestion du NAT).
❓ Questions :
- D’autres abonnés YouPrice (réseau Orange) ont-ils observé ce comportement ?
- Est-ce un blocage volontaire du ping/ICMP en mode modem ?
- Le même problème existe-t-il sur YouPrice avec réseau SFR ?
- Des solutions connues pour forcer une connectivité IPv4 complète en partage de connexion ?
Merci d’avance pour vos retours ou pistes. Je suis preneur de toute info technique ou retour d’expérience !
Pascal
- Blocage ping en partage de connexion youprice (orange)
- Gmail connexion - Guide
- Partage de photos - Guide
- Chromecast connexion - Guide
- Meilleur site partage abonnement - Accueil - Services en ligne
- Partage de connexion iphone - Guide
4 réponses
Je dois ajouter un élément important que je viens de tester :
-
- « À noter : lorsque j’active le VPN McAfee sur mon PC, le ping vers GitHub fonctionne parfaitement. Cela confirme que le blocage vient du routage ou du filtrage réseau côté YouPrice. »
Bonjour,
Pourquoi vouloir pinger le site s'il est normalement accessible?
à partir de ma Box SFR qui n'a rien à voir avec un point d'accès mobile le ping réussit à www.github.com mais échoue à 140.182.121.3.
Le ping du domaine le résout par définition vers l'IP via le DNS.
Le comportement est curieux, dans certains cas certains sites interdisent le ping vers leur serveur, dans d'autres, en dehors de considérations sur le pare-feu laissant passer ou pas les paquets ICMP (mais qui s'y opposerait alors en passant par le nom de domaine) c'est l'opérateur et/ou le dispositif de connexion qui peut le filtrer.
Salut,
retour d'expérience:
1/ avec tous les mobiles Android que j'ai eus jusqu'ici, je n'ai jamais eu d'adresse ipV6 autre que locale sur un partage de connexion (ipconfig/all)
2/ A priori www.github.com n'a pas d'adresse ipv6:
brupala@Mate-X-PRO:~$ host github.com github.com has address 140.82.121.3 github.com mail is handled by 1 aspmx.l.google.com. github.com mail is handled by 5 alt1.aspmx.l.google.com. github.com mail is handled by 10 alt4.aspmx.l.google.com. github.com mail is handled by 5 alt2.aspmx.l.google.com. github.com mail is handled by 10 alt3.aspmx.l.google.com. brupala@Mate-X-PRO:~$ host www.github.com www.github.com is an alias for github.com. github.com has address 140.82.121.4 github.com mail is handled by 1 aspmx.l.google.com. github.com mail is handled by 5 alt1.aspmx.l.google.com. github.com mail is handled by 5 alt2.aspmx.l.google.com. github.com mail is handled by 10 alt3.aspmx.l.google.com. github.com mail is handled by 10 alt4.aspmx.l.google.com. brupala@Mate-X-PRO:~$ brupala@Mate-X-PRO:~$ host google.com google.com has address 142.250.179.110 google.com has IPv6 address 2a00:1450:4007:806::200e google.com mail is handled by 10 smtp.google.com. brupala@Mate-X-PRO:~$
Après, internet sur réseau mobile, ce n'est pas tout à fait internet.
J'oubliais:
un partage de connexion mobile n'est pas un modem, mais un routeur nat.
Edit:
Par acquis de conscience, je viens de faire une nouvelle mesure, il ya quelques mois que je n'avais pas vérifié, un partage de connexion mobile sur ma connexion mobile actuelle, Bouygues:
pas d'ipv4 publique propre, sans doute celle du CGN en 89.85.242.111, une adresse ipv6 (2 même) dans le même /64 que le mobile en 2a04:
Carte réseau sans fil Wi-Fi :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201 160MHz
Adresse physique . . . . . . . . . . . : FA-BB-9E-E3-57-**
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a04:cec0:10e6:5f18:2197:26fa:c26c:****(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a04:cec0:10e6:5f18:dd16:c563:2051:****(préféré)
Adresse IPv6 de liaison locale. . . . .: fe80::4701:7bb3:7d47:213b%4(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 10.102.219.92(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : vendredi 3 octobre 2025 10:30:08
Bail expirant. . . . . . . . . . . . . : vendredi 3 octobre 2025 11:30:26
Passerelle par défaut. . . . . . . . . : fe80::d4f4:daff:feab:9e42%4
10.102.219.80
Serveur DHCP . . . . . . . . . . . . . : 10.102.219.80
IAID DHCPv6 . . . . . . . . . . . : 70528695
DUID de client DHCPv6. . . . . . . . : 00-03-00-01-FA-BB-9E-E3-57-**
Serveurs DNS. . . . . . . . . . . . . : 1.1.1.1
DoH: https://cloudflare-dns.com/dns-query
9.9.9.9
DoH: https://dns.quad9.net/dns-query
2a04:cec0:10e6:5f18::72
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Un ping vers www.github.com obtient bien une réponse via le CGN/nat64 de Bouygues:
C:\Users\Brupala>tracert www.github.com
Détermination de l’itinéraire vers github.com [140.82.121.3]
avec un maximum de 30 sauts :
1 160 ms 164 ms 143 ms 10.102.219.80
2 * * * Délai d’attente de la demande dépassé.
3 * * * Délai d’attente de la demande dépassé.
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 149 ms 143 ms 135 ms 10.110.147.50
7 170 ms 136 ms 137 ms 212.195.60.0
8 164 ms 149 ms 152 ms be41.cbr01-ntr.net.bbox.fr [212.194.171.132]
9 134 ms 148 ms 147 ms 62.34.2.248
10 263 ms 144 ms 136 ms 62.34.2.134
11 152 ms 156 ms 145 ms de-cix.fra.github.com [80.81.196.79]
12 * * * Délai d’attente de la demande dépassé.
13 * * * Délai d’attente de la demande dépassé.
14 173 ms 148 ms 151 ms lb-140-82-121-3-fra.github.com [140.82.121.3]
Itinéraire déterminé.
C:\Users\Brupala>ping github.com
Envoi d’une requête 'ping' sur github.com [64:ff9b::8c52:7903] avec 32 octets de données :
Réponse de 64:ff9b::8c52:7903 : temps=39 ms
Réponse de 64:ff9b::8c52:7903 : temps=57 ms
Réponse de 64:ff9b::8c52:7903 : temps=44 ms
Réponse de 64:ff9b::8c52:7903 : temps=47 ms
Statistiques Ping pour 64:ff9b::8c52:7903:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 39ms, Maximum = 57ms, Moyenne = 46ms
****
8c52:7903 correspond bien à 140.82.121.3 en hexadécimal
****
Tout ceci n'apporte rien à ton problème vu que ce n'est pas le même opérateur, mais pour indiquer que le partage de connexion Bouygues est maintenant, et c'est récent, je le découvre, derrière un nat64 avec seulement des ipv4 privées et des ipv6 publiques, comme était déjà leur réseau fixe parfois.
Après ça dépend peut-être des APN, je viens de voir que j'ai forcé sur APN IPV6 au lieu de ipV4 & ipV6, certainement pour un autre test avant.
bon j'ai eu une réponse de YOUPRICE qui pourra servir je pense à pas mal d'entre-vous, si vous êtes gênés par cet aspect, car après avoir paramètré l'APN en manuel ça fonctionne. voici ce qui est préconisé par leur support :
- Nom : youprice
- APN : orange
- Proxy : Non défini (par défaut)
- Port : Non défini (par défaut)
- Nom d'utilisateur : orange
- Mot de passe : orange
- Serveur : Non défini (par défaut)
- MMSC : http://mms.orange.fr
- Proxy MMS : 192.168.10.200
- Port MMS : 8080
- MCC : 208 (par défaut)
- MNC : 01
- Type d'authentification : PAP
- Type d'APN : default,supl,mms,xcap,dun
- Protocole APN : IPv4
- Protocole d'itinérance APN : IPv4
- Activer/désactiver APN : APN activé (par défaut)
- Support : Non défini (par défaut)
(P.S. l'APN paramétré par défaut n'est pas modifiable, il faudra donc en créer un nouveau et basculer sur celui-ci pour la connexion )
Je vous en souhaite bonne réception.