Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger

[lm2 via frnog]

Au même titre qu'ils auront fait des pieds et des mains pour décourager et 
ralentir l'usage de solutions par internet (whatsapp, rcs..) pour conserver 
leur petit bonus d'itinérance à l'étranger ou vers l'étranger.



personnellement un abonnement dont la vowifi fonctionne très bien en france, et 
qui ne fonctionne pas de même hors d'europe, je considère cela éliminatoire, 
c'est résiliation direct une fois de retour au bercail avec boycott de 
l'opérateur sans autre forme de procès (et le bouche à oreille associé, bien 
entendu). À un moment faut arrêter de prendre les abonnés pour des vaches, ceux 
qui continuent ces pratiques se tirent une balle dans le pied.



c'est justement l'intéret de la vowifi, c'est pas que palier aux défauts de 
couverture, mais permettre l'usage d'internet comme alternative à l'itinérance 
partout dans le monde, sans aucun surcout. L'opé qui n'approuve pas ce 
raisonnement, n'a qu'à mettre la clé sous la porte, personne ne le regrettera.





il me semble qu'il y a quelques mois c'était le cas une brève période chez 
orange/sosh, mais ils s'en sont aperçus et c'est normalement pleinement 
utilisable partout dans le monde (et si c'était pas le cas j'encouragerais 
volontier aux résiliations massives).


From: Clement Cavadore 
To: David Ponzone ;
   Xavier Claude 
Subject: Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger
Date: 12/05/2024 12:56:45 Europe/Paris
Cc: FRNOG 

Hello,

Je pense que les opérateurs pourront trouver toutes les excuses du
monde pour justifier de ne pas autoriser la VoWifi à l'étranger, mais
en vrai, clairement, la problématique de base doit être de protéger
leurs intérêts commerciaux. 


Je dois partir à l'autre bout du monde dans quelques temps (dans une
destination non incluse dans le roaming de mon forfait), et clairement,
quand tu vois qu'ils te proposent sans sourciller un tarif de 13.31€ le
Mo, et 2.90€/min d'appel sortant (1.40€/min d'appel entrant), et je ne
parle même pas des tarifs des SMS envoyés/MMS, ils ne vont pas te
faciliter la tâche à te dire "c'est le même prix qu'en France si tu es
en VoWifi !"

Clément

On Sun, 2024-05-12 at 12:46 +0200, David Ponzone wrote:
> Hmm pas bête mais même connecté en WIFI avec VoWIFI activé, je pense
> que le 112 est acheminé en GSM.
> 
> David
> 
> > Le 12 mai 2024 à 12:25, Xavier Claude  a
> > écrit :
> > 
> > Est-ce que ce ne serait pas pour pouvoir gérer les cas d'appels
> > d'urgence. Si tu es connecté à une antenne on sait où router
> > l'appel d'urgence, si tu es à l'étranger, c'est à l'opérateur local
> > de faire ce routage, donc pas possible si tu pas par le Wifi.
> > 
> > Xavier
> > 
> > 
> > Le dimanche 12 mai 2024 à 11:19, David Ponzone
> >  a écrit :
> > 
> > > Merci pour la confirmation, c’est donc bien une histoire de HLR.
> > > 
> > > Ceci dit, je vois pas bien comment concurrencer (sérieusement) un
> > > opérateur mobile en se répondant sur le WIFI gratuit dispo dans
> > > un pays….
> > > 
> > > David
> > > 
> > > > Le 12 mai 2024 à 04:09, Maximus . themaxim...@outlook.fr a
> > > > écrit :
> > > > 
> > > > Bonjour,
> > > > 
> > > > J’ai un cas pratique qui illustre parfaitement l’explication.
> > > > 2 mobiles, 1 Orange Caraïbe et 1 Orange France
> > > > On va faire l’exemple avec 1, mais ça fonctionne aussi avec
> > > > l’autre dans le sens inverse.
> > > > 
> > > > Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi
> > > > fonctionne.
> > > > Je prends l’avion pour aller en France, mais en passant le
> > > > téléphone en mode avion.
> > > > En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé
> > > > la partie mobile.
> > > > 
> > > > Dès que j’active la partie mobile, je reçois le SMS qui indique
> > > > que je suis en roaming (Orange Caraïbes et France ne sont pas
> > > > les mêmes opérateurs) et la VoWiFi se coupe.
> > > > 
> > > > Si je reviens dans les Caraïbes, tant que je n’ai pas activé le
> > > > réseau mobile pour que l’opérateur détecte que je suis à
> > > > nouveau connecté directement sur son réseau, la VoWiFi ne
> > > > revient pas.
> > > > 
> > > > Je pense que c’est fait exprès, pour que les opérateurs ne
> > > > rentrent pas en concurrences dans différentes pays. Si tu
> > > > pouvais faire de la VoWiFi partout dans le monde, pourquoi
> > > > irais-tu prendre l’abonnement de l’opérateur local. Tu prends
> > > > un abonnement étranger moins cher.
> > > > Ils veulent que tu utilises la VoWiF

Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger

[Nang Bat]

Ça dépend des pays et des opérateurs.
Aux US c'est souvent obligatoire de fournir une address E911 pour
pouvoir faire de la VoWifi, ça sert d'adresse par défaut si un appel
au 911 via VoWifi n'est pas localisable autrement (sachant que le
ng911 fait, quand c'est possible, suivre des metadatas de localisation
dans la session sip jusqu'au PSAP). En France vu qu'on a pas trop de
continuité en VoIP vers les PSAP ça doit pas être supporté par les
opérateur. Après il y a d'autres considérations (genre interception
légale obligatoirement possible pour tout les téléphone dans certain
pays) qui rendent glissant la promotion de la VoWifi hors du pays de
l'abonné. Mais le problème n'est pas insoluble (cf les work item
SEW1/SEW2 du 3gpp pour les appels d'urgences en VoWifi (le roaming y
est discuté) avec le bémol d'un truc avec d'avoir trop d'acteurs dans
la boucle (3gpp vs ng911 vs ng112).

Le dim. 12 mai 2024 à 12:47, David Ponzone  a écrit :
>
> Hmm pas bête mais même connecté en WIFI avec VoWIFI activé, je pense que le 
> 112 est acheminé en GSM.
>
> David
>
> > Le 12 mai 2024 à 12:25, Xavier Claude  a écrit :
> >
> > Est-ce que ce ne serait pas pour pouvoir gérer les cas d'appels d'urgence. 
> > Si tu es connecté à une antenne on sait où router l'appel d'urgence, si tu 
> > es à l'étranger, c'est à l'opérateur local de faire ce routage, donc pas 
> > possible si tu pas par le Wifi.
> >
> > Xavier
> >
> >
> > Le dimanche 12 mai 2024 à 11:19, David Ponzone  a 
> > écrit :
> >
> >> Merci pour la confirmation, c’est donc bien une histoire de HLR.
> >>
> >> Ceci dit, je vois pas bien comment concurrencer (sérieusement) un 
> >> opérateur mobile en se répondant sur le WIFI gratuit dispo dans un pays….
> >>
> >> David
> >>
> >>> Le 12 mai 2024 à 04:09, Maximus . themaxim...@outlook.fr a écrit :
> >>>
> >>> Bonjour,
> >>>
> >>> J’ai un cas pratique qui illustre parfaitement l’explication.
> >>> 2 mobiles, 1 Orange Caraïbe et 1 Orange France
> >>> On va faire l’exemple avec 1, mais ça fonctionne aussi avec l’autre dans 
> >>> le sens inverse.
> >>>
> >>> Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi fonctionne.
> >>> Je prends l’avion pour aller en France, mais en passant le téléphone en 
> >>> mode avion.
> >>> En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé la partie 
> >>> mobile.
> >>>
> >>> Dès que j’active la partie mobile, je reçois le SMS qui indique que je 
> >>> suis en roaming (Orange Caraïbes et France ne sont pas les mêmes 
> >>> opérateurs) et la VoWiFi se coupe.
> >>>
> >>> Si je reviens dans les Caraïbes, tant que je n’ai pas activé le réseau 
> >>> mobile pour que l’opérateur détecte que je suis à nouveau connecté 
> >>> directement sur son réseau, la VoWiFi ne revient pas.
> >>>
> >>> Je pense que c’est fait exprès, pour que les opérateurs ne rentrent pas 
> >>> en concurrences dans différentes pays. Si tu pouvais faire de la VoWiFi 
> >>> partout dans le monde, pourquoi irais-tu prendre l’abonnement de 
> >>> l’opérateur local. Tu prends un abonnement étranger moins cher.
> >>> Ils veulent que tu utilises la VoWiFi quand tu as un problème de 
> >>> couverture local. L’opérateur n’est pas/plus capable de te fournir du 
> >>> mobile, mais tu peux toujours téléphoner avec le WiFi.
> >>>
> >>> Le 11 mai 2024 à 09:28, David Ponzone david.ponz...@gmail.com a écrit :
> >>>
> >>> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
> >>> français sait sur son HLR que tu n’es pas en France.
> >>>
> >>> David
> >>>
> >>> Le 11 mai 2024 à 15:21, Erwan David 
> >>> mailto:er...@rail.eu.org> a écrit :
> >>>
> >>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
> >>> l'étranger. En pratique comment le détecte-t-il ? En particulier si le 
> >>> wifi est routé dans un VPN qui sors ensuite avec une IP française ?
> >>>
> >>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer 
> >>> VoWifi/VoLTE sur mon one plus nord...
> >>>
> >>> ---
> >>> 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/
> >
> >
> > ---
> > 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] [TECH] VoWifi : appels depuis l'étranger

[Xavier Claude]

Je n'en suis pas sûr, parce que justement, l'intérêt du VoWifi, c'est justement 
de palier à des problèmes de couverture. Mais même sans ça, il y a des numéros 
d'urgence par pays autre que le 112 qui seront routé directement par 
l'opérateur local.

Le dimanche 12 mai 2024 à 12:46, David Ponzone  a 
écrit :

> Hmm pas bête mais même connecté en WIFI avec VoWIFI activé, je pense que le 
> 112 est acheminé en GSM.
> 
> David
> 
> > Le 12 mai 2024 à 12:25,
> > 
> > Xavier Claude
> > 
> > cont...@xavierclaude.be a écrit :
> > 
> > Est-ce que ce ne serait pas pour pouvoir gérer les cas d'appels d'urgence. 
> > Si tu es connecté à une antenne on sait où router l'appel d'urgence, si tu 
> > es à l'étranger, c'est à l'opérateur local de faire ce routage, donc pas 
> > possible si tu pas par le Wifi.
> > 
> > Xavier
> > 
> > Le dimanche 12 mai 2024 à 11:19, David Ponzone david.ponz...@gmail.com a 
> > écrit :
> > 
> > > Merci pour la confirmation, c’est donc bien une histoire de HLR.
> > > 
> > > Ceci dit, je vois pas bien comment concurrencer (sérieusement) un 
> > > opérateur mobile en se répondant sur le WIFI gratuit dispo dans un pays….
> > > 
> > > David
> > > 
> > > > Le 12 mai 2024 à 04:09, Maximus . themaxim...@outlook.fr a écrit :
> > > > 
> > > > Bonjour,
> > > > 
> > > > J’ai un cas pratique qui illustre parfaitement l’explication.
> > > > 2 mobiles, 1 Orange Caraïbe et 1 Orange France
> > > > On va faire l’exemple avec 1, mais ça fonctionne aussi avec l’autre 
> > > > dans le sens inverse.
> > > > 
> > > > Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi fonctionne.
> > > > Je prends l’avion pour aller en France, mais en passant le téléphone en 
> > > > mode avion.
> > > > En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé la partie 
> > > > mobile.
> > > > 
> > > > Dès que j’active la partie mobile, je reçois le SMS qui indique que je 
> > > > suis en roaming (Orange Caraïbes et France ne sont pas les mêmes 
> > > > opérateurs) et la VoWiFi se coupe.
> > > > 
> > > > Si je reviens dans les Caraïbes, tant que je n’ai pas activé le réseau 
> > > > mobile pour que l’opérateur détecte que je suis à nouveau connecté 
> > > > directement sur son réseau, la VoWiFi ne revient pas.
> > > > 
> > > > Je pense que c’est fait exprès, pour que les opérateurs ne rentrent pas 
> > > > en concurrences dans différentes pays. Si tu pouvais faire de la VoWiFi 
> > > > partout dans le monde, pourquoi irais-tu prendre l’abonnement de 
> > > > l’opérateur local. Tu prends un abonnement étranger moins cher.
> > > > Ils veulent que tu utilises la VoWiFi quand tu as un problème de 
> > > > couverture local. L’opérateur n’est pas/plus capable de te fournir du 
> > > > mobile, mais tu peux toujours téléphoner avec le WiFi.
> > > > 
> > > > Le 11 mai 2024 à 09:28, David Ponzone david.ponz...@gmail.com a écrit :
> > > > 
> > > > Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
> > > > français sait sur son HLR que tu n’es pas en France.
> > > > 
> > > > David
> > > > 
> > > > Le 11 mai 2024 à 15:21, Erwan David 
> > > > mailto:er...@rail.eu.org> a écrit :
> > > > 
> > > > Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
> > > > l'étranger. En pratique comment le détecte-t-il ? En particulier si le 
> > > > wifi est routé dans un VPN qui sors ensuite avec une IP française ?
> > > > 
> > > > (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer 
> > > > VoWifi/VoLTE sur mon one plus nord...
> > > > 
> > > > ---
> > > > 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/
> > 
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/


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

Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger

[Clement Cavadore]

Hello,

Je pense que les opérateurs pourront trouver toutes les excuses du
monde pour justifier de ne pas autoriser la VoWifi à l'étranger, mais
en vrai, clairement, la problématique de base doit être de protéger
leurs intérêts commerciaux. 


Je dois partir à l'autre bout du monde dans quelques temps (dans une
destination non incluse dans le roaming de mon forfait), et clairement,
quand tu vois qu'ils te proposent sans sourciller un tarif de 13.31€ le
Mo, et 2.90€/min d'appel sortant (1.40€/min d'appel entrant), et je ne
parle même pas des tarifs des SMS envoyés/MMS, ils ne vont pas te
faciliter la tâche à te dire "c'est le même prix qu'en France si tu es
en VoWifi !"

Clément

On Sun, 2024-05-12 at 12:46 +0200, David Ponzone wrote:
> Hmm pas bête mais même connecté en WIFI avec VoWIFI activé, je pense
> que le 112 est acheminé en GSM.
> 
> David
> 
> > Le 12 mai 2024 à 12:25, Xavier Claude  a
> > écrit :
> > 
> > Est-ce que ce ne serait pas pour pouvoir gérer les cas d'appels
> > d'urgence. Si tu es connecté à une antenne on sait où router
> > l'appel d'urgence, si tu es à l'étranger, c'est à l'opérateur local
> > de faire ce routage, donc pas possible si tu pas par le Wifi.
> > 
> > Xavier
> > 
> > 
> > Le dimanche 12 mai 2024 à 11:19, David Ponzone
> >  a écrit :
> > 
> > > Merci pour la confirmation, c’est donc bien une histoire de HLR.
> > > 
> > > Ceci dit, je vois pas bien comment concurrencer (sérieusement) un
> > > opérateur mobile en se répondant sur le WIFI gratuit dispo dans
> > > un pays….
> > > 
> > > David
> > > 
> > > > Le 12 mai 2024 à 04:09, Maximus . themaxim...@outlook.fr a
> > > > écrit :
> > > > 
> > > > Bonjour,
> > > > 
> > > > J’ai un cas pratique qui illustre parfaitement l’explication.
> > > > 2 mobiles, 1 Orange Caraïbe et 1 Orange France
> > > > On va faire l’exemple avec 1, mais ça fonctionne aussi avec
> > > > l’autre dans le sens inverse.
> > > > 
> > > > Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi
> > > > fonctionne.
> > > > Je prends l’avion pour aller en France, mais en passant le
> > > > téléphone en mode avion.
> > > > En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé
> > > > la partie mobile.
> > > > 
> > > > Dès que j’active la partie mobile, je reçois le SMS qui indique
> > > > que je suis en roaming (Orange Caraïbes et France ne sont pas
> > > > les mêmes opérateurs) et la VoWiFi se coupe.
> > > > 
> > > > Si je reviens dans les Caraïbes, tant que je n’ai pas activé le
> > > > réseau mobile pour que l’opérateur détecte que je suis à
> > > > nouveau connecté directement sur son réseau, la VoWiFi ne
> > > > revient pas.
> > > > 
> > > > Je pense que c’est fait exprès, pour que les opérateurs ne
> > > > rentrent pas en concurrences dans différentes pays. Si tu
> > > > pouvais faire de la VoWiFi partout dans le monde, pourquoi
> > > > irais-tu prendre l’abonnement de l’opérateur local. Tu prends
> > > > un abonnement étranger moins cher.
> > > > Ils veulent que tu utilises la VoWiFi quand tu as un problème
> > > > de couverture local. L’opérateur n’est pas/plus capable de te
> > > > fournir du mobile, mais tu peux toujours téléphoner avec le
> > > > WiFi.
> > > > 
> > > > Le 11 mai 2024 à 09:28, David Ponzone david.ponz...@gmail.com a
> > > > écrit :
> > > > 
> > > > Au hasard, tu es connecté en 4G à l’opérateur local, donc ton
> > > > opérateur français sait sur son HLR que tu n’es pas en France.
> > > > 
> > > > David
> > > > 
> > > > Le 11 mai 2024 à 15:21, Erwan David
> > > > mailto:er...@rail.eu.org> a écrit :
> > > > 
> > > > Mon nouvel opérateur me met que je ne peux pas appeler en
> > > > VoWifi depuis l'étranger. En pratique comment le détecte-t-il ?
> > > > En particulier si le wifi est routé dans un VPN qui sors
> > > > ensuite avec une IP française ?
> > > > 
> > > > (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer
> > > > VoWifi/VoLTE sur mon one plus nord...
> > > > 
> > > > ---
> > > > 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/
> > 
> > 
> > ---
> > 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] [TECH] VoWifi : appels depuis l'étranger

[David Ponzone]

Hmm pas bête mais même connecté en WIFI avec VoWIFI activé, je pense que le 112 
est acheminé en GSM.

David

> Le 12 mai 2024 à 12:25, Xavier Claude  a écrit :
> 
> Est-ce que ce ne serait pas pour pouvoir gérer les cas d'appels d'urgence. Si 
> tu es connecté à une antenne on sait où router l'appel d'urgence, si tu es à 
> l'étranger, c'est à l'opérateur local de faire ce routage, donc pas possible 
> si tu pas par le Wifi.
> 
> Xavier
> 
> 
> Le dimanche 12 mai 2024 à 11:19, David Ponzone  a 
> écrit :
> 
>> Merci pour la confirmation, c’est donc bien une histoire de HLR.
>> 
>> Ceci dit, je vois pas bien comment concurrencer (sérieusement) un opérateur 
>> mobile en se répondant sur le WIFI gratuit dispo dans un pays….
>> 
>> David
>> 
>>> Le 12 mai 2024 à 04:09, Maximus . themaxim...@outlook.fr a écrit :
>>> 
>>> Bonjour,
>>> 
>>> J’ai un cas pratique qui illustre parfaitement l’explication.
>>> 2 mobiles, 1 Orange Caraïbe et 1 Orange France
>>> On va faire l’exemple avec 1, mais ça fonctionne aussi avec l’autre dans le 
>>> sens inverse.
>>> 
>>> Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi fonctionne.
>>> Je prends l’avion pour aller en France, mais en passant le téléphone en 
>>> mode avion.
>>> En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé la partie 
>>> mobile.
>>> 
>>> Dès que j’active la partie mobile, je reçois le SMS qui indique que je suis 
>>> en roaming (Orange Caraïbes et France ne sont pas les mêmes opérateurs) et 
>>> la VoWiFi se coupe.
>>> 
>>> Si je reviens dans les Caraïbes, tant que je n’ai pas activé le réseau 
>>> mobile pour que l’opérateur détecte que je suis à nouveau connecté 
>>> directement sur son réseau, la VoWiFi ne revient pas.
>>> 
>>> Je pense que c’est fait exprès, pour que les opérateurs ne rentrent pas en 
>>> concurrences dans différentes pays. Si tu pouvais faire de la VoWiFi 
>>> partout dans le monde, pourquoi irais-tu prendre l’abonnement de 
>>> l’opérateur local. Tu prends un abonnement étranger moins cher.
>>> Ils veulent que tu utilises la VoWiFi quand tu as un problème de couverture 
>>> local. L’opérateur n’est pas/plus capable de te fournir du mobile, mais tu 
>>> peux toujours téléphoner avec le WiFi.
>>> 
>>> Le 11 mai 2024 à 09:28, David Ponzone david.ponz...@gmail.com a écrit :
>>> 
>>> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
>>> français sait sur son HLR que tu n’es pas en France.
>>> 
>>> David
>>> 
>>> Le 11 mai 2024 à 15:21, Erwan David 
>>> mailto:er...@rail.eu.org> a écrit :
>>> 
>>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
>>> l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi 
>>> est routé dans un VPN qui sors ensuite avec une IP française ?
>>> 
>>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE 
>>> sur mon one plus nord...
>>> 
>>> ---
>>> 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/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger

[Xavier Claude]

Est-ce que ce ne serait pas pour pouvoir gérer les cas d'appels d'urgence. Si 
tu es connecté à une antenne on sait où router l'appel d'urgence, si tu es à 
l'étranger, c'est à l'opérateur local de faire ce routage, donc pas possible si 
tu pas par le Wifi.

Xavier


Le dimanche 12 mai 2024 à 11:19, David Ponzone  a 
écrit :

> Merci pour la confirmation, c’est donc bien une histoire de HLR.
> 
> Ceci dit, je vois pas bien comment concurrencer (sérieusement) un opérateur 
> mobile en se répondant sur le WIFI gratuit dispo dans un pays….
> 
> David
> 
> > Le 12 mai 2024 à 04:09, Maximus . themaxim...@outlook.fr a écrit :
> > 
> > Bonjour,
> > 
> > J’ai un cas pratique qui illustre parfaitement l’explication.
> > 2 mobiles, 1 Orange Caraïbe et 1 Orange France
> > On va faire l’exemple avec 1, mais ça fonctionne aussi avec l’autre dans le 
> > sens inverse.
> > 
> > Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi fonctionne.
> > Je prends l’avion pour aller en France, mais en passant le téléphone en 
> > mode avion.
> > En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé la partie 
> > mobile.
> > 
> > Dès que j’active la partie mobile, je reçois le SMS qui indique que je suis 
> > en roaming (Orange Caraïbes et France ne sont pas les mêmes opérateurs) et 
> > la VoWiFi se coupe.
> > 
> > Si je reviens dans les Caraïbes, tant que je n’ai pas activé le réseau 
> > mobile pour que l’opérateur détecte que je suis à nouveau connecté 
> > directement sur son réseau, la VoWiFi ne revient pas.
> > 
> > Je pense que c’est fait exprès, pour que les opérateurs ne rentrent pas en 
> > concurrences dans différentes pays. Si tu pouvais faire de la VoWiFi 
> > partout dans le monde, pourquoi irais-tu prendre l’abonnement de 
> > l’opérateur local. Tu prends un abonnement étranger moins cher.
> > Ils veulent que tu utilises la VoWiFi quand tu as un problème de couverture 
> > local. L’opérateur n’est pas/plus capable de te fournir du mobile, mais tu 
> > peux toujours téléphoner avec le WiFi.
> > 
> > Le 11 mai 2024 à 09:28, David Ponzone david.ponz...@gmail.com a écrit :
> > 
> > Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
> > français sait sur son HLR que tu n’es pas en France.
> > 
> > David
> > 
> > Le 11 mai 2024 à 15:21, Erwan David 
> > mailto:er...@rail.eu.org> a écrit :
> > 
> > Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
> > l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi 
> > est routé dans un VPN qui sors ensuite avec une IP française ?
> > 
> > (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE 
> > sur mon one plus nord...
> > 
> > ---
> > 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/


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

Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger

[David Ponzone]

Merci pour la confirmation, c’est donc bien une histoire de HLR.

Ceci dit, je vois pas bien comment concurrencer (sérieusement) un opérateur 
mobile en se répondant sur le WIFI gratuit dispo dans un pays….

David

> Le 12 mai 2024 à 04:09, Maximus .  a écrit :
> 
> Bonjour,
> 
> J’ai un cas pratique qui illustre parfaitement l’explication.
> 2 mobiles, 1 Orange Caraïbe et 1 Orange France
> On va faire l’exemple avec 1, mais ça fonctionne aussi avec l’autre dans le 
> sens inverse.
> 
> Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi fonctionne.
> Je prends l’avion pour aller en France, mais en passant le téléphone en mode 
> avion.
> En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé la partie 
> mobile.
> 
> Dès que j’active la partie mobile, je reçois le SMS qui indique que je suis 
> en roaming (Orange Caraïbes et France ne sont pas les mêmes opérateurs) et la 
> VoWiFi se coupe.
> 
> Si je reviens dans les Caraïbes, tant que je n’ai pas activé le réseau mobile 
> pour que l’opérateur détecte que je suis à nouveau connecté directement sur 
> son réseau, la VoWiFi ne revient pas.
> 
> 
> Je pense que c’est fait exprès, pour que les opérateurs ne rentrent pas en 
> concurrences dans différentes pays. Si tu pouvais faire de la VoWiFi partout 
> dans le monde, pourquoi irais-tu prendre l’abonnement de l’opérateur local. 
> Tu prends un abonnement étranger moins cher.
> Ils veulent que tu utilises la VoWiFi quand tu as un problème de couverture 
> local. L’opérateur n’est pas/plus capable de te fournir du mobile, mais tu 
> peux toujours téléphoner avec le WiFi.
> 
> 
> 
> Le 11 mai 2024 à 09:28, David Ponzone  a écrit :
> 
> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
> français sait sur son HLR que tu n’es pas en France.
> 
> David
> 
> 
> Le 11 mai 2024 à 15:21, Erwan David 
> mailto:er...@rail.eu.org>> a écrit :
> 
> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
> l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi 
> est routé dans un VPN qui sors ensuite avec une IP française ?
> 
> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE 
> sur mon one plus nord...
> 
> 
> ---
> 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] [TECH] VoWifi : appels depuis l'étranger

