[FRnOG] [MISC] De l'usage du DPI sur le réseau

2022-06-23 Par sujet yoshi 

Bon matin la liste,

Comme nous sommes vendredi, je lance une interrogation qui me titille 
depuis un petit moment en espérant qu'elle puisse égailler, ou au moins 
animer, votre journée.


Dans quelles conditions, finalités, autorisations un opérateur peut il 
recourir au DPI et à l'analyse DNS sur son réseau ?


Sollicité sur la question via l'oiseau bleu, l'ARCEP n'a pas répondu 
pour l'instant.


J'ai néanmoins collecté quelques retours, notamment CPCE L.33.2 et CPCE 
L.33.14 qui bornent déjà pas mal la question (merci à Marc Ress et 
Alexandre Archambault).


N'étant pas juriste, ma compréhension des textes de loi est limitée.
De ce que j'en comprends, en dehors du CPCE L.33.14 et du CPCE 
L.33.2.III, le recours au DPI est interdit notamment pour les finalités 
mentionnées au CPCE L.33.2.IV. Mais évidement je peux comprendre de 
travers et toute précision est bienvenue.


Benjamin Bayard à précisé que l'opérateur de réseau ne pouvait pas faire 
grand chose au niveau DNS, contrairement à l'opérateur du résolveur qui 
dispose d'une plus grande latitude et de contraintes légales (notamment 
obligation de filtrer sur décision administrative et/ou judiciaire).


La question sous-jacente était, comment font donc les opérateurs pour 
affirmer que les GAFAM occupent plus de 50% de la bande passante 
utilisée sur leurs réseaux (justifiant de faire du lobbying en vu 
d'obtenir un financement de leurs réseaux en contrepartie de cet usage) ?


Stéphane Bortzmeyer a pointé du doigt qu'il n'était nullement nécessaire 
de recourir au DPI pour cette finalité et que l'usage de NetFlow/IPFix 
suffisait.


Une recherche sur le site de l'ARCEP ne fourni que peu de résultat.
Le communiqué 
https://www.arcep.fr/actualites/les-communiques-de-presse/detail/n/larcep-rend-public-son-avis-augouvernement-sur-la-mesure-de-la-structure-de-lusage-de-la-bande.html 
évoque le DPI mais n'en borne pas l'usage qui pourrait en être fait.


Enfin, quelle(s) éventuelle(s) sanction(s) pour les opérateurs qui y 
recourraient quand même ?


Également sollicités sur la question, Bouygues, Free, Numericable, 
Orange et SFR n'ont, sans réelle surprise, pas répondu pour le moment 
(hors réponses automatiques et support client qui ne sait évidement pas 
répondre à la question mais qui de toute façon n'est pas là pour ça).


J'en appelle donc à vos avis respectifs sur le sujet.

Au plaisir de vous lire.
Bonne journée.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Panne ADSL et mobile SFR, orange, Bouygues...

2022-06-23 Par sujet Vincent Duvernet 
Bonsoir.

Voilà je viens de passer dans la Sarthe pour chopper de la data.
Depuis plusieurs heures, plus de mobile ni d'ADSL au moins sur ces opérateurs 
sur un rayon d'au moins 15 km...
Si ça c'est pas de la grosse panne.
Je me demande où se trouve le point d'interconnexion commun entre tout ce petit 
monde.

Je cherche des informations dessus du quelqu'un a.

Merci.

Vincent

Obtenir Outlook pour Android

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] RE: ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

2022-06-23 Par sujet JCLB 
Et quand ils en fournissent, ils en abusent de ce bel IPv6.

Souvent l'APN de hotspot/tethering fournit un DNS qui effectue du DNS64.
Or si cette techno est excellente quand le terminal est conscient de se prendre 
du NAT64 (Android, Iphone iOS), elle ne l'est pas quand c'est un PC, une 
console de jeu, etc.

Et je ne vois pas l'avantage pour les ISP à pousser DNS64+NAT64 sur le 
tethering, ça consomme toujours des sessions NAT stateful sur des boitiers, et 
ça n'empêche pas de devoir fournir une connectivité IPv4 pour les apps qui ne 
font pas de requêtes  ou utilisent une IPv4 littérale.

Si quelqu'un d'Orange et Bouygues me lit, SVP séparez vos APN et arrêtez de 
faire du DNS64 sur le mode hotspot.
Je n'ai pas testé le hotspot de SFR ou Free depuis bien longtemps.

Jean-Charles BISECCO

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Xavier 
Beaudouin via frnog
Envoyé : jeudi 23 juin 2022 12:04
À : frnog 
Objet : Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 
4G entre EuroInformation Telecom et Neo Telecoms

Hello,

> Je vais peut être dire une énorme bêtise, mais il me semble que le 
> problème vient du fait que le nombre de connexions actives par client 
> est limité par les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de 
> clients derrière chaque IP, ils "protègent" les ressources en mémoire 
> de leurs équipements en restreignant ces connexions.

Et ces opérateurs ne fournissent pas d'IPv6 aux clients mobiles ?
Parce que ça permettrais de limiter les problèmes liées a la demande de 
ressource stupides pour NATer l'ipv4.

Parce qu'en 2022... voila...

/Xavier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problème d'accès à une partie d'un site web

2022-06-23 Par sujet David Ponzone 
Hervé,

Merci beaucoup pour la confirmation, je peux décemment répondre à mon client 
que le problème est côté bca.fr 


> Le 23 juin 2022 à 11:24, Herve Perraud  a écrit :
> 
> Bonjour,
> 
> 
> Je viens de tester: il y a des similitudes avec le pb que nous rencontrons..
> Sur mon poste, depuis free, j'arrive bien sur le portail réparateur avec 
> firefox, pas avec chrome
> 
> 
> Par contre, pour nous, le pb se pose sur un BigIP, mais utilisé en portail 
> SSL.
> Notre appli fonctionne bien avec firefox
> Tout ce qui est basé sur chrome ne fonctionne pas..
> 
> On voit qu'à un moment chrome ré-écrit la requête pour passer en direct (sans 
> passer par le portail SSL), ce qui est refusé par les ACL
> La "bonne" requête (comme ci-dessous) fonctionne pourtant bien avec chrome.. 
> C'est juste la ré-écriture à un moment qui "bugge".
> 
> Le plus drôle :-(, c'est que chrome avec une extension switch user-agent 
> positionnée sur firefox fonctionne..
> (même chose avec bca.fr pour moi).
> 
> Pour l'instant, on pense que c'est l'appli (pas ouverte) qui gère mal/pas le 
> user-agent..
> Mais on est encore en cours d'investigations
> 
> Peut-être que de votre côté, ça marche quand l'accès à l'appli est possible 
> en direct..
> 
> 
> Bon courage,
> 
> A+
> 
> 
> 
> - Mail original -
> De: "David Ponzone" 
> À: "Pierre LANCASTRE" 
> Cc: "Alain Bitschiné" , "frnog-tech" 
> 
> Envoyé: Mercredi 22 Juin 2022 11:10:41
> Objet: Re: [FRnOG] [TECH] Problème d'accès à une partie d'un site web
> 
> Peu probable mais merci de l’info, ça peut servir.
> 
> J’ai un peu avancé en creusant côté client et côté site.
> 
> En fait, le client s’est planté, ça marche quand on accède directement à:
> https://www.bca.fr/reparateur-web/login.action 
> 
> 
> Ce qui ne marche pas, c’est quand on y arrive par:
> https://www.bca.fr/ 
> (puis Votre Espace, puis Portail Réparateur)
> 
> Parce qu’en passant par là, on est envoyé sur:
> http://reparateur.bca.fr/reparateur-web/login.action 
> 
> qui fait un 302 vers:
> https://www.bca.fr/reparateur-web/login.action 
> 
> 
> Et ça semble être le 302 qui ne passe pas depuis les PC (tous à priori) du 
> client.
> Pareil avec Edge et Chrome.
> reparateur.bca.fr et www.bca.fr  arrivent sur la même IP, 
> et il y a bien un certificat pour *.bca.fr  sur les 2.
> 
> Une petite recherche sur F5 et HTTP 302 montrent que c’est un sujet à 
> problème.
> 
>> Le 21 juin 2022 à 23:01, Pierre LANCASTRE  a 
>> écrit :
>> 
>> Hello
>> 
>> Peut être autre piste (j'ai eu le cas @home) : carte réseau du pc client 
>> configure en Jumbo mtu. Le lb du serveur syn/ack en Jumbo. Et paf ça marche 
>> plus. --> du coup chez moi je mss clamp a 1460 tout ce qui va vers le wan. 
>> Je reste en Jumbo en local pour optimiser les transfers avec le NAS syno.
>> 
>> ++
>> 
>> Pierre
>> 
>> Le mar. 21 juin 2022 à 22:46, Alain Bitschiné via frnog > > a écrit :
>> Bonjour,
>> 
>> Qu’est-ce qui te fait penser à un problème de MTU ? Tu as de la 
>> fragmentation côté client ?
>> Côté serveur je ne vois pas de réduction de MTU. De chez moi le TCP MSS est 
>> à 1460 sur les paquets SYN dans les deux sens, et je ne vois pas de perte 
>> sur les gros paquets.
>> 
>> Une piste si tu as de la fragmentation côté client... il y a une chose à 
>> savoir sur les F5 BigIP : ils n’aiment pas trop les paquets doublement 
>> fragmentés. Ils n’acceptent pas les fragments trop petits (je n’ai plus la 
>> limite en tête) si ce n’est pas le fragment final.
>> J’ai déjà vu ça dans le cas d’un client qui envoyait des paquets fragmentés, 
>> qui étaient ensuite à nouveau fragmentés à cause d’un tunnel GRE pour une 
>> protection DDoS côté serveur. Le F5 bloquait le petit fragment 
>> intermédiaire… et donc la session TCP. Ici ça a été résolu en ajustant le 
>> TCP MSS au niveau des routeurs d’accès Internet côté serveur.
>> Je doute que le F5 BigIP casse le PMTU Discovery. En revanche, un firewall 
>> sur le chemin pourrait bloquer les paquets ICMP nécessaires...
>> 
>> Alain Bitschiné
>> 
>>> Le 21 juin 2022 à 20:36, David Ponzone >> > a écrit :
>>> 
>>> J’ai un problème assez étrange, et je cherche des éléments de réponse.
>>> 
>>> Un client peut accéder à:
>>> 
>>> https://www.bca.fr 
>>> Mais pas à:
>>> https://www.bca.fr/reparateur-web/login.action 
>>>  
>>> >> >
>>> 
>>> Alors que la seconde URL est parfaitement joignable pour moi (donc même AS 
>>> que mon client) ou depuis Bouygues FTTH ou depuis Orange Mobile.
>>> Plus délicat: connecté en VPN SSL pour accéder au site depuis la même IP 
>>> publique que

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet David Ponzone 
Merci pour la confirmation, je suis donc pas fou.

Comme je doute d’arriver à faire en sorte que le MVNO fasse changer ça chez 
Bouygues, je pense qu’on va oublier Bouygues.



> Le 23 juin 2022 à 14:01, Gael de Violet.tel  a 
> écrit :
> 
> Bonjour,
> 
> Je confirme, pour y avoir bossé, que l'infra UTM Bytel entreprise utilise 
> bien Fortinet.
> 
> Chez EIT, ou j'ai des connexion aussi, récemment racheté, c'est le flou 
> artistique.
> 
> ils ne communiquent que très peu, y compris en interne, et ne réagissent que, 
> quand le support s'acharne.
> 
> pour ceux que ca intéresse, le cœur full MVNO est géré via Ericsson et ils 
> poussent à fond pour de la migration light Bytel ou MVNO Orange quand ils 
> sont dans les choux après avoir excommunié SFR.
> 
> /off/ bien entendu
> 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

2022-06-23 Par sujet Greg 
Chez EI il existe une option pour augmenter les ports au niveau de CGNAT il
me semble.

чт, 23 июн. 2022 г. в 14:00, Lucas :

> On 23/06/22 at 11:49 +0200, Matthieu Racine wrote:
> > Je vais peut être dire une énorme bêtise, mais il me semble que le
> problème
> > vient du fait que le nombre de connexions actives par client est limité
> par
> > les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de clients derrière
> chaque
> > IP, ils "protègent" les ressources en mémoire de leurs équipements en
> > restreignant ces connexions.
>
> Effectivement, j'arrive à établir (et à maintenir) environ 230
> connexions TCP en parallèle, mais quand j'en rajoute, je reproduis le
> problème. Donc c'est effectivement plutôt un problème de nombre max de
> connexions autorisées.
>
> > Je ne sais pas si cette restriction est également active sur les autres
> > opérateurs avec CGNAT...
>
> Avec un abonnement Sosh, je ne reproduis pas le problème (ça fonctionne
> jusqu'à au moins 1000 connexions)
>
> Lucas
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet Gael de Violet.tel 

Bonjour,

Je confirme, pour y avoir bossé, que l'infra UTM Bytel entreprise 
utilise bien Fortinet.


Chez EIT, ou j'ai des connexion aussi, récemment racheté, c'est le flou 
artistique.


ils ne communiquent que très peu, y compris en interne, et ne réagissent 
que, quand le support s'acharne.


pour ceux que ca intéresse, le cœur full MVNO est géré via Ericsson et 
ils poussent à fond pour de la migration light Bytel ou MVNO Orange 
quand ils sont dans les choux après avoir excommunié SFR.


/off/ bien entendu

Gaël


Le 23/06/2022 à 10:55, David Ponzone a écrit :

Richard,

1/ moi j’ai le problème chez un MVNO light, donc c’est bien Bouygues et c’est 
de mon cas que je parlais
2/ Lucas a le problème aussi sur une carte EIT. Après, on ne sait pas 
formellement si cette carte est sur le full-MVNO ou pas (mais à priori oui, 
d’après un autre sujet qu’il a ouvert hier sur un problème de rate-limiting 
excessif). Comme EIT c’est Bouygues maintenant, on peut aussi penser qu’is ont 
acheté le même équipement pour gérer leur CGNAT, ou que Bouygues le fait pour 
eux maintenant, auquel cas: EIT/Bouygues peuvent le faire :)


Le 23 juin 2022 à 10:49, Richard Klein  a écrit :

Bonjour
@David ,en quoi Bouygues peux le faire ?
Lorsque tu utilises un full MVNO je crois que que le MVNO utilise bien sa 
propre infra pour sortir sur le net et pas celle de Bouygues qui est 
l'opérateur hôte côtes antennaire.
La preuve est que ton ip publique sur ta sim est probablement un pool qui n'est 
pas chez Bouygues. Donc ne pas faire de raccourcis :-)

Richard

Le jeu. 23 juin 2022 à 10:43, David Ponzone mailto:david.ponz...@gmail.com>> a écrit :
Matthieu,

Merci, non pas de m’avoir envoyé la commande car je l’avais déjà fait et ça 
marchait pas, mais de m’avoir fait me replonger dans le problème.
J’ai trouvé en 2 min.
J’avais désactivé SCCP dans la VDOM mais pas dans la VDOM root qui est la 
default-gw de l’autre VDOM.
S’il y a vraiment un truc qui est insupportable chez Fortinet, c’est bien ces ALG 
VOIP activés par défaut, même dans un VDOM root qui fait que du routage BGP4, avec 
une policy ALL->ALL.
C’est contre-intuitif au possible.

Donc si j’ai pu le faire, Bouygues peut aussi :)