[Maximus .]

Bonjour,

J’ai un cas pratique qui illustre parfaitement l’explication.
2 mobiles, 1 Orange Caraïbe et 1 Orange France
On va faire l’exemple avec 1, mais ça fonctionne aussi avec l’autre dans le 
sens inverse.

Je suis aux Antilles avec le téléphone Caraïbes. La VoWiFi fonctionne.
Je prends l’avion pour aller en France, mais en passant le téléphone en mode 
avion.
En arrivant, la VoWiFi fonctionne tant que je n’ai pas activé la partie mobile.

Dès que j’active la partie mobile, je reçois le SMS qui indique que je suis en 
roaming (Orange Caraïbes et France ne sont pas les mêmes opérateurs) et la 
VoWiFi se coupe.

Si je reviens dans les Caraïbes, tant que je n’ai pas activé le réseau mobile 
pour que l’opérateur détecte que je suis à nouveau connecté directement sur son 
réseau, la VoWiFi ne revient pas.


Je pense que c’est fait exprès, pour que les opérateurs ne rentrent pas en 
concurrences dans différentes pays. Si tu pouvais faire de la VoWiFi partout 
dans le monde, pourquoi irais-tu prendre l’abonnement de l’opérateur local. Tu 
prends un abonnement étranger moins cher.
Ils veulent que tu utilises la VoWiFi quand tu as un problème de couverture 
local. L’opérateur n’est pas/plus capable de te fournir du mobile, mais tu peux 
toujours téléphoner avec le WiFi.



Le 11 mai 2024 à 09:28, David Ponzone  a écrit :

Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
français sait sur son HLR que tu n’es pas en France.

David


Le 11 mai 2024 à 15:21, Erwan David 
mailto:er...@rail.eu.org>> a écrit :

Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi est 
routé dans un VPN qui sors ensuite avec une IP française ?

(au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE sur 
mon one plus nord...


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



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

Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger

[Richard Klein]

-La première réponse est que les restrictions IP sont là pour la sécurité.
Donc pourquoi d'autre opérateurs le font?
-La seconde non officiel est qu il y avait tellement de prestas que plus
personne ne sait comment cela juste marche  Donc pourquoi chercher a
révolutionner le monde et faire de l'innovation ?


Richard


Le sam. 11 mai 2024 à 19:59, David Ponzone  a
écrit :

> Ok
>
> Pour revenir à la question de départ, au delà du comment, y a le pourquoi.
> Cela pourrait-il être une raison pécuniaire ?
> Une petite entente cordiale pour bloquer la VoWIFI en roaming et que tout
> le monde continue à se gaver avec le roaming GSM ?
>
> Je sais, c’est un peu conspi, mais on a vu pire.
>
> David
>
> Le 11 mai 2024 à 17:46, Richard Klein  a écrit :
>
> Non c est volontaire car dans tous les cas c est ton mobile qui
> s'enregistre sur l'IMS en SIP.
> C est un gros raccourci car seul le media de transport change
> (cellulaire/wifi) et je suppose que les mécanisme d'autorisations et
> d'authentifications sont similaires.
> Sur le support N2 mobile j avais un pauvre power point pour décrire
> l'architecture et mon expert mobile n en savait pas plus que moi :-)
>
> Richard
>
> Le sam. 11 mai 2024, 17:04, David Ponzone  a
> écrit :
>
>> Tu as pas un peu interverti à plusieurs reprises  les mots LTE et WIFI
>> dans ton message ? Car j’ai du mal à y retrouver mon latin :)
>>
>> David Ponzone
>>
>>
>>
>> > Le 11 mai 2024 à 15:51, Richard Klein  a écrit :
>> >
>> > Le cas de la VoWifi est similaire .
>> > Il y a aussi les plages IP avec des ACL prochent de L’IMS qui gère la
>> VoLTE.
>> > Deux exemples:
>> > 1)Il y a 15 mois environs lorsque j étais en support N2 pour un
>> opérateur mobile ,un client n’arrivait pas à faire de la VOWIFI via
>> starlink.
>> > Après 2 à 3 semaines de négociations en interne et la fourniture par
>> starlink des plages nous avons ajouté celle-ci sur l ensemble de le france .
>> > 2) un client n arrivait pas à faire de la VoLTE sur son wifi d
>> entreprise .
>> > Après mise en place de son ip dans la DMZ de son firewall le résultat
>> était toujours négatif.
>> > Nous avons aussi vérifier avec une box GP que la ligne était ok en
>> VoWifi et VoLTE .
>> > Il y avait bien un bloquage de son IP wan qui était anciennement une IP
>> UK.
>> > Dans les bases externe l ip était bien déclaré en FR mais pas chez l
>> opérateur mobile.
>> > Donc avec un peu de patience et en trouvant les bonnes personnes il est
>> possible de faire avancer les choses.
>> >
>> > Pour revenir à la VoLTE …
>> > Pas sur que passer par un VPN va résoudre le problème car de mémoire il
>> y a d’autres mécanismes en place pour localiser le mobile et libre à l
>> opérateur de les exploiter.
>> >
>> > A vérifier mais seul free propose de la VoXXX en dehors de la france.
>> >
>> > Richard
>> >
>> >
>> >> Le 11 mai 2024 à 15:28, David Ponzone  a
>> écrit :
>> >>
>> >> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton
>> opérateur français sait sur son HLR que tu n’es pas en France.
>> >>
>> >> David
>> >>
>> >>
>>  Le 11 mai 2024 à 15:21, Erwan David  a écrit :
>> >>>
>> >>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi
>> depuis l'étranger. En pratique comment le détecte-t-il ? En particulier si
>> le wifi est routé dans un VPN qui sors ensuite avec une IP française ?
>> >>>
>> >>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer
>> VoWifi/VoLTE sur mon one plus nord...
>> >>>
>> >>>
>> >>> ---
>> >>> 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] [TECH] VoWifi : appels depuis l'étranger

[David Ponzone]

Ok

Pour revenir à la question de départ, au delà du comment, y a le pourquoi.
Cela pourrait-il être une raison pécuniaire ?
Une petite entente cordiale pour bloquer la VoWIFI en roaming et que tout le 
monde continue à se gaver avec le roaming GSM ?

Je sais, c’est un peu conspi, mais on a vu pire.

David

> Le 11 mai 2024 à 17:46, Richard Klein  a écrit :
> 
> Non c est volontaire car dans tous les cas c est ton mobile qui s'enregistre 
> sur l'IMS en SIP.
> C est un gros raccourci car seul le media de transport change 
> (cellulaire/wifi) et je suppose que les mécanisme d'autorisations et 
> d'authentifications sont similaires.
> Sur le support N2 mobile j avais un pauvre power point pour décrire 
> l'architecture et mon expert mobile n en savait pas plus que moi :-)
> 
> Richard
> 
> Le sam. 11 mai 2024, 17:04, David Ponzone  > a écrit :
> Tu as pas un peu interverti à plusieurs reprises  les mots LTE et WIFI dans 
> ton message ? Car j’ai du mal à y retrouver mon latin :)
> 
> David Ponzone
> 
> 
> 
> > Le 11 mai 2024 à 15:51, Richard Klein  > > a écrit :
> > 
> > Le cas de la VoWifi est similaire .
> > Il y a aussi les plages IP avec des ACL prochent de L’IMS qui gère la VoLTE.
> > Deux exemples:
> > 1)Il y a 15 mois environs lorsque j étais en support N2 pour un opérateur 
> > mobile ,un client n’arrivait pas à faire de la VOWIFI via starlink.
> > Après 2 à 3 semaines de négociations en interne et la fourniture par 
> > starlink des plages nous avons ajouté celle-ci sur l ensemble de le france .
> > 2) un client n arrivait pas à faire de la VoLTE sur son wifi d entreprise .
> > Après mise en place de son ip dans la DMZ de son firewall le résultat était 
> > toujours négatif.
> > Nous avons aussi vérifier avec une box GP que la ligne était ok en VoWifi 
> > et VoLTE .
> > Il y avait bien un bloquage de son IP wan qui était anciennement une IP UK.
> > Dans les bases externe l ip était bien déclaré en FR mais pas chez l 
> > opérateur mobile.
> > Donc avec un peu de patience et en trouvant les bonnes personnes il est 
> > possible de faire avancer les choses.
> > 
> > Pour revenir à la VoLTE …
> > Pas sur que passer par un VPN va résoudre le problème car de mémoire il y a 
> > d’autres mécanismes en place pour localiser le mobile et libre à l 
> > opérateur de les exploiter.
> > 
> > A vérifier mais seul free propose de la VoXXX en dehors de la france.
> > 
> > Richard
> > 
> > 
> >> Le 11 mai 2024 à 15:28, David Ponzone  >> > a écrit :
> >> 
> >> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
> >> français sait sur son HLR que tu n’es pas en France.
> >> 
> >> David
> >> 
> >> 
>  Le 11 mai 2024 à 15:21, Erwan David   > a écrit :
> >>> 
> >>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
> >>> l'étranger. En pratique comment le détecte-t-il ? En particulier si le 
> >>> wifi est routé dans un VPN qui sors ensuite avec une IP française ?
> >>> 
> >>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer 
> >>> VoWifi/VoLTE sur mon one plus nord...
> >>> 
> >>> 
> >>> ---
> >>> 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] [TECH] VoWifi : appels depuis l'étranger

[Richard Klein]

Non c est volontaire car dans tous les cas c est ton mobile qui
s'enregistre sur l'IMS en SIP.
C est un gros raccourci car seul le media de transport change
(cellulaire/wifi) et je suppose que les mécanisme d'autorisations et
d'authentifications sont similaires.
Sur le support N2 mobile j avais un pauvre power point pour décrire
l'architecture et mon expert mobile n en savait pas plus que moi :-)

Richard

Le sam. 11 mai 2024, 17:04, David Ponzone  a
écrit :

> Tu as pas un peu interverti à plusieurs reprises  les mots LTE et WIFI
> dans ton message ? Car j’ai du mal à y retrouver mon latin :)
>
> David Ponzone
>
>
>
> > Le 11 mai 2024 à 15:51, Richard Klein  a écrit :
> >
> > Le cas de la VoWifi est similaire .
> > Il y a aussi les plages IP avec des ACL prochent de L’IMS qui gère la
> VoLTE.
> > Deux exemples:
> > 1)Il y a 15 mois environs lorsque j étais en support N2 pour un
> opérateur mobile ,un client n’arrivait pas à faire de la VOWIFI via
> starlink.
> > Après 2 à 3 semaines de négociations en interne et la fourniture par
> starlink des plages nous avons ajouté celle-ci sur l ensemble de le france .
> > 2) un client n arrivait pas à faire de la VoLTE sur son wifi d
> entreprise .
> > Après mise en place de son ip dans la DMZ de son firewall le résultat
> était toujours négatif.
> > Nous avons aussi vérifier avec une box GP que la ligne était ok en
> VoWifi et VoLTE .
> > Il y avait bien un bloquage de son IP wan qui était anciennement une IP
> UK.
> > Dans les bases externe l ip était bien déclaré en FR mais pas chez l
> opérateur mobile.
> > Donc avec un peu de patience et en trouvant les bonnes personnes il est
> possible de faire avancer les choses.
> >
> > Pour revenir à la VoLTE …
> > Pas sur que passer par un VPN va résoudre le problème car de mémoire il
> y a d’autres mécanismes en place pour localiser le mobile et libre à l
> opérateur de les exploiter.
> >
> > A vérifier mais seul free propose de la VoXXX en dehors de la france.
> >
> > Richard
> >
> >
> >> Le 11 mai 2024 à 15:28, David Ponzone  a
> écrit :
> >>
> >> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton
> opérateur français sait sur son HLR que tu n’es pas en France.
> >>
> >> David
> >>
> >>
>  Le 11 mai 2024 à 15:21, Erwan David  a écrit :
> >>>
> >>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi
> depuis l'étranger. En pratique comment le détecte-t-il ? En particulier si
> le wifi est routé dans un VPN qui sors ensuite avec une IP française ?
> >>>
> >>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer
> VoWifi/VoLTE sur mon one plus nord...
> >>>
> >>>
> >>> ---
> >>> 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] [TECH] VoWifi : appels depuis l'étranger

[David Ponzone]

Tu as pas un peu interverti à plusieurs reprises  les mots LTE et WIFI dans ton 
message ? Car j’ai du mal à y retrouver mon latin :)

David Ponzone



> Le 11 mai 2024 à 15:51, Richard Klein  a écrit :
> 
> Le cas de la VoWifi est similaire .
> Il y a aussi les plages IP avec des ACL prochent de L’IMS qui gère la VoLTE.
> Deux exemples:
> 1)Il y a 15 mois environs lorsque j étais en support N2 pour un opérateur 
> mobile ,un client n’arrivait pas à faire de la VOWIFI via starlink.
> Après 2 à 3 semaines de négociations en interne et la fourniture par starlink 
> des plages nous avons ajouté celle-ci sur l ensemble de le france .
> 2) un client n arrivait pas à faire de la VoLTE sur son wifi d entreprise .
> Après mise en place de son ip dans la DMZ de son firewall le résultat était 
> toujours négatif.
> Nous avons aussi vérifier avec une box GP que la ligne était ok en VoWifi et 
> VoLTE .
> Il y avait bien un bloquage de son IP wan qui était anciennement une IP UK.
> Dans les bases externe l ip était bien déclaré en FR mais pas chez l 
> opérateur mobile.
> Donc avec un peu de patience et en trouvant les bonnes personnes il est 
> possible de faire avancer les choses.
> 
> Pour revenir à la VoLTE …
> Pas sur que passer par un VPN va résoudre le problème car de mémoire il y a 
> d’autres mécanismes en place pour localiser le mobile et libre à l opérateur 
> de les exploiter.
> 
> A vérifier mais seul free propose de la VoXXX en dehors de la france.
> 
> Richard
> 
> 
>> Le 11 mai 2024 à 15:28, David Ponzone  a écrit :
>> 
>> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
>> français sait sur son HLR que tu n’es pas en France.
>> 
>> David
>> 
>> 
 Le 11 mai 2024 à 15:21, Erwan David  a écrit :
>>> 
>>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
>>> l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi 
>>> est routé dans un VPN qui sors ensuite avec une IP française ?
>>> 
>>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE 
>>> sur mon one plus nord...
>>> 
>>> 
>>> ---
>>> 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] [TECH] VoWifi : appels depuis l'étranger

[Richard Klein]

Le cas de la VoWifi est similaire .
Il y a aussi les plages IP avec des ACL prochent de L’IMS qui gère la VoLTE.
Deux exemples:
1)Il y a 15 mois environs lorsque j étais en support N2 pour un opérateur 
mobile ,un client n’arrivait pas à faire de la VOWIFI via starlink.
Après 2 à 3 semaines de négociations en interne et la fourniture par starlink 
des plages nous avons ajouté celle-ci sur l ensemble de le france .
2) un client n arrivait pas à faire de la VoLTE sur son wifi d entreprise .
Après mise en place de son ip dans la DMZ de son firewall le résultat était 
toujours négatif.
Nous avons aussi vérifier avec une box GP que la ligne était ok en VoWifi et 
VoLTE .
Il y avait bien un bloquage de son IP wan qui était anciennement une IP UK.
Dans les bases externe l ip était bien déclaré en FR mais pas chez l opérateur 
mobile.
Donc avec un peu de patience et en trouvant les bonnes personnes il est 
possible de faire avancer les choses.

Pour revenir à la VoLTE …
Pas sur que passer par un VPN va résoudre le problème car de mémoire il y a 
d’autres mécanismes en place pour localiser le mobile et libre à l opérateur de 
les exploiter.

A vérifier mais seul free propose de la VoXXX en dehors de la france.

Richard


> Le 11 mai 2024 à 15:28, David Ponzone  a écrit :
> 
> Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
> français sait sur son HLR que tu n’es pas en France.
> 
> David
> 
> 
>> Le 11 mai 2024 à 15:21, Erwan David  a écrit :
>> 
>> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
>> l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi 
>> est routé dans un VPN qui sors ensuite avec une IP française ?
>> 
>> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE 
>> sur mon one plus nord...
>> 
>> 
>> ---
>> 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] [TECH] VoWifi : appels depuis l'étranger

[David Ponzone]

Au hasard, tu es connecté en 4G à l’opérateur local, donc ton opérateur 
français sait sur son HLR que tu n’es pas en France.

David


> Le 11 mai 2024 à 15:21, Erwan David  a écrit :
> 
> Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
> l'étranger. En pratique comment le détecte-t-il ? En particulier si le wifi 
> est routé dans un VPN qui sors ensuite avec une IP française ?
> 
> (au passage y'a bien que Sosh (Orange ?) qui refuse d'activer VoWifi/VoLTE 
> sur mon one plus nord...
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] VoWifi : appels depuis l'étranger

[Erwan David]

Mon nouvel opérateur me met que je ne peux pas appeler en VoWifi depuis 
l'étranger. En pratique comment le détecte-t-il ? En particulier si le 
wifi est routé dans un VPN qui sors ensuite avec une IP française ?


(au passage y'a bien que Sosh (Orange ?) qui refuse d'activer 
VoWifi/VoLTE sur mon one plus nord...



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

Re: [FRnOG] [TECH] Certificat Android pfx

[sofiane JALID]

Bonjour Théophile

Merci pour tes réponses


En gros j’ai un serveur web qui permet aux utilisateurs admin de générer
des certificats Android afin de faire signer en premier lieu la csr avec
les infos dans un inputbox fourni par ces derniers

Ensuite de récupérer le p7b au format base64 et la cer de la pki et ensuite
convertir cela en un fichier pfx avec un mot de passe personnalisé

Voici une partie du code au début qui m’a valu ce problème

Pour convertir le fichier pfx Android initial

Et qui me pose le problème sur certain Android notamment au niveau du mot
de passe refusé

openssl pkcs12 -export -out "${login}_${annee}.pfx" -inkey
"${login}_${annee}_private.pem" -in "$certificate" -certfile "$chain"
-passout pass:"$password" -passin pass:"$password"



J’ai fait évoluer le code de manière à créer 3 types de formulaires Android
10-14

openssl pkcs12 -export -out "$pfx_file" -inkey "$private_key" -in
"$cert_file" -passout pass:"$password" -passin pass:"$password" -keypbe
aes-256 -certpbe aes-256 -macalg sha256


Android 8-10

openssl pkcs12 -export -out "$pfx_file" -inkey "$private_key" -in
"$cert_file" -passout pass:"$password" -passin pass:"$password" -keypbe
aes-128 -certpbe aes-128 -macalg sha256



Android 5-7

openssl pkcs12 -export -out "$pfx_file" -inkey "$private_key" -in
"$cert_file" -passout pass:"$password" -passin pass:"$password" -keypbe
3des -certpbe 3des -macalg sha1

Je me suis fier à cette documentation
https://stackoverflow.com/questions/71872900/installing-pcks12-certificate-in-android-wrong-password-bug





Le ven. 10 mai 2024 à 10:21, Théophile Helleboid  a
écrit :

> Bonjour Stephane,
>
> Je constate qu’après génération de certificat wifi 802.1x certain mobile
> > comme les crosscall ou galaxy tab m’empêche d’installer le pfx avec le
> bon
> > password pourtant ces mêmes certificats s’installe correctement sur
> > d’autres modèle d’androïdes toute version confondu
>
>
> Les dernières versions d'Android exigent désormais que le certificat
> importé soit bien un "Certificat d'Autorité", c'est-à-dire avec le flag
> "X509v3 Basic Constraints CA" à "True".
>
> Auparavant, il était possible d'ajouter un certificat intermédiaire, voire
> le certificat "enfant". Désormais, cela ne fonctionne plus.
>
> Si vous tentiez d'importer le certificat "enfant", cela était peut être la
> source du problème.
> Pour vérifier que le certificat (au format PEM) ait bien le flag "CA" avec
> openssl :
> openssl x509 -in wifi-cert.pem -noout -text
>
> Le "CA: TRUE" doit être présent dans les extensions X509 :
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:TRUE
>
> Je soupçonne que le changement est concomitant au "December Security Patch
> for Android 11", sans en avoir la certitude.
>
> https://www.reddit.com/r/networking/comments/j7ero1/psa_android_11s_december_security_update_will/
>
> Tenez nous au courant si cela est la solution au problème.
>
> Bonne journée à tous,
> --
> Théophile Helleboid
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Certificat Android pfx

[Théophile Helleboid]

Bonjour Stephane,

Je constate qu’après génération de certificat wifi 802.1x certain mobile
> comme les crosscall ou galaxy tab m’empêche d’installer le pfx avec le bon
> password pourtant ces mêmes certificats s’installe correctement sur
> d’autres modèle d’androïdes toute version confondu


Les dernières versions d'Android exigent désormais que le certificat
importé soit bien un "Certificat d'Autorité", c'est-à-dire avec le flag
"X509v3 Basic Constraints CA" à "True".

Auparavant, il était possible d'ajouter un certificat intermédiaire, voire
le certificat "enfant". Désormais, cela ne fonctionne plus.

Si vous tentiez d'importer le certificat "enfant", cela était peut être la
source du problème.
Pour vérifier que le certificat (au format PEM) ait bien le flag "CA" avec
openssl :
openssl x509 -in wifi-cert.pem -noout -text

Le "CA: TRUE" doit être présent dans les extensions X509 :
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE

Je soupçonne que le changement est concomitant au "December Security Patch
for Android 11", sans en avoir la certitude.
https://www.reddit.com/r/networking/comments/j7ero1/psa_android_11s_december_security_update_will/

Tenez nous au courant si cela est la solution au problème.

Bonne journée à tous,
--
Théophile Helleboid

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

[FRnOG] [TECH] Rapport Spoofer pour FRnOG pour avril 2024

[CAIDA Spoofer Project]

Dans le cadre d'un projet de mesure du spoofing IP et de la
validation d'adresse source (https://spoofer.caida.org), CAIDA
produit des rapports mensuels automatisés des AS qui annoncent
des préfixes BGP depuis lesquels nous recevons des paquets
spoofés.  Suite au feedback de la communauté sécurité, nous avons
décidé d'envoyer ces rapports aux mailing lists des communautés
réseau afin de s'assurer que les AS en question obtiennent
l'information.

Ce rapport résume les tests réalisés en fra.

Améliorations en avril 2024 :
 aucune

Problèmes de validation d'adresse source détectés en avril 2024:
ASNNom   Date débutDate fin
200063 CAMINI-IMPEX  2023-06-16   2024-04-28
200136   2024-01-12   2024-04-25

Pour plus d'information sur les tests réalisés,
vous pouvez visiter l'adresse suivante :
https://spoofer.caida.org/recent_tests.php?country_include=fra_block=1

Merci d'envoyer vos commentaires ou suggestions à spoofer-i...@caida.org


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

[FRnOG] [TECH] script / algo numéro mnémotechniques

[Teddy DOURE]

Bonjour,

La question a peut être déjà été posée, si c'est le cas je m'en excuse.

Est-ce que quelqu'un aurait un pti début d'algo ou script permettant de 
retrouver dans une liste de numéros, ceux qui pourraient être taggés comme 
mnémotechnique ?

Merci d'avance.

T.DOURE

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

[FRnOG] [TECH] Certificat Android pfx

[Stephane Miguel]

Bonjour


Je constate qu’après génération de certificat wifi 802.1x certain mobile
comme les crosscall ou galaxy tab m’empêche d’installer le pfx avec le bon
password pourtant ces mêmes certificats s’installe correctement sur
d’autres modèle d’androïdes toute version confondu

J’ai pensé au départ a une protection sur les mobiles mais apparement pas.

Pour info j’ai lu sur internet que les mobiles sont censés avoir un code
pin mais même chose après setup du code pin

J’ai mis des pfx avec blank password même chose aussi
Alors que sur Windows, ou sur quelques modèles de Samsung j’ai pas le
problème

Avez vous une idée ?

Merci bien

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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Jérôme Marteaux]