Le 23 juin 2022 à 10:32, Matthieu Racine mailto:m.rac...@free.fr>> a écrit :


Le 23/06/2022 à 03:04, David Ponzone a écrit :

Et justement, il est connu que FortiOS reconnait l’échange du protocole 
Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à cause 
d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai pas cherché 
très très fort ceci dit, mais c’est plus compliqué que pour couper le SIP ALG).

Hello,

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-disable-ALG-for-SCCP-traffic-to-allow-TCP/ta-p/191898?externalID=FD46259
  


MR.


---
Liste de diffusion du FRnOG
http://www.frnog.org/  


---
Liste de diffusion du FRnOG
http://www.frnog.org/  


---
Liste de diffusion du FRnOG
http://www.frnog.org/

--


 Gaël LESTRA

Dirigeant

Violet.tel&com




0465844484  | 0783424133 

g...@violet.tel 

www.violet.tel 

9 rue caffarelli, 06200 Nice



facebook 
twitter 
linkedin   
instagram 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

2022-06-23 Par sujet Lucas 
On 23/06/22 at 11:49 +0200, Matthieu Racine wrote:
> Je vais peut être dire une énorme bêtise, mais il me semble que le problème
> vient du fait que le nombre de connexions actives par client est limité par
> les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de clients derrière chaque
> IP, ils "protègent" les ressources en mémoire de leurs équipements en
> restreignant ces connexions.