Le 07/05/2024 à 11:08, David Ponzone a écrit :

J’ai des forts doutes sur la capacité du MVNO-Light à faire bouger Orange, ou 
même répondre.

Ceci dit, si Philippe a le problème avec des cartes Orange Pro, et moi avec des 
cartes MVNO-Light, c’est que c’est un problème inhérent à l’infra complète 
Orange Mobile, dans le contexte Fortinet/Forticlient.


Détrompe toi, chaque MVNO-light a ces propres règles de firewalling chez 
Orange qu'il peut faire évoluer.
Orange Pro et MVNO-light ne partage pas la même infra, mais probablement 
les mêmes modèles d'équipements avec les mêmes versions d'où les 
problèmes identiques.




J’ai de nombreux Mikrotik qui montent des tunnels IKEv2 à travers les mêmes 
cartes MVNO-Light vers du Fortinet, sans problème.


Probablement un ALG qui se déclenche spécifiquement sur le trafic fortinet ?


Ca pourrait donc être lié aussi au MTU négocié par IOS avec Orange.

Si Philippe peut tester avec Android pour voir….

David


Le 6 mai 2024 à 22:15, Jérôme Marteaux  a écrit :

Si tu as accès au support du MVNO-light, remonte-leur le problème, il est 
possible qu'il y ai un firewall sur le chemin dont l'ALG ou l'inspection de 
paquet pose problème.

Jérôme

Le 06/05/2024 à 21:42, David Ponzone a écrit :

Comme je l’ai posté il y a quelques jours, j’ai reproduit le problème de 
Philippe, avec un MVNO-Light Orange (donc techniquement, c’est Orange, CGNAT 
Orange, c’est même normalement plus propre).
Par contre, mon APN, aucune idée :)
David

Le 6 mai 2024 à 19:49, Jérôme Marteaux  a écrit :

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

Bonjour !
En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile.
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.
Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.

Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :

Bonjour



Par curiosité c'est Orange en direct ou via un revendeur ?
L'IP publique appartient à Orange ?
Quel est le nom de l'APN ?


--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Paul Rolland (ポール・ロラン)]

Hello,

On Tue, 7 May 2024 11:08:19 +0200
David Ponzone  wrote:

> Ca pourrait donc être lié aussi au MTU négocié par IOS avec Orange.

Pour info, je fais du partage de connection via un iPhone sur mon Nux quand
je suis hors zone Wifi, et j'ai eu des problemes de MTU a une epoque qui
m'avait oblige a baisser la MTU sur le Nux pour reussir a utiliser mon
partage... 
Mais depuis, j'ai pu supprimer ce hack.
Il reste peut-etre des endroits ou ca ne marche tjrs pas... 
Est-ce OP a le probleme partout (geographiquement) ?

Paul


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

J’ai des forts doutes sur la capacité du MVNO-Light à faire bouger Orange, ou 
même répondre.

Ceci dit, si Philippe a le problème avec des cartes Orange Pro, et moi avec des 
cartes MVNO-Light, c’est que c’est un problème inhérent à l’infra complète 
Orange Mobile, dans le contexte Fortinet/Forticlient.

J’ai de nombreux Mikrotik qui montent des tunnels IKEv2 à travers les mêmes 
cartes MVNO-Light vers du Fortinet, sans problème.
Ca pourrait donc être lié aussi au MTU négocié par IOS avec Orange.

Si Philippe peut tester avec Android pour voir….

David

> Le 6 mai 2024 à 22:15, Jérôme Marteaux  a écrit :
> 
> Si tu as accès au support du MVNO-light, remonte-leur le problème, il est 
> possible qu'il y ai un firewall sur le chemin dont l'ALG ou l'inspection de 
> paquet pose problème.
> 
> Jérôme
> 
> Le 06/05/2024 à 21:42, David Ponzone a écrit :
>> Comme je l’ai posté il y a quelques jours, j’ai reproduit le problème de 
>> Philippe, avec un MVNO-Light Orange (donc techniquement, c’est Orange, CGNAT 
>> Orange, c’est même normalement plus propre).
>> Par contre, mon APN, aucune idée :)
>> David
>>> Le 6 mai 2024 à 19:49, Jérôme Marteaux  a écrit :
>>> 
>>> Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :
 Bonjour !
 En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
 Mobile.
 Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est 
 une honte absolue. Intéressant intellectuellement pour comprendre, mais 
 inadmissible en production.
 Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
 centaines de millisecondes.
 Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
 accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
 d’opérateurs alternatifs pour qu’on puisse terminer le projet.
> Le 6 mai 2024 à 11:46, Thierry Chich  a 
> écrit :
> 
> Bonjour
> 
> 
>>> Par curiosité c'est Orange en direct ou via un revendeur ?
>>> L'IP publique appartient à Orange ?
>>> Quel est le nom de l'APN ?
>>> 
>>> Jérôme
>>> 
> 
> -- 
> Jérôme Marteaux
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Jérôme Marteaux]

Si tu as accès au support du MVNO-light, remonte-leur le problème, il 
est possible qu'il y ai un firewall sur le chemin dont l'ALG ou 
l'inspection de paquet pose problème.


Jérôme

Le 06/05/2024 à 21:42, David Ponzone a écrit :

Comme je l’ai posté il y a quelques jours, j’ai reproduit le problème de 
Philippe, avec un MVNO-Light Orange (donc techniquement, c’est Orange, CGNAT 
Orange, c’est même normalement plus propre).
Par contre, mon APN, aucune idée :)

David



Le 6 mai 2024 à 19:49, Jérôme Marteaux  a écrit :

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

Bonjour !
En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile.
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.
Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.

Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :

Bonjour



Par curiosité c'est Orange en direct ou via un revendeur ?
L'IP publique appartient à Orange ?
Quel est le nom de l'APN ?

Jérôme



--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Comme je l’ai posté il y a quelques jours, j’ai reproduit le problème de 
Philippe, avec un MVNO-Light Orange (donc techniquement, c’est Orange, CGNAT 
Orange, c’est même normalement plus propre).
Par contre, mon APN, aucune idée :)

David


> Le 6 mai 2024 à 19:49, Jérôme Marteaux  a écrit :
> 
> Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :
>> Bonjour !
>> En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
>> Mobile.
>> Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est 
>> une honte absolue. Intéressant intellectuellement pour comprendre, mais 
>> inadmissible en production.
>> Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
>> centaines de millisecondes.
>> Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
>> accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
>> d’opérateurs alternatifs pour qu’on puisse terminer le projet.
>>> Le 6 mai 2024 à 11:46, Thierry Chich  a écrit 
>>> :
>>> 
>>> Bonjour
>>> 
>>> 
> Par curiosité c'est Orange en direct ou via un revendeur ?
> L'IP publique appartient à Orange ?
> Quel est le nom de l'APN ?
> 
> Jérôme
> 
> -- 
> Jérôme Marteaux
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Forticlient VPN SSL

[Stephane Miguel]

Bonjour

Je constate avec l’un de mes clients en tshoot que lors de l’établissement
d’un vpn ssl avec une passerelle distante

Le client forticlient tente de se synchroniser vers d’autres adresses avant
même de se connecter à la target

Par moment sa fail et je vois même pas de trafic quand je filtre vers
l’adresse wan du  concentrateur vpn

En revanche je vois en pagaille des ip ou certaine semble être des ip
portant le fqdn de maj forti

Lorsque je claque l’adresse du concentrateur sur un navigateur je vois bien
du trafic
Mais lorsque je passe par le client forti rien !!

Par moment j’ai des failed update et je suis obligé d’ouvrir large alors
que j’aime juste pas ça !

La topologie :

pc hors domaine mais secure car gère par la compagnie

rupture protocolaire (bastion )

Machine jump à double interface

Cette dernière a deux interface
L’une pour le maintient rdp domaine etc

La seconde interface pour la wan

Des routes statiques pour la première

Et une route par défaut pour la wan natté

Pour l’usage d’internet il y’a ssl intercept qui redirige vers mon portail
captif de mon firewall pour la seconde gestion d’identité pour Allow
uniquement des users d’un groupe de sécurité spécifique


Ça marche parfaitement bien

Sauf ce client vpn qui semble bien décidé à me rendre chèvre à dialoguer
avec lui même (serveur de mise à jour forti) avant même d’établir quoi que
ce soit !

J’ai déjà mis les url que j’ai vu sur le net mais j’ai toutes les deux
semaines un t-shoot à faire car leur client vpn n’envoie plus rien et
semble garder pour lui le trafic pas avant que forti update lui donne le go

Avez vous eu ce genre xp full cancer ?

Merci bien

Stéphane

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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Jérôme Marteaux]

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

Bonjour !

En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile.
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.

Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.


Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :

Bonjour



Par curiosité c'est Orange en direct ou via un revendeur ?
L'IP publique appartient à Orange ?
Quel est le nom de l'APN ?

Jérôme

--
Jérôme Marteaux


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Toussaint OTTAVI]

Le 06/05/2024 à 11:54, Philippe ASTIER via frnog a écrit :

En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile.


C'est sans doute un peu plus complexe que çà. Je pense que si IPSec ne 
passait plus du tout sur Orange Mobile, on serait beaucoup plus nombreux 
à l'avoir constaté :-)


On serait plutôt à priori sur un cas particulier (on a un petit mot en 3 
lettres pour désigner çà) d'une interaction entre l'opérateur, le 
fournisseur de la solution VPN, et, peut-être, un matériel spécifique, 
ou toute autre particularité liée à l'installation. Cà peut s'avérer 
complexe et chronophage à diagnostiquer. Et, quand bien même tu arrives 
à déterminer une cause exacte, et à l'imputer à un intermédiaire précis, 
encore faut-il que tu ne tombes pas sur quelqu'un en face qui pense que 
Wireshark est un requin bleu dans un célèbre dessin animé Français qui 
veut empêcher Zig de bouffer sa copine ;-) Donc, même si tu finis par 
trouver, tu n'auras pas forcément la main pour résoudre le problème seul !


Par pragmatisme, dans ce genre de situation, il est souvent préférable 
de rechercher une solution de contournement, une combinaison "qui 
fonctionne" afin de ne pas être bloqué coté client . Car le client se 
fout que çà vienne d'Orange, de Fortinet, de Poutine ou des phases de la 
lune ;-)  Il a un interlocuteur, c'est toi; et pour lui, c'est *ta* 
solution qui ne fonctionne pas ;-)


Ensuite, si l'impact client est important, rien n'empêche de creuser le 
problème par la suite, histoire de comprendre ce qui cloche, et pouvoir 
mieux anticiper. Mais si c'est sur un cas à la c**, pardon, un cas 
particulier d'un seul mec qui a 5 postes,  qui a insisté pour mettre le 
firewall en DMZ derrière une box en tissu, qui n'a pas voulu attendre 
l'installation d'un deuxième lien chez un opérateur différent, qui sait 
tout faire tout seul mieux que toi, et chez qui ton SSLVPN ne fonctionne 
pas sur terminaux Apple alors qu'il fonctionne très bien sur Android, 
mieux vaut laisser le client aller voir ailleurs  ;-)



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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Bonjour !

En fait, c’est pas compliqué, ça passe juste plus du tout chez Orange Pro 
Mobile. 
Et en 2024, devoir bricoler des APNs ou des MTU pour que ça marche, c’est une 
honte absolue. Intéressant intellectuellement pour comprendre, mais 
inadmissible en production.
Tu changes d’opérateur ou tu essaies en Wifi, et hop, connecté en quelques 
centaines de millisecondes.

Je suis en discussion avec le client pour savoir ce qu’on met en priorité: 
accélération du déploiement de la solution ZTNA, quitte à mettre de eSIM 
d’opérateurs alternatifs pour qu’on puisse terminer le projet.

> Le 6 mai 2024 à 11:46, Thierry Chich  a écrit :
> 
> Bonjour
> 
> 
> Moi je ferais quand même une capture sur un qui qui marche et un qui marche 
> pas. Le coup de l'isakmp fragmenté, je l'ai eu aussi. Pas avec du forti en 
> revanche. Le certif était gros, le paquet isakmp passait pas en 1500 octets, 
> et une maj d'un ios cisco avait décidé qu'il fallait droppé. Alors oui, la 
> phase 1 est sensé fonctionner, mais bon.
> 
> 
> Le 02/05/2024 à 20:53, Philippe ASTIER via frnog a écrit :
>> Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé 
>> ce qui se passe en wifi vs 4G/5G Orange.
>> 
>> Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
>> négociation a l’air vraiment identique.
>> Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un 
>> truc qui m’échappe.
>> 
>> Mais bon sang, qu’est-ce que ça cause ces logs !….
>> 
>> Le 2 mai 2024 à 19:30, David Ponzone  a écrit :
>> 
>> Vincent,
>> 
>> Ca bloque pas chez Orange puisque Philippe dit que la négociation 
>> Phase1/Phase2 semble bien se passer et puis paf!
>> 
>> Philippe,
>> 
>> Tu vas devoir entrer dans le monde du debug Forti :)
>> 
>> David
>> 
>> Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a 
>> écrit :
>> 
>> On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
>> ...
>> 
>> - sur la partie « split-tuneling », je ne vois pas trop le rapport.
>> 
>> Aucun, c'est la description du bug de David en SSL qui y ressemble
>> 
>> Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
>> n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben 
>> ça juste fonctionne sans aucun souci.
>> Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il 
>> n’y a que chez Orange (offre Orange Pro) que ça semble se déclencher, et 
>> c’est pénible.
>> 
>> C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
>> (uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
>> C'est en tout cas ce que je constate.
>> Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.
>> 
>> Vincent.
>> 
>> 
>> Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a 
>> écrit :
>> On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
>> On doit pas parler du même problème.
>> Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
>> priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
>> n’est pas dispo en IPv6.
>> Je ne connais pas fortinet, mais la description ressemble a un problème de 
>> split tunneling.
>> Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
>> « A good IPv6 is a disabled one ».
>> Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la 
>> plupart du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web 
>> simple.
>> IPv6, lui, fonctionne correctement.
>> Vincent.
>> ...
>> ---
>> 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/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> -- 
> 
> Thierry CHICH
> 
> x...@ac-clermont.fr 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Thierry Chich]

Bonjour


Moi je ferais quand même une capture sur un qui qui marche et un qui 
marche pas. Le coup de l'isakmp fragmenté, je l'ai eu aussi. Pas avec du 
forti en revanche. Le certif était gros, le paquet isakmp passait pas en 
1500 octets, et une maj d'un ios cisco avait décidé qu'il fallait 
droppé. Alors oui, la phase 1 est sensé fonctionner, mais bon.



Le 02/05/2024 à 20:53, Philippe ASTIER via frnog a écrit :

Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé ce 
qui se passe en wifi vs 4G/5G Orange.

Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
négociation a l’air vraiment identique.
Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un truc 
qui m’échappe.

Mais bon sang, qu’est-ce que ça cause ces logs !….

Le 2 mai 2024 à 19:30, David Ponzone  a écrit :

Vincent,

Ca bloque pas chez Orange puisque Philippe dit que la négociation Phase1/Phase2 
semble bien se passer et puis paf!

Philippe,

Tu vas devoir entrer dans le monde du debug Forti :)

David

Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a écrit :

On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
...

- sur la partie « split-tuneling », je ne vois pas trop le rapport.

Aucun, c'est la description du bug de David en SSL qui y ressemble

Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben ça 
juste fonctionne sans aucun souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il n’y 
a que chez Orange (offre Orange Pro) que ça semble se déclencher, et c’est 
pénible.

C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
(uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
C'est en tout cas ce que je constate.
Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.

Vincent.


Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a écrit :
On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
n’est pas dispo en IPv6.
Je ne connais pas fortinet, mais la description ressemble a un problème de 
split tunneling.
Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
« A good IPv6 is a disabled one ».
Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la plupart 
du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web simple.
IPv6, lui, fonctionne correctement.
Vincent.
...
---
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/


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


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

--

Thierry CHICH

x...@ac-clermont.fr 



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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philou via frnog]

Bonjour Toussaint,

On Thu, 2 May 2024 19:34:29 +0200
Toussaint OTTAVI  wrote:

> Les conditions dans lesquelles un paquet IKE a besoin d'être fragmenté 
> et/ou les paquets arrivent dans le désordre,  je ne les connais pas 
> vraiment.

- Éviter la fragmentation au niveau IP. Les paquets fragmentés pourraient être 
filtrés en chemin par certains routeurs
- En IKEv2, la fragmentation IKE sera utilisée la plupart du temps dans la 
phase IKE_AUTH, en particulier lors de l'utilisation de certificats SSL
- En IKEv1 (ou v2), cela peut être dû à une clé PSK très/trop longue
- La raison pour laquelle les paquets arrivent dans le désordre, je ne saurais 
dire (autrement que le "U" dans "UDP" ;)

> En revanche, dans mon client VPN logiciel (d'une autre 
> marque, je le rappelle), il y a une option "Restrict the size of the 
> first ISAKMP packet sent". Depuis que cette option existe (je dirais un 
> an ou deux), lorsque le problème se produit, elle permet de le résoudre.

Je ne connais pas le logiciel utilisé mais cela ressemble à l'activation de la 
fragmentation IKE avec une éventuelle détection du PMTU afin d'éviter la 
fragmentation IP.

My 2 cents,

Philou


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Au passage, en debug, je vois 2 trucs bizarres:

-le CGNAT d’Orange présente mon mobile avec les ports 500 et 4500 sur l’IP 
Publique CGNAT (92.184.116.219), ce qui parait invraisemblable, donc leur CGNAT 
doit avoir un IPSEC-ALG, et comme tout bon ALG (ou presque), il doit faire de 
la merde
(Hypothèse2: y a pas d’IPSEC-ALG, et seul le premier mobile derrière l’IP 
publique profite des ports 500/4500)

-la déco semble provoquer par une demande du client:

ike 0: comes 92.184.116.219:4500->X.X.X.X:4500,ifindex=5
ike 0:TestIPsec_0:25093: recv ISAKMP SA delete eeebca155dd89958/0aeba54063d5e433

(Peut-être une conséquence de la non-réception de certains paquets envoyés par 
le FG vers le port 4500 du client)

Bref, un beau merdier. Vive SSL.

David

> Le 3 mai 2024 à 09:16, Philippe ASTIER via frnog  a écrit :
> 
> 
>> Le 3 mai 2024 à 08:54, Dev Mart  a écrit :
>> 
>> Hello, tu as aucun log dans VPN events pour t'aiguiller sur le problème ?
> 
> Salut,
> 
> Alors les VPN Events, ils ne voient pas grand chose, tout est « success » et 
> joliment vert.
> 
> Non, les vrais logs, tu les as en CLI :
> 
> diag debug application ike -1
> diag debug enable
> 
> Et aussi  diagnose vpn ike log-filter … si tu ne veux pas mourrir sous les 
> logs des autres tunnels VPN qui ne t’intéressent pas.
> 
> Le seul souci c’est que c’est TRES verbose, donc ça prend du temps à lire et 
> digérer.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Philippe,

Si ça peut te rassurer (….), j’ai exactement le même comportement que toi avec 
un FG en 6.2.X en IPv4-only, et le client natif IPsec IOS (en mode Cisco IPsec):
-en wifi (Bouygues Tel, IPv6 actif): ça monte
-en 4G (Orange par MVNO-light, IPv6 actif): ça monte pas

J’ai essayé de mettre le nattraversal en forced côté FG, pas mieux.

Ca semble donc plus être un problème avec Orange que d’IPv6.

David

> Le 3 mai 2024 à 09:16, Philippe ASTIER via frnog  a écrit :
> 
> 
>> Le 3 mai 2024 à 08:54, Dev Mart  a écrit :
>> 
>> Hello, tu as aucun log dans VPN events pour t'aiguiller sur le problème ?
> 
> Salut,
> 
> Alors les VPN Events, ils ne voient pas grand chose, tout est « success » et 
> joliment vert.
> 
> Non, les vrais logs, tu les as en CLI :
> 
> diag debug application ike -1
> diag debug enable
> 
> Et aussi  diagnose vpn ike log-filter … si tu ne veux pas mourrir sous les 
> logs des autres tunnels VPN qui ne t’intéressent pas.
> 
> Le seul souci c’est que c’est TRES verbose, donc ça prend du temps à lire et 
> digérer.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

> Le 3 mai 2024 à 08:54, Dev Mart  a écrit :
> 
> Hello, tu as aucun log dans VPN events pour t'aiguiller sur le problème ?

Salut,

Alors les VPN Events, ils ne voient pas grand chose, tout est « success » et 
joliment vert.

Non, les vrais logs, tu les as en CLI :

diag debug application ike -1
diag debug enable

Et aussi  diagnose vpn ike log-filter … si tu ne veux pas mourrir sous les logs 
des autres tunnels VPN qui ne t’intéressent pas.

Le seul souci c’est que c’est TRES verbose, donc ça prend du temps à lire et 
digérer.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

> On Thu, May 2, 2024, at 19:04, Philippe ASTIER via frnog wrote:
>> - les Forti sont exclusivement en IPv4 (eh oui, vous pourrez me 
>> troller, je suis un fervent défenseur d’IPv6, mais pas dans ce cas ;p )
> 
> Pourquoi ?
> Tu peux avoir l'IPv6 actif uniquement sur le cote WAN du FW (qui est deja 
> suppose etre globalement joignable en v4).

C’est juste une conf historique d’un temps où leur FTTO (et SDSL avant) n’avait 
pas d’IPv6.

Un truc vient de jaillir dans ma tête… J’ai cru voir hier dans les logs que le 
NAT-T n’était pas bien détecté en 4G/5G… 
Comme si quand le client est en IPv6, il ne se voit pas derrière un NAT (ce qui 
d’un point de vue v6 est juste, mais faux en v4…).

Ca irait dans le sens de s’activer l’APN v6.

Je vais me retaper les 3000 lignes de logs et en refaire avec le client… Happy 
Friday.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

> On Thu, May 2, 2024, at 12:56, David Ponzone wrote:
>> Désactive IPv6 sur le client pour voir.
> 
> ??? En 2024 AD ???