Effectivement, j'arrive à établir (et à maintenir) environ 230
connexions TCP en parallèle, mais quand j'en rajoute, je reproduis le
problème. Donc c'est effectivement plutôt un problème de nombre max de
connexions autorisées.

> Je ne sais pas si cette restriction est également active sur les autres
> opérateurs avec CGNAT...

Avec un abonnement Sosh, je ne reproduis pas le problème (ça fonctionne
jusqu'à au moins 1000 connexions)

Lucas


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

2022-06-23 Par sujet Xavier Beaudouin via frnog 
Hello,

> Je vais peut être dire une énorme bêtise, mais il me semble que le
> problème vient du fait que le nombre de connexions actives par client
> est limité par les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de
> clients derrière chaque IP, ils "protègent" les ressources en mémoire de
> leurs équipements en restreignant ces connexions.

Et ces opérateurs ne fournissent pas d'IPv6 aux clients mobiles ?
Parce que ça permettrais de limiter les problèmes liées a la demande de 
ressource stupides pour NATer l'ipv4.

Parce qu'en 2022... voila...

/Xavier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] ICMP "Communication Administratively Prohibited" en 4G entre EuroInformation Telecom et Neo Telecoms

2022-06-23 Par sujet Matthieu Racine 
Je vais peut être dire une énorme bêtise, mais il me semble que le 
problème vient du fait que le nombre de connexions actives par client 
est limité par les routeurs CGNAT de BTBD (ex EIT). Vu le nombre de 
clients derrière chaque IP, ils "protègent" les ressources en mémoire de 
leurs équipements en restreignant ces connexions.


Je ne sais pas si cette restriction est également active sur les autres 
opérateurs avec CGNAT...


Avec un téléphone portable ça ne se sent pas (trop), par contre avec un 
réseau natté derrière un routeur 4G, c'est pénible...


MR.

Le 22/06/2022 à 21:19, Lucas a écrit :

Bonjour,

J'ai un abonnement 4G NRJ Mobile (une des marques de EuroInformation
Telecom -- maintenant Bouygues Telecom Business-Distribution) que
j'utilise dans un routeur 4G.

De manière aléatoire, je recois des ICMP type 3 / code 13
("Communication Administratively Prohibited") en réponse à des SYN
TCP, a priori surtout lorsque je navigue sur des sites qui génèrent
beaucoup de connexions.

Je le reproduis de manière systématique au bout de quelques secondes avec:
mtr --tcp -P 443 www.nrjmobile.fr

Un traceroute avant l'apparition du problème:

$ tcptraceroute -q 1 www.nrjmobile.fr 443
Tracing the path to www.nrjmobile.fr (145.226.174.108) on TCP port 443 (https), 
30 hops max
  1  192.168.11.1  0.570 ms
  2  *
  3  *
  4  10.64.96.62  33.906 ms
  5  *
  6  ei-telecom-gw2.tcr2.th2.par.cust.as8218.eu (83.167.60.227)  40.152 ms
  7  ae25.tcr2.th2.par.core.as8218.eu (83.167.60.226)  38.294 ms
  8  ae24.ter4.eqx2.par.core.as8218.eu (83.167.56.193)  37.433 ms
  9  193.253.13.102  38.469 ms
  [...]
22  lil-www.nrjmobile.fr (145.226.174.108)  45.029 ms
23  lil-www.nrjmobile.fr (145.226.174.108) [open]  39.315 ms

Un traceroute quand le problème se produit:

Tracing the path to www.nrjmobile.fr (145.226.174.108) on TCP port 443 (https), 
30 hops max
  1  192.168.11.1  0.526 ms
  2  *
  3  10.64.35.94  34.028 ms
  4  10.64.96.62  30.197 ms
  5  10.64.96.57  29.182 ms
  6  ei-telecom-gw2.tcr2.th2.par.cust.as8218.eu (83.167.60.227)  43.163 ms
  7  185.228.229.172  37.179 ms !A

Le routeur qui renvoie l'erreur est toujours dans la plage
185.228.229/24, qui appartient à EuroInformation Telecom.

Je le reproduis sur toutes les destinations qui transitent par Neo
Telecoms (as8218.eu), mais pas sur les autres (celles qui peer
directement avec EIT ? mais il y en a peu, par exemple www.google.com).

Ca ressemble à un problème de rate limiting trop agressif (?).

J'ai contacté l'assistance technique, mais sans réponse satisfaisante
("la couverture est OK, ça doit être un problème du routeur").

Je pense que je vais juste changer d'opérateur, mais je suis curieux de
savoir si quelqu'un a une explication.

Je me demandais aussi s'il y avait un site qui référence les atteintes à
la neutralité du net par les opérateurs mobiles, histoire de savoir à
quoi m'attendre (j'ai l'impression que Sosh est mieux de ce côté là,
mais je me demande comment se positionnent les autres).

Lucas


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problème d'accès à une partie d'un site web

2022-06-23 Par sujet Herve Perraud 
Bonjour,


Je viens de tester: il y a des similitudes avec le pb que nous rencontrons..
Sur mon poste, depuis free, j'arrive bien sur le portail réparateur avec 
firefox, pas avec chrome


Par contre, pour nous, le pb se pose sur un BigIP, mais utilisé en portail SSL.
Notre appli fonctionne bien avec firefox
Tout ce qui est basé sur chrome ne fonctionne pas..

On voit qu'à un moment chrome ré-écrit la requête pour passer en direct (sans 
passer par le portail SSL), ce qui est refusé par les ACL
La "bonne" requête (comme ci-dessous) fonctionne pourtant bien avec chrome.. 
C'est juste la ré-écriture à un moment qui "bugge".