Oui, je suis assez d’accord, et pour mémoire, sur iOS/iPadOS, c’est totalement 
impossible en cellulaire (sauf bidouilles APN, et encore, je vais tâcher de 
tester.

> Pourquoi pas activer IPv6 sur le head-end (au moins cote WAN) "juste pour 
> voir" ?

Oui, ok, pour voir ça me va, ça ne coûte pas grand chose, et ça ne changera 
rien à mes confs.

> Sinon, cote Forti, il y a la "firewall authentication", mais c'est un truc 
> qui va plutot (vaguement) dans le sens du ZTNA (et ca implique que l'ensemble 
> des ressources exposes aient des IP publiques - plus simple en v6 qu'en v4)

Comme dit précédemmentt, on devrait implanter d’ici l’été une solution de ZTNA 
(JAMF Private Access), qui établit un tunnel wireguard avec l’infra JAMF, et on 
est en IKEv2 fixe vers l’infra du client. 
Je teste depuis quelques semaines chez moi, ça marche rudement bien, avec 
contrôle d’accès depuis le client (identité, conformité et ce qu’on veut), et 
possible traffic vectoring, DNS privé. Du coup aucune exposition publique de 
l’infra du client.
Je ne voulais pas révolutionner la conf des Forti avant ça.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Dev Mart]

Hello, tu as aucun log dans VPN events pour t'aiguiller sur le problème ?


Cordialement

Le ven. 3 mai 2024, 08:20, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Thu, May 2, 2024, at 19:04, Philippe ASTIER via frnog wrote:
> > - les Forti sont exclusivement en IPv4 (eh oui, vous pourrez me
> > troller, je suis un fervent défenseur d’IPv6, mais pas dans ce cas ;p )
>
> Pourquoi ?
> Tu peux avoir l'IPv6 actif uniquement sur le cote WAN du FW (qui est deja
> suppose etre globalement joignable en v4).
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Radu-Adrian Feurdean]

On Thu, May 2, 2024, at 19:04, Philippe ASTIER via frnog wrote:
> - les Forti sont exclusivement en IPv4 (eh oui, vous pourrez me 
> troller, je suis un fervent défenseur d’IPv6, mais pas dans ce cas ;p )

Pourquoi ?
Tu peux avoir l'IPv6 actif uniquement sur le cote WAN du FW (qui est deja 
suppose etre globalement joignable en v4).


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Radu-Adrian Feurdean]

On Thu, May 2, 2024, at 12:56, David Ponzone wrote:
> Désactive IPv6 sur le client pour voir.

??? En 2024 AD ???
Pourquoi pas activer IPv6 sur le head-end (au moins cote WAN) "juste pour voir" 
?

Sinon, cote Forti, il y a la "firewall authentication", mais c'est un truc qui 
va plutot (vaguement) dans le sens du ZTNA (et ca implique que l'ensemble des 
ressources exposes aient des IP publiques - plus simple en v6 qu'en v4)


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Ouais, c’est pas le point fort de Forti.

David Ponzone



> Le 2 mai 2024 à 20:53, Philippe ASTIER  a 
> écrit :
> 
>  Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé 
> ce qui se passe en wifi vs 4G/5G Orange.
> 
> Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
> négociation a l’air vraiment identique.
> Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un truc 
> qui m’échappe.
> 
> Mais bon sang, qu’est-ce que ça cause ces logs !….
> 
>>> Le 2 mai 2024 à 19:30, David Ponzone  a écrit :
>>> 
>>> Vincent,
>>> 
>>> Ca bloque pas chez Orange puisque Philippe dit que la négociation 
>>> Phase1/Phase2 semble bien se passer et puis paf!
>>> 
>>> Philippe,
>>> 
>>> Tu vas devoir entrer dans le monde du debug Forti :)
>>> 
>>> David
>>> 
>>> Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a 
>>> écrit :
>>> 
>>> On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
>>> ...
>>> 
 - sur la partie « split-tuneling », je ne vois pas trop le rapport.
>>> 
>>> Aucun, c'est la description du bug de David en SSL qui y ressemble
>>> 
 Ce que je trouve désolant, c’est que quand le client qui se connecte est 
 sur n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / 
 FreePro, ben ça juste fonctionne sans aucun souci.
 Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il 
 n’y a que chez Orange (offre Orange Pro) que ça semble se déclencher, et 
 c’est pénible.
>>> 
>>> C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
>>> (uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
>>> C'est en tout cas ce que je constate.
>>> Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.
>>> 
>>> Vincent.
>>> 
 
> Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a 
> écrit :
> On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
>> On doit pas parler du même problème.
>> Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
>> priori, et se déclenche quand le client a accès à IPv6 alors que le 
>> serveur n’est pas dispo en IPv6.
> Je ne connais pas fortinet, mais la description ressemble a un problème 
> de split tunneling.
> Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
>> « A good IPv6 is a disabled one ».
> Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la 
> plupart du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du 
> web simple.
> IPv6, lui, fonctionne correctement.
> Vincent.
>> ...
> ---
> 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/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 

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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Oui ben j’ai commencé le debug, (diag debug application ike -1) et comparé ce 
qui se passe en wifi vs 4G/5G Orange.

Pour le moment, à part le fait que ça coupe dans le deuxième cas, la 
négociation a l’air vraiment identique.
Je vais tâcher de faire du vrai diff entre les deux, il y a forcément un truc 
qui m’échappe.

Mais bon sang, qu’est-ce que ça cause ces logs !….

Le 2 mai 2024 à 19:30, David Ponzone  a écrit :

Vincent,

Ca bloque pas chez Orange puisque Philippe dit que la négociation Phase1/Phase2 
semble bien se passer et puis paf!

Philippe,

Tu vas devoir entrer dans le monde du debug Forti :)

David

Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a écrit :

On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
...

- sur la partie « split-tuneling », je ne vois pas trop le rapport.

Aucun, c'est la description du bug de David en SSL qui y ressemble

Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben ça 
juste fonctionne sans aucun souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il n’y 
a que chez Orange (offre Orange Pro) que ça semble se déclencher, et c’est 
pénible.

C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
(uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
C'est en tout cas ce que je constate.
Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.

Vincent.


Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a écrit :
On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
n’est pas dispo en IPv6.
Je ne connais pas fortinet, mais la description ressemble a un problème de 
split tunneling.
Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
« A good IPv6 is a disabled one ».
Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la plupart 
du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web simple.
IPv6, lui, fonctionne correctement.
Vincent.
...
---
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/


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


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Jérôme Marteaux]

Le 02/05/2024 à 19:34, Toussaint OTTAVI a écrit :


Le 02/05/2024 à 12:48, Philippe ASTIER via frnog a écrit :

Depuis quelques mois (dur à retracer), chez un seul client, impossible
de monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur
le device ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet depuis
n’importe quel autre opérateur fonctionne sans souci.


J'utilise une autre marque de firewalls, mais il m'arrive parfois de 
constater ce phénomène. Parfois, çà se produit sur certaines connexions 
en partage 4G/5G (pas toutes). D'autres fois, derrière une Livebox, çà 
passe en Ethernet, mais çà ne passe pas en WiFi. Il n'y a pas de règle 
absolue...


Il y a longtemps, je m'étais amusé à faire des captures de paquets :
- IKE, c'est de l'UDP. Lorsque le premier paquet est trop gros, il est 
fragmenté
- Coté destination, les fragments arrivent "dans le mauvais ordre" (mais 
pourquoi ???)
- Le ré-assemblage des fragments ne se fait pas, et cela empêche la 
négociation IKE de démarrer


Les conditions dans lesquelles un paquet IKE a besoin d'être fragmenté 
et/ou les paquets arrivent dans le désordre,  je ne les connais pas 
vraiment.  En revanche, dans mon client VPN logiciel (d'une autre 
marque, je le rappelle), il y a une option "Restrict the size of the 
first ISAKMP packet sent". Depuis que cette option existe (je dirais un 
an ou deux), lorsque le problème se produit, elle permet de le résoudre.


Hope this helps...


Peut-être est-ce une application précoce de:
https://www.lemonde.fr/pixels/article/2024/04/22/europol-s-oppose-au-chiffrement-des-messageries_6229195_4408996.html

Le VPN ne fonctionnant plus, il faut passer que ça passe en clair ! :)

--
Jérôme Marteaux



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

Re: [SPAM] Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Toussaint OTTAVI]

Le 02/05/2024 à 19:30, David Ponzone a écrit :

Ca bloque pas chez Orange puisque Philippe dit que la négociation Phase1/Phase2 
semble bien se passer et puis paf!


J'avais lu un peu trop rapidement. Donc, cela ne ressemble pas à mon 
problème de paquet ISAKMP initial fragmenté qui arrive dans le désordre...

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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Toussaint OTTAVI]

Le 02/05/2024 à 12:48, Philippe ASTIER via frnog a écrit :

Depuis quelques mois (dur à retracer), chez un seul client, impossible
de monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur
le device ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet depuis
n’importe quel autre opérateur fonctionne sans souci.


J'utilise une autre marque de firewalls, mais il m'arrive parfois de 
constater ce phénomène. Parfois, çà se produit sur certaines connexions 
en partage 4G/5G (pas toutes). D'autres fois, derrière une Livebox, çà 
passe en Ethernet, mais çà ne passe pas en WiFi. Il n'y a pas de règle 
absolue...


Il y a longtemps, je m'étais amusé à faire des captures de paquets :
- IKE, c'est de l'UDP. Lorsque le premier paquet est trop gros, il est 
fragmenté
- Coté destination, les fragments arrivent "dans le mauvais ordre" (mais 
pourquoi ???)
- Le ré-assemblage des fragments ne se fait pas, et cela empêche la 
négociation IKE de démarrer


Les conditions dans lesquelles un paquet IKE a besoin d'être fragmenté 
et/ou les paquets arrivent dans le désordre,  je ne les connais pas 
vraiment.  En revanche, dans mon client VPN logiciel (d'une autre 
marque, je le rappelle), il y a une option "Restrict the size of the 
first ISAKMP packet sent". Depuis que cette option existe (je dirais un 
an ou deux), lorsque le problème se produit, elle permet de le résoudre.


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Vincent,

Ca bloque pas chez Orange puisque Philippe dit que la négociation Phase1/Phase2 
semble bien se passer et puis paf!

Philippe,

Tu vas devoir entrer dans le monde du debug Forti :)

David

> Le 2 mai 2024 à 19:19, Vincent Tondellier via frnog  a écrit 
> :
> 
> On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
> ...
> 
>> - sur la partie « split-tuneling », je ne vois pas trop le rapport. 
> 
> Aucun, c'est la description du bug de David en SSL qui y ressemble
> 
>> Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
>> n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben 
>> ça juste fonctionne sans aucun souci.
>> Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il 
>> n’y a que chez Orange (offre Orange Pro) que ça semble se déclencher, et 
>> c’est pénible.
> 
> C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
> (uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.
> C'est en tout cas ce que je constate.
> Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.
> 
> Vincent.
> 
>> 
>>> Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a 
>>> écrit :
>>> On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
 On doit pas parler du même problème.
 Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
 priori, et se déclenche quand le client a accès à IPv6 alors que le 
 serveur n’est pas dispo en IPv6.
>>> Je ne connais pas fortinet, mais la description ressemble a un problème de 
>>> split tunneling.
>>> Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
 « A good IPv6 is a disabled one ».
>>> Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la 
>>> plupart du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web 
>>> simple.
>>> IPv6, lui, fonctionne correctement.
>>> Vincent.
 ...
>>> ---
>>> 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/


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Vincent Tondellier via frnog]

On jeudi 2 mai 2024 19 h 04 min 32 s CEST, Philippe ASTIER via frnog wrote:
...

- sur la partie « split-tuneling », je ne vois pas trop le 
rapport. 


Aucun, c'est la description du bug de David en SSL qui y ressemble

Ce que je trouve désolant, c’est que quand le client qui se 
connecte est sur n’importe quel autre réseau, avec ou sans IPv6, 
ou chez Free / FreePro, ben ça juste fonctionne sans aucun 
souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez 
Forti, mais  il n’y a que chez Orange (offre Orange Pro) que ça 
semble se déclencher, et c’est pénible.


C'est ce que je dis, il y a un truc sur l'IPv4 (uniquement) chez orange 
(uniquement) qui bloque l'udp et/ou l'esp, comme un proxy tcp only.

C'est en tout cas ce que je constate.
Activer ou désactiver l'IPv6 d'un coté seulement n'y changera rien.

Vincent.



Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog 
 a écrit :


On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:

On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que 
SSL/Forticlient à priori, et se déclenche quand le client a 
accès à IPv6 alors que le serveur n’est pas dispo en IPv6.


Je ne connais pas fortinet, mais la description ressemble a un 
problème de split tunneling.


Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.


« A good IPv6 is a disabled one ».


Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 
est la plupart du temps cassé (CGNAT, DNS64 et autre) pour 
autre chose que du web simple.

IPv6, lui, fonctionne correctement.

Vincent.


 ...



---
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] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Désolé de ne pas être revenus vers vous avant ! Après-midi chargée et 
impossible d’avoir le client pour test avant demain.

Alors, je confirme :

- les clients se connectent en IPSec (IKEv1 ou v2, a priori, ça fait pareil) 
sur un FQDN IPv4-only,
- les Forti sont exclusivement en IPv4 (eh oui, vous pourrez me troller, je 
suis un fervent défenseur d’IPv6, mais pas dans ce cas ;p )
- les Forti sont sur la branche 7.2 pour le moment.

- Je n’ai pas encore pu toucher à leurs réglages d’APN, que je peux contrôler 
par un profil de configuration, y compris la version, v4 vs v6. (David, Apple 
Configurator, ça existe encore, mais on n’y touche plus depuis un moment, c’est 
trop basique)
On a les réglages à utiliser chez Orange ? 

- sur la partie « split-tuneling », je ne vois pas trop le rapport. Le tunnel 
s’établit, et tombe quasi immédiatement, uniquement via le réseau data d’Orange 
Pro. Par n’importe quel autre réseau qu’on a pu tester, ça fonctionne. 
- j’avoue que le coup de l’IP à la place du FQDN, ça coûte pas cher à tester, 
mais ça me choque ! 

- IPv6 n’est pas désactivable sur iOS. On peut le désactiver manuellement sur 
un SSID donné en Wifi ou une connexion Ethernet, mais pas de manière générale, 
et pas en cellulaire. 

Ce que je trouve désolant, c’est que quand le client qui se connecte est sur 
n’importe quel autre réseau, avec ou sans IPv6, ou chez Free / FreePro, ben ça 
juste fonctionne sans aucun souci.
Donc je veux bien qu’il y ait aussi un bug qui traine chez Forti, mais  il n’y 
a que chez Orange (offre Orange Pro) que ça semble se déclencher, et c’est 
pénible.



> Le 2 mai 2024 à 15:15, Vincent Tondellier via frnog  a écrit 
> :
> 
> On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:
>> On doit pas parler du même problème.
>> Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
>> priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
>> n’est pas dispo en IPv6.
> 
> Je ne connais pas fortinet, mais la description ressemble a un problème de 
> split tunneling.
> 
> Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.
> 
>> « A good IPv6 is a disabled one ».
> 
> Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la plupart 
> du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web simple.
> IPv6, lui, fonctionne correctement.
> 
> Vincent.
> 
>> 
>>> Le 2 mai 2024 à 14:46, Vincent Tondellier  a 
>>> écrit :
>>> Bonjour,
>>> On jeudi 2 mai 2024 12 h 56 min 30 s CEST, David Ponzone wrote: ...
>> 
>> 
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Vincent Tondellier via frnog]

On jeudi 2 mai 2024 14 h 54 min 53 s CEST, David Ponzone wrote:

On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que 
SSL/Forticlient à priori, et se déclenche quand le client a 
accès à IPv6 alors que le serveur n’est pas dispo en IPv6.


Je ne connais pas fortinet, mais la description ressemble a un problème de 
split tunneling.


Cependant, Philippe parlait d'un problème avec IKEv2, pas avec SSL/ppp.


« A good IPv6 is a disabled one ».


Sans vouloir nourrir le troll, sur les réseaux mobiles, l'IPv4 est la 
plupart du temps cassé (CGNAT, DNS64 et autre) pour autre chose que du web 
simple.

IPv6, lui, fonctionne correctement.

Vincent.



Le 2 mai 2024 à 14:46, Vincent Tondellier 
 a écrit :


Bonjour,

On jeudi 2 mai 2024 12 h 56 min 30 s CEST, David Ponzone wrote: ...







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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

On doit pas parler du même problème.
Celui auquel je pense doit dater de 2021, concerne que SSL/Forticlient à 
priori, et se déclenche quand le client a accès à IPv6 alors que le serveur 
n’est pas dispo en IPv6.

« A good IPv6 is a disabled one ».

David

> Le 2 mai 2024 à 14:46, Vincent Tondellier  a écrit 
> :
> 
> Bonjour,
> 
> On jeudi 2 mai 2024 12 h 56 min 30 s CEST, David Ponzone wrote:
>> Désactive IPv6 sur le client pour voir.
> 
> C'est le contraire qu'il faut faire. En IPv6 ca passe, en IPv4 non 
> (probablement CGNAT ou autre mécanisme de transition a la con qui fout la 
> merde).
> 
> (Re-)testé a l'instant sur un orange grand public, avec l'appli strongswan 
> sur android.
> "Use IPv6 transport address" dans la conf coché : OK, décoché : KO.
> (avec serveur IKEv2 strongswan et IPv6 activé, et kernel 5.10).
> 
> Ca fait de mes souvenirs plus d'un an que c'est comme ça.
> 
> Vincent.
> 
> On jeudi 2 mai 2024 12 h 48 min 37 s CEST, Philippe ASTIER via frnog wrote:
>> Salut à tous !
>> 
>> Je rencontre un souci très pénible.
>> 
>> J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
>> Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
>> FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les 
>> sites distants sans aucun souci, fiables, ça monte très vite en IKEv2.
>> La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
>> clients Forti selon les cas, mais pas eu beaucoup de soucis.
>> 
>> Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
>> monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le 
>> device ou en partage de connexion).
>> Avec la même configuration, la connexion en wifi/ethernet depuis n’importe 
>> quel autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro 
>> mobiles, aucun problème, le tunnel est établie en 150 ms à peine.
>> 
>> Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
>> normalement, puis j’ai quasi dans la foulée un message du type «  recv 
>> ISAKMP SA delete » dans les logs de debug du Forti, et le tunnel ne monte 
>> pas.
>> 
>> 
>> Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
>> tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
>> pourrait me donner des pistes…
>> Any idea ?
>> 
>> 
>> (PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
>> train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait 
>> juste marcher comme chez les autres opérateurs, ça me soulagerait des 
>> plaintes récurrentes et justifiées du client)
> 


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Vincent Tondellier via frnog]

Bonjour,

On jeudi 2 mai 2024 12 h 56 min 30 s CEST, David Ponzone wrote:

Désactive IPv6 sur le client pour voir.


C'est le contraire qu'il faut faire. 
En IPv6 ca passe, en IPv4 non (probablement CGNAT ou autre mécanisme de 
transition a la con qui fout la merde).


(Re-)testé a l'instant sur un orange grand public, avec l'appli strongswan 
sur android.

"Use IPv6 transport address" dans la conf coché : OK, décoché : KO.
(avec serveur IKEv2 strongswan et IPv6 activé, et kernel 5.10).

Ca fait de mes souvenirs plus d'un an que c'est comme ça.

Vincent.

On jeudi 2 mai 2024 12 h 48 min 37 s CEST, Philippe ASTIER via frnog wrote:

Salut à tous !

Je rencontre un souci très pénible.

J’ai depuis plus de dix ans plusieurs clients avec des sites 
distants et des Fortigate. Lignes fibres pour la plupart 
aujourd'hui, chez Orange Pro, Free, FreePro, SFR, Colt, Unyc, 
peu importe. J’ai des tunnels IPSec entre les sites distants 
sans aucun souci, fiables, ça monte très vite en IKEv2.
La plupart ont aussi un accès via leurs mobiles ou ordinateurs. 
SSL, IPSec, clients Forti selon les cas, mais pas eu beaucoup de 
soucis.


Depuis quelques mois (dur à retracer), chez un seul client, 
impossible de monter un tunnel IPSec via iOS ou macOS quand ils 
sont en 4G/5G (sur le device ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet 
depuis n’importe quel autre opérateur fonctionne sans souci. 
J’ai essayé via Free et FreePro mobiles, aucun problème, le 
tunnel est établie en 150 ms à peine.


Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble 
se passer normalement, puis j’ai quasi dans la foulée un message 
du type «  recv ISAKMP SA delete » dans les logs de debug du 
Forti, et le tunnel ne monte pas.



Comme je viens de manger du log de debug depuis des jours en 
m’arrachant la tête, je me suis dit que soumettre ça à la 
brillante sagacité de la liste pourrait me donner des pistes…

Any idea ?


(PS: oui, dans ce cas précis, on envisage le VPN SSL, voire 
même on est en train de mettre une solution ZTNA basée sur 
Wireguard, mais si ça pouvait juste marcher comme chez les 
autres opérateurs, ça me soulagerait des plaintes récurrentes et 
justifiées du client)



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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Baptiste Chappe]

Salut,
Remplace le fqdn par l’ipv4 sur le client :-) c’est crade mais ca marche
(tête fortinet 7.2 et 7.4) …

Baptiste


Le jeu. 2 mai 2024 à 13:24, David Ponzone  a
écrit :

> Si c’est le fameux bug Forticlient/IPv6, c’est seulement en SSL de mémoire:
>
>
> https://community.fortinet.com/t5/Support-Forum/IPv6-causing-SSL-VPN-connection-issue/m-p/9089
> <
> https://community.fortinet.com/t5/Support-Forum/IPv6-causing-SSL-VPN-connection-issue/m-p/9089
> >
>
> Pour IOS, à une époque, on pouvait virer IPv6 en faisant un profile custom
> avec:
>
> https://support.apple.com/apple-configurator <
> https://support.apple.com/apple-configurator>
>
> David
>
> > Le 2 mai 2024 à 13:08, Philippe ASTIER 
> a écrit :
> >
> > OK, why not, on va faire ça sur le Mac, pas possible sur iOS.
> >
> > (Chez Free, pas besoin de désactiver IPv6 en tout cas.)
> >
> >
> > Et pour la MTU, Ludovic, moi je veux bien…. Mais de quel côté ? Et puis
> le PMTU il est sensé être négocié proprement, je n’ai jamais eu à le faire
> sur aucun tunnel VPN.
> >
> >
> > Ce qui me choque, c’est que le seul fait de passer par Orange Mobile
> casse le fonctionnement d’un VPN alors qu’aucune des deux extrémités n’a
> changé sa configuration.
> >
> >
> >
> >> Le 2 mai 2024 à 12:56, David Ponzone  a écrit
> :
> >>
> >> Désactive IPv6 sur le client pour voir.
> >>
> >> David
> >>
> >>> Le 2 mai 2024 à 12:48, Philippe ASTIER via frnog  a
> écrit :
> >>>
> >>> Salut à tous !
> >>>
> >>> Je rencontre un souci très pénible.
> >>>
> >>> J’ai depuis plus de dix ans plusieurs clients avec des sites distants
> et des Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange
> Pro, Free, FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec
> entre les sites distants sans aucun souci, fiables, ça monte très vite en
> IKEv2.
> >>> La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL,
> IPSec, clients Forti selon les cas, mais pas eu beaucoup de soucis.
> >>>
> >>> Depuis quelques mois (dur à retracer), chez un seul client, impossible
> de monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le
> device ou en partage de connexion).
> >>> Avec la même configuration, la connexion en wifi/ethernet depuis
> n’importe quel autre opérateur fonctionne sans souci. J’ai essayé via Free
> et FreePro mobiles, aucun problème, le tunnel est établie en 150 ms à peine.
> >>>
> >>> Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se
> passer normalement, puis j’ai quasi dans la foulée un message du type «
> recv ISAKMP SA delete » dans les logs de debug du Forti, et le tunnel ne
> monte pas.
> >>>
> >>>
> >>> Comme je viens de manger du log de debug depuis des jours en
> m’arrachant la tête, je me suis dit que soumettre ça à la brillante
> sagacité de la liste pourrait me donner des pistes…
> >>> Any idea ?
> >>>
> >>>
> >>> (PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on
> est en train de mettre une solution ZTNA basée sur Wireguard, mais si ça
> pouvait juste marcher comme chez les autres opérateurs, ça me soulagerait
> des plaintes récurrentes et justifiées du client)
> >>> ---
> >>> 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] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Si c’est le fameux bug Forticlient/IPv6, c’est seulement en SSL de mémoire:

https://community.fortinet.com/t5/Support-Forum/IPv6-causing-SSL-VPN-connection-issue/m-p/9089
 


Pour IOS, à une époque, on pouvait virer IPv6 en faisant un profile custom avec:

https://support.apple.com/apple-configurator 


David

> Le 2 mai 2024 à 13:08, Philippe ASTIER  a 
> écrit :
> 
> OK, why not, on va faire ça sur le Mac, pas possible sur iOS.
> 
> (Chez Free, pas besoin de désactiver IPv6 en tout cas.)
> 
> 
> Et pour la MTU, Ludovic, moi je veux bien…. Mais de quel côté ? Et puis le 
> PMTU il est sensé être négocié proprement, je n’ai jamais eu à le faire sur 
> aucun tunnel VPN.
> 
> 
> Ce qui me choque, c’est que le seul fait de passer par Orange Mobile casse le 
> fonctionnement d’un VPN alors qu’aucune des deux extrémités n’a changé sa 
> configuration.
> 
> 
> 
>> Le 2 mai 2024 à 12:56, David Ponzone  a écrit :
>> 
>> Désactive IPv6 sur le client pour voir.
>> 
>> David
>> 
>>> Le 2 mai 2024 à 12:48, Philippe ASTIER via frnog  a écrit :
>>> 
>>> Salut à tous !
>>> 
>>> Je rencontre un souci très pénible.
>>> 
>>> J’ai depuis plus de dix ans plusieurs clients avec des sites distants et 
>>> des Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, 
>>> Free, FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre 
>>> les sites distants sans aucun souci, fiables, ça monte très vite en IKEv2.
>>> La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
>>> clients Forti selon les cas, mais pas eu beaucoup de soucis.
>>> 
>>> Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
>>> monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le 
>>> device ou en partage de connexion).
>>> Avec la même configuration, la connexion en wifi/ethernet depuis n’importe 
>>> quel autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro 
>>> mobiles, aucun problème, le tunnel est établie en 150 ms à peine.
>>> 
>>> Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
>>> normalement, puis j’ai quasi dans la foulée un message du type «  recv 
>>> ISAKMP SA delete » dans les logs de debug du Forti, et le tunnel ne monte 
>>> pas.
>>> 
>>> 
>>> Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
>>> tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
>>> pourrait me donner des pistes…
>>> Any idea ?
>>> 
>>> 
>>> (PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
>>> train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait 
>>> juste marcher comme chez les autres opérateurs, ça me soulagerait des 
>>> plaintes récurrentes et justifiées du client)
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
> 


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

OK, why not, on va faire ça sur le Mac, pas possible sur iOS.

(Chez Free, pas besoin de désactiver IPv6 en tout cas.)


Et pour la MTU, Ludovic, moi je veux bien…. Mais de quel côté ? Et puis le PMTU 
il est sensé être négocié proprement, je n’ai jamais eu à le faire sur aucun 
tunnel VPN.


Ce qui me choque, c’est que le seul fait de passer par Orange Mobile casse le 
fonctionnement d’un VPN alors qu’aucune des deux extrémités n’a changé sa 
configuration.



> Le 2 mai 2024 à 12:56, David Ponzone  a écrit :
> 
> Désactive IPv6 sur le client pour voir.
> 
> David
> 
>> Le 2 mai 2024 à 12:48, Philippe ASTIER via frnog  a écrit :
>> 
>> Salut à tous !
>> 
>> Je rencontre un souci très pénible.
>> 
>> J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
>> Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
>> FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les 
>> sites distants sans aucun souci, fiables, ça monte très vite en IKEv2.
>> La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
>> clients Forti selon les cas, mais pas eu beaucoup de soucis.
>> 
>> Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
>> monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le 
>> device ou en partage de connexion).
>> Avec la même configuration, la connexion en wifi/ethernet depuis n’importe 
>> quel autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro 
>> mobiles, aucun problème, le tunnel est établie en 150 ms à peine.
>> 
>> Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
>> normalement, puis j’ai quasi dans la foulée un message du type «  recv 
>> ISAKMP SA delete » dans les logs de debug du Forti, et le tunnel ne monte 
>> pas.
>> 
>> 
>> Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
>> tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
>> pourrait me donner des pistes…
>> Any idea ?
>> 
>> 
>> (PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
>> train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait 
>> juste marcher comme chez les autres opérateurs, ça me soulagerait des 
>> plaintes récurrentes et justifiées du client)
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


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

Re: [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[David Ponzone]

Désactive IPv6 sur le client pour voir.

David

> Le 2 mai 2024 à 12:48, Philippe ASTIER via frnog  a écrit :
> 
> Salut à tous !
> 
> Je rencontre un souci très pénible.
> 
> J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
> Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
> FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les sites 
> distants sans aucun souci, fiables, ça monte très vite en IKEv2.
> La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
> clients Forti selon les cas, mais pas eu beaucoup de soucis.
> 
> Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
> monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le 
> device ou en partage de connexion).
> Avec la même configuration, la connexion en wifi/ethernet depuis n’importe 
> quel autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro 
> mobiles, aucun problème, le tunnel est établie en 150 ms à peine.
> 
> Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
> normalement, puis j’ai quasi dans la foulée un message du type «  recv ISAKMP 
> SA delete » dans les logs de debug du Forti, et le tunnel ne monte pas.
> 
> 
> Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
> tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
> pourrait me donner des pistes…
> Any idea ?
> 
> 
> (PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
> train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait 
> juste marcher comme chez les autres opérateurs, ça me soulagerait des 
> plaintes récurrentes et justifiées du client)
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] RE: Problèmes IPSec sur Orange Mobile

[Ludovic de Bélair]

Bonjour Philippe,

Constaté le même phénomène la semaine dernière entre un partage de connexion 4G 
Orange Pro et un firewall utilisé sur une FFTH Free pour monter un VPN L2TP... 
Suis pas allé plus loin car je n'étais pas le revendeur de la carte SIM - je 
sais c'est pas beau mais pas le temps ! J'ai montré au client que cela 
fonctionnait sur d'autres FAI 4G ou fixe et lui ai suggéré de prendre attache 
avec ses fournisseurs... Je n'avais même pas de trace de connexion IKE sur le 
firewall comme si c'était filtré en amont.

Ludovic

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Philippe 
ASTIER via frnog
Envoyé : jeudi 2 mai 2024 12:49
À : frnog-tech 
Objet : [FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

Salut à tous !

Je rencontre un souci très pénible.

J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les sites 
distants sans aucun souci, fiables, ça monte très vite en IKEv2.
La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
clients Forti selon les cas, mais pas eu beaucoup de soucis.

Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le device 
ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet depuis n’importe quel 
autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro mobiles, 
aucun problème, le tunnel est établie en 150 ms à peine.

Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
normalement, puis j’ai quasi dans la foulée un message du type «  recv ISAKMP 
SA delete » dans les logs de debug du Forti, et le tunnel ne monte pas.


Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
pourrait me donner des pistes… Any idea ?


(PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait juste 
marcher comme chez les autres opérateurs, ça me soulagerait des plaintes 
récurrentes et justifiées du client)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

[FRnOG] [TECH] Problèmes IPSec sur Orange Mobile

[Philippe ASTIER via frnog]

Salut à tous !

Je rencontre un souci très pénible.

J’ai depuis plus de dix ans plusieurs clients avec des sites distants et des 
Fortigate. Lignes fibres pour la plupart aujourd'hui, chez Orange Pro, Free, 
FreePro, SFR, Colt, Unyc, peu importe. J’ai des tunnels IPSec entre les sites 
distants sans aucun souci, fiables, ça monte très vite en IKEv2.
La plupart ont aussi un accès via leurs mobiles ou ordinateurs. SSL, IPSec, 
clients Forti selon les cas, mais pas eu beaucoup de soucis.

Depuis quelques mois (dur à retracer), chez un seul client, impossible de 
monter un tunnel IPSec via iOS ou macOS quand ils sont en 4G/5G (sur le device 
ou en partage de connexion).
Avec la même configuration, la connexion en wifi/ethernet depuis n’importe quel 
autre opérateur fonctionne sans souci. J’ai essayé via Free et FreePro mobiles, 
aucun problème, le tunnel est établie en 150 ms à peine.

Sur Orange Pro Mobile, la négociation des phases 1 et 2 semble se passer 
normalement, puis j’ai quasi dans la foulée un message du type «  recv ISAKMP 
SA delete » dans les logs de debug du Forti, et le tunnel ne monte pas.


Comme je viens de manger du log de debug depuis des jours en m’arrachant la 
tête, je me suis dit que soumettre ça à la brillante sagacité de la liste 
pourrait me donner des pistes…
Any idea ?


(PS: oui, dans ce cas précis, on envisage le VPN SSL, voire même on est en 
train de mettre une solution ZTNA basée sur Wireguard, mais si ça pouvait juste 
marcher comme chez les autres opérateurs, ça me soulagerait des plaintes 
récurrentes et justifiées du client)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] FTTH Access Orange et ONT

[Steeve BEAUVAIS - Société Serinya Telecom]

Merci à tous pour vos retours !

Je ne comprends pas la remarque du spof sur l'ONT. Le FTTH seule est un
spof, avec son OLT, son ONT, son CPE etc...

*Le seul avantage, c’est de maitriser sa livraison, parce que Orange et son
petit process «  tiens je t’envoie l’ONT par la Poste », pour une
entreprise et dans l’état actuel de la qualité de service des transporteurs
en 2024, ça fait du déchet.*
Je suis d'accord, mais pour l'instant quand je les fais livrer chez moi je
ne vois pas trop de problème de livraison.

L'autre point en défaveur est la gestion des mises à jour qui ajoute une
charge et on est pas à l'abri que du jour au lendemain Orange change ses
OLT et donc la liste de compatibilité des ONT...

La meilleure solution reste d'arriver à faire acheter une FTTO au client :)

Cordialement,
Steeve


Le jeu. 25 avr. 2024 à 13:13, Richard Klein  a
écrit :

> Bonjour
>
> Le fameux STT ... Il y a eu des périodes où il était systématiquement
> opposé dans les tickets.
> Cela a changé ?
>
> Richard
>
> Le jeu. 25 avr. 2024, 12:54, David Ponzone  a
> écrit :
>
> > Oui, personnellement, je m’amuse pas à mettre mon propre ONT.
> > Déjà, ça revient plus cher.
> > Ca évite aussi de la config et un échange avec Orange pour leur
> > communiquer le SLID.
> > Ca évite les réponses d’Orange en support du type « ah c’est STT, c’est
> la
> > faute de votre ONT ».
> > Le seul avantage, c’est de maitriser sa livraison, parce que Orange et
> son
> > petit process «  tiens je t’envoie l’ONT par la Poste », pour une
> > entreprise et dans l’état actuel de la qualité de service des
> transporteurs
> > en 2024, ça fait du déchet.
> >
> > David
> >
> >
> > > Le 25 avr. 2024 à 12:48, Ducassou Laurent  a écrit :
> > >
> > > Salut,
> > >
> > > Ça me rappel l'époque des ADSL 512k avec modems et modem-routeur en
> > collecte ATM et des listes fermés ! Et si on avait malheur de sortir des
> > listes officielles de compatibilité, ça dépendait totalement du DSLAM qui
> > était en face.
> > >
> > > Il n’empêche, c'est vrai que l'ONT ou box permet d'être un point pour
> > justement savoir où est la responsabilité de chaqu'un, mais ça ajoute un
> > SPOF au final qui consomme même de l’énergie et dans tous les cas, on est
> > responsable des "choc électrique" que celui-ci prends.
> > >
> > > Que de souvenir dirons certains ! =)
> > >
> > > Laurent
> > >
> > > Le 25/04/2024 à 12:33, David Ponzone a écrit :
> > >> Ah t’inquiète pas, Orange fournit la liste des ONT compatible, tu as
> le
> > choix entre 2 modèles :)
> > >>
> > >>
> > >>> Le 25 avr. 2024 à 12:03, Pavel Polyakov  a
> > écrit :
> > >>>
> > >>> Steeve BEAUVAIS - Société Serinya Telecom
> > >>> :
> > >>>
> >  Je me lance dans une étude pour déterminer si je ne suis pas mieux
> de
> >  prendre moi-même l'ONT, aussi bien en termes de déploiement que
> >  d'exploitation.
> > >>> Ça peut être difficile car l'ONT est souvent spécifique au
> fournisseur
> > >>> de l'OLT. Je les remplace par des modules SFP mais il faut parfois
> > >>> passer un certain temps avant d'arriver à les rendre compatibles.
> > >>>
> > >>>
> > >>> ---
> > >>> Liste de diffusion du FRnOG
> > >>> http://www.frnog.org/
> > >>
> > >> ---
> > >> Liste de diffusion du FRnOG
> > >> http://www.frnog.org/
> > >
> > > --
> > > Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
> > > www.avast.com
> > >
> > >
> > > ---
> > > 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/
>

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

RE: [FRnOG] [TECH] USB charge électrique Android

[RIVIERE Yoann]

Bonjour, 

C'est un problème connu dans m'impression 3D (les CM envoie du jus sur le port 
USB destiné à être relié au raspberry pi faisant tourner Klipper ou octoprint.

 Pour cela, 3 solutions : 
- soit un bout de scotch sur le V+ USB 
(https://qph.cf2.quoracdn.net/main-qimg-ed54ddfea95c4375962a409fbe3bcfb8-lq ).
- Soit couper le V+ sur le câble comme cité ci-dessous
- soit acheter un PortaPow bloqueur d'alim 
(https://www.amazon.fr/PortaPow-Bloc-dalimentation-USB-bo%C3%AEtier/dp/B094FYL9QT)

Pour ma part, j'ai fabriqué mon module avec 2 connecteurs USB et un PCB de 
prototypage qui trainaient dans un de mes tiroir 3 pattes sur 4 à relier.

Cordialement

Yoann Rivière


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
David Ponzone
Envoyé : jeudi 25 avril 2024 15:33
À : Noryungi 
Cc : Stephane Miguel ; frnog-tech 
Objet : Re: [FRnOG] [TECH] USB charge électrique Android

ATTENTION: Cet e-mail provient d'une personne externe à votre organisation. Ne 
cliquez pas sur les liens ou n'ouvrez pas les pièces jointes si vous ne 
connaissez pas l'expéditeur et que vous n'êtes pas certain que le contenu est 
sûr.
'

https://antiphishing.vadesecure.com/v4?f=V0xKeTZlcEZ5bEtadnZZY9gsgbn2MqbhacZ0nW6xiZtXfwBYPvCM8_1XL7mhAzbB=YXUyZ0VCTnNidXhadndMVa_B8l3aNzphDqXqFGoGpis=C5UG=UFF0ZW53anlrcnYyNFZ1OY1cJMSFajXS0Zr-Bhm7iSGZKhsub4aWp6qfPe4pRCAs=607cc07571f6abab79044aee9a145798cd0456252cbf5799a0b9adedad35b5ad=https%3A%2F%2Fnewscrewdriver.com%2F2022%2F02%2F01%2Fmaking-a-usb-data-only-cable%2F
 
<https://antiphishing.vadesecure.com/v4?f=V0xKeTZlcEZ5bEtadnZZY9gsgbn2MqbhacZ0nW6xiZtXfwBYPvCM8_1XL7mhAzbB=YXUyZ0VCTnNidXhadndMVa_B8l3aNzphDqXqFGoGpis=C5UG=UFF0ZW53anlrcnYyNFZ1OY1cJMSFajXS0Zr-Bhm7iSGZKhsub4aWp6qfPe4pRCAs=607cc07571f6abab79044aee9a145798cd0456252cbf5799a0b9adedad35b5ad=https%3A%2F%2Fnewscrewdriver.com%2F2022%2F02%2F01%2Fmaking-a-usb-data-only-cable%2F>

J’ai pas l’impression que ça existe en tout-fait-prêt-à-brancher.
Le marché pour ça serait une niche en plus, et une mini.

David

> Le 25 avr. 2024 à 15:18, Noryungi  a écrit :
>
> Pour proposer uniquement une charge électrique, dans connexion 
> données, c'est simple, ça existe, par exemple :
>
> https://antiphishing.vadesecure.com/v4?f=V0xKeTZlcEZ5bEtadnZZY9gsgbn2M
> qbhacZ0nW6xiZtXfwBYPvCM8_1XL7mhAzbB=YXUyZ0VCTnNidXhadndMVa_B8l3aNzph
> DqXqFGoGpis=C5UG=UFF0ZW53anlrcnYyNFZ1OY1cJMSFajXS0Zr-Bhm7iSGZKhsub
> 4aWp6qfPe4pRCAs=64e65607cce83ba2d6f32bef281e9019cd146c4de071f97de3d8
> 23b931284cf4=https%3A%2F%2Fwww.amazon.com%2FPlugable-Universal-Charg
> e-Only-Adapter-Android%2Fdp%2FB00FA9GXKM
>
> Pour le data only, sans charge électrique, je soupçonne que ça existe, 
> mais sans avoir de preuve...
>
> On Thu, Apr 25, 2024, 11:30 Stephane Miguel  wrote:
>
>> Bonjour
>>
>> Je cherche à utiliser un câble ou une fonctionnalité propre à Windows 
>> afin d’utiliser le mode transfert ou échange de donnée sans que le 
>> périphérique charge
>>
>> Topologie
>>
>> PC WINDOWS dans un domaine
>> Câble usb
>> Mobile Android
>> L’idée est d’autoriser l’échange de donnée mais pas d’autoriser la 
>> charge électrique
>>
>> Ceci pour une OU ou se loge des PC spécifique à un projet
>>
>> J’ai beau chercher je ne trouve pas hormis le usb on the go dont on 
>> m’a parlé mais je ne sais pas si c’est fonctionnel d’une part et 
>> d’autre part je préférerai un mode sur le système est ce possible
>>
>>
>> Sur un autre sujet j’aimerai bloquer le mode modem sur une autre OU 
>> et offrir que la charge électrique ceci afin qu’une seconde carte 
>> réseau ne monte pas et parasite la table de routage du pc dans le 
>> domaine
>>
>> Merci bien
>>
>> Stéphane
>>
>> ---
>> Liste de diffusion du FRnOG
>> https://antiphishing.vadesecure.com/v4?f=V0xKeTZlcEZ5bEtadnZZY9gsgbn2
>> MqbhacZ0nW6xiZtXfwBYPvCM8_1XL7mhAzbB=YXUyZ0VCTnNidXhadndMVa_B8l3aNz
>> phDqXqFGoGpis=C5UG=UFF0ZW53anlrcnYyNFZ1OY1cJMSFajXS0Zr-Bhm7iSGZKh
>> sub4aWp6qfPe4pRCAs=b3cb83f7123a56d2d58b4ffd14fdd17b80a2eaf65987a9db
>> be7117842e441bc3=http%3A%2F%2Fwww.frnog.org%2F
>>
>
> ---
> Liste de diffusion du FRnOG
> https://antiphishing.vadesecure.com/v4?f=V0xKeTZlcEZ5bEtadnZZY9gsgbn2M
> qbhacZ0nW6xiZtXfwBYPvCM8_1XL7mhAzbB=YXUyZ0VCTnNidXhadndMVa_B8l3aNzph
> DqXqFGoGpis=C5UG=UFF0ZW53anlrcnYyNFZ1OY1cJMSFajXS0Zr-Bhm7iSGZKhsub
> 4aWp6qfPe4pRCAs=b3cb83f7123a56d2d58b4ffd14fdd17b80a2eaf65987a9dbbe71
> 17842e441bc3=http%3A%2F%2Fwww.frnog.org%2F


---
Liste de diffusion du FRnOG
https://antiphishing.vadesecure.com/v4?f=V0xKeTZlcEZ5bEtadnZZY9gsgbn2MqbhacZ0nW6xiZtXfwBYPvCM8_1XL7mhAzbB=YXUyZ0VCTnNidXhadndMVa_B8l3aNzphDqXqFGoGpis=C5UG=UFF0ZW53anlrcnYyNFZ1OY1cJMSFajXS0Zr-Bhm7iSGZKhsub4aWp6qfPe4pRCAs=b3cb83f7123a56d2d58b4ffd14fdd17b80a2eaf65987a9dbbe7117842e441bc3=http%3A%2F%2Fwww.frnog.org%2F

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

Re: [FRnOG] [TECH] USB charge électrique Android

[David Ponzone]

https://newscrewdriver.com/2022/02/01/making-a-usb-data-only-cable/ 


J’ai pas l’impression que ça existe en tout-fait-prêt-à-brancher.
Le marché pour ça serait une niche en plus, et une mini.

David

> Le 25 avr. 2024 à 15:18, Noryungi  a écrit :
> 
> Pour proposer uniquement une charge électrique, dans connexion données,
> c'est simple, ça existe, par exemple :
> 
> https://www.amazon.com/Plugable-Universal-Charge-Only-Adapter-Android/dp/B00FA9GXKM
> 
> Pour le data only, sans charge électrique, je soupçonne que ça existe, mais
> sans avoir de preuve...
> 
> On Thu, Apr 25, 2024, 11:30 Stephane Miguel  wrote:
> 
>> Bonjour
>> 
>> Je cherche à utiliser un câble ou une fonctionnalité propre à Windows afin
>> d’utiliser le mode transfert ou échange de donnée sans que le périphérique
>> charge
>> 
>> Topologie
>> 
>> PC WINDOWS dans un domaine
>> Câble usb
>> Mobile Android
>> L’idée est d’autoriser l’échange de donnée mais pas d’autoriser la charge
>> électrique
>> 
>> Ceci pour une OU ou se loge des PC spécifique à un projet
>> 
>> J’ai beau chercher je ne trouve pas hormis le usb on the go dont on m’a
>> parlé mais je ne sais pas si c’est fonctionnel d’une part et d’autre part
>> je préférerai un mode sur le système est ce possible
>> 
>> 
>> Sur un autre sujet j’aimerai bloquer le mode modem sur une autre OU et
>> offrir que la charge électrique ceci afin qu’une seconde carte réseau ne
>> monte pas et parasite la table de routage du pc dans le domaine
>> 
>> Merci bien
>> 
>> Stéphane
>> 
>> ---
>> 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] [TECH] USB charge électrique Android

[Noryungi]

Pour proposer uniquement une charge électrique, dans connexion données,
c'est simple, ça existe, par exemple :

https://www.amazon.com/Plugable-Universal-Charge-Only-Adapter-Android/dp/B00FA9GXKM

Pour le data only, sans charge électrique, je soupçonne que ça existe, mais
sans avoir de preuve...

On Thu, Apr 25, 2024, 11:30 Stephane Miguel  wrote:

> Bonjour
>
> Je cherche à utiliser un câble ou une fonctionnalité propre à Windows afin
> d’utiliser le mode transfert ou échange de donnée sans que le périphérique
> charge
>
> Topologie
>
> PC WINDOWS dans un domaine
> Câble usb
> Mobile Android
> L’idée est d’autoriser l’échange de donnée mais pas d’autoriser la charge
> électrique
>
> Ceci pour une OU ou se loge des PC spécifique à un projet
>
> J’ai beau chercher je ne trouve pas hormis le usb on the go dont on m’a
> parlé mais je ne sais pas si c’est fonctionnel d’une part et d’autre part
> je préférerai un mode sur le système est ce possible
>
>
> Sur un autre sujet j’aimerai bloquer le mode modem sur une autre OU et
> offrir que la charge électrique ceci afin qu’une seconde carte réseau ne
> monte pas et parasite la table de routage du pc dans le domaine
>
> Merci bien
>
> Stéphane
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] FTTH Access Orange et ONT

[Richard Klein]

Bonjour

Le fameux STT ... Il y a eu des périodes où il était systématiquement
opposé dans les tickets.
Cela a changé ?

Richard

Le jeu. 25 avr. 2024, 12:54, David Ponzone  a
écrit :

> Oui, personnellement, je m’amuse pas à mettre mon propre ONT.
> Déjà, ça revient plus cher.
> Ca évite aussi de la config et un échange avec Orange pour leur
> communiquer le SLID.
> Ca évite les réponses d’Orange en support du type « ah c’est STT, c’est la
> faute de votre ONT ».
> Le seul avantage, c’est de maitriser sa livraison, parce que Orange et son
> petit process «  tiens je t’envoie l’ONT par la Poste », pour une
> entreprise et dans l’état actuel de la qualité de service des transporteurs
> en 2024, ça fait du déchet.
>
> David
>
>
> > Le 25 avr. 2024 à 12:48, Ducassou Laurent  a écrit :
> >
> > Salut,
> >
> > Ça me rappel l'époque des ADSL 512k avec modems et modem-routeur en
> collecte ATM et des listes fermés ! Et si on avait malheur de sortir des
> listes officielles de compatibilité, ça dépendait totalement du DSLAM qui
> était en face.
> >
> > Il n’empêche, c'est vrai que l'ONT ou box permet d'être un point pour
> justement savoir où est la responsabilité de chaqu'un, mais ça ajoute un
> SPOF au final qui consomme même de l’énergie et dans tous les cas, on est
> responsable des "choc électrique" que celui-ci prends.
> >
> > Que de souvenir dirons certains ! =)
> >
> > Laurent
> >
> > Le 25/04/2024 à 12:33, David Ponzone a écrit :
> >> Ah t’inquiète pas, Orange fournit la liste des ONT compatible, tu as le
> choix entre 2 modèles :)
> >>
> >>
> >>> Le 25 avr. 2024 à 12:03, Pavel Polyakov  a
> écrit :
> >>>
> >>> Steeve BEAUVAIS - Société Serinya Telecom
> >>> :
> >>>
>  Je me lance dans une étude pour déterminer si je ne suis pas mieux de
>  prendre moi-même l'ONT, aussi bien en termes de déploiement que
>  d'exploitation.
> >>> Ça peut être difficile car l'ONT est souvent spécifique au fournisseur
> >>> de l'OLT. Je les remplace par des modules SFP mais il faut parfois
> >>> passer un certain temps avant d'arriver à les rendre compatibles.
> >>>
> >>>
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/
> >>
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> >
> > --
> > Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
> > www.avast.com
> >
> >
> > ---
> > 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] [TECH] FTTH Access Orange et ONT