Le plus drôle :-(, c'est que chrome avec une extension switch user-agent 
positionnée sur firefox fonctionne..
(même chose avec bca.fr pour moi).

Pour l'instant, on pense que c'est l'appli (pas ouverte) qui gère mal/pas le 
user-agent..
Mais on est encore en cours d'investigations

Peut-être que de votre côté, ça marche quand l'accès à l'appli est possible en 
direct..


Bon courage,

A+



- Mail original -
De: "David Ponzone" 
À: "Pierre LANCASTRE" 
Cc: "Alain Bitschiné" , "frnog-tech" 
Envoyé: Mercredi 22 Juin 2022 11:10:41
Objet: Re: [FRnOG] [TECH] Problème d'accès à une partie d'un site web

Peu probable mais merci de l’info, ça peut servir.

J’ai un peu avancé en creusant côté client et côté site.

En fait, le client s’est planté, ça marche quand on accède directement à:
https://www.bca.fr/reparateur-web/login.action 


Ce qui ne marche pas, c’est quand on y arrive par:
https://www.bca.fr/ 
(puis Votre Espace, puis Portail Réparateur)

Parce qu’en passant par là, on est envoyé sur:
http://reparateur.bca.fr/reparateur-web/login.action 

qui fait un 302 vers:
https://www.bca.fr/reparateur-web/login.action 


Et ça semble être le 302 qui ne passe pas depuis les PC (tous à priori) du 
client.
Pareil avec Edge et Chrome.
reparateur.bca.fr et www.bca.fr  arrivent sur la même IP, 
et il y a bien un certificat pour *.bca.fr  sur les 2.

Une petite recherche sur F5 et HTTP 302 montrent que c’est un sujet à problème.

> Le 21 juin 2022 à 23:01, Pierre LANCASTRE  a 
> écrit :
> 
> Hello
> 
> Peut être autre piste (j'ai eu le cas @home) : carte réseau du pc client 
> configure en Jumbo mtu. Le lb du serveur syn/ack en Jumbo. Et paf ça marche 
> plus. --> du coup chez moi je mss clamp a 1460 tout ce qui va vers le wan. Je 
> reste en Jumbo en local pour optimiser les transfers avec le NAS syno.
> 
> ++
> 
> Pierre
> 
> Le mar. 21 juin 2022 à 22:46, Alain Bitschiné via frnog  > a écrit :
> Bonjour,
> 
> Qu’est-ce qui te fait penser à un problème de MTU ? Tu as de la fragmentation 
> côté client ?
> Côté serveur je ne vois pas de réduction de MTU. De chez moi le TCP MSS est à 
> 1460 sur les paquets SYN dans les deux sens, et je ne vois pas de perte sur 
> les gros paquets.
> 
> Une piste si tu as de la fragmentation côté client... il y a une chose à 
> savoir sur les F5 BigIP : ils n’aiment pas trop les paquets doublement 
> fragmentés. Ils n’acceptent pas les fragments trop petits (je n’ai plus la 
> limite en tête) si ce n’est pas le fragment final.
> J’ai déjà vu ça dans le cas d’un client qui envoyait des paquets fragmentés, 
> qui étaient ensuite à nouveau fragmentés à cause d’un tunnel GRE pour une 
> protection DDoS côté serveur. Le F5 bloquait le petit fragment intermédiaire… 
> et donc la session TCP. Ici ça a été résolu en ajustant le TCP MSS au niveau 
> des routeurs d’accès Internet côté serveur.
> Je doute que le F5 BigIP casse le PMTU Discovery. En revanche, un firewall 
> sur le chemin pourrait bloquer les paquets ICMP nécessaires...
> 
> Alain Bitschiné
> 
> > Le 21 juin 2022 à 20:36, David Ponzone  > > a écrit :
> > 
> > J’ai un problème assez étrange, et je cherche des éléments de réponse.
> > 
> > Un client peut accéder à:
> > 
> > https://www.bca.fr 
> > Mais pas à:
> > https://www.bca.fr/reparateur-web/login.action 
> >  
> >  > >
> > 
> > Alors que la seconde URL est parfaitement joignable pour moi (donc même AS 
> > que mon client) ou depuis Bouygues FTTH ou depuis Orange Mobile.
> > Plus délicat: connecté en VPN SSL pour accéder au site depuis la même IP 
> > publique que mon client: ça marche.
> > 
> > Le client ne peut pas non plus accéder à la seconde URL depuis un site chez 
> > SFR.
> > 
> > Le site www.bca.fr   > > est chez OBS, et semble être derrière un BigIP (si 
> > j’en crois la réponse du serveur HTTP).
> > 
> > J’ai donc tendance à penser que c’est le BigIP qui va pas

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet David Ponzone 
Richard,

1/ moi j’ai le problème chez un MVNO light, donc c’est bien Bouygues et c’est 
de mon cas que je parlais
2/ Lucas a le problème aussi sur une carte EIT. Après, on ne sait pas 
formellement si cette carte est sur le full-MVNO ou pas (mais à priori oui, 
d’après un autre sujet qu’il a ouvert hier sur un problème de rate-limiting 
excessif). Comme EIT c’est Bouygues maintenant, on peut aussi penser qu’is ont 
acheté le même équipement pour gérer leur CGNAT, ou que Bouygues le fait pour 
eux maintenant, auquel cas: EIT/Bouygues peuvent le faire :)

> Le 23 juin 2022 à 10:49, Richard Klein  a écrit :
> 
> Bonjour
> @David ,en quoi Bouygues peux le faire ?
> Lorsque tu utilises un full MVNO je crois que que le MVNO utilise bien sa 
> propre infra pour sortir sur le net et pas celle de Bouygues qui est 
> l'opérateur hôte côtes antennaire.
> La preuve est que ton ip publique sur ta sim est probablement un pool qui 
> n'est pas chez Bouygues. Donc ne pas faire de raccourcis :-)
> 
> Richard
> 
> Le jeu. 23 juin 2022 à 10:43, David Ponzone  > a écrit :
> Matthieu,
> 
> Merci, non pas de m’avoir envoyé la commande car je l’avais déjà fait et ça 
> marchait pas, mais de m’avoir fait me replonger dans le problème.
> J’ai trouvé en 2 min.
> J’avais désactivé SCCP dans la VDOM mais pas dans la VDOM root qui est la 
> default-gw de l’autre VDOM.
> S’il y a vraiment un truc qui est insupportable chez Fortinet, c’est bien ces 
> ALG VOIP activés par défaut, même dans un VDOM root qui fait que du routage 
> BGP4, avec une policy ALL->ALL.
> C’est contre-intuitif au possible.
> 
> Donc si j’ai pu le faire, Bouygues peut aussi :)
> 
> > Le 23 juin 2022 à 10:32, Matthieu Racine  > > a écrit :
> > 
> > 
> > Le 23/06/2022 à 03:04, David Ponzone a écrit :
> >> Et justement, il est connu que FortiOS reconnait l’échange du protocole 
> >> Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à 
> >> cause d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai 
> >> pas cherché très très fort ceci dit, mais c’est plus compliqué que pour 
> >> couper le SIP ALG).
> > 
> > Hello,
> > 
> > https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-disable-ALG-for-SCCP-traffic-to-allow-TCP/ta-p/191898?externalID=FD46259
> >  
> > 
> > 
> > MR.
> > 
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/ 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet Richard Klein 
Bonjour
@David ,en quoi Bouygues peux le faire ?
Lorsque tu utilises un full MVNO je crois que que le MVNO utilise bien sa
propre infra pour sortir sur le net et pas celle de Bouygues qui est
l'opérateur hôte côtes antennaire.
La preuve est que ton ip publique sur ta sim est probablement un pool qui
n'est pas chez Bouygues. Donc ne pas faire de raccourcis :-)

Richard

Le jeu. 23 juin 2022 à 10:43, David Ponzone  a
écrit :