[David Ponzone]

Oui, personnellement, je m’amuse pas à mettre mon propre ONT.
Déjà, ça revient plus cher.
Ca évite aussi de la config et un échange avec Orange pour leur communiquer le 
SLID.
Ca évite les réponses d’Orange en support du type « ah c’est STT, c’est la 
faute de votre ONT ».
Le seul avantage, c’est de maitriser sa livraison, parce que Orange et son 
petit process «  tiens je t’envoie l’ONT par la Poste », pour une entreprise et 
dans l’état actuel de la qualité de service des transporteurs en 2024, ça fait 
du déchet.

David


> Le 25 avr. 2024 à 12:48, Ducassou Laurent  a écrit :
> 
> Salut,
> 
> Ça me rappel l'époque des ADSL 512k avec modems et modem-routeur en collecte 
> ATM et des listes fermés ! Et si on avait malheur de sortir des listes 
> officielles de compatibilité, ça dépendait totalement du DSLAM qui était en 
> face.
> 
> Il n’empêche, c'est vrai que l'ONT ou box permet d'être un point pour 
> justement savoir où est la responsabilité de chaqu'un, mais ça ajoute un SPOF 
> au final qui consomme même de l’énergie et dans tous les cas, on est 
> responsable des "choc électrique" que celui-ci prends.
> 
> Que de souvenir dirons certains ! =)
> 
> Laurent
> 
> Le 25/04/2024 à 12:33, David Ponzone a écrit :
>> Ah t’inquiète pas, Orange fournit la liste des ONT compatible, tu as le 
>> choix entre 2 modèles :)
>> 
>> 
>>> Le 25 avr. 2024 à 12:03, Pavel Polyakov  a écrit :
>>> 
>>> Steeve BEAUVAIS - Société Serinya Telecom
>>> :
>>> 
 Je me lance dans une étude pour déterminer si je ne suis pas mieux de
 prendre moi-même l'ONT, aussi bien en termes de déploiement que
 d'exploitation.
>>> Ça peut être difficile car l'ONT est souvent spécifique au fournisseur
>>> de l'OLT. Je les remplace par des modules SFP mais il faut parfois
>>> passer un certain temps avant d'arriver à les rendre compatibles.
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> -- 
> Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
> www.avast.com
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] FTTH Access Orange et ONT

[Ducassou Laurent]

Salut,

Ça me rappel l'époque des ADSL 512k avec modems et modem-routeur en 
collecte ATM et des listes fermés ! Et si on avait malheur de sortir des 
listes officielles de compatibilité, ça dépendait totalement du DSLAM 
qui était en face.


Il n’empêche, c'est vrai que l'ONT ou box permet d'être un point pour 
justement savoir où est la responsabilité de chaqu'un, mais ça ajoute un 
SPOF au final qui consomme même de l’énergie et dans tous les cas, on 
est responsable des "choc électrique" que celui-ci prends.


Que de souvenir dirons certains ! =)

Laurent

Le 25/04/2024 à 12:33, David Ponzone a écrit :

Ah t’inquiète pas, Orange fournit la liste des ONT compatible, tu as le choix 
entre 2 modèles :)



Le 25 avr. 2024 à 12:03, Pavel Polyakov  a écrit :

Steeve BEAUVAIS - Société Serinya Telecom
:


Je me lance dans une étude pour déterminer si je ne suis pas mieux de
prendre moi-même l'ONT, aussi bien en termes de déploiement que
d'exploitation.

Ça peut être difficile car l'ONT est souvent spécifique au fournisseur
de l'OLT. Je les remplace par des modules SFP mais il faut parfois
passer un certain temps avant d'arriver à les rendre compatibles.


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


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


--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com


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

Re: [FRnOG] [TECH] FTTH Access Orange et ONT

[David Ponzone]

Ah t’inquiète pas, Orange fournit la liste des ONT compatible, tu as le choix 
entre 2 modèles :)


> Le 25 avr. 2024 à 12:03, Pavel Polyakov  a écrit :
> 
> Steeve BEAUVAIS - Société Serinya Telecom
> :
> 
>> Je me lance dans une étude pour déterminer si je ne suis pas mieux de
>> prendre moi-même l'ONT, aussi bien en termes de déploiement que
>> d'exploitation.
> 
> Ça peut être difficile car l'ONT est souvent spécifique au fournisseur
> de l'OLT. Je les remplace par des modules SFP mais il faut parfois
> passer un certain temps avant d'arriver à les rendre compatibles.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] USB charge électrique Android

[Stephane Miguel]

Bonjour

Je cherche à utiliser un câble ou une fonctionnalité propre à Windows afin
d’utiliser le mode transfert ou échange de donnée sans que le périphérique
charge

Topologie

PC WINDOWS dans un domaine
Câble usb
Mobile Android
L’idée est d’autoriser l’échange de donnée mais pas d’autoriser la charge
électrique

Ceci pour une OU ou se loge des PC spécifique à un projet

J’ai beau chercher je ne trouve pas hormis le usb on the go dont on m’a
parlé mais je ne sais pas si c’est fonctionnel d’une part et d’autre part
je préférerai un mode sur le système est ce possible


Sur un autre sujet j’aimerai bloquer le mode modem sur une autre OU et
offrir que la charge électrique ceci afin qu’une seconde carte réseau ne
monte pas et parasite la table de routage du pc dans le domaine

Merci bien

Stéphane

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

[FRnOG] [TECH] FTTH Access Orange et ONT

[Steeve BEAUVAIS - Société Serinya Telecom]

Bonjour à tous,

Question purement telco aujourd'hui.
Depuis la sortie de l'offre FTTH Access OWF, j'ai pris l'habitude de
commander avec leur propre ONT pour bien scinder les périmètres de
responsabilité.

Sauf que je m'aperçois que dans un peu moins d'un quart des déploiements,
l'ONT est mal configuré (j'ai pas encore creusé ce qui est mal configuré,
ça va venir). Le reste des échecs vous vous en doutez c'est du tech absent
ou pas fiable.

Je me lance dans une étude pour déterminer si je ne suis pas mieux de
prendre moi-même l'ONT, aussi bien en termes de déploiement que
d'exploitation.

Vos témoignages et vos avis m'intéressent !

Et pour ça j'ai déjà quelques questions dans ma besace :

   - Avez-vous fait le même choix que moi ? (il paraît que mon choix est
   une exception chez Orange)
  - Si oui, est-ce pour une raison particulière ?
  - Et faites-vous le même constat que moi ?
   - Parvenez-vous à superviser et à manager cet ONT ? Si oui comment ?
   - Avez-vous déjà eu à faire des mises à jour du firmware ?
  - J'arrive pas à comprendre si c'est Orange qui déploie les MaJ où si
  c'est à nous de le faire
   - Avez-vous beaucoup de pannes ?

Merci à tous par avance,
Steeve

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

Re: [FRnOG] [TECH] choix techno coeur de réseau

[Nicolas Parpandet via frnog]

Hello,

Ma réponse est biaisée certainement, Cisco un jour, cisco toujours 


  *
tous les admins réseau connaissent
  *
Documentation, support, performances, stabilité, fonctionnalités, la liste 
est longue
  *
gamme catalyst éprouvée et increvable 

J'ai commencé il y a 20 ans en achetant des kits sur ebay : qui étaient 
littéralement tombés du camion lors de la livraison, switchs écrasés, façade 
explosée etc : le matériel fonctionnait qd même aucun souci, ca m'a marqué à 
l'époque lol...

A+

Nicolas


From: frnog-requ...@frnog.org  on behalf of jstraw via 
frnog 
Sent: Wednesday, April 24, 2024 15:19
To: frnog-t...@frnog.org 
Subject: [FRnOG] [TECH] choix techno coeur de réseau

Bonjour la communauté,


Je fais appel à vous pour nous aider / conforter à faire un choix technologique 
sur du coeur de réseau faisans exclusivement du L2, le routage étant assuré par 
firewall.



Nous avons deux salles info avec de la virtualisation qui a ses propres 
switches.



Chaque salle info aura un switch fibre monté en cluster via ISL fibre et la 
techno du constructeur avec son jumeau.

Le cluster de FW est monté croisé avec agréga LACP 2x10Gb

Le sw pour la virtu est monté croisé avec agréga LACP 2x10Gb



Jusque la rien de fou.



Nous avons 3 constructeurs en shortlist.

Cisco Catalyst 9500

Aruba 8360

Juniper EX4650



Sans considérations financière quels sont vos favoris appuyé par votre 
argumentaire.


Nous connaissons bien Aruba et Cisco, nous sommes curieux de la couche IA de 
Juniper. Nous nous posons des questions sur l'avenir de JUNIPER avec le rachat 
par HPE.

Notre décision est prise a 80% ca nous permettra de nous conforter dans notre 
choix.





Merci







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

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

[FRnOG] [TECH] choix techno coeur de réseau

[jstraw via frnog]

Bonjour la communauté,


Je fais appel à vous pour nous aider / conforter à faire un choix technologique 
sur du coeur de réseau faisans exclusivement du L2, le routage étant assuré par 
firewall.



Nous avons deux salles info avec de la virtualisation qui a ses propres 
switches.



Chaque salle info aura un switch fibre monté en cluster via ISL fibre et la 
techno du constructeur avec son jumeau.

Le cluster de FW est monté croisé avec agréga LACP 2x10Gb

Le sw pour la virtu est monté croisé avec agréga LACP 2x10Gb



Jusque la rien de fou. 



Nous avons 3 constructeurs en shortlist. 

Cisco Catalyst 9500 

Aruba 8360

Juniper EX4650



Sans considérations financière quels sont vos favoris appuyé par votre 
argumentaire.


Nous connaissons bien Aruba et Cisco, nous sommes curieux de la couche IA de 
Juniper. Nous nous posons des questions sur l'avenir de JUNIPER avec le rachat 
par HPE.

Notre décision est prise a 80% ca nous permettra de nous conforter dans notre 
choix.





Merci







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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Fabien Sirjean]

Bonjour,

Merci beaucoup pour vos réponses et avis.

Ça nous a conforté dans l'idée de ne pas faire de spanning-tree à 
l'échelle de l'infra, car nous n'en avons pas besoin (et pas envie).


Voilà ce que ça donne au final chez nous :

 * Pas de spanning-tree sur notre infra, du tout, sur les couches core
   et aggregation (no spanning-tree). Tous les liens sont redondés en
   LACP (vPC/MLAG).
 * Du spanning-tree le plus simple possible sur les couches access,
   chaque stack étant la racine de son propre arbre local, qui ne sort
   pas de la stack (à priori du rapid-pvst par simplicité sur nos 2960x)
 * Sur les switchs d'access, il faut donc systématiquement faire du
   bpdufilter sur les ports upstream (pour ne pas propager l'arbre
   spanning-tree vers l'infra)
 * Sur les ports edge, on fait du portfast (pour éviter les latences à
   l'allumage du port) et du bpduguard pour shut un port edge qui
   reçoit des BPDU (un switch, à priori)
 * En complément sur les ports edge, on fait du storm-control pour
   couper s'il y a trop de broadcast/multicast ; et du port-security
   pour limiter le nombre de MAC autorisées sur un port (variable selon
   le type de VLAN)
 * Et on bosse sur l’implémentation de 802.1x et Private Vlan, mais
   c'est un autre sujet.

Bonne journée à toutes et tous,

Fabien


On 4/22/24 17:49, Fabien Sirjean wrote:

Bonjour la liste !

Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
collègues, alors je viens ici chercher des avis éclairés.


On exploite une infra campus, de type 3 tiers (core/aggreg/access), en 
pur layer 2 (des VLAN propagés entre l'edge et le core) en 
multi-constructeurs (HP procurve, Extreme, Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse 
vingtaine de bâtiments, sur un seul site. Le core est à cheval sur 
deux bâtiments, tout comme la couche d'aggreg des différents switchs 
d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon 
la couleur de l'équipement), on a aucune boucle sur l'infra.


On est en train de reprendre la config de nos switchs (refonte totale 
du parc, on déploie du 2060X refurbished) et on se pose une question 
bête : spanning-tree or not spanning tree ?


Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les 
équipements). On veut bien sur faire de la détection de boucle (voire 
du bpdu guard) sur les ports edge ; mais quid des liens infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et 
notre manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, 
PVST, MSTP...) techno du diable, on a pas très envie de faire un seul 
arbre spanning-tree à l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps de 
convergence infinis, et on a pas très envie de recommencer. Mais c'est 
ce que nous préconise un presta, alors on doute de nos choix.


Un avis sur la question ? Vous faites comment chez vous ?

Bien sur la meilleure réponse est de tout passer en L3 et de faire du 
routage, mais... C'est pas au programme pour l'instant ;-)


Merci d'avance de vos retours !

Bonne soirée,

Fabien


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

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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Denis Fondras via frnog]

Le Mon, Apr 22, 2024 at 07:16:42PM +, NELLI Olivier a écrit :
> Bonsoir à tous,
> Le spanning-tree marche bien pour de très petites infras. Le mstp est 
> compliqué (le rstp est mieux, plus simple) mais la convergence, bien 
> qu'améliorée, reste mauvaise (plusieurs secondes voir 1/2 minute). A mon 
> avis, dans votre cas le stp et dérivés seraient à proscrire.
> Il y a une techno peu utilisée en campus mais qui est super pour ces 
> environnements de niv 2. C'est le rps/erps/rrpp. Ça gère des boucles, 
> imbriquées ou non, ça converge hyper bien (<100ms), c'est assez simple en 
> mettre en œuvre et ça s'adapterai assez bien à votre profil (300sw/20 
> bâtiments).

Autant je trouve ERPS efficace sur des petites infras, autant je suis dubitatif
sur un anneau avec un grand nombre de switches.


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Phil Regnauld]

David Ponzone (david.ponzone) writes:
> 
> 
> Suffit d’un téléphone IP et d’un bouffon qui trouve dommage que son port PC 
> soit pas dans une prise murale.

C'est pas ça qu'on appelle la boucle locale ? :D

P.


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[David Ponzone]

> Le 23 avr. 2024 à 03:38, Guillaume Lorre  a écrit :
> 
> 
> Autre interrogation : il y a encore des hubs, des mini-switch ou autre
> horreurs dans le genre chez toi ? A prendre en compte pour du loop-protect.
> 

Suffit d’un téléphone IP et d’un bouffon qui trouve dommage que son port PC 
soit pas dans une prise murale.

David


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Guillaume Lorre]

Salut,

MSTP semble effectivement le mieux indiqué.
C'est pas trop compliqué à comprendre (ca reste une sorte de mélange entre
RSTP et RPVST) qui est assez souple, malléable et adaptatif par rapport aux
autres protocoles Spanning-tree (par exemple : les régions dans ton cas
pour avoir plusieurs arbres).
Attention quand même à l'interopérabilité sur les phases de migration. J'ai
déjà eu de mauvaises surprises, sur du Catalyst notamment, lorsque des BPDU
de différents protocoles se déplacent sur le réseau.

Et puis tout dépends de l'étendu de tes VLAN sur tes bâtiments. Tout les
VLANs sont déployés et utilisés sur plusieurs bâtiments ou non ? Si c'est
pas le cas, la topologie en VLAN locaux et routage à l'agrégation est
peut-être pas si loin.

Ou sinon pas de STP et du stormcontrol blindés partout et un très bon
monitoring mais je suis moins fan.

Autre interrogation : il y a encore des hubs, des mini-switch ou autre
horreurs dans le genre chez toi ? A prendre en compte pour du loop-protect.

A+

Guillaume.

Le lun. 22 avr. 2024, 20:40, Pierre LANCASTRE 
a écrit :

> Hello
>
> +1 pour le mstp. Car plus flexible sur certaines archi. Par exemple sur des
> étages "coeur" ou on veut avoir des vlan point a point entre les "switch
> routeurs" pour faire du routage dynamique, pour passer des vlan de synchro
> firewalls via deux paths différents, etc.
> Avec MSTP tu peux faire plusieurs arbres, avec rstp un seul, et le
> pvst/vstp c est le plus flexible (1 vlan 1 arbre) mais c est pas scalable,
> et source potentielle de bonnes blagues, au moins sur iOS Cisco. Exemple un
> peu vieux : tu configures le N+1 ème VLAN avec N le nombre max d instances
> stp. Et hop, le Cisco te fait un no spanning tree vlan xxx avec xxx le vlan
> id de plus haut de souvenir (pas sur).
>
> J avais eu jadis des incompatibilités MSTP entre des Cisco et des Extreme,
> mais ça date de 2007, j pense que ça c est amélioré depuis :)
>
> Bref, une page pour aider à comparer les +/- des protos
>
> https://www.juniper.net/documentation/us/en/software/junos/stp-l2/topics/topic-map/spanning-tree-configuring-mstp.html
>
> A+
>
> Pierre L.
>
> Le lun. 22 avr. 2024, 5 h 04 p.m., Nicolas Parpandet via frnog <
> frnog@frnog.org> a écrit :
>
> > Hello,
> >
> > Comme tu as un environnement hétérogène, le spanning tree le plus
> > compatible "inter-marques" est très certainement le MSTP 
> >
> > A+
> >
> > Nicolas
> >
> >
> > ________
> > From: frnog-requ...@frnog.org  on behalf of
> > Fabien Sirjean 
> > Sent: Monday, April 22, 2024 17:49
> > To: frnog-t...@frnog.org 
> > Subject: [FRnOG] [TECH] Spanning-tree sur infra campus
> >
> > Bonjour la liste !
> >
> > Ça fait maintenant quelques semaines qu'on se gratte la tête avec les
> > collègues, alors je viens ici chercher des avis éclairés.
> >
> > On exploite une infra campus, de type 3 tiers (core/aggreg/access), en
> > pur layer 2 (des VLAN propagés entre l'edge et le core) en
> > multi-constructeurs (HP procurve, Extreme, Cisco 2960X...).
> > Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine
> > de bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments,
> > tout comme la couche d'aggreg des différents switchs d'access.
> > Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la
> > couleur de l'équipement), on a aucune boucle sur l'infra.
> >
> > On est en train de reprendre la config de nos switchs (refonte totale du
> > parc, on déploie du 2060X refurbished) et on se pose une question bête :
> > spanning-tree or not spanning tree ?
> >
> > Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les
> > équipements). On veut bien sur faire de la détection de boucle (voire du
> > bpdu guard) sur les ports edge ; mais quid des liens infra ?
> > Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et
> > notre manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST,
> > MSTP...) techno du diable, on a pas très envie de faire un seul arbre
> > spanning-tree à l'échelle de notre infra.
> > On a vécu des changements de topologie incessants, avec des temps de
> > convergence infinis, et on a pas très envie de recommencer. Mais c'est
> > ce que nous préconise un presta, alors on doute de nos choix.
> >
> > Un avis sur la question ? Vous faites comment chez vous ?
> >
> > Bien sur la meilleure réponse est de tout passer en L3 et de faire du
> > routage, mais... C'est pas au programme pour l'instant ;-)
> >
> > Merci d'avance de vos retours !
> >
> > Bonne soirée,
> >
> > Fabien
> >
> >
> > ---
> > 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/
>

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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Pierre LANCASTRE]

Hello

+1 pour le mstp. Car plus flexible sur certaines archi. Par exemple sur des
étages "coeur" ou on veut avoir des vlan point a point entre les "switch
routeurs" pour faire du routage dynamique, pour passer des vlan de synchro
firewalls via deux paths différents, etc.
Avec MSTP tu peux faire plusieurs arbres, avec rstp un seul, et le
pvst/vstp c est le plus flexible (1 vlan 1 arbre) mais c est pas scalable,
et source potentielle de bonnes blagues, au moins sur iOS Cisco. Exemple un
peu vieux : tu configures le N+1 ème VLAN avec N le nombre max d instances
stp. Et hop, le Cisco te fait un no spanning tree vlan xxx avec xxx le vlan
id de plus haut de souvenir (pas sur).

J avais eu jadis des incompatibilités MSTP entre des Cisco et des Extreme,
mais ça date de 2007, j pense que ça c est amélioré depuis :)

Bref, une page pour aider à comparer les +/- des protos
https://www.juniper.net/documentation/us/en/software/junos/stp-l2/topics/topic-map/spanning-tree-configuring-mstp.html

A+

Pierre L.

Le lun. 22 avr. 2024, 5 h 04 p.m., Nicolas Parpandet via frnog <
frnog@frnog.org> a écrit :

> Hello,
>
> Comme tu as un environnement hétérogène, le spanning tree le plus
> compatible "inter-marques" est très certainement le MSTP 
>
> A+
>
> Nicolas
>
>
> 
> From: frnog-requ...@frnog.org  on behalf of
> Fabien Sirjean 
> Sent: Monday, April 22, 2024 17:49
> To: frnog-t...@frnog.org 
> Subject: [FRnOG] [TECH] Spanning-tree sur infra campus
>
> Bonjour la liste !
>
> Ça fait maintenant quelques semaines qu'on se gratte la tête avec les
> collègues, alors je viens ici chercher des avis éclairés.
>
> On exploite une infra campus, de type 3 tiers (core/aggreg/access), en
> pur layer 2 (des VLAN propagés entre l'edge et le core) en
> multi-constructeurs (HP procurve, Extreme, Cisco 2960X...).
> Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine
> de bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments,
> tout comme la couche d'aggreg des différents switchs d'access.
> Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la
> couleur de l'équipement), on a aucune boucle sur l'infra.
>
> On est en train de reprendre la config de nos switchs (refonte totale du
> parc, on déploie du 2060X refurbished) et on se pose une question bête :
> spanning-tree or not spanning tree ?
>
> Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les
> équipements). On veut bien sur faire de la détection de boucle (voire du
> bpdu guard) sur les ports edge ; mais quid des liens infra ?
> Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et
> notre manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST,
> MSTP...) techno du diable, on a pas très envie de faire un seul arbre
> spanning-tree à l'échelle de notre infra.
> On a vécu des changements de topologie incessants, avec des temps de
> convergence infinis, et on a pas très envie de recommencer. Mais c'est
> ce que nous préconise un presta, alors on doute de nos choix.
>
> Un avis sur la question ? Vous faites comment chez vous ?
>
> Bien sur la meilleure réponse est de tout passer en L3 et de faire du
> routage, mais... C'est pas au programme pour l'instant ;-)
>
> Merci d'avance de vos retours !
>
> Bonne soirée,
>
> Fabien
>
>
> ---
> 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] [TECH] Spanning-tree sur infra campus

[Nicolas Parpandet via frnog]

Hello,

Comme tu as un environnement hétérogène, le spanning tree le plus compatible 
"inter-marques" est très certainement le MSTP 

A+

Nicolas



From: frnog-requ...@frnog.org  on behalf of Fabien 
Sirjean 
Sent: Monday, April 22, 2024 17:49
To: frnog-t...@frnog.org 
Subject: [FRnOG] [TECH] Spanning-tree sur infra campus

Bonjour la liste !

Ça fait maintenant quelques semaines qu'on se gratte la tête avec les
collègues, alors je viens ici chercher des avis éclairés.

On exploite une infra campus, de type 3 tiers (core/aggreg/access), en
pur layer 2 (des VLAN propagés entre l'edge et le core) en
multi-constructeurs (HP procurve, Extreme, Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine
de bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments,
tout comme la couche d'aggreg des différents switchs d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la
couleur de l'équipement), on a aucune boucle sur l'infra.

On est en train de reprendre la config de nos switchs (refonte totale du
parc, on déploie du 2060X refurbished) et on se pose une question bête :
spanning-tree or not spanning tree ?

Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les
équipements). On veut bien sur faire de la détection de boucle (voire du
bpdu guard) sur les ports edge ; mais quid des liens infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et
notre manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST,
MSTP...) techno du diable, on a pas très envie de faire un seul arbre
spanning-tree à l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps de
convergence infinis, et on a pas très envie de recommencer. Mais c'est
ce que nous préconise un presta, alors on doute de nos choix.

Un avis sur la question ? Vous faites comment chez vous ?

Bien sur la meilleure réponse est de tout passer en L3 et de faire du
routage, mais... C'est pas au programme pour l'instant ;-)

Merci d'avance de vos retours !

Bonne soirée,

Fabien


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

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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[NELLI Olivier]

Bonsoir à tous,
Le spanning-tree marche bien pour de très petites infras. Le mstp est compliqué 
(le rstp est mieux, plus simple) mais la convergence, bien qu'améliorée, reste 
mauvaise (plusieurs secondes voir 1/2 minute). A mon avis, dans votre cas le 
stp et dérivés seraient à proscrire.
Il y a une techno peu utilisée en campus mais qui est super pour ces 
environnements de niv 2. C'est le rps/erps/rrpp. Ça gère des boucles, 
imbriquées ou non, ça converge hyper bien (<100ms), c'est assez simple en 
mettre en œuvre et ça s'adapterai assez bien à votre profil (300sw/20 
bâtiments).
Cdt,

Olivier

Le 22/04/2024 17:51, « frnog-requ...@frnog.org 
 au nom de Fabien Sirjean » 
mailto:frnog-requ...@frnog.org> au nom de 
fsirj...@eddie.fdn.fr > a écrit :


Ce mail provient de l'extérieur, restons vigilants


Bonjour la liste !


Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
collègues, alors je viens ici chercher des avis éclairés.


On exploite une infra campus, de type 3 tiers (core/aggreg/access), en 
pur layer 2 (des VLAN propagés entre l'edge et le core) en 
multi-constructeurs (HP procurve, Extreme, Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine 
de bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments, 
tout comme la couche d'aggreg des différents switchs d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la 
couleur de l'équipement), on a aucune boucle sur l'infra.


On est en train de reprendre la config de nos switchs (refonte totale du 
parc, on déploie du 2060X refurbished) et on se pose une question bête : 
spanning-tree or not spanning tree ?


Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les 
équipements). On veut bien sur faire de la détection de boucle (voire du 
bpdu guard) sur les ports edge ; mais quid des liens infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et 
notre manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST, 
MSTP...) techno du diable, on a pas très envie de faire un seul arbre 
spanning-tree à l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps de 
convergence infinis, et on a pas très envie de recommencer. Mais c'est 
ce que nous préconise un presta, alors on doute de nos choix.


Un avis sur la question ? Vous faites comment chez vous ?


Bien sur la meilleure réponse est de tout passer en L3 et de faire du 
routage, mais... C'est pas au programme pour l'instant ;-)


Merci d'avance de vos retours !


Bonne soirée,


Fabien




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




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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Clément Guivy]

On 22/04/2024 20:18, Paul Rolland (ポール・ロラン) wrote:

Et si tu nous expliquais pourquoi tu ne veux pas de Spanning-tree ? A la
base, il a ete fait pour gerer ces problemes de boucles. Tu ne veux pas des
problemes de boucles, mais tu ne veux pas non plus de la solution
naturelle. C'est un peu complexe du coup ;)


Tout à fait d'accord là-dessus. Il faut préciser le besoin avant de 
chercher (à écarter) une solution. Pour l'instant sauf si j'ai raté 
quelque chose, on pourrait très bien être face à un problème XY.


J'ai déjà fait du campus (~50 switches) avec STP (RSTP en l'occurence), 
ça fonctionne comme prévu quand c'est configuré correctement (et ce 
n'est pas très compliqué à configurer). Et ce n'est pas incompatible 
avec le LACP ou même le stacking (pour ceux qui pratiquent cette 
religion :o ).


Penser à récupérer les messages syslog de détection de boucle pour 
avertir le help desk ou les admins quand quelqu'un fait une boulette, si 
c'est pertinent.


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Paul Rolland (ポール・ロラン)]

Bonsoir,

On Mon, 22 Apr 2024 18:08:33 +0200
Fabien Sirjean  wrote:

> > Tu as une boucle dans ton L2 ou pas ?  
> Non, et c'est pas prévu puisqu'on redonde tout en LACP.
>
> > Et si non, y a des bouffons qui pourraient en faire une ?  
> 
> Sur les liens autres que edge (c'est-à-dire sur l'infra) les bouffons
> éventuels c'est nous, et on sait châtier les collègues au besoin. --> Non

Bon, mes deux sous:
 - "c'est pas prevu", c'est une mauvaise reponse. Si tu le prevois pas, le
   jour ou ca va arriver, tu seras bien triste.

 - "on sait châtier les collègues au besoin", ok, sauf que ca sera trop
   tard.

Je te conseille donc, si tu es sur ce genre d'approche, de t'assurer que
ton OOB pour manager tous tes equipements, et deboucler en remote en cas de
boulette, est bien fonctionnel et totalement independant. 

> Par contre sur les ports edge (ceux où sont connectés les users, ceux
> qui font peur et qui branchent/débranchent leurs équipements en
> permanence) c'est un risque sérieux.

En plus des suggestions deja faites, tu peux aussi regarder :
 - max mac-address, pour limiter le nombre de MAC, et bloquer si ca depasse
   1 par exemple,
 - 802.1x ???
 
> Si je suis ta logique, on souhaite donc uniquement détecter une boucle
> sur les ports edge. Comment on fait ça proprement, sans se lancer dans
> du spanning-tree sur l'infra ?

Et si tu nous expliquais pourquoi tu ne veux pas de Spanning-tree ? A la
base, il a ete fait pour gerer ces problemes de boucles. Tu ne veux pas des
problemes de boucles, mais tu ne veux pas non plus de la solution
naturelle. C'est un peu complexe du coup ;)
 
Paul


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Phil Regnauld]

Fabien Sirjean (fsirjean) writes:
> Bonjour la liste !
> 
> Ça fait maintenant quelques semaines qu'on se gratte la tête avec les
> collègues, alors je viens ici chercher des avis éclairés.
> 
> On exploite une infra campus, de type 3 tiers (core/aggreg/access), en pur
> layer 2 (des VLAN propagés entre l'edge et le core) en multi-constructeurs
> (HP procurve, Extreme, Cisco 2960X...).


Ne pas faire du 3 tiers en pur L2 ? Je sais, c'est pas au programme :)


> On est en train de reprendre la config de nos switchs (refonte totale du
> parc, on déploie du 2060X refurbished) et on se pose une question bête :
> spanning-tree or not spanning tree ?

MSTP si possible.

> techno du diable, on a pas très envie de faire un seul arbre spanning-tree à
> l'échelle de notre infra.

Bonne idée.

> On a vécu des changements de topologie incessants, avec des temps de
> convergence infinis, et on a pas très envie de recommencer. Mais c'est ce
> que nous préconise un presta, alors on doute de nos choix.

Si on contrôle bien les liens infra et on est quasi sûr que personne
ne va faire des boucles à ce niveau, on peut décider de fermer les ports
manuellement. Ou voir si il y a des options vPC / MLAG pour utiliser des
liens redondants de manière efficace (moins certain quand on fait du
multi-vendeur bien évidemment).

> Bien sur la meilleure réponse est de tout passer en L3 et de faire du
> routage, mais... C'est pas au programme pour l'instant ;-)

Mais y réfléchir fortement - et ça ne nécessite pas forcément
une transition complète du réseau en une seule étape.

P.


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Emmanuel ANDRÉ via frnog]

Salut,

Perso, je le configurerai partout, même sans boucle dans le design à 
date mais pour le futur, tu es boufon-proof ready.


Le storm control, fait avec des ASR920, ça marche mais c'est le backbone 
qui tient pas les end device qui au delà de 100 Mbps de bcast sont dans 
le vent déjà.



Le 22/04/2024 à 19:29, Fabien Sirjean a écrit :

Hello,

On 4/22/24 18:51, Aurélien TABARAUD wrote:

Salut,

Fonction storm control avec en action le shutdown du port au delà 
d’un certain seuil de paquets de broadcast.


Merci pour le retour :-)

On met déjà du storm-control, mais la question du seuil n'est pas 
évidente. Même 1% sur un port 10G, ça fait quand même 100 Mbps...


D'ailleurs, vous les mettez à combien vos seuils de storm-control ?

On voulait donc mettre du bpduguard en complément, d'où la question 
sur spanning-tree.


Bonne soirée !

Fabien





Ensuite ton technicien gère les tickets de support « ehhh mon réseau 
marche plus » ouverts au fur et à mesure par les utilisateurs.


Syntaxe Cisco : storm-control
Synthaxe HP : storm-constrain
Etc

Cordialement,

Aurélien


Par exemple, j'ai l'impression que si je fais un "no spanning-tree" 
sur un 2960X, les commandes "spanning-tree bpduguard enable" sur un 
port sont sans effet.


Bonne soirée,

Fabien


David


Le 22 avr. 2024 à 17:49, Fabien Sirjean   
a écrit :

Bonjour la liste !

Ça fait maintenant quelques semaines qu'on se gratte la tête avec 
les collègues, alors je viens ici chercher des avis éclairés.


On exploite une infra campus, de type 3 tiers 
(core/aggreg/access), en pur layer 2 (des VLAN propagés entre 
l'edge et le core) en multi-constructeurs (HP procurve, Extreme, 
Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse 
vingtaine de bâtiments, sur un seul site. Le core est à cheval sur 
deux bâtiments, tout comme la couche d'aggreg des différents 
switchs d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever 
selon la couleur de l'équipement), on a aucune boucle sur l'infra.


On est en train de reprendre la config de nos switchs (refonte 
totale du parc, on déploie du 2060X refurbished) et on se pose une 
question bête : spanning-tree or not spanning tree ?


Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les 
équipements). On veut bien sur faire de la détection de boucle 
(voire du bpdu guard) sur les ports edge ; mais quid des liens 
infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, 
et notre manque de maîtrise de cette (ou plutôt ces entre STP, 
RSTP, PVST, MSTP...) techno du diable, on a pas très envie de 
faire un seul arbre spanning-tree à l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps 
de convergence infinis, et on a pas très envie de recommencer. 
Mais c'est ce que nous préconise un presta, alors on doute de nos 
choix.


Un avis sur la question ? Vous faites comment chez vous ?

Bien sur la meilleure réponse est de tout passer en L3 et de faire 
du routage, mais... C'est pas au programme pour l'instant ;-)


Merci d'avance de vos retours !

Bonne soirée,

Fabien


---
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/

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


--
Bien cordialement,
Emmanuel André


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Erwan David]

Le 22/04/2024 à 19:29, Fabien Sirjean a écrit :

Hello,

On 4/22/24 18:51, Aurélien TABARAUD wrote:

Salut,

Fonction storm control avec en action le shutdown du port au delà 
d’un certain seuil de paquets de broadcast.


Merci pour le retour :-)

On met déjà du storm-control, mais la question du seuil n'est pas 
évidente. Même 1% sur un port 10G, ça fait quand même 100 Mbps...


D'ailleurs, vous les mettez à combien vos seuils de storm-control ?

On voulait donc mettre du bpduguard en complément, d'où la question 
sur spanning-tree.


Bonne soirée !

Fabien 



Attention avec le BPDUGuard, j'ai déjà vu un virtualbox émettre des 
BPDU, le dev qui avait besoin de se simuler un petit réseau était un peu 
emmerdé.



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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Fabien Sirjean]

Hello,

On 4/22/24 18:51, Aurélien TABARAUD wrote:

Salut,

Fonction storm control avec en action le shutdown du port au delà d’un certain 
seuil de paquets de broadcast.


Merci pour le retour :-)

On met déjà du storm-control, mais la question du seuil n'est pas 
évidente. Même 1% sur un port 10G, ça fait quand même 100 Mbps...


D'ailleurs, vous les mettez à combien vos seuils de storm-control ?

On voulait donc mettre du bpduguard en complément, d'où la question sur 
spanning-tree.


Bonne soirée !

Fabien





Ensuite ton technicien gère les tickets de support « ehhh mon réseau marche 
plus » ouverts au fur et à mesure par les utilisateurs.

Syntaxe Cisco : storm-control
Synthaxe HP : storm-constrain
Etc

Cordialement,

Aurélien



Par exemple, j'ai l'impression que si je fais un "no spanning-tree" sur un 2960X, les 
commandes "spanning-tree bpduguard enable" sur un port sont sans effet.

Bonne soirée,

Fabien


David



Le 22 avr. 2024 à 17:49, Fabien Sirjean   a écrit :

Bonjour la liste !

Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
collègues, alors je viens ici chercher des avis éclairés.

On exploite une infra campus, de type 3 tiers (core/aggreg/access), en pur 
layer 2 (des VLAN propagés entre l'edge et le core) en multi-constructeurs (HP 
procurve, Extreme, Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine de 
bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments, tout 
comme la couche d'aggreg des différents switchs d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la 
couleur de l'équipement), on a aucune boucle sur l'infra.

On est en train de reprendre la config de nos switchs (refonte totale du parc, 
on déploie du 2060X refurbished) et on se pose une question bête : 
spanning-tree or not spanning tree ?

Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les équipements). 
On veut bien sur faire de la détection de boucle (voire du bpdu guard) sur les ports edge 
; mais quid des liens infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et notre 
manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST, MSTP...) 
techno du diable, on a pas très envie de faire un seul arbre spanning-tree à 
l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps de 
convergence infinis, et on a pas très envie de recommencer. Mais c'est ce que 
nous préconise un presta, alors on doute de nos choix.

Un avis sur la question ? Vous faites comment chez vous ?

Bien sur la meilleure réponse est de tout passer en L3 et de faire du routage, 
mais... C'est pas au programme pour l'instant ;-)

Merci d'avance de vos retours !

Bonne soirée,

Fabien


---
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/

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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Emmanuel Halbwachs]

Bonsoir,

Fabien Sirjean (Mon 2024-04-22 18:08:33 +0200) :
> Par contre sur les ports edge (ceux où sont connectés les users, ceux qui
> font peur et qui branchent/débranchent leurs équipements en permanence)
> c'est un risque sérieux.
> 
> Si je suis ta logique, on souhaite donc uniquement détecter une boucle sur
> les ports edge. Comment on fait ça proprement, sans se lancer dans du
> spanning-tree sur l'infra ?

Chez Procurve, il y a loop-protect.

Chez nous, nous voulions nous prémunir du câble branché entre deux
prises murales (faut vraiment vouloir) mais surtout nous prémunir
d'une boucle faite sur un mini-switch non manageable connecté sur un
port (vu régulièrement).

Pour bloquer le port (action par défaut) pendant une
temporisation p. ex. de 5' (300 s), qui se répètera tant que le
problème n'aura pas disparu :

loop-protect  
loop-protect disable-timer 300


Ou alors une temporisation de zéro, c.-à-d. que le port restera
indéfiniment bloqué tant que l'admin ne l'aura pas débloqué
(pédagogie). ;-). La temporisation de 0 est la valeur par défaut :

loop-protect  
loop-protect disable-timer 0

La doc HP mentionne que cette technique est plus sûre que la
protection BPDU, car un équipement comme un mini-switch pourrait dans
certains cas dropper les paquets BPDU.

Bonne soirée,

-- 
Emmanuel Halbwachs, Observatoire de Paris, ✆ +33 1 45 07 75 54
DIO¹ / CASTORS² 嶺 / PANDA³ 
¹ Direction Informatique de l'Observatoire ; ² CAlcul, STOckage, Réseau, Système
³ Pool of Awesome Network Devices Administrators


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Aurélien TABARAUD via frnog]

> Le 22 avr. 2024 à 18:08, Fabien Sirjean  a écrit :
> 
> Hello,
> 
>> On 4/22/24 18:00, David Ponzone wrote:
>> Si tu reviens aux fondamentaux, c’est quoi la raison d’être de STP ?
> OK, j'aime bien l'approche ;-)
>> -avoir un réseau qui fonctionne avec une boucle
>> -avoir un réseau qui continue de fonctionner quand un bouffon vient former 
>> une boucle qui était pas prévue en branchant un câble n’importe où
>> 
>> Tu as une boucle dans ton L2 ou pas ?
> Non, et c'est pas prévu puisqu'on redonde tout en LACP.
>> Et si non, y a des bouffons qui pourraient en faire une ?
> 
> Sur les liens autres que edge (c'est-à-dire sur l'infra) les bouffons 
> éventuels c'est nous, et on sait châtier les collègues au besoin. --> Non
> 
> Par contre sur les ports edge (ceux où sont connectés les users, ceux qui 
> font peur et qui branchent/débranchent leurs équipements en permanence) c'est 
> un risque sérieux.
> 
> Si je suis ta logique, on souhaite donc uniquement détecter une boucle sur 
> les ports edge. Comment on fait ça proprement, sans se lancer dans du 
> spanning-tree sur l'infra ?

Salut,

Fonction storm control avec en action le shutdown du port au delà d’un certain 
seuil de paquets de broadcast.

Ensuite ton technicien gère les tickets de support « ehhh mon réseau marche 
plus » ouverts au fur et à mesure par les utilisateurs.

Syntaxe Cisco : storm-control
Synthaxe HP : storm-constrain
Etc

Cordialement,

Aurélien 


> Par exemple, j'ai l'impression que si je fais un "no spanning-tree" sur un 
> 2960X, les commandes "spanning-tree bpduguard enable" sur un port sont sans 
> effet.
> 
> Bonne soirée,
> 
> Fabien
> 
>> David
>> 
>> 
 Le 22 avr. 2024 à 17:49, Fabien Sirjean  a écrit :
>>> 
>>> Bonjour la liste !
>>> 
>>> Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
>>> collègues, alors je viens ici chercher des avis éclairés.
>>> 
>>> On exploite une infra campus, de type 3 tiers (core/aggreg/access), en pur 
>>> layer 2 (des VLAN propagés entre l'edge et le core) en multi-constructeurs 
>>> (HP procurve, Extreme, Cisco 2960X...).
>>> Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine de 
>>> bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments, tout 
>>> comme la couche d'aggreg des différents switchs d'access.
>>> Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la 
>>> couleur de l'équipement), on a aucune boucle sur l'infra.
>>> 
>>> On est en train de reprendre la config de nos switchs (refonte totale du 
>>> parc, on déploie du 2060X refurbished) et on se pose une question bête : 
>>> spanning-tree or not spanning tree ?
>>> 
>>> Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les 
>>> équipements). On veut bien sur faire de la détection de boucle (voire du 
>>> bpdu guard) sur les ports edge ; mais quid des liens infra ?
>>> Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et notre 
>>> manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST, MSTP...) 
>>> techno du diable, on a pas très envie de faire un seul arbre spanning-tree 
>>> à l'échelle de notre infra.
>>> On a vécu des changements de topologie incessants, avec des temps de 
>>> convergence infinis, et on a pas très envie de recommencer. Mais c'est ce 
>>> que nous préconise un presta, alors on doute de nos choix.
>>> 
>>> Un avis sur la question ? Vous faites comment chez vous ?
>>> 
>>> Bien sur la meilleure réponse est de tout passer en L3 et de faire du 
>>> routage, mais... C'est pas au programme pour l'instant ;-)
>>> 
>>> Merci d'avance de vos retours !
>>> 
>>> Bonne soirée,
>>> 
>>> Fabien
>>> 
>>> 
>>> ---
>>> 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/


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

Re: [FRnOG] [TECH] Spanning-tree sur infra campus

[Fabien Sirjean]

Hello,

On 4/22/24 18:00, David Ponzone wrote:

Si tu reviens aux fondamentaux, c’est quoi la raison d’être de STP ?

OK, j'aime bien l'approche ;-)

-avoir un réseau qui fonctionne avec une boucle
-avoir un réseau qui continue de fonctionner quand un bouffon vient former une 
boucle qui était pas prévue en branchant un câble n’importe où

Tu as une boucle dans ton L2 ou pas ?

Non, et c'est pas prévu puisqu'on redonde tout en LACP.

Et si non, y a des bouffons qui pourraient en faire une ?


Sur les liens autres que edge (c'est-à-dire sur l'infra) les bouffons 
éventuels c'est nous, et on sait châtier les collègues au besoin. --> Non


Par contre sur les ports edge (ceux où sont connectés les users, ceux 
qui font peur et qui branchent/débranchent leurs équipements en 
permanence) c'est un risque sérieux.


Si je suis ta logique, on souhaite donc uniquement détecter une boucle 
sur les ports edge. Comment on fait ça proprement, sans se lancer dans 
du spanning-tree sur l'infra ?


Par exemple, j'ai l'impression que si je fais un "no spanning-tree" sur 
un 2960X, les commandes "spanning-tree bpduguard enable" sur un port 
sont sans effet.


Bonne soirée,

Fabien


David



Le 22 avr. 2024 à 17:49, Fabien Sirjean  a écrit :

Bonjour la liste !

Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
collègues, alors je viens ici chercher des avis éclairés.

On exploite une infra campus, de type 3 tiers (core/aggreg/access), en pur 
layer 2 (des VLAN propagés entre l'edge et le core) en multi-constructeurs (HP 
procurve, Extreme, Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine de 
bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments, tout 
comme la couche d'aggreg des différents switchs d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la 
couleur de l'équipement), on a aucune boucle sur l'infra.

On est en train de reprendre la config de nos switchs (refonte totale du parc, 
on déploie du 2060X refurbished) et on se pose une question bête : 
spanning-tree or not spanning tree ?

Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les équipements). 
On veut bien sur faire de la détection de boucle (voire du bpdu guard) sur les ports edge 
; mais quid des liens infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et notre 
manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST, MSTP...) 
techno du diable, on a pas très envie de faire un seul arbre spanning-tree à 
l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps de 
convergence infinis, et on a pas très envie de recommencer. Mais c'est ce que 
nous préconise un presta, alors on doute de nos choix.

Un avis sur la question ? Vous faites comment chez vous ?

Bien sur la meilleure réponse est de tout passer en L3 et de faire du routage, 
mais... C'est pas au programme pour l'instant ;-)

Merci d'avance de vos retours !

Bonne soirée,

Fabien


---
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] [TECH] Spanning-tree sur infra campus

[David Ponzone]

Si tu reviens aux fondamentaux, c’est quoi la raison d’être de STP ?

-avoir un réseau qui fonctionne avec une boucle
-avoir un réseau qui continue de fonctionner quand un bouffon vient former une 
boucle qui était pas prévue en branchant un câble n’importe où

Tu as une boucle dans ton L2 ou pas ?
Et si non, y a des bouffons qui pourraient en faire une ?

David


> Le 22 avr. 2024 à 17:49, Fabien Sirjean  a écrit :
> 
> Bonjour la liste !
> 
> Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
> collègues, alors je viens ici chercher des avis éclairés.
> 
> On exploite une infra campus, de type 3 tiers (core/aggreg/access), en pur 
> layer 2 (des VLAN propagés entre l'edge et le core) en multi-constructeurs 
> (HP procurve, Extreme, Cisco 2960X...).
> Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine de 
> bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments, tout 
> comme la couche d'aggreg des différents switchs d'access.
> Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la 
> couleur de l'équipement), on a aucune boucle sur l'infra.
> 
> On est en train de reprendre la config de nos switchs (refonte totale du 
> parc, on déploie du 2060X refurbished) et on se pose une question bête : 
> spanning-tree or not spanning tree ?
> 
> Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les équipements). 
> On veut bien sur faire de la détection de boucle (voire du bpdu guard) sur 
> les ports edge ; mais quid des liens infra ?
> Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et notre 
> manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST, MSTP...) 
> techno du diable, on a pas très envie de faire un seul arbre spanning-tree à 
> l'échelle de notre infra.
> On a vécu des changements de topologie incessants, avec des temps de 
> convergence infinis, et on a pas très envie de recommencer. Mais c'est ce que 
> nous préconise un presta, alors on doute de nos choix.
> 
> Un avis sur la question ? Vous faites comment chez vous ?
> 
> Bien sur la meilleure réponse est de tout passer en L3 et de faire du 
> routage, mais... C'est pas au programme pour l'instant ;-)
> 
> Merci d'avance de vos retours !
> 
> Bonne soirée,
> 
> Fabien
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Spanning-tree sur infra campus