> Matthieu,
>
> Merci, non pas de m’avoir envoyé la commande car je l’avais déjà fait et
> ça marchait pas, mais de m’avoir fait me replonger dans le problème.
> J’ai trouvé en 2 min.
> J’avais désactivé SCCP dans la VDOM mais pas dans la VDOM root qui est la
> default-gw de l’autre VDOM.
> S’il y a vraiment un truc qui est insupportable chez Fortinet, c’est bien
> ces ALG VOIP activés par défaut, même dans un VDOM root qui fait que du
> routage BGP4, avec une policy ALL->ALL.
> C’est contre-intuitif au possible.
>
> Donc si j’ai pu le faire, Bouygues peut aussi :)
>
> > Le 23 juin 2022 à 10:32, Matthieu Racine  a écrit :
> >
> >
> > Le 23/06/2022 à 03:04, David Ponzone a écrit :
> >> Et justement, il est connu que FortiOS reconnait l’échange du protocole
> Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à
> cause d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai
> pas cherché très très fort ceci dit, mais c’est plus compliqué que pour
> couper le SIP ALG).
> >
> > Hello,
> >
> >
> https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-disable-ALG-for-SCCP-traffic-to-allow-TCP/ta-p/191898?externalID=FD46259
> >
> > MR.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet David Ponzone 
Matthieu,

Merci, non pas de m’avoir envoyé la commande car je l’avais déjà fait et ça 
marchait pas, mais de m’avoir fait me replonger dans le problème.
J’ai trouvé en 2 min.
J’avais désactivé SCCP dans la VDOM mais pas dans la VDOM root qui est la 
default-gw de l’autre VDOM.
S’il y a vraiment un truc qui est insupportable chez Fortinet, c’est bien ces 
ALG VOIP activés par défaut, même dans un VDOM root qui fait que du routage 
BGP4, avec une policy ALL->ALL.
C’est contre-intuitif au possible.

Donc si j’ai pu le faire, Bouygues peut aussi :)

> Le 23 juin 2022 à 10:32, Matthieu Racine  a écrit :
> 
> 
> Le 23/06/2022 à 03:04, David Ponzone a écrit :
>> Et justement, il est connu que FortiOS reconnait l’échange du protocole 
>> Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à cause 
>> d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai pas 
>> cherché très très fort ceci dit, mais c’est plus compliqué que pour couper 
>> le SIP ALG).
> 
> Hello,
> 
> https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-disable-ALG-for-SCCP-traffic-to-allow-TCP/ta-p/191898?externalID=FD46259
> 
> MR.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet Matthieu Racine 



Le 23/06/2022 à 03:04, David Ponzone a écrit :

Et justement, il est connu que FortiOS reconnait l’échange du protocole 
Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à cause 
d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai pas cherché 
très très fort ceci dit, mais c’est plus compliqué que pour couper le SIP ALG).


Hello,

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-disable-ALG-for-SCCP-traffic-to-allow-TCP/ta-p/191898?externalID=FD46259

MR.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet David Ponzone 
On avance :)

Je confirme le TTL altéré par un équipement à 2 hops du terminal.

Je t’ai gardé le meilleur pour la fin: le port 5060 est concerné aussi.
Encore un point commun avec Fortinet qui par défaut fait de la merde sur SIP 
(ça se désactive mais c’est pas trivial).

Le port MGCP n’est pas concerné par contre.