[Fabien Sirjean]

Bonjour la liste !

Ça fait maintenant quelques semaines qu'on se gratte la tête avec les 
collègues, alors je viens ici chercher des avis éclairés.


On exploite une infra campus, de type 3 tiers (core/aggreg/access), en 
pur layer 2 (des VLAN propagés entre l'edge et le core) en 
multi-constructeurs (HP procurve, Extreme, Cisco 2960X...).
Grosso-modo 300 (stacks de) switchs, répartis dans une grosse vingtaine 
de bâtiments, sur un seul site. Le core est à cheval sur deux bâtiments, 
tout comme la couche d'aggreg des différents switchs d'access.
Tous les liens sont redondés en LACP (technos VPC/MLAG/whatever selon la 
couleur de l'équipement), on a aucune boucle sur l'infra.


On est en train de reprendre la config de nos switchs (refonte totale du 
parc, on déploie du 2060X refurbished) et on se pose une question bête : 
spanning-tree or not spanning tree ?


Aujourd'hui il n'y en a pas du tout ("no spanning-tree" sur les 
équipements). On veut bien sur faire de la détection de boucle (voire du 
bpdu guard) sur les ports edge ; mais quid des liens infra ?
Entre le nombre d'équipements, l'hétérogénéité des constructeurs, et 
notre manque de maîtrise de cette (ou plutôt ces entre STP, RSTP, PVST, 
MSTP...) techno du diable, on a pas très envie de faire un seul arbre 
spanning-tree à l'échelle de notre infra.
On a vécu des changements de topologie incessants, avec des temps de 
convergence infinis, et on a pas très envie de recommencer. Mais c'est 
ce que nous préconise un presta, alors on doute de nos choix.


Un avis sur la question ? Vous faites comment chez vous ?

Bien sur la meilleure réponse est de tout passer en L3 et de faire du 
routage, mais... C'est pas au programme pour l'instant ;-)


Merci d'avance de vos retours !

Bonne soirée,

Fabien


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

[FRnOG] [TECH] programmation de contrôleurs réseau Intel i210

[Pierre Colombier via frnog]

Bonjour à tous,

J'ai des contrôleurs réseau i210 prévus pour de la fibre 1G. (ref exacte 
WGI210IS ou WGI210AS)


Problème, ils ne sont pas programmés et sont visiblement inutilisables 
sans ça.


#lspci

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Unprogrammed 
(rev 03)



Pour résoudre ce problème, il semblerait qu'un outil spécifique d'Intel, 
nommé eeupdate, soit requis. Cet outil permet d'injecter le firmware 
nécessaire, la configuration appropriée, et une adresse MAC.



Sauf que je viens de passer une bonne part de la journée sur le site de 
intel, et si j'ai bien trouvé des discussions de personnes confrontées à 
des difficultés similaires, ça semble tout de même être un parcours du 
combattant pour obtenir l'outil.


Du coup, je pars à la pêche et lance un petit appel ici.

Si quelqu'un a de l'expérience avec cette procédure, des contacts chez 
Intel, ou pourrait même partager les fichiers nécessaires, je vous 
serais extrêmement reconnaissant.



Merci d'avance pour toute aide ou direction que vous pourriez me fournir.



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

Re: [FRnOG] [TECH] Fibre G.655 pour backbone - FS.com

[Denis Fondras via frnog]

Le Thu, Apr 18, 2024 at 12:07:11PM +0200, Aurélien TABARAUD via frnog a écrit :
> Bonjour,
> 
> Je t’invite à lire dans les archives de la liste FRnOG la réponse de Matthieu 
> Husson du Dimanche 14 octobre 2018 à 13h58min59s sur le sujet [TECH] Types de 
> fibre optique.
> 
> Tu croiseras aujourd’hui de la G.655 que très rarement. Il reste aussi 
> quelques câbles mixtes chez SFR par ex (coucou LDCOM).
> 
> Le spécifique coûteras toujours plus cher, donc c’est plus rentable 
> aujourd’hui de s’adapter sur de la G.652D qui est quelque chose d’assez 
> standard de nos jours que de faire des déploiements exotiques.
> Nos chers constructeurs ont su trouver des solutions pour augmenter les 
> performances de transmission car le volume de G.652D déployé permet de 
> justifier des investissements de R pour industrialiser certaines techniques 
> liées au traitement du signal ou à la photonique
> 

Et de façon plus générale les articles FS.com sont à prendre avec de grosses
pincettes tant c'est sur-simplifié et/ou obsolète (on dirait du ChatGPT :D).

> Cordialement,
> 
> Aurélien 
> 
> > Le 17 avr. 2024 à 22:33, Ge DUPIN  a écrit :
> > 
> > Bonsoir
> > 
> > En faisant des recherches sur G.655, je suis tombé sur le site de fs.com 
> > dont l’article 
> > https://community.fs.com/fr/article/single-mode-fiber-comparison-g-652-vs-g-655.html
> > fait l’éloge de la fibre G.655 qui coche toutes les cases de 10G à 100G 
> > alors que G.652 coche seulement 10G.
> > 
> > S’il y a quelqu’un de FS sur cette liste, pourriez vous élaborer sur cette 
> > assertion ?
> > 
> > Je précise que ma question s'adresse essentiellement aux backbones
> > 
> > Merci d’avance
> > 
> > Ge
> > 
> > 
> > 
> > ---
> > 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] [TECH] Fibre G.655 pour backbone - FS.com

[Aurélien TABARAUD via frnog]

Bonjour,

Je t’invite à lire dans les archives de la liste FRnOG la réponse de Matthieu 
Husson du Dimanche 14 octobre 2018 à 13h58min59s sur le sujet [TECH] Types de 
fibre optique.

Tu croiseras aujourd’hui de la G.655 que très rarement. Il reste aussi quelques 
câbles mixtes chez SFR par ex (coucou LDCOM).

Le spécifique coûteras toujours plus cher, donc c’est plus rentable aujourd’hui 
de s’adapter sur de la G.652D qui est quelque chose d’assez standard de nos 
jours que de faire des déploiements exotiques.
Nos chers constructeurs ont su trouver des solutions pour augmenter les 
performances de transmission car le volume de G.652D déployé permet de 
justifier des investissements de R pour industrialiser certaines techniques 
liées au traitement du signal ou à la photonique

Cordialement,

Aurélien 

> Le 17 avr. 2024 à 22:33, Ge DUPIN  a écrit :
> 
> Bonsoir
> 
> En faisant des recherches sur G.655, je suis tombé sur le site de fs.com dont 
> l’article 
> https://community.fs.com/fr/article/single-mode-fiber-comparison-g-652-vs-g-655.html
> fait l’éloge de la fibre G.655 qui coche toutes les cases de 10G à 100G alors 
> que G.652 coche seulement 10G.
> 
> S’il y a quelqu’un de FS sur cette liste, pourriez vous élaborer sur cette 
> assertion ?
> 
> Je précise que ma question s'adresse essentiellement aux backbones
> 
> Merci d’avance
> 
> Ge
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Fibre G.655 pour backbone - FS.com

[Ge DUPIN]

Bonsoir

En faisant des recherches sur G.655, je suis tombé sur le site de fs.com dont 
l’article 
https://community.fs.com/fr/article/single-mode-fiber-comparison-g-652-vs-g-655.html
 fait l’éloge de la fibre G.655 qui coche toutes les cases de 10G à 100G alors 
que G.652 coche seulement 10G.

S’il y a quelqu’un de FS sur cette liste, pourriez vous élaborer sur cette 
assertion ?

Je précise que ma question s'adresse essentiellement aux backbones

Merci d’avance 

Ge



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

Re: [FRnOG] [TECH] DNS Load Balancer

[Brahim AGALMOUCHE]

 Hello,
Je crois Azure traffic manager peut être une bonne option également (très
facile à mettre en place et à tester, après faut voir le billing)...
Cordialement.


Le mar. 16 avr. 2024 à 12:28, Toussaint OTTAVI  a
écrit :

>
>
> Le 15/04/2024 à 19:10, Michel KOENIG via frnog a écrit :
> > Je n'avais pas précisé, mais la solution serait pour du flux TCP pour
> une application propriétaire et/ou des tunnels IPSEC
>
> Une solution simple est de mettre les deux IP en round-robin sur une
> seule entrée DNS A. Les deux IP seront donc utilisables simultanément,
> mais sans gestion de priorité. Ce n'est donc pas adapté à toutes les
> situations.
>
> S'il s'agit de tunnels IPSec, en ce qui me concerne, je monte deux
> tunnels, un sur chaque interface. Il n'y a plus de notion de lien normal
> / secours. Il y a deux liens, chacun avec des caractéristiques propres.
> La répartition des flux dans les deux tunnels se fait en interne sur le
> routeur / firewall, en fonction de ce que permet l'équipement. Par
> exemple : les flux de prod en priorité sur le lien 1, et tout le reste
> en priorité sur le lien 2.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] DNS Load Balancer

[Toussaint OTTAVI]

Le 15/04/2024 à 19:10, Michel KOENIG via frnog a écrit :

Je n'avais pas précisé, mais la solution serait pour du flux TCP pour une 
application propriétaire et/ou des tunnels IPSEC


Une solution simple est de mettre les deux IP en round-robin sur une 
seule entrée DNS A. Les deux IP seront donc utilisables simultanément, 
mais sans gestion de priorité. Ce n'est donc pas adapté à toutes les 
situations.


S'il s'agit de tunnels IPSec, en ce qui me concerne, je monte deux 
tunnels, un sur chaque interface. Il n'y a plus de notion de lien normal 
/ secours. Il y a deux liens, chacun avec des caractéristiques propres. 
La répartition des flux dans les deux tunnels se fait en interne sur le 
routeur / firewall, en fonction de ce que permet l'équipement. Par 
exemple : les flux de prod en priorité sur le lien 1, et tout le reste 
en priorité sur le lien 2.

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

Re: [FRnOG] [TECH] Microsoft peering se ferme

[Jean Barbezat]

+1 c’est déjà assez dur de déterminer la capacité d’un peer avec qui tu as
une session directe… alors si tu ne sais pas exactement où tu envoies ton
traffic, et que tout ton traffic engineering dépend de edns ou de ton
anycast. Tu finis avec des policy pour les RS, pour les p2p peers via des
IXs, et les seules choses dont tu es sur : les PNIs.
Il faudra bien résoudre le problème d’absence de traffic signaling sur les
IXPs surtout si certains acteurs les laissent volontairement saturer.

-Jean

On Mon, 15 Apr 2024 at 11:48 AM, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> wrote:

> On Thu, Apr 4, 2024, at 12:35, David Ponzone wrote:
> > Bonjour tous,
> >
> > Petit changement de politique de peering en cours chez Microsoft: ils
> > arrêtent les sessions avec les RS et ils deviennent plus sélectifs pour
> > les sessions de peering direct (ils l’étaient peu ou pas avant).
> >
> > Si quelqu’un a des infos sur les raisons de ce revirement soudain.
>
> Hello,
>
> Puisqu'il se trouve que j'ai pu avoir quelques informations en plus :
>  - Il s'agit de Google pas de Microsoft. Micorosoft n'ont jamais ete sur
> les route-servers des IXP "classiques", ils sont meme marques "Never via
> RS" dans PeeringDB. Ils (Micorosoft) commencent par contre a pousser de
> plus en plus MAPS (qui est RS-based), disponibe chez vos IXP favoris (au
> moins chez la plupart d'entre eux)
>  - Ce n'est pas limite a France-IX, c'est une tendance globale chez
> Google, qui a deja commence il y a plusieurs mois chez d'autres IXP. A
> priori ca serait un decision prise a assez haut niveau de leur cote. Du
> cote Euro-IX (association des IXP europeens) on essaye de voir ce qu'il est
> possible de faire pour renverser cette tendance en proposant des interfaces
> unifies (regles de filtrage IRR/ROA, communautes de TE plus uniformes -
> deja fait pour les "large communities", ...). On ne sait pas ce que ca va
> donner, mais en tente
>  - Google via les RS et Google via session directe ou PNI (voir meme via
> transit) ca n'a jamais ete le meme chose. Il y a toujours eu des routes
> plus specifiques via "autre chose que les RS", et leur gestion des
> interconnections semblait toujours preferer (via localpref, donc
> prioritaire sur l'AS-path) les interconnection "plus explicites" (sessions
> directes ou PNI).
>  - Ca fait deja un certain temps que l'approche preferee (par Google) soit
> leur propre "peering portal", avec les quelques soucis ayant existe au fil
> des annees desormais resolus (a priori).
>
> Donc oui, c'est une "nouvelle" un peu inquietante, mais pas
> fondamentallement catastrophique.
>
> Cote "pourquoi", on a entendu plusieurs choses comme:
>  - quand tu dois gerer des connections sur des centaines des IX, chacun
> avec ses propres regles (filtrage, signalling) ca commence a etre bien plus
> complique a gerer que des sessions BGP directes (et fortement automatises).
> On espere bien que ca concerne pas tans que ca les IX europeens, ou comme
> explique plus haut, nous essayons d'uniformiser un peu les choses.
>  - meilleure gestion du trafic, surtout avec la democratisation des
> "remote peerings" qui se fait parfois de facon pas tres raisonnable.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Re: Analyse Capture WireShark

[Nicolas Parpandet via frnog]

ethereal à disparu, mais wireshark le remplace très bien et en plus complet,

dans wireshark tu as déjà énormément de choses dans le menu Statistics :

  *
Conversations (durée, débits...)
  *
IO Graphs (tu peux changer le Y Axis)
  *
le flow graph

Après tu as du PRTG, Solarwinds ... mais bon on en revient toujours aux sources 


Ou en laissant trainer une sonde avec ntopng ... (lui par contre est tordu)

A+

Nicolas


From: Michel KOENIG 
Sent: Monday, April 15, 2024 22:21
To: Nicolas Parpandet ; frnog-t...@frnog.org 

Subject: RE: Analyse Capture WireShark


Merci Nicolas pour ton retour



Tu as un lien pour récupérer le soft ?



Michel



De : Nicolas Parpandet 
Envoyé : lundi 15 avril 2024 22:14
À : frnog-t...@frnog.org; Michel KOENIG 
Objet : Re: Analyse Capture WireShark





To:​frnog-t...@frnog.org;​Michel KOENIG 
mailto:michel.koe...@ncc-info.com>>​

Mon 2024-04-15 22:12

Hello Michel,



Wireshark provient justement du projet Ethereal de Gerald Combs, qui à ensuite 
été renommé en Wireshark suite à son embauche chez CACE Technologies (puis 
Riverbed...)

sinon j'utilisai déjà le projet sous son ancien nom, et il y a tout ce qu'il 
faut pour les graphiques (flux tcp sous forme de graphe, bande passante, perte 
de paquets, gigue...)

Pour la VOIP c'est sympa il y a tout ce qu'il faut.



A+



Nicolas





From: frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> 
mailto:frnog-requ...@frnog.org>> on behalf of Michel 
KOENIG via frnog mailto:frnog@frnog.org>>
Sent: Monday, April 15, 2024 21:32
To: frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Subject: [FRnOG] [TECH] Analyse Capture WireShark



Bonjour,
Wireshark est un super outil que je pense nous utilisons tous souvent dans 
notre métier
Par contre, c'est un peu Matrix à décoder
Il existait un outil plutôt sympa chez Cace Technologies (ensuite racheté par 
Riverbed) qui permettait une analyse graphique depuis les pcap
Super sympa par exemple pour faire des graph de charge
Chez Cace, c'était Cace Pilot et le nom commercial chez Riverbed était 
SteelCentral Packet Analyzer
Après de nombreuses recherches, je ne trouve plus ce produit
Quelqu'un connait son successeur ou un produit qui ferait le même boulot ?
Cordialement
Michel KOENIG

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

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

Re: [FRnOG] [TECH] RE: Analyse Capture WireShark

[Pierre LANCASTRE]

Hello,

Sinon sur windows, quand j'utilisais, j'aimais bien le soft de colasoft
capsa free https://www.colasoft.com/products/freeware.php
https://www.colasoft.com/capsa-free/

Pas mal de features intéressantes,

++

Pierre

Le lun. 15 avr. 2024 à 16:21, Michel KOENIG via frnog  a
écrit :

> Merci Nicolas pour ton retour
>
> Tu as un lien pour récupérer le soft ?
>
> Michel
>
> De : Nicolas Parpandet 
> Envoyé : lundi 15 avril 2024 22:14
> À : frnog-t...@frnog.org; Michel KOENIG 
> Objet : Re: Analyse Capture WireShark
>
>
> To:​frnog-t...@frnog.org;​Michel KOENIG  <mailto:michel.koe...@ncc-info.com>>​
> Mon 2024-04-15 22:12
> Hello Michel,
>
> Wireshark provient justement du projet Ethereal de Gerald Combs, qui à
> ensuite été renommé en Wireshark suite à son embauche chez CACE
> Technologies (puis Riverbed...)
> sinon j'utilisai déjà le projet sous son ancien nom, et il y a tout ce
> qu'il faut pour les graphiques (flux tcp sous forme de graphe, bande
> passante, perte de paquets, gigue...)
> Pour la VOIP c'est sympa il y a tout ce qu'il faut.
>
> A+
>
> Nicolas
>
> 
> From: frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> <
> frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org>> on behalf of
> Michel KOENIG via frnog mailto:frnog@frnog.org>>
> Sent: Monday, April 15, 2024 21:32
> To: frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> <
> frnog-t...@frnog.org<mailto:frnog-t...@frnog.org>>
> Subject: [FRnOG] [TECH] Analyse Capture WireShark
>
> Bonjour,
> Wireshark est un super outil que je pense nous utilisons tous souvent dans
> notre métier
> Par contre, c'est un peu Matrix à décoder
> Il existait un outil plutôt sympa chez Cace Technologies (ensuite racheté
> par Riverbed) qui permettait une analyse graphique depuis les pcap
> Super sympa par exemple pour faire des graph de charge
> Chez Cace, c'était Cace Pilot et le nom commercial chez Riverbed était
> SteelCentral Packet Analyzer
> Après de nombreuses recherches, je ne trouve plus ce produit
> Quelqu'un connait son successeur ou un produit qui ferait le même boulot ?
> Cordialement
> Michel KOENIG
>
> ---
> 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/

[FRnOG] [TECH] RE: Analyse Capture WireShark

[Michel KOENIG via frnog]

Merci Nicolas pour ton retour

Tu as un lien pour récupérer le soft ?

Michel

De : Nicolas Parpandet 
Envoyé : lundi 15 avril 2024 22:14
À : frnog-t...@frnog.org; Michel KOENIG 
Objet : Re: Analyse Capture WireShark


To:​frnog-t...@frnog.org;​Michel KOENIG 
mailto:michel.koe...@ncc-info.com>>​
Mon 2024-04-15 22:12
Hello Michel,

Wireshark provient justement du projet Ethereal de Gerald Combs, qui à ensuite 
été renommé en Wireshark suite à son embauche chez CACE Technologies (puis 
Riverbed...)
sinon j'utilisai déjà le projet sous son ancien nom, et il y a tout ce qu'il 
faut pour les graphiques (flux tcp sous forme de graphe, bande passante, perte 
de paquets, gigue...)
Pour la VOIP c'est sympa il y a tout ce qu'il faut.

A+

Nicolas


From: frnog-requ...@frnog.org<mailto:frnog-requ...@frnog.org> 
mailto:frnog-requ...@frnog.org>> on behalf of Michel 
KOENIG via frnog mailto:frnog@frnog.org>>
Sent: Monday, April 15, 2024 21:32
To: frnog-t...@frnog.org<mailto:frnog-t...@frnog.org> 
mailto:frnog-t...@frnog.org>>
Subject: [FRnOG] [TECH] Analyse Capture WireShark

Bonjour,
Wireshark est un super outil que je pense nous utilisons tous souvent dans 
notre métier
Par contre, c'est un peu Matrix à décoder
Il existait un outil plutôt sympa chez Cace Technologies (ensuite racheté par 
Riverbed) qui permettait une analyse graphique depuis les pcap
Super sympa par exemple pour faire des graph de charge
Chez Cace, c'était Cace Pilot et le nom commercial chez Riverbed était 
SteelCentral Packet Analyzer
Après de nombreuses recherches, je ne trouve plus ce produit
Quelqu'un connait son successeur ou un produit qui ferait le même boulot ?
Cordialement
Michel KOENIG

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

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

[FRnOG] [TECH] Re: Analyse Capture WireShark

[Nicolas Parpandet via frnog]

To:​frnog-t...@frnog.org;​Michel KOENIG ​
Mon 2024-04-15 22:12
Hello Michel,

Wireshark provient justement du projet Ethereal de Gerald Combs, qui à ensuite 
été renommé en Wireshark suite à son embauche chez CACE Technologies (puis 
Riverbed...)
sinon j'utilisai déjà le projet sous son ancien nom, et il y a tout ce qu'il 
faut pour les graphiques (flux tcp sous forme de graphe, bande passante, perte 
de paquets, gigue...)
Pour la VOIP c'est sympa il y a tout ce qu'il faut.

A+

Nicolas


From: frnog-requ...@frnog.org  on behalf of Michel 
KOENIG via frnog 
Sent: Monday, April 15, 2024 21:32
To: frnog-t...@frnog.org 
Subject: [FRnOG] [TECH] Analyse Capture WireShark

Bonjour,
Wireshark est un super outil que je pense nous utilisons tous souvent dans 
notre métier
Par contre, c'est un peu Matrix à décoder
Il existait un outil plutôt sympa chez Cace Technologies (ensuite racheté par 
Riverbed) qui permettait une analyse graphique depuis les pcap
Super sympa par exemple pour faire des graph de charge
Chez Cace, c'était Cace Pilot et le nom commercial chez Riverbed était 
SteelCentral Packet Analyzer
Après de nombreuses recherches, je ne trouve plus ce produit
Quelqu'un connait son successeur ou un produit qui ferait le même boulot ?
Cordialement
Michel KOENIG

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

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

[FRnOG] [TECH] Analyse Capture WireShark

[Michel KOENIG via frnog]

Bonjour,
Wireshark est un super outil que je pense nous utilisons tous souvent dans 
notre métier
Par contre, c'est un peu Matrix à décoder
Il existait un outil plutôt sympa chez Cace Technologies (ensuite racheté par 
Riverbed) qui permettait une analyse graphique depuis les pcap
Super sympa par exemple pour faire des graph de charge
Chez Cace, c'était Cace Pilot et le nom commercial chez Riverbed était 
SteelCentral Packet Analyzer
Après de nombreuses recherches, je ne trouve plus ce produit
Quelqu'un connait son successeur ou un produit qui ferait le même boulot ?
Cordialement
Michel KOENIG

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

Re: [FRnOG] [TECH] DNS Load Balancer

[Guillaume Tournat via frnog]

Avec du GSLB DNS c’est assez simple
Tu as ce type de service chez FortiGSLB (Fortinet)
ou Amazon Route53, ou Cloudflare…



> On 15 Apr 2024, at 18:19, Michel KOENIG via frnog  wrote:
> 
> Bonjour,
> Nous souhaiterions mettre en place une entrée DNS de type A qui pointe vers 
> une IP publique chez nous
> Et qu’en cas de rupture de ce lien, cette entrée DNS pointe sur la ligne de 
> backup qui a bien entendu une autre IP publique
> Avez-vous connaissance d’une solution facile à mettre en œuvre (SOA chez 
> nous) ou disponible chez un provider ?
> Cordialement
> Michel KOENIG
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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