> Le 23 juin 2022 à 09:22, Lucas  a écrit :
> 
> Intéressant. Je reproduis le problème avec mon abonnement NRJ Mobile
> (EIT), par exemple avec:
> server$ nc -l -p 2000 > t
> client$ dd if=/dev/urandom bs=5k count=1 > t
> client$ nc -N server 2000 < t
> 
> Ce qui est amusant, c'est que le client recoit bien des ACK en échange
> des données, mais ce n'est pas le serveur qui les envoie.  D'ailleurs le
> TTL des ACK est de 62, contre un TTL de 51 pour les ACK d'un échange
> normal (sur un autre port).
> 
> La fin de connexion n'est pas filtrée, mais est réécrite pour que les
> données qui ont été interceptées mais acquittées par la middlebox ne
> perturbent pas l'échange.
> Vu du client, ça donne:
> 53160 → 2000 [FIN, ACK] Seq=5121 Ack=1 Win=64256 Len=0 TSval=3941021092 
> TSecr=1817006976
> 2000 → 53160 [FIN, ACK] Seq=1 Ack=5122 Win=180224 Len=0 TSval=1817006982 
> TSecr=3941021091
> 53160 → 2000 [ACK] Seq=5122 Ack=2 Win=64256 Len=0 TSval=3941021152 
> TSecr=1817006982
> mais vu du serveur, ça donne:
> 2612 → 2000 [FIN, ACK] Seq=1 Ack=1 Win=180224 Len=0 TSval=1817006982 
> TSecr=2630718538
> 2000 → 2612 [FIN, ACK] Seq=1 Ack=2 Win=65280 Len=0 TSval=2630718559 
> TSecr=1817006982
> 2612 → 2000 [ACK] Seq=2 Ack=2 Win=180224 Len=0 TSval=1817006984 
> TSecr=2630718559
> => le numéro de séquence ("relatif", c'est ce que wireshark affiche) est
> 5121 vu du client, mais 1 vu du serveur.
> 
> Le TTL élevé (62) fait penser que c'est l'un des premiers équipements
> qui réalise cette opération, ce qui expliquerait pourquoi on voit le
> problème à la fois avec Bouygues et EIT.
> 
> Lucas


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [BIZ] SIM Bouygues MVNO: pas neutre ?

2022-06-23 Par sujet Lucas 
On 23/06/22 at 03:04 +0200, David Ponzone wrote:
> > Le 22 juin 2022 à 21:31, Lucas  a écrit :
> > 
> > Bonjour David,
> > 
> > On 22/06/22 at 20:53 +0200, David Ponzone wrote:
> >> Petite question aux utilisateurs d’une offre MVNO(-light) Bouygues:
> >> 
> >> Vous avez remarqué qu’il y avait des restrictions IP sur le traffic data ?
> > 
> > Ton mail me fait remarquer qu'un mail que j'avais essayé d'envoyer il y
> > a quelques jours, concernant un MVNO Bouygues, n'est pas passé. Je viens
> > de le renvoyer.
> > 
> > Tu constates ça avec quel MVNO ? Attention, je crois que certains MVNO
> > Bouygues (ceux de ex-EuroInformation Telecom) conservent un coeur de
> > réseau spécifique (c'est mon cas avec NRJ Mobile).
> 
> EIT est un full-MVNO. A ce titre, on peut imaginer qu’ils ont fait un choix 
> différent pour le CGNAT.
> A priori, tous les MVNO(-light) de Bouygues devraient avoir le problème 
> puisqu’ils se reposent totalement sur l’infra Bouygues.
> 
> >> Du genre les communications TCP sur certains ports qui passent mais sont 
> >> altérées par le CGNAT.
> > 
> > Que constates-tu exactement comme altération ?
> 
> L’outil Speedtest de Mikrotik permet de tester la bande passante up/down 
> entre 2 Mikrotiks.
> Et bien ça échoue.
> Le début de la connexion se fait normalement.
> Si A est le Mikrotik derrière le CGNAT, ça donne:
> A (TCP RANDOM)  — — —SYN—— — —>  B (TCP 2000)
> A ((TCP RANDOM) <———SYN ACK——— B (TCP 2000)
> A (TCP RANDOM)  — — — ACK —— — —> B (TCP 2000)
> 
> Ensuite B envoie un TCP PSH à A.
> Avec le CGNAT Bouygues, A ne reçoit jamais ce PSH.
> 
> Ce qui est rigolo, c’est que si à la place du CGNAT Bouygues, j’ai un FTTO 
> propre mais qui traverse ensuite un Fortinet , j’ai le MÊME comportement.
> Et justement, il est connu que FortiOS reconnait l’échange du protocole 
> Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à cause 
> d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai pas 
> cherché très très fort ceci dit, mais c’est plus compliqué que pour couper le 
> SIP ALG).
> 
> De là à penser que le CGNAT Bouygues, c’est du Fortinet, il n’y a qu’un pas.
> Vu en plus que Bouygues et Fortinet ont communiqué il y a quelques années sur 
> un partenariat sur du Fortigate-VM...
> 
> Sur le fond, je vais pas faire un cake pour un port TCP mais comme je peux 
> pas savoir s’il y en a pas (plein) d’autres, ça va être bye-bye Bouygues.

Intéressant. Je reproduis le problème avec mon abonnement NRJ Mobile
(EIT), par exemple avec:
server$ nc -l -p 2000 > t
client$ dd if=/dev/urandom bs=5k count=1 > t
client$ nc -N server 2000 < t

Ce qui est amusant, c'est que le client recoit bien des ACK en échange
des données, mais ce n'est pas le serveur qui les envoie.  D'ailleurs le
TTL des ACK est de 62, contre un TTL de 51 pour les ACK d'un échange
normal (sur un autre port).

La fin de connexion n'est pas filtrée, mais est réécrite pour que les
données qui ont été interceptées mais acquittées par la middlebox ne
perturbent pas l'échange.
Vu du client, ça donne:
53160 → 2000 [FIN, ACK] Seq=5121 Ack=1 Win=64256 Len=0 TSval=3941021092 
TSecr=1817006976
2000 → 53160 [FIN, ACK] Seq=1 Ack=5122 Win=180224 Len=0 TSval=1817006982 
TSecr=3941021091
53160 → 2000 [ACK] Seq=5122 Ack=2 Win=64256 Len=0 TSval=3941021152 
TSecr=1817006982
mais vu du serveur, ça donne:
2612 → 2000 [FIN, ACK] Seq=1 Ack=1 Win=180224 Len=0 TSval=1817006982 
TSecr=2630718538
2000 → 2612 [FIN, ACK] Seq=1 Ack=2 Win=65280 Len=0 TSval=2630718559 
TSecr=1817006982
2612 → 2000 [ACK] Seq=2 Ack=2 Win=180224 Len=0 TSval=1817006984 TSecr=2630718559
=> le numéro de séquence ("relatif", c'est ce que wireshark affiche) est
5121 vu du client, mais 1 vu du serveur.

Le TTL élevé (62) fait penser que c'est l'un des premiers équipements
qui réalise cette opération, ce qui expliquerait pourquoi on voit le
problème à la fois avec Bouygues et EIT.

Lucas


---
Liste de diffusion du FRnOG
http://www.frnog.org/