[FRnOG] [TECH] Switch Alcatel - Perte de licence 6450

[Adriano SIMAO-BOURGEOIS]

Bonjour,

Avec notre association avons acheté 2 switchs alcatel OS 6450 qui avaient 
initialement une licence 10G, celle-ci semble perdu puisqu'au lieu d'être un 
switch 1G avec uplink en 10G nous nous trouvons avec un 100m 1G.
Quelqu'un aurait -il une solution ?
Merci d'avance pour vos réponses et bonne journée,

Cordialement,


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

Re: [FRnOG] [TECH] Bgp sous FRR

[Willy Manga]

.
On 17/05/2024 13:19, Nicolas de Brou wrote:

Bonjour

J’ai identifié mon interface
Que je force ou pas l’ip source, je passe toujours par ce
Un traceroute montre que je passe à travers 4 routeurs supplémentaires de cet 
opérateur avant de perdre la suite.


Sans aucune donnée réelle, je dirais dans tous les cas:

- le fait de passer par le même opérateur dépend à la fois de votre 
configuration de routage locale et la destination


- après le 4è saut, un routeur ne sait ni comment joindre la destination 
ou bien ne sait pas comment vous joindre en retour ou bien les deux





--
Willy Manga


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

Re: [FRnOG] [TECH] Bgp sous FRR

[Nicolas de Brou]

Bonjour

J’ai identifié mon interface
Que je force ou pas l’ip source, je passe toujours par ce 
Un traceroute montre que je passe à travers 4 routeurs supplémentaires de cet 
opérateur avant de perdre la suite.



> Le 17 mai 2024 à 07:36, Willy Manga  a écrit :
> 
> Bonjour,
> 
>> On 16/05/2024 20:04, Nicolas de Brou wrote:
>> Hello
>> Je me suis mal exprimé, désolé
>> On a deux transitaire et ça fonctionne
>> Le routeur « route » et les majs bgp fonctionne
> 
> 
>> C’est le Linux qui lui n’accède pas à internet
>> Alors que je peux me connecter dessus à distance…
> 
> Il faudrait plus de détails notamment le résultat de mtr (ou à défaut 
> traceroute) depuis une adresse (ou interface) spécifique du routeur.
> 
> En partant du shell du système d'exploitation, pour une destination donnée, 
> effectuer:
> 
> * un mtr sans spécifier une interface d'origine .
> ex: mtr -nrc 3 mon.adresse.de.destination
> 
> * un mtr en spécifiant une adresse d'origine (loopback, adresse d'un bloc 
> interne, adresse de point à point avec fournisseur A, adresse de point à 
> point avec fournisseur B,..)
> ex. mtr -nrc 3 -a mon.adresse.source mon.adresse.de.destination
> 
> 
> Vu que vous avez deux transitaires, il faudrait un échantillon en terme de 
> destination qui puisse passer par les deux opérateurs. Avant d'effectuer le 
> test mtr, vous pouvez rapidement déterminer le réseau qui sera utilisé en 
> faisant depuis le shell du système d'exploitation un
> 
> ip route get mon.adresse.de.destination
> 
> J'ai volontairement omis ce que pourrait vous indiquer la table de routage de 
> FRR (pour l'instant)
> 
> 
> --
> Willy Manga
> 


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

Re: [FRnOG] [TECH] Problème FortiGate

[Toussaint OTTAVI]

Le 16/05/2024 à 23:03, Jérôme Marteaux a écrit :

Ce n'est pas une bonne idée. Exemple avec ce schéma:
CPE <--> PE

Si la MTU du PE est à 1500 et celle du CPE est à 1492: lorsque le PE 
va envoyer des paquets à 1500 le CPE va les dropper.


Tu es sûr de çà ? Moi, j'ai plutôt l'impression que le CPE ne va pas 
envoyer de paquets plus gros que son MTU, mais que s'il reçoit des 
paquets plus gros, çà ne le gêne pas. Je n'ai jamais véritablement tracé 
çà, mais il m'est arrivé, sur des tests, de mettre des MTU 
volontairement très bas, et çà a toujours fonctionné.


Et surtout le drop n'émet pas un paquet ICMP, donc si c'est du TCP la 
pile TCP doit interpréter ce drop comme un problème de MTU et pas une 
perte de paquet "classique", d'où le long délai pour établir une 
connexion (qui plus est en HTTPS avec la session SSL).


Plus généralement :
- Dans le cas où c'est un routeur à moi qui monte une session PPPoE 
derrière un ONT fourni par l'opérateur, qui assume le rôle de CPE ? 
L'ONT ? Ou mon routeur ?
- Si l'opérateur utilise de la collecte entre le CPE et son PE, on ne 
sait pas forcément ce qui peut se trouver entre les deux, notamment sur 
le réseau de l'opérateur de collecte. C'est un problème du PPPoE : 
l'utilisateur, et parfois l'opérateur du PE, ne maîtrisent pas forcément 
tous les intermédiaires qui sont susceptibles de dropper des paquets 
sans prévenir...


Les problèmes que j'ai pu rencontrer sur du PPPoE, pour lesquels la 
valeur négociée ne fonctionnait pas, et/ou pour lesquels j'ai dû 
descendre le MTU en dessous de la valeur classique de 1492, c'était :
- soit dans le cas d'opérateurs tiers utilisant une collecte d'un autre 
opérateur (que je suppose donc avoir utilisé un tunnel L2TP ou 
équivalent sur le chemin)
- soit avec des dispositifs utilisant des formes diverses 
d'encapsulation (GRE, MLPPP, ...)


Concernant les méthodes de détection  :
- avec des sites en ligne qui proposent cette fonction : j'ai déjà eu 
des résultats incohérents (sans pouvoir dire pourquoi)
- avec la méthode du ping en réduisant progressivement la taille de 
paquets : il faut pinguer un hôte de confiance derrière un réseau de 
confiance ; j'ai souvenir de bizarreries avec 8.8.8.8, qui ne répondait 
pas pour certaines valeurs spécifiques !


Donc, le MTU sur PPPoE, cela reste un sujet vendreditesque :-) Cela peut 
s'avérer un peu empirique, surtout dans des configurations (matériel / 
WAN) différentes de celles que l'on a l'habitude d'utiliser.


--
D'où l'intérêt de privilégier des liens WAN où l'opérateur fournit un 
CPE qui livre sur une interface Ethernet, avec un MTU de 1500. Ce qui se 
passe entre le CPE et le PE ne concerne que lui. En général, il maîtrise 
ses matériels ainsi que son réseau, et cela sera sans surprises. Et 
quand bien même il y aurait des surprises, ce serait alors à lui de les 
résoudre ;-) C'est un problème classique de "frontière de 
responsabilité", et de facilité à déterminer clairement cette 
"frontière". Ceci étant, cela ne veut pas dire que je n'ai jamais dû 
réduire des MTU sur des opérateurs me livrant en Ethernet :-)




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

Re: [FRnOG] [TECH] Bgp sous FRR

[Willy Manga]

Bonjour,

On 16/05/2024 20:04, Nicolas de Brou wrote:

Hello

Je me suis mal exprimé, désolé

On a deux transitaire et ça fonctionne
Le routeur « route » et les majs bgp fonctionne





C’est le Linux qui lui n’accède pas à internet
Alors que je peux me connecter dessus à distance…


Il faudrait plus de détails notamment le résultat de mtr (ou à défaut 
traceroute) depuis une adresse (ou interface) spécifique du routeur.


En partant du shell du système d'exploitation, pour une destination 
donnée, effectuer:


* un mtr sans spécifier une interface d'origine .
ex: mtr -nrc 3 mon.adresse.de.destination

* un mtr en spécifiant une adresse d'origine (loopback, adresse d'un 
bloc interne, adresse de point à point avec fournisseur A, adresse de 
point à point avec fournisseur B,..)

ex. mtr -nrc 3 -a mon.adresse.source mon.adresse.de.destination


Vu que vous avez deux transitaires, il faudrait un échantillon en terme 
de destination qui puisse passer par les deux opérateurs. Avant 
d'effectuer le test mtr, vous pouvez rapidement déterminer le réseau qui 
sera utilisé en faisant depuis le shell du système d'exploitation un


ip route get mon.adresse.de.destination

J'ai volontairement omis ce que pourrait vous indiquer la table de 
routage de FRR (pour l'instant)



--
Willy Manga


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

Re: [FRnOG] [TECH] Problème FortiGate

[Vincent]

Salut,

Désolé ca va pas t'aider mais attention, 2 PCs dans un même
réseau/navigateur ne signifie pas du tout forcément la même requête
réseau..

Juste en parlant de proxy HTTP  tu peux  avoir:
- un poste qui sera configuré via  son DHCP pour utiliser  un proxy HTTP
via un proxy.pac:
- Les navigateurs IE/Chrome l'utiliseront via la conf windows mais pas
forcément Firefox.
- Un autre aura peut être des exceptions de proxy déclarées  manuellement.
- un qui utilisera le même proxy pour le http ET https
-  un dernier qui aura un proxy http et un autre pour le https.
Juste pour une histoire de proxy, chaque cas précédent aura une requete
différente (https, http over TLS, https over https,..)

Tu vas perdre quelques points de vue et cheveux   mais je te conseille de
sortir combo curl/wireshark côté client PLUS une autre sonde pour comparer.


 Dans mon cas perso, le FW modifiait les en-tetes TCP et cassait les
sessions TLS. Mes pcaps aux niveaux du  SQUID, je voyais des paques émis
par le client que je ne retrouvait pas dans le pcap du dit client (testé
sous Wireshak Windows et GNU/Linux)...  ça m'a rendu fou..

Bon courage! Tiens nous au jus quand tu trouves l'origine de ton probleme.
A+
V.

PS: On est vendredi, pour troller entre la MSS et MTU,  je vous joint un de
mes petit code récent BASH/AWK completement useless

Ca va modifier la MSS vers les @IP qui vous scannent, c'est une défense
type "deception".  (à ne pas utiliser en prod bien sur)

#!/usr/bin/env bash
export PATH="/bin:/usr/bin:/sbin"
# "pretty" useless AntiBruteForce bash script
# Deception Counter-mesure settings a 5bytes MSS window with the attacker
# 0. Get the ip/interface of your gateway
# 1. tailling logs
# 2. awk script matching failled auths (LOG_FILTER), extract @IP, execute
the FILTER inline script
# 3. set the MSS to 5bytes with the previous @ip  (except  WHITELIST)
# Vive La Commune!

# VARIABLES
# journalctl filter with IP
LOG_FILTER='$0 ~ /.*sshd.*failure.*/ || $0 ~ /smtpd.*lost connection after
EHLO from unknown.*/'
WHITELIST=('127.0.0.1' '192.168.1.254')
#  TEST : /!\ CHANGED THE LAST 2 LINES !!
#DEBUG="echo " ; LOG_TEST="toto 8.8.8.8 toto" ; LOG_FILTER='toto.*toto'

# CODE NE PAS MODIFIER!
# -1. Check dependances
tools=('awk' 'sed' 'journalctl' 'ip')
for i in  ${!tools[@]} ; do command -v "${tools[i]}"  &> /dev/null || {
echo  "manque ${tools[i]}" ; exit -1; }; done

#0.
read -r gw dev<<<$(ip route | awk '/default/ {print $3 " " $5}')

#3.
FILTER=$(cat  Le 16/05/2024 à 09:34, Toussaint OTTAVI a écrit :
> >
> >
> > Le 15/05/2024 à 14:48, Hugues Voiturier a écrit :
> >> Mais quelle excellente idée de changer la MTU de l’interface sans
> >> changer la MSS,
> >
> > Je suppose que cela dépend des équipements. MSS = MTU moins les headers
> > (IP, TCP, IPsec...). Par défaut, le matériel que j'utilise calcule la
> > MSS tout seul en fonction de la MTU spécifiée. A vérifier dans la doc du
> > firewall, mais s'il ne le fait pas automatiquement, si on réduit la MTU,
> > il faut à priori réduire aussi la MSS à MTU - 40 (20 octets de header
> > TCP + 20 octets de header IP)
> >
> > --
> > Sinon, à ma connaissance, il n'y a pas de risque à spécifier une MTU (et
> > une MSS) trop petite (à part bien sûr la fragmentation excessive, qui
> > peut dégrader les performances).
>
> Ce n'est pas une bonne idée. Exemple avec ce schéma:
> CPE <--> PE
>
> Si la MTU du PE est à 1500 et celle du CPE est à 1492: lorsque le PE va
> envoyer des paquets à 1500 le CPE va les dropper.
> Et surtout le drop n'émet pas un paquet ICMP, donc si c'est du TCP la
> pile TCP doit interpréter ce drop comme un problème de MTU et pas une
> perte de paquet "classique", d'où le long délai pour établir une
> connexion (qui plus est en HTTPS avec la session SSL).
>
> Et inversement PE / CPE.
>
> La MTU doit toujours être identique des 2 côtés et il n'y a pas d'autre
> possibilité.
>
> $ ping -M do -s xxx ip
>
> peut parfaitement détecter des problèmes de MTU.
>
> >
> > 1492 est la valeur classique d'une MTU sur un lien WAN PPPoE.
> > Avec certains opérateurs, et en fonction de la façon dont ils collectent
> > le trafic pour le ramener sur leur infra, on peut être amenés à
> > descendre la MTU jusqu'à 1452 pour que le trafic passe bien.
>
> Ca c'est un problème, car la MTU est négociée par le PPPoE, est-ce que
> ton routeur a bien pris en compte la négo PPPoE ?
> Le LNS lui va envoyer des paquets à la MTU sans savoir que ton CPE a une
> MTU beaucoup petite.
>
> >
> > Pour ce que j'ai pu en voir, on n'a besoin de modifier la MTU que si

Re: [FRnOG] [TECH] Problème FortiGate

[Jérôme Marteaux]

Le 16/05/2024 à 09:34, Toussaint OTTAVI a écrit :



Le 15/05/2024 à 14:48, Hugues Voiturier a écrit :
Mais quelle excellente idée de changer la MTU de l’interface sans 
changer la MSS,


Je suppose que cela dépend des équipements. MSS = MTU moins les headers 
(IP, TCP, IPsec...). Par défaut, le matériel que j'utilise calcule la 
MSS tout seul en fonction de la MTU spécifiée. A vérifier dans la doc du 
firewall, mais s'il ne le fait pas automatiquement, si on réduit la MTU, 
il faut à priori réduire aussi la MSS à MTU - 40 (20 octets de header 
TCP + 20 octets de header IP)


--
Sinon, à ma connaissance, il n'y a pas de risque à spécifier une MTU (et 
une MSS) trop petite (à part bien sûr la fragmentation excessive, qui 
peut dégrader les performances).


Ce n'est pas une bonne idée. Exemple avec ce schéma:
CPE <--> PE

Si la MTU du PE est à 1500 et celle du CPE est à 1492: lorsque le PE va 
envoyer des paquets à 1500 le CPE va les dropper.
Et surtout le drop n'émet pas un paquet ICMP, donc si c'est du TCP la 
pile TCP doit interpréter ce drop comme un problème de MTU et pas une 
perte de paquet "classique", d'où le long délai pour établir une 
connexion (qui plus est en HTTPS avec la session SSL).


Et inversement PE / CPE.

La MTU doit toujours être identique des 2 côtés et il n'y a pas d'autre 
possibilité.


$ ping -M do -s xxx ip

peut parfaitement détecter des problèmes de MTU.



1492 est la valeur classique d'une MTU sur un lien WAN PPPoE.
Avec certains opérateurs, et en fonction de la façon dont ils collectent 
le trafic pour le ramener sur leur infra, on peut être amenés à 
descendre la MTU jusqu'à 1452 pour que le trafic passe bien.


Ca c'est un problème, car la MTU est négociée par le PPPoE, est-ce que 
ton routeur a bien pris en compte la négo PPPoE ?
Le LNS lui va envoyer des paquets à la MTU sans savoir que ton CPE a une 
MTU beaucoup petite.




Pour ce que j'ai pu en voir, on n'a besoin de modifier la MTU que si 
l'on monte soi-même la session PPPoE. Si l'opérateur fournit un routeur, 
c'est lui qui se débrouille, et on garde une MTU normale de 1500 sur 
l'interface Ethernet.




Normalement en IPv4 les routeurs fragmentent, à charge au destinataire 
de ré-assembler. Donc si c'est bien fait, le CPE doit arriver à 
fragmenter correctement.
En IPv6 c'est l'émetteur qui doit fragmenter avant d'envoyer les paquets 
(d'où l'importance du PMTUd et de laisser passer ICMP).


Jérôme

--
Jérôme Marteaux



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

Re: [FRnOG] [TECH] Bgp sous FRR

[Vincent PAGES]

Hello,


Certains opérateurs te fournissent des blocs d'interco IP non routables. 
Ainsi tu peux te connecter sur ton routeur avec les IPs de ton asn, mais 
si le linux essaye de sortir sur internet via cette interco, possible 
qu'il utilise la mauvaise IP source.



Dans ce cas, tente un ping et force l'IP source pour voir si ca résoud 
ton problème.



Et effectivement, ca peut aussi venir des DNS qui ne sont pas joignables 
aussi avec des ips d'interco publiques mais non annoncées sur Internet.



Cela évite pour l'opérateur et ton infra qu'il y ait des DDOS sur ces 
plages IPs.




Le 16/05/2024 à 18:55, Laurent Barme a écrit :


Le 16/05/2024 à 18:04, Nicolas de Brou a écrit :

Hello

Je me suis mal exprimé, désolé

On a deux transitaire et ça fonctionne
Le routeur « route » et les majs bgp fonctionne

C’est le Linux qui lui n’accède pas à internet
Alors que je peux me connecter dessus à distance…
Cela m'évoque un problème de DNS mal (ou pas défini) au niveau du 
contexte linux…


Merci


Le 16 mai 2024 à 17:41, Raphael Mazelier  a écrit :

Hello la liste,

Quand tu dis fait bien son travail que veut tu dire ?
Il route ? parce que bon si ton FRR/guagge est vautré mais qu'il te 
reste des routes et une default il va router. Mais tu n'auras pas 
trop d'update :)


--
Raph


On 16/05/2024 16:53, Nicolas de Brou wrote:

Bonjour,

Je cherche quelqu’un qui connaît bien FRR / Quagga qui pourrait 
accepter de perdre une heure Max pour comprendre pourquoi mon 
routeur fait bien son travaille mais que depuis la cli je ne puisse 
pas accéder aux ressource (exemple mise à jour)


Merci d’avance

---
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] Bgp sous FRR

[Laurent Barme]

Le 16/05/2024 à 18:04, Nicolas de Brou a écrit :

Hello

Je me suis mal exprimé, désolé

On a deux transitaire et ça fonctionne
Le routeur « route » et les majs bgp fonctionne

C’est le Linux qui lui n’accède pas à internet
Alors que je peux me connecter dessus à distance…

Cela m'évoque un problème de DNS mal (ou pas défini) au niveau du contexte 
linux…


Merci


Le 16 mai 2024 à 17:41, Raphael Mazelier  a écrit :

Hello la liste,

Quand tu dis fait bien son travail que veut tu dire ?
Il route ? parce que bon si ton FRR/guagge est vautré mais qu'il te reste des 
routes et une default il va router. Mais tu n'auras pas trop d'update :)

--
Raph


On 16/05/2024 16:53, Nicolas de Brou wrote:

Bonjour,

Je cherche quelqu’un qui connaît bien FRR / Quagga qui pourrait accepter de 
perdre une heure Max pour comprendre pourquoi mon routeur fait bien son 
travaille mais que depuis la cli je ne puisse pas accéder aux ressource 
(exemple mise à jour)

Merci d’avance

---
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] Bgp sous FRR

[Nicolas de Brou]

Hello

Je me suis mal exprimé, désolé 

On a deux transitaire et ça fonctionne
Le routeur « route » et les majs bgp fonctionne

C’est le Linux qui lui n’accède pas à internet
Alors que je peux me connecter dessus à distance…

Merci

> Le 16 mai 2024 à 17:41, Raphael Mazelier  a écrit :
> 
> Hello la liste,
> 
> Quand tu dis fait bien son travail que veut tu dire ?
> Il route ? parce que bon si ton FRR/guagge est vautré mais qu'il te reste des 
> routes et une default il va router. Mais tu n'auras pas trop d'update :)
> 
> --
> Raph
> 
>> On 16/05/2024 16:53, Nicolas de Brou wrote:
>> 
>> Bonjour,
>> 
>> Je cherche quelqu’un qui connaît bien FRR / Quagga qui pourrait accepter de 
>> perdre une heure Max pour comprendre pourquoi mon routeur fait bien son 
>> travaille mais que depuis la cli je ne puisse pas accéder aux ressource 
>> (exemple mise à jour)
>> 
>> Merci d’avance
>> 
>> ---
>> 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] Bgp sous FRR

[Raphael Mazelier]

Hello la liste,

Quand tu dis fait bien son travail que veut tu dire ?
Il route ? parce que bon si ton FRR/guagge est vautré mais qu'il te reste des 
routes et une default il va router. Mais tu n'auras pas trop d'update :)

--
Raph

On 16/05/2024 16:53, Nicolas de Brou wrote:

> Bonjour,
>
> Je cherche quelqu’un qui connaît bien FRR / Quagga qui pourrait accepter de 
> perdre une heure Max pour comprendre pourquoi mon routeur fait bien son 
> travaille mais que depuis la cli je ne puisse pas accéder aux ressource 
> (exemple mise à jour)
>
> Merci d’avance
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[lm2 via frnog]

>Heureusement que ce n'est pas encore implémenté chez beaucoup 
d'opérateurs, car évidemment, sans certificat valide, plus d'appels tout 

court.



Hmm wait.. ça veut dire que si des flics sonnent à ma porte, je dois préférer 
croire que des (faux) flics (ou faux tech erdf) viennent me rassurer en me 
cambriolant par derrière? Nous sommes censés préférer qu'un dispositif de 
sécurité soit désactivé plutot que le système aussi étanche qu'une passoire?



ça aurait été l'absolue et parfaite opportunité, cette coupure, pour mettre les 
opérateurs au pieds du mur de leur responsabilité : soit traiter manu militari 
le problème des escroqueries téléphoniques, soit couper toutes les comm' ; que 
je sache, en cas d'embrasement des cités, il est bien mis sur la table par les 
gouvernements de couper la 4/5G?



>ce service 
aurait du être porté par un service d’État pour assurer une neutralité 

de traitement et une anonymisation des données.



l'état "responsable" quant aux données, comme pour la souveraineté, n'existe 
plus depuis longtemps, pour ce domaine...

ça me rappelle complèteemnt le fiasco "bloctel" géré en sous main par une 
entité privée..



>Par ailleurs, ça fait déjà plus de 1 an que cette technologie devrait 
être "obligatoire", mais la date est continuellement repoussée pour tous 
les problèmes cités précédemment.



Elle est prévue d'être repoussée encore après 2030..



>j'ai le sentiment que ce sujet va être encore plus compliqué 
que ipv6 à être déployé

nous avons le pays le plus compliqué au monde, et c'est pas pour redresser la 
barre..





pour revenir à une réflexion plus posée : pourquoi les opérateurs ne proposent 
pas, lors de l'ouverture de la ligne, par exemple la possibilité d'interdire 
tout appel entrant provenant d'un opérateur qui n'est pas sur le sol français?

ça en filtrerait un paquet.. je trouve ça plus qu'irresponsable de laisser ce 
spoofing encore "dans la nature", dans quelques années ça finira.. au pénal?



From: Jeremy 
To: Daniel ;
   frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?
Date: 14/05/2024 23:25:40 Europe/Paris

Mais dans la réalité, l'implantation du MAN se déroule extrêmement mal 
autant coté opérateurs que coté APNF.
Pour exemple, pas plus tard que la semaine dernière, l'un des certificat 
racine permettant d'authentifier les appels n'a pas été renouvelé dans 
les temps par les équipes en charge.
Heureusement que ce n'est pas encore implémenté chez beaucoup 
d'opérateurs, car évidemment, sans certificat valide, plus d'appels tout 
court.

Nous sommes également plusieurs opérateurs à avoir émis de sérieux 
doutes quand à la capacité de l'infrastructure à tenir la charge des 
flux lié aux demandes d'authentification de la part des opérateurs, ou 
de l’interopérabilité avec les appels venant de l'étranger.
Je suis également particulièrement agacé que ce dispositif soit porté 
par un groupement d'opérateur (principalement nationaux) qui ont de ce 
fait tout loisir de disposer d'informations, de statistiques et de 
données liés à leur concurrents et à leur volume d'échange d'appels, ou 
autrement dit, leur part de marché. J'ai toujours pensé que ce service 
aurait du être porté par un service d’État pour assurer une neutralité 
de traitement et une anonymisation des données. Évidemment, l'équipe 
dirigeante m'a assuré de cette discrétion mais dans les faits, je n'ai 
reçu aucune garantie technique ou juridique me permettant d'être certain 
que nos flux ne seront pas inspectés en détail. OPA, quand tu nous tiens...

La documentation, l'accompagnement et la définition précise de la 
nouvelle norme MAN semblent être aux abonnés absents puisque nous sommes 
nombreux à être laissé pour compte au bord de la route. Heureusement 
qu'on est accompagné par un infogéreur expérimenté qui s'est déjà amusé 
sur cette technologie, et qui n'a fait que confirmer nos craintes.

Par ailleurs, ça fait déjà plus de 1 an que cette technologie devrait 
être "obligatoire", mais la date est continuellement repoussée pour tous 
les problèmes cités précédemment.

A noter qu'aux USA, seul 40% des appels sont désormais authentifiés, 
alors que la norme est obligatoire depuis plusieurs années déjà. Les 
opérateurs sont donc contraint de continuer à laisser passer les appels 
non authentifier au risque de ne plus rien recevoir.

En bref, j'ai le sentiment que ce sujet va être encore plus compliqué 
que ipv6 à être déployé, sans compte le cout (que je considère) 
exorbitant pour adhérer à l'APNF et à la certification MAN, cout qui ne 
trouve, à mon sens, aucune justification vu la qualité de 
l'accompagnement et du déploiement.

Conclusion, soyez patient, et priez.

Jérémy

Le 14/05/2024 à 15:27, Daniel via frnog a écrit :
> Bonjour. Aux dernières nouvelles le MAN devrait être actif 
> définitivement en septembre
>
> Le 14/05/2024 à 15:22, Hervé BRY via frnog a écrit :
>> Bonjour la liste,
>>
>> Je viens une nouvelle fois, comme probablement nombre 

[FRnOG] [TECH] Bgp sous FRR

[Nicolas de Brou]

Bonjour,

Je cherche quelqu’un qui connaît bien FRR / Quagga qui pourrait accepter de 
perdre une heure Max pour comprendre pourquoi mon routeur fait bien son 
travaille mais que depuis la cli je ne puisse pas accéder aux ressource 
(exemple mise à jour)

Merci d’avance

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

[FRnOG] Re: [MISC] Régulations nouvelles (Was: Tempête solaire prévue cette nuit

[Gregory ROCHER]

Le 16/05/2024 à 16:29, Stephane Bortzmeyer a écrit :

C'est la loi. Contrairement aux RFC, c'est difficile à lire.


Je croyais qu'on n'avait pas le droit de troller ici ?

Merci pour la réponse
--
Grégory Rocher


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

[FRnOG] Re: [MISC] Régulations nouvelles (Was: Tempête solaire prévue cette nuit

[Stephane Bortzmeyer]

On Thu, May 16, 2024 at 04:13:12PM +0200,
 Gregory ROCHER  wrote 
 a message of 43 lines which said:

> > https://www.legifrance.gouv.fr/jorf/id/JORFTEXT49523217
> 
> mm… j'ai lu en diagonale, c'est un peu indigeste.

C'est la loi. Contrairement aux RFC, c'est difficile à lire.

> > « Art. R. 2321-1-12.-Les fournisseurs de système de résolution de noms de 
> > domaine transmettent aux agents mentionnés au premier alinéa de l'article 
> > L. 2321-3-1 les données techniques suivantes :
> > « 1° Les enregistrements issus des serveurs gérant le système d'adressage 
> > par domaine, incluant le nom de domaine, le type d'enregistrement, sa durée 
> > de vie et sa valeur ;
> > « 2° L'horodatage de ces enregistrements.
> 
> * Ça refroidi un peu les ardeurs à mettre à disposition un résolveur ouvert
> sur l'internet, non ? Ils parlent bien des logs là ? pas du contenu de la
> zone ?

IANAL, attention.

C'est en effet comme cela que je l'interprète. PS : attention, le
terme "log" peut faire penser à un fichier alors que là, on utilisera
plutôt dnstap ou une techno équivalente.

> * Et est-ce que les personnes opérant des serveurs faisant autorité sont
> concernées ? Au hasard :) l'Afnic ? avec fr. re. les autres ?

Oui, mais pas par cet article. L'Afnic l'était déjà suite à la
convention avec l'État.


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

Re: [FRnOG] [MISC] Régulations nouvelles (Was: Tempête solaire prévue cette nuit

[Gregory ROCHER]

Le 16/05/2024 à 10:02, Stephane Bortzmeyer a écrit :

Mieux (ou pire, selon le point de vue), le décret de ce week-end :

https://www.legifrance.gouv.fr/jorf/id/JORFTEXT49523217


mm… j'ai lu en diagonale, c'est un peu indigeste.

Mais j'ai une (deux) questions


« Art. R. 2321-1-12.-Les fournisseurs de système de résolution de noms de 
domaine transmettent aux agents mentionnés au premier alinéa de l'article L. 
2321-3-1 les données techniques suivantes :
« 1° Les enregistrements issus des serveurs gérant le système d'adressage par 
domaine, incluant le nom de domaine, le type d'enregistrement, sa durée de vie 
et sa valeur ;
« 2° L'horodatage de ces enregistrements.


* Ça refroidi un peu les ardeurs à mettre à disposition un résolveur 
ouvert sur l'internet, non ? Ils parlent bien des logs là ? pas du 
contenu de la zone ?


* Et est-ce que les personnes opérant des serveurs faisant autorité sont 
concernées ? Au hasard :) l'Afnic ? avec fr. re. les autres ?


Si oui fournir les logs qd on voit les conditions…

1° La fréquence du relevé, au moins quotidienne, des données mentionnées à l'article R. 2321-1-12 ; 


4° La fréquence de transmission de ces données, au moins hebdomadaire. 



--
Grégory Rocher
02 29 00 85 79 (8579)


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

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[David Ponzone]

> Le 16 mai 2024 à 14:27, Gérald Vannier  a écrit :
> 
> Disons que je ne sais pas bien où ça en est sur le sujet mais il existe 
> toujours ces call-centers qui utilisent des numéros français pour appeler en 
> France, certains ne commerce(çaient) pas directement avec un opérateur 
> français.
> 
> Un autre cas, et je vais prendre l'autre point de vue : nous opérateur 
> français pouvons présenter des numéros étrangers.
> Prenons France vers Belgique par exemple : il est possible pour un opérateur 
> français de prendre un numéro belge: en gros tu achètes un numéro belge (il y 
> a des sociétés qui sont spécialisées), tu associes un numéro en 09x.  Qd 
> le numéro belge, reçoit un appel, il y a une redirection vers le 09xxx qui 
> revient vers l'opérateur français pour faire sonner la ligne qu'il tient. 
> L'opérateur qui donc a ce numéro belge peut envoyer des appels vers la 
> Belgique en présentant un numéro belge, en passant pas un transitaire 
> français (Orange par exemple)...
> C'est un service qui se vend en France, pour des entreprises qui ont des 
> entités à l'international et qui veulent gérer leur téléphonie en centralisé 
> sur une offre locale.


En fait, on en revient à un problème simple qu’on connait déjà en BGP: c’est à 
l’opérateur qui a le client final (dont client qui lui n’est pas opérateur) de 
vérifier si ce que le client envoie est autorisé, car il détient bien les 
ressources.
C’est je pense la volonté du MAN, et ça marchera peut-être au niveau national 
(peut-être car il y a tous les cas « gris » qui vont probablement faire échouer 
le truc comme aux US), mais ça ne marchera jamais au niveau international, car 
il y aura toujours un shady opérateur dans un shady pays pour pas se plier à la 
règle.
Après, comme le transit téléphonique international dépend de moins de 10 
acteurs, ceux-là pourraient mettre des filtres sévères sur ce qui vient des 
shady pays, mais là, on rentre dans la géopolitique.

David


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

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Greg]

Bonjour,

>Pour exemple, pas plus tard que la semaine dernière, l'un des certificat
>racine permettant d'authentifier les appels n'a pas été renouvelé dans
>les temps par les équipes en charge.

Il me semble que c'est la CRL de certificat ROOT, bien que ce n'est pas
terrible, les certificats de signature restent valides.


вт, 14 мая 2024 г. в 23:26, Jeremy :

> Mais dans la réalité, l'implantation du MAN se déroule extrêmement mal
> autant coté opérateurs que coté APNF.
> Pour exemple, pas plus tard que la semaine dernière, l'un des certificat
> racine permettant d'authentifier les appels n'a pas été renouvelé dans
> les temps par les équipes en charge.
> Heureusement que ce n'est pas encore implémenté chez beaucoup
> d'opérateurs, car évidemment, sans certificat valide, plus d'appels tout
> court.
>
> Nous sommes également plusieurs opérateurs à avoir émis de sérieux
> doutes quand à la capacité de l'infrastructure à tenir la charge des
> flux lié aux demandes d'authentification de la part des opérateurs, ou
> de l’interopérabilité avec les appels venant de l'étranger.
> Je suis également particulièrement agacé que ce dispositif soit porté
> par un groupement d'opérateur (principalement nationaux) qui ont de ce
> fait tout loisir de disposer d'informations, de statistiques et de
> données liés à leur concurrents et à leur volume d'échange d'appels, ou
> autrement dit, leur part de marché. J'ai toujours pensé que ce service
> aurait du être porté par un service d’État pour assurer une neutralité
> de traitement et une anonymisation des données. Évidemment, l'équipe
> dirigeante m'a assuré de cette discrétion mais dans les faits, je n'ai
> reçu aucune garantie technique ou juridique me permettant d'être certain
> que nos flux ne seront pas inspectés en détail. OPA, quand tu nous tiens...
>
> La documentation, l'accompagnement et la définition précise de la
> nouvelle norme MAN semblent être aux abonnés absents puisque nous sommes
> nombreux à être laissé pour compte au bord de la route. Heureusement
> qu'on est accompagné par un infogéreur expérimenté qui s'est déjà amusé
> sur cette technologie, et qui n'a fait que confirmer nos craintes.
>
> Par ailleurs, ça fait déjà plus de 1 an que cette technologie devrait
> être "obligatoire", mais la date est continuellement repoussée pour tous
> les problèmes cités précédemment.
>
> A noter qu'aux USA, seul 40% des appels sont désormais authentifiés,
> alors que la norme est obligatoire depuis plusieurs années déjà. Les
> opérateurs sont donc contraint de continuer à laisser passer les appels
> non authentifier au risque de ne plus rien recevoir.
>
> En bref, j'ai le sentiment que ce sujet va être encore plus compliqué
> que ipv6 à être déployé, sans compte le cout (que je considère)
> exorbitant pour adhérer à l'APNF et à la certification MAN, cout qui ne
> trouve, à mon sens, aucune justification vu la qualité de
> l'accompagnement et du déploiement.
>
> Conclusion, soyez patient, et priez.
>
> Jérémy
>
> Le 14/05/2024 à 15:27, Daniel via frnog a écrit :
> > Bonjour. Aux dernières nouvelles le MAN devrait être actif
> > définitivement en septembre
> >
> > Le 14/05/2024 à 15:22, Hervé BRY via frnog a écrit :
> >> Bonjour la liste,
> >>
> >> Je viens une nouvelle fois, comme probablement nombre d'entre vous,
> >> d'être
> >> victime d'un spoofing de mon numéro mobile : une personne m'appelle
> >> en me
> >> disant "qui êtes vous, vous venez de m'appeler ?" alors que bien
> >> évidemment
> >> je ne l'ai jamais appelé. Cela semble se multiplier ces derniers
> >> mois. Un
> >> collègue m'a même fait part d'un appel qu'il a reçu usurpant le
> >> numéro d'un
> >> commissariat parisien et, contactée, la police ne pouvait rien faire
> >> d'autre que confirmer le problème !
> >>
> >> J'avais en tête depuis une conférence FRnOG il y a quelques temps
> >> déjà que
> >> la mise en place des protocoles STIR/SHAKEN et autres joyeusetés
> >> était en
> >> cours en France. Savez-vous où en est le déploiement ? Y a-t-il une
> >> échéance pour le filtrage des appels non authentifiés ?
> >>
> >> Hervé BRY
> >> Head of Infrastructure
> >> Geneanet (http://www.geneanet.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] Forticlient, Linux et OpenSSL

[Pierre DOLIDON]

Le 16/05/2024 à 13:35, Dominique Rousseau a écrit :

Le Thu, May 16, 2024 at 12:30:28PM +0200, Pierre DOLIDON [sn...@sn4ky.net] a 
écrit:

Le 16/05/2024 à 11:14, Dominique Rousseau a écrit :

Il faut récupérer initialement le certificat (ça se fait directement
avec la commande openfortivpn ) et mettre l'empreinte dans le fichier de
configuration.

aurais tu un exemple à ce sujet ?
Je galère de mon côté... et ai poussé le client a monter un tunnel VPN L2L
(parceque en plus, le besoin de L2L est bien là)
mais en attendant, côté FG le CN et le FQDN changent tous les mois (oui oui)
et sont pas résolvables, et j'en ai marre de bricoler

Si tu ne l'as pas autrement, de memoire, il "suffit" de préparer le
fichier de configuration avec tout ce que tu veux *sauf* le
'trusted-cert', et quand tu le lances, ça te donne une erreur avec
l'empreinte vue.

Peut-etre avec un « -v »


ah oui, on est d'accord, c'est bien de ça que je parlais en partie 
"bricolage" :-)



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

RE: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Gérald Vannier]

Disons que je ne sais pas bien où ça en est sur le sujet mais il existe 
toujours ces call-centers qui utilisent des numéros français pour appeler en 
France, certains ne commerce(çaient) pas directement avec un opérateur français.

Un autre cas, et je vais prendre l'autre point de vue : nous opérateur français 
pouvons présenter des numéros étrangers.
Prenons France vers Belgique par exemple : il est possible pour un opérateur 
français de prendre un numéro belge: en gros tu achètes un numéro belge (il y a 
des sociétés qui sont spécialisées), tu associes un numéro en 09x.  Qd le 
numéro belge, reçoit un appel, il y a une redirection vers le 09xxx qui revient 
vers l'opérateur français pour faire sonner la ligne qu'il tient. 
L'opérateur qui donc a ce numéro belge peut envoyer des appels vers la Belgique 
en présentant un numéro belge, en passant pas un transitaire français (Orange 
par exemple)...
C'est un service qui se vend en France, pour des entreprises qui ont des 
entités à l'international et qui veulent gérer leur téléphonie en centralisé 
sur une offre locale.
Là si la Belgique implémente le MAN, ça va grincer également.
(pour info, les pays européens commencent à faire du protectionnisme, ça bouge, 
on ne peut plus faire cela depuis récemment avec certains pays européens).

Si ce que tu penses était vrai, on pourrait depuis longtemps couper les appels 
de spoofing qui viennent d'opérateurs étrangers  or ce n'est réellement pas le 
cas... En même temps tu me diras, entre ce qu'on peut faire et ce qu'on fait, 
il peut y avoir un écart.

-Original Message-
From: David Ponzone  
Sent: jeudi 16 mai 2024 14:08
To: Gérald Vannier 
Cc: Raphaël Barrois ; Adrien Versnaeyen 
; Jeremy ; Daniel 
; frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?


> Le 16 mai 2024 à 13:51, Gérald Vannier  a écrit :
> 
> Les appels sur les interco étrangères ne seront pas signées.
> Si rien n’empêche un opérateur de signer A, je crois surtout, qu’il ne 
> prendra pas de risques (ou moins) et signera C.
> En l’état, le spoofing venant de l’étranger ne sera pas arrêter.
> 
> MAIS, il faut mettre cette disposition à côté des législations sur les 
> numéros, NPV, etc. « Normalement » les call-centers doivent utiliser des 
> numéros spécifiques, légaux (au moins, si pas légitime). Et donc, il 
> resterait qu’un appel direct (non redirigé) émis via un opérateur étranger 
> avec un numéro non « spécifique » devient louche.
> En mettant ces dispositions ensemble, on devrait améliorer la situation « 
> spoofing ».
> 

Gérald,

Je suis pas sûr de comprendre.
S’il n’est pas redirigé, un appel entrant venant d’un opérateur étranger 
devrait être bloqué s’il vient de +33, et surtout s’il l’appel est aussi pour 
+33.
De la même manière que je bloque tout paquet IP qui veut entrer sur mon réseau 
et dont l’IP source est à moi.

David



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

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[David Ponzone]

> Le 16 mai 2024 à 13:51, Gérald Vannier  a écrit :
> 
> Les appels sur les interco étrangères ne seront pas signées.
> Si rien n’empêche un opérateur de signer A, je crois surtout, qu’il ne 
> prendra pas de risques (ou moins) et signera C.
> En l’état, le spoofing venant de l’étranger ne sera pas arrêter.
> 
> MAIS, il faut mettre cette disposition à côté des législations sur les 
> numéros, NPV, etc. « Normalement » les call-centers doivent utiliser des 
> numéros spécifiques, légaux (au moins, si pas légitime). Et donc, il 
> resterait qu’un appel direct (non redirigé) émis via un opérateur étranger 
> avec un numéro non « spécifique » devient louche.
> En mettant ces dispositions ensemble, on devrait améliorer la situation « 
> spoofing ».
> 

Gérald,

Je suis pas sûr de comprendre.
S’il n’est pas redirigé, un appel entrant venant d’un opérateur étranger 
devrait être bloqué s’il vient de +33, et surtout s’il l’appel est aussi pour 
+33.
De la même manière que je bloque tout paquet IP qui veut entrer sur mon réseau 
et dont l’IP source est à moi.

David



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

RE: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Gérald Vannier]

Les appels sur les interco étrangères ne seront pas signées.
Si rien n’empêche un opérateur de signer A, je crois surtout, qu’il ne prendra 
pas de risques (ou moins) et signera C.
En l’état, le spoofing venant de l’étranger ne sera pas arrêter.

MAIS, il faut mettre cette disposition à côté des législations sur les numéros, 
NPV, etc. « Normalement » les call-centers doivent utiliser des numéros 
spécifiques, légaux (au moins, si pas légitime). Et donc, il resterait qu’un 
appel direct (non redirigé) émis via un opérateur étranger avec un numéro non « 
spécifique » devient louche.
En mettant ces dispositions ensemble, on devrait améliorer la situation « 
spoofing ».

Gérald

From: Raphaël Barrois 
Sent: jeudi 16 mai 2024 10:47
To: Gérald Vannier 
Cc: Adrien Versnaeyen ; Jeremy ; 
Daniel ; frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

Bonjour,

Voici dans les grandes lignes ma compréhension du système à date.

Une fois que le MAN sera déployé et complètement activé, les opérateurs (de 
transit et de terminaison) sont supposés couper les appels non signés ou mal 
signés, et remonter l'information à l'APNF.
Concrètement, chaque appel porte une signature, apposé par un opérateur 
(identifié par le certificat dont il indique la référence dans l'en-tête), avec 
un niveau de confiance :
- A : J'ai injecté l'appel sur le réseau, je connais le client source, et j'ai 
vérifié qu'il avait le droit de présenter ce numéro
- B : J'ai injecté l'appel sur le réseau, je connais le client source, mais je 
n'ai pas vérifié qu'il avait le droit de présenter ce numéro
- C : J'ai injecté l'appel sur le réseau, mais depuis une source tierce ; je 
n'ai rien pu vérifier (appel international, transfert d'appel).

Lorsqu'un opérateur de transit ou de terminaison reçoit un appel, il est censé :
0. Laisser passer les appels d'urgence
1. Couper l'appel s'il présente un numéro appelant français, un numéro appelé 
français, mais pas de signature ou une signature malformée ;
2. Récupérer de sa copie locale de la base de certificats le certificat 
référencé dans l'en-tête STIR/Shaken ;
3. Vérifier la signature — et couper l'appel si elle est invalide.

Concrètement, rien n'empêche à ce stade un opérateur de signer au niveau A un 
appel qu'il reçoit d'un centre d'appel international ou autre.
En revanche, l'opérateur en question prend de fait la responsabilité de l'appel 
; les opérateurs de terminaison peuvent donc déterminer d'où vient la fraude.
Cela donnera des éléments concrets pour soit bloquer les appels émanant de cet 
opérateur, soit le signaler à l'ARCEP pour punition.

In fine, tout dépendra de la volonté de l'ARCEP à policer ce beau monde, et de 
la capacité des opérateurs de terminaison à identifier les appels abusifs…
Mais le MAN a été accéléré par l'ARCEP suite à une hausse de la grogne côté 
politique ; et les banques commencent à avoir de vrais soucis de fraude à 
l'usurpation de numéro appelant, ce qui a de bonnes chances d'augmenter la 
pression sur ce beau monde.

--
Raphaël Barrois

On Thu, 16 May 2024 at 10:29, Gérald Vannier 
mailto:gerald.vann...@mmtt.fr>> wrote:
Oui, le MAN s’applique au niveau national, mais il faut intégrer ce genre 
d’usages qui exist(ai)ent :

  *   Call center à l’étranger, branché sur un opérateur local à l’étranger qui 
envoie vers la France en passant par un opérateur français
  *   Envoi appel vers France avec des numéros sources français
 *   Le numéro source « appartient » à l’opérateur français qui reçoit 
l’appel / L’opérateur français termine l’appel
 *   Le numéro source « n’appartient pas » à l’opérateur français qui 
reçoit l’appel  / L’opérateur français ne termine pas l’appel et le transmet 
(transit)

Comment l’opérateur français va noter/évaluer la confiance/la légitimité de 
l’appel dans le numéro ?
Je ne sais pas si finalement c’est encore autorisé. Le client étranger doit ( 
?) contractualiser avec un opérateur français.
Ce point est important car de ce que nous avons expérimenté, les usurpations 
arrivaient à travers des opérateurs étrangers.

Idem, j’appelle un numéro étranger qui redirige vers un numéro français : 
l’appel part sur opérateur étranger et revient..

J’avoue que je ne sais pas trop où on en est sur ces cas d’usages.
Quelqu’un sait côté frnog ?

Gérald



From: Adrien Versnaeyen mailto:a.versnae...@gmail.com>>
Sent: mercredi 15 mai 2024 23:08
To: Gérald Vannier mailto:gerald.vann...@mmtt.fr>>
Cc: Jeremy mailto:li...@freeheberg.com>>; Daniel 
mailto:t...@tootai.net>>; 
frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

Bonjour,

Pour le moment je suis plutot d'accord avec votre ressenti.

En revanche je pensais que ce dispositif n'allait s'appliquer que pour des 
appels nationaux et que , part conséquent,  la vérification ne serait pas 
activée sur les intercos avec des carriers internationaux. Du coup les appels a 
destination de clients français en France 

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Dominique Rousseau]

Le Thu, May 16, 2024 at 12:30:28PM +0200, Pierre DOLIDON [sn...@sn4ky.net] a 
écrit:
> Le 16/05/2024 à 11:14, Dominique Rousseau a écrit :
> >Il faut récupérer initialement le certificat (ça se fait directement
> >avec la commande openfortivpn ) et mettre l'empreinte dans le fichier de
> >configuration.
> 
> aurais tu un exemple à ce sujet ?
> Je galère de mon côté... et ai poussé le client a monter un tunnel VPN L2L
> (parceque en plus, le besoin de L2L est bien là)
> mais en attendant, côté FG le CN et le FQDN changent tous les mois (oui oui)
> et sont pas résolvables, et j'en ai marre de bricoler

Si tu ne l'as pas autrement, de memoire, il "suffit" de préparer le
fichier de configuration avec tout ce que tu veux *sauf* le
'trusted-cert', et quand tu le lances, ça te donne une erreur avec
l'empreinte vue.

Peut-etre avec un « -v »


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Pierre DOLIDON]

Le 16/05/2024 à 11:14, Dominique Rousseau a écrit :

Il faut récupérer initialement le certificat (ça se fait directement
avec la commande openfortivpn ) et mettre l'empreinte dans le fichier de
configuration.


aurais tu un exemple à ce sujet ?
Je galère de mon côté... et ai poussé le client a monter un tunnel VPN 
L2L (parceque en plus, le besoin de L2L est bien là)
mais en attendant, côté FG le CN et le FQDN changent tous les mois (oui 
oui) et sont pas résolvables, et j'en ai marre de bricoler


merci =)

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

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Stéphane Rivière]

Le 16/05/2024 à 11:14, Dominique Rousseau a écrit :

Merci Dominique, je viens de noter tes conseils dans le dossier du client.


Pas si vieux, en fait :)


Effectivement, ça semblerait dater de 2015... C'était plutôt 
'affectueux' au sens où le style de codage et les choix (vites vus) 
semblaient refléter une approche old-school (c'est un compliment), car 
je bataille souvent avec du code 'moderne' écrit dans des langages de 
kicools nourris de microservices. Alors ça fait du bien de voir ça.



Et selon la cohabitation que tu veux avoir avec le reste du système sur
lequel tu l'utilises, moi, il y a 2 options que j'utilise dans la conf
pour qu'il ne touche pas au DNS :

set-dns = 0
pppd-use-peerdns = 0


Bon à savoir. On va tester comme ça.

On des portables-poubelles pour ces usages, un doze X pour les 
backoffices bancaires pourris - mais qui utilise encore cette mégabouse 
d'Adobe Air ? le crédit agric'ole bien sûr - pour la vente en ligne de 
nos clients ecommerce, et d'autres sous nux - notre use case du jour - 
pour les accès VPN clients.


--
Stéphane Rivière
Ile d'Oléron - France

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

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Dominique Rousseau]

Le Thu, May 16, 2024 at 10:57:00AM +0200, Stéphane Rivière [s...@genesix.org] a 
écrit:
> Merci pour vos réponses rapides
> 
> https://github.com/adrienverge/openfortivpn
> 
> Et paquet direct pour Ubuntu  : openfortivpn
> 
> Un bon vieux bidule codé très proprement en C et des retours positifs, ça
> sent bon...

Pas si vieux, en fait :)

Mais oui, ça marche tres bien, et plutot mieux que le "forticlient"
officiel. Ça s'occupe de la partie moche TLS et ça utilise pppd pour
établir la connexion.
Il faut récupérer initialement le certificat (ça se fait directement
avec la commande openfortivpn ) et mettre l'empreinte dans le fichier de
configuration.

Le paquet Ubuntu ne fourni(ssai?)t pas d'unit SystemD si tu as besoin
que ça se (re)lance automatiquement.

Et selon la cohabitation que tu veux avoir avec le reste du système sur
lequel tu l'utilises, moi, il y a 2 options que j'utilise dans la conf
pour qu'il ne touche pas au DNS :

set-dns = 0
pppd-use-peerdns = 0


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Arnaud Gelly]

Ancien utilisateur d'openfortivpn maintenant passé sur openconnect pour la
gestion du DTLS et autres options avancées.

Bonne journée à tous
--
Arnaud


On Thu, 16 May 2024 at 10:57, Stéphane Rivière  wrote:

> Merci pour vos réponses rapides
>
> https://github.com/adrienverge/openfortivpn
>
> Et paquet direct pour Ubuntu  : openfortivpn
>
> Un bon vieux bidule codé très proprement en C et des retours positifs,
> ça sent bon...
>
> Donc quand ça va ressortir le mois prochain, je vais suivre votre conseil !
>
> Encore merci pour votre aide :)
>
> --
> Stéphane Rivière
> Ile d'Oléron - France
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Problème FortiGate

[Florian VANNIER]

Pas fait ce test Toussaint, je vais voir ca.


Adrien, au niveau des DNS, nous utilisons les DNS FortiGuard, environ 10ms
de latence.

Les tests "sans filtrage" sont fait pour l'ensemble du LAN vers le WAN.



Le jeu. 16 mai 2024 à 09:54, Toussaint OTTAVI  a
écrit :

>
>
> Le 16/05/2024 à 09:42, Florian VANNIER a écrit :
> > Nous avons également fait ce test en utilisant des règles SDWAN pour
> > forcer sur l'un puis l'autre, même constat 
>
> Comme l'a dit Hugues dans une des toutes premières réponses, les
> symptômes "certains trucs fonctionnent et d'autres pas" étaient
> clairement évocateurs d'un problème de MTU/MSS.
>
> Cependant, si cela se produit chez deux opérateurs différents, c'est
> assez peu plausible.
>
> Un des trucs que je tenterais pour lever le doute, c'est de me brancher
> en direct sur un routeur opérateur, puis sur l'autre (sans passer par le
> Forti).
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
*Florian VANNIER*
Administrateur systèmes et réseaux
Tel : +33 6 83 10 70 09
E-mail : florian.vannie...@gmail.com

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

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Stéphane Rivière]

Merci pour vos réponses rapides

https://github.com/adrienverge/openfortivpn

Et paquet direct pour Ubuntu  : openfortivpn

Un bon vieux bidule codé très proprement en C et des retours positifs, 
ça sent bon...


Donc quand ça va ressortir le mois prochain, je vais suivre votre conseil !

Encore merci pour votre aide :)

--
Stéphane Rivière
Ile d'Oléron - France


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

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Raphaël Barrois]

Bonjour,

Voici dans les grandes lignes ma compréhension du système à date.

Une fois que le MAN sera déployé et complètement activé, les opérateurs (de
transit et de terminaison) sont supposés couper les appels non signés ou
mal signés, et remonter l'information à l'APNF.
Concrètement, chaque appel porte une signature, apposé par un opérateur
(identifié par le certificat dont il indique la référence dans l'en-tête),
avec un niveau de confiance :
- A : J'ai injecté l'appel sur le réseau, je connais le client source, et
j'ai vérifié qu'il avait le droit de présenter ce numéro
- B : J'ai injecté l'appel sur le réseau, je connais le client source, mais
je n'ai pas vérifié qu'il avait le droit de présenter ce numéro
- C : J'ai injecté l'appel sur le réseau, mais depuis une source tierce ;
je n'ai rien pu vérifier (appel international, transfert d'appel).

Lorsqu'un opérateur de transit ou de terminaison reçoit un appel, il est
censé :
0. Laisser passer les appels d'urgence
1. Couper l'appel s'il présente un numéro appelant français, un numéro
appelé français, mais pas de signature ou une signature malformée ;
2. Récupérer de sa copie locale de la base de certificats le certificat
référencé dans l'en-tête STIR/Shaken ;
3. Vérifier la signature — et couper l'appel si elle est invalide.

Concrètement, rien n'empêche à ce stade un opérateur de signer au niveau A
un appel qu'il reçoit d'un centre d'appel international ou autre.
En revanche, l'opérateur en question prend de fait la responsabilité de
l'appel ; les opérateurs de terminaison peuvent donc déterminer d'où vient
la fraude.
Cela donnera des éléments concrets pour soit bloquer les appels émanant de
cet opérateur, soit le signaler à l'ARCEP pour punition.

In fine, tout dépendra de la volonté de l'ARCEP à policer ce beau monde, et
de la capacité des opérateurs de terminaison à identifier les appels
abusifs…
Mais le MAN a été accéléré par l'ARCEP suite à une hausse de la grogne côté
politique ; et les banques commencent à avoir de vrais soucis de fraude à
l'usurpation de numéro appelant, ce qui a de bonnes chances d'augmenter la
pression sur ce beau monde.

-- 
Raphaël Barrois

On Thu, 16 May 2024 at 10:29, Gérald Vannier  wrote:

> Oui, le MAN s’applique au niveau national, mais il faut intégrer ce genre
> d’usages qui exist(ai)ent :
>
>   *   Call center à l’étranger, branché sur un opérateur local à
> l’étranger qui envoie vers la France en passant par un opérateur français
>   *   Envoi appel vers France avec des numéros sources français
>  *   Le numéro source « appartient » à l’opérateur français qui reçoit
> l’appel / L’opérateur français termine l’appel
>  *   Le numéro source « n’appartient pas » à l’opérateur français qui
> reçoit l’appel  / L’opérateur français ne termine pas l’appel et le
> transmet (transit)
>
> Comment l’opérateur français va noter/évaluer la confiance/la légitimité
> de l’appel dans le numéro ?
> Je ne sais pas si finalement c’est encore autorisé. Le client étranger
> doit ( ?) contractualiser avec un opérateur français.
> Ce point est important car de ce que nous avons expérimenté, les
> usurpations arrivaient à travers des opérateurs étrangers.
>
> Idem, j’appelle un numéro étranger qui redirige vers un numéro français :
> l’appel part sur opérateur étranger et revient..
>
> J’avoue que je ne sais pas trop où on en est sur ces cas d’usages.
> Quelqu’un sait côté frnog ?
>
> Gérald
>
>
>
> From: Adrien Versnaeyen 
> Sent: mercredi 15 mai 2024 23:08
> To: Gérald Vannier 
> Cc: Jeremy ; Daniel ;
> frnog@frnog.org
> Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?
>
> Bonjour,
>
> Pour le moment je suis plutot d'accord avec votre ressenti.
>
> En revanche je pensais que ce dispositif n'allait s'appliquer que pour des
> appels nationaux et que , part conséquent,  la vérification ne serait pas
> activée sur les intercos avec des carriers internationaux. Du coup les
> appels a destination de clients français en France sont aussi pris en
> compte ?
>
> Cdt,
>
> Adrien
>
>
> Le mer. 15 mai 2024, 09:40, Gérald Vannier  gerald.vann...@mmtt.fr>> a écrit :
> Bonjour,
> Je n'ai pas tout à fait le même sentiment.
> L'implémentation rencontre qlq soucis, mais ça reste rare et sans doute
> normal, tout le monde est encore en phase de rodage.
> Prendre un incident (important certes) et s'appuyer dessus pour dire que
> ça se déroule mal me semble abusé.
> Un point pour vous : le projet a dj un bon décalage de planning.
>
> Sur la robustesse de l'infra, nous avons choisi de ne pas faire d'appel en
> temps réel à chq appel, nous rechargeons uniquement lors de changement de
> certificats notifié par le système, cela ne doit pas écrouler la partie
> serveur. C'est vrai que si tous les opérateurs interrogent le service à chq
> appel, ça peut devenir chaud.
>
> Je vous rejoins sur l'implémentation : zones d'ombres restantes,
> interfaces déclarées mais la mise en place réelle est toujours d'actualité
> (certains opérateurs 

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

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

Bonjour,

On Thu, 16 May 2024 10:23:34 +0200
David Ponzone  wrote:

> Qui a fait la conf côté FG ?
> Quelqu’un qui sait un peu ce qu’il fait ?
> 
> Et ça marche avec un Forticlient Win ou Mac ?

J'ai des acces remote Forti depuis un Nux, mais je fais ca avec
"openfortivpn"... c'est triste a dire, mais c'est le seul client que j'ai
trouve qui me permet de me connecter ;)
Apres, pas sur du tout que ca integre tout ce que peut faire "forticlient
zero trust fabric agent VPN", mais bon, si ca peut aider:
openfortivpn.x86_64   1.21.0-2.fc39

Paul


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

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Daniel via frnog]

Bonjour. J'utilise openfortivpn sous Ubuntu 22.04 et cela fonctionne. Je 
ne connais pas le modèle Forti de l'autre extrémité.


Le 16/05/2024 à 10:20, Stéphane Rivière a écrit :

Bonjour à tous,

Puisqu'on parle beaucoup de fortigate sur la liste... un truc en 
attente depuis un an en mode pas urgent... :)


Un client très micromou héberge ses ressources 'on premises' comment 
on dit aujourd'hui. Manifestement, le grand routeur/firewall de 
l'entreprise est un fortigate (pas plus d'info sur la chose). Pour 
effectuer nos maintenances (il a un manchot sous hyper-v pour son soft 
de prod que nous administrons), on se connecte en SSH et WEB et ça roule.


Pour des tests, il a été exprimé le besoin d'un accès à son intranet 
par VPN. On a reçu un forticlient zero trust fabric agent VPN 
(7.0.7.0246 free version pour Linux), semble t-il fondé sur OpenSSL 
(aucune indication de version hormis (C) 1998-2018) quand on regarde 
les crédits. Ça se connecte du premier coup sans râler et c'est tout. 
Bien sûr ça ne marche pas. Bien sûr tous nos autres clients très 
manchots ne posent aucun souci avec OpenSSL/OpenVPN. Et on a plusieurs 
VPN pour la boite également fondés sur OpenSSL/OpenVPN qui gazouillent 
invariablement bien.


D'après quelques amis 'fortigatés', il semble que ce genre de chose 
(routeur/firewall fortigate, forticlient sur GNU/Linux (ici ubuntu 
22.04 LTS) ne tombe pas nécessairement en marche. N'ayant rien trouvé 
de décisif à l'époque dans la KB fortigate, je me demandais si vous 
aviez juste quelques conseils de base à me communiquer afin que je les 
retransmettre au service IT du client, qui est très sympa mais 
clairement en dehors de sa zone de confort (comme nous d'ailleurs, on 
n'a jamais vu un fortigate de notre vie).


Bien à vous tous,


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

RE: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Gérald Vannier]

Oui, le MAN s’applique au niveau national, mais il faut intégrer ce genre 
d’usages qui exist(ai)ent :

  *   Call center à l’étranger, branché sur un opérateur local à l’étranger qui 
envoie vers la France en passant par un opérateur français
  *   Envoi appel vers France avec des numéros sources français
 *   Le numéro source « appartient » à l’opérateur français qui reçoit 
l’appel / L’opérateur français termine l’appel
 *   Le numéro source « n’appartient pas » à l’opérateur français qui 
reçoit l’appel  / L’opérateur français ne termine pas l’appel et le transmet 
(transit)

Comment l’opérateur français va noter/évaluer la confiance/la légitimité de 
l’appel dans le numéro ?
Je ne sais pas si finalement c’est encore autorisé. Le client étranger doit ( 
?) contractualiser avec un opérateur français.
Ce point est important car de ce que nous avons expérimenté, les usurpations 
arrivaient à travers des opérateurs étrangers.

Idem, j’appelle un numéro étranger qui redirige vers un numéro français : 
l’appel part sur opérateur étranger et revient..

J’avoue que je ne sais pas trop où on en est sur ces cas d’usages.
Quelqu’un sait côté frnog ?

Gérald



From: Adrien Versnaeyen 
Sent: mercredi 15 mai 2024 23:08
To: Gérald Vannier 
Cc: Jeremy ; Daniel ; frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

Bonjour,

Pour le moment je suis plutot d'accord avec votre ressenti.

En revanche je pensais que ce dispositif n'allait s'appliquer que pour des 
appels nationaux et que , part conséquent,  la vérification ne serait pas 
activée sur les intercos avec des carriers internationaux. Du coup les appels a 
destination de clients français en France sont aussi pris en compte ?

Cdt,

Adrien


Le mer. 15 mai 2024, 09:40, Gérald Vannier 
mailto:gerald.vann...@mmtt.fr>> a écrit :
Bonjour,
Je n'ai pas tout à fait le même sentiment.
L'implémentation rencontre qlq soucis, mais ça reste rare et sans doute normal, 
tout le monde est encore en phase de rodage.
Prendre un incident (important certes) et s'appuyer dessus pour dire que ça se 
déroule mal me semble abusé.
Un point pour vous : le projet a dj un bon décalage de planning.

Sur la robustesse de l'infra, nous avons choisi de ne pas faire d'appel en 
temps réel à chq appel, nous rechargeons uniquement lors de changement de 
certificats notifié par le système, cela ne doit pas écrouler la partie 
serveur. C'est vrai que si tous les opérateurs interrogent le service à chq 
appel, ça peut devenir chaud.

Je vous rejoins sur l'implémentation : zones d'ombres restantes, interfaces 
déclarées mais la mise en place réelle est toujours d'actualité (certains 
opérateurs "importants" ont écrit ne pas être tout à fait prêts et nous sommes 
en attente de réalisation de tests sur leurs interco).
Septembre devra être scruté avec bcp d'attention puisque c'est à ce moment que 
les opérateurs pourraient couper les appels "illégitimes" au sens MAN.
Je partage vos doutes sur les appels internationaux, les derniers spoofing que 
nous avons traités arrivaient sur notre interco Orange à partir d'opérateurs 
étrangers (j'avoue que je n'ai pas tout le chemin) : les opérateurs pourront 
noter l'appel avec une note basse mais pourra-t-on couper, aura-t-on tous les 
éléments permettant de le faire à bon escient ? (et avoir une solution 
international semble compliqué : 
https://commsrisk.com/global-stir-shaken-is-dead-what-comes-next/)

La documentation gérée par l'APNF me semble très correcte, à quoi faites-vous 
référence ? Nous recevons des notification emails qd il y a des mises à jour. 
Il y a eu qlq visio pour expliquer et répondre aux questions (peu nombreuses 
ces visio, mais je n'ai pas identifié qu'elles n'étaient pas suffisantes). Les 
équipes APNF sont réactives et répondent aux questions.

Votre remarque sur le fait que le dispositif soit porté par un groupement 
d'opérateurs : bien vu ! Je n'avais pas mis le doigt dessus. Plus généralement, 
plusieurs services qui devraient relever de l'état sont confiés à l'APNF (les 
urgences...), c'est effectivement un point qui peut gratter.

A suivre... mais ça me semble aller un peu plus vitre que l'IPV6 

Gérald

-Original Message-
From: frnog-requ...@frnog.org 
mailto:frnog-requ...@frnog.org>> On Behalf Of Jeremy
Sent: mardi 14 mai 2024 23:26
To: Daniel mailto:t...@tootai.net>>; 
frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

Mais dans la réalité, l'implantation du MAN se déroule extrêmement mal autant 
coté opérateurs que coté APNF.
Pour exemple, pas plus tard que la semaine dernière, l'un des certificat racine 
permettant d'authentifier les appels n'a pas été renouvelé dans les temps par 
les équipes en charge.
Heureusement que ce n'est pas encore implémenté chez beaucoup d'opérateurs, car 
évidemment, sans certificat valide, plus d'appels tout court.

Nous sommes également plusieurs opérateurs à 

Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL

[David Ponzone]

Qui a fait la conf côté FG ?
Quelqu’un qui sait un peu ce qu’il fait ?

Et ça marche avec un Forticlient Win ou Mac ?

David

> Le 16 mai 2024 à 10:20, Stéphane Rivière  a écrit :
> 
> Bonjour à tous,
> 
> Puisqu'on parle beaucoup de fortigate sur la liste... un truc en attente 
> depuis un an en mode pas urgent... :)
> 
> Un client très micromou héberge ses ressources 'on premises' comment on dit 
> aujourd'hui. Manifestement, le grand routeur/firewall de l'entreprise est un 
> fortigate (pas plus d'info sur la chose). Pour effectuer nos maintenances (il 
> a un manchot sous hyper-v pour son soft de prod que nous administrons), on se 
> connecte en SSH et WEB et ça roule.
> 
> Pour des tests, il a été exprimé le besoin d'un accès à son intranet par VPN. 
> On a reçu un forticlient zero trust fabric agent VPN (7.0.7.0246 free version 
> pour Linux), semble t-il fondé sur OpenSSL (aucune indication de version 
> hormis (C) 1998-2018) quand on regarde les crédits. Ça se connecte du premier 
> coup sans râler et c'est tout. Bien sûr ça ne marche pas. Bien sûr tous nos 
> autres clients très manchots ne posent aucun souci avec OpenSSL/OpenVPN. Et 
> on a plusieurs VPN pour la boite également fondés sur OpenSSL/OpenVPN qui 
> gazouillent invariablement bien.
> 
> D'après quelques amis 'fortigatés', il semble que ce genre de chose 
> (routeur/firewall fortigate, forticlient sur GNU/Linux (ici ubuntu 22.04 LTS) 
> ne tombe pas nécessairement en marche. N'ayant rien trouvé de décisif à 
> l'époque dans la KB fortigate, je me demandais si vous aviez juste quelques 
> conseils de base à me communiquer afin que je les retransmettre au service IT 
> du client, qui est très sympa mais clairement en dehors de sa zone de confort 
> (comme nous d'ailleurs, on n'a jamais vu un fortigate de notre vie).
> 
> Bien à vous tous,
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Forticlient, Linux et OpenSSL

[Stéphane Rivière]

Bonjour à tous,

Puisqu'on parle beaucoup de fortigate sur la liste... un truc en attente 
depuis un an en mode pas urgent... :)


Un client très micromou héberge ses ressources 'on premises' comment on 
dit aujourd'hui. Manifestement, le grand routeur/firewall de 
l'entreprise est un fortigate (pas plus d'info sur la chose). Pour 
effectuer nos maintenances (il a un manchot sous hyper-v pour son soft 
de prod que nous administrons), on se connecte en SSH et WEB et ça roule.


Pour des tests, il a été exprimé le besoin d'un accès à son intranet par 
VPN. On a reçu un forticlient zero trust fabric agent VPN (7.0.7.0246 
free version pour Linux), semble t-il fondé sur OpenSSL (aucune 
indication de version hormis (C) 1998-2018) quand on regarde les 
crédits. Ça se connecte du premier coup sans râler et c'est tout. Bien 
sûr ça ne marche pas. Bien sûr tous nos autres clients très manchots ne 
posent aucun souci avec OpenSSL/OpenVPN. Et on a plusieurs VPN pour la 
boite également fondés sur OpenSSL/OpenVPN qui gazouillent 
invariablement bien.


D'après quelques amis 'fortigatés', il semble que ce genre de chose 
(routeur/firewall fortigate, forticlient sur GNU/Linux (ici ubuntu 22.04 
LTS) ne tombe pas nécessairement en marche. N'ayant rien trouvé de 
décisif à l'époque dans la KB fortigate, je me demandais si vous aviez 
juste quelques conseils de base à me communiquer afin que je les 
retransmettre au service IT du client, qui est très sympa mais 
clairement en dehors de sa zone de confort (comme nous d'ailleurs, on 
n'a jamais vu un fortigate de notre vie).


Bien à vous tous,

--
Stéphane Rivière
Ile d'Oléron - France

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

[FRnOG] [MISC] Régulations nouvelles (Was: Tempête solaire prévue cette nuit

[Stephane Bortzmeyer]

On Wed, May 15, 2024 at 11:26:37AM +0200,
 Gregory ROCHER  wrote 
 a message of 33 lines which said:

> On ne sait pas si une tempête solaire fera tomber l'internet.
> 
> Les (bureaucrates) EU et US y arriveront peut-être bien plus rapidement ?
> 
> https://labs.ripe.net/author/romain-bosc/sanctions-cybersec-policy-and-the-future-of-telecoms-eu-regulation-update-may-2024/

Mieux (ou pire, selon le point de vue), le décret de ce week-end :

https://www.legifrance.gouv.fr/jorf/id/JORFTEXT49523217


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

Re: [FRnOG] [TECH] Problème FortiGate

[Toussaint OTTAVI]

Le 16/05/2024 à 09:42, Florian VANNIER a écrit :
Nous avons également fait ce test en utilisant des règles SDWAN pour 
forcer sur l'un puis l'autre, même constat 


Comme l'a dit Hugues dans une des toutes premières réponses, les 
symptômes "certains trucs fonctionnent et d'autres pas" étaient 
clairement évocateurs d'un problème de MTU/MSS.


Cependant, si cela se produit chez deux opérateurs différents, c'est 
assez peu plausible.


Un des trucs que je tenterais pour lever le doute, c'est de me brancher 
en direct sur un routeur opérateur, puis sur l'autre (sans passer par le 
Forti).



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

Re: [FRnOG] [TECH] Problème FortiGate

[Toussaint OTTAVI]

Le 15/05/2024 à 15:22, Nicolas VUILLERMET a écrit :

On avait dit que le vendredi…

Should I block ICMP? 
shouldiblockicmp.com 






Bah, c'est un sujet classique de philo, notamment auprès d'un opérateur 
au goût acidulé :-) Merci à Stéphane BORTZMEYER d'avoir écrit un 
excellent article, que je cite souvent en référence :


"Un des plus gros problèmes que rencontre ICMP aujourd'hui, est que 
beaucoup de coupe-feux administrés par des ignorants bloquent la 
totalité des paquets ICMP. Cette erreur vient en général d'une mauvaise 
compréhension des problèmes de sécurité (comme le ping of death, mal 
nommé puisqu'il n'est pas spécifique à ping, ou à ICMP). Le résultat est 
que certains protocoles comme la découverte de la MTU du chemin 
fonctionnent mal (cf. RFC 4821)."


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

Re: [FRnOG] [TECH] Problème FortiGate

[Florian VANNIER]

Bonjour Toussaint,
Nous avons également fait ce test en utilisant des règles SDWAN pour forcer
sur l'un puis l'autre, même constat 

Oui changer la MTU je ne sais pas si ca va changer qqch, on verra.

Le jeu. 16 mai 2024 à 09:35, Toussaint OTTAVI  a
écrit :

>
>
> Le 15/05/2024 à 14:48, Hugues Voiturier a écrit :
> > Mais quelle excellente idée de changer la MTU de l’interface sans
> > changer la MSS,
>
> Je suppose que cela dépend des équipements. MSS = MTU moins les headers
> (IP, TCP, IPsec...). Par défaut, le matériel que j'utilise calcule la
> MSS tout seul en fonction de la MTU spécifiée. A vérifier dans la doc du
> firewall, mais s'il ne le fait pas automatiquement, si on réduit la MTU,
> il faut à priori réduire aussi la MSS à MTU - 40 (20 octets de header
> TCP + 20 octets de header IP)
>
> --
> Sinon, à ma connaissance, il n'y a pas de risque à spécifier une MTU (et
> une MSS) trop petite (à part bien sûr la fragmentation excessive, qui
> peut dégrader les performances).
>
> 1492 est la valeur classique d'une MTU sur un lien WAN PPPoE.
> Avec certains opérateurs, et en fonction de la façon dont ils collectent
> le trafic pour le ramener sur leur infra, on peut être amenés à
> descendre la MTU jusqu'à 1452 pour que le trafic passe bien.
>
> Pour ce que j'ai pu en voir, on n'a besoin de modifier la MTU que si
> l'on monte soi-même la session PPPoE. Si l'opérateur fournit un routeur,
> c'est lui qui se débrouille, et on garde une MTU normale de 1500 sur
> l'interface Ethernet.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
*Florian VANNIER*
Administrateur systèmes et réseaux
Tel : +33 6 83 10 70 09
E-mail : florian.vannie...@gmail.com

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

Re: [FRnOG] [TECH] Problème FortiGate

[Toussaint OTTAVI]

Le 15/05/2024 à 14:48, Hugues Voiturier a écrit :
Mais quelle excellente idée de changer la MTU de l’interface sans 
changer la MSS,


Je suppose que cela dépend des équipements. MSS = MTU moins les headers 
(IP, TCP, IPsec...). Par défaut, le matériel que j'utilise calcule la 
MSS tout seul en fonction de la MTU spécifiée. A vérifier dans la doc du 
firewall, mais s'il ne le fait pas automatiquement, si on réduit la MTU, 
il faut à priori réduire aussi la MSS à MTU - 40 (20 octets de header 
TCP + 20 octets de header IP)


--
Sinon, à ma connaissance, il n'y a pas de risque à spécifier une MTU (et 
une MSS) trop petite (à part bien sûr la fragmentation excessive, qui 
peut dégrader les performances).


1492 est la valeur classique d'une MTU sur un lien WAN PPPoE.
Avec certains opérateurs, et en fonction de la façon dont ils collectent 
le trafic pour le ramener sur leur infra, on peut être amenés à 
descendre la MTU jusqu'à 1452 pour que le trafic passe bien.


Pour ce que j'ai pu en voir, on n'a besoin de modifier la MTU que si 
l'on monte soi-même la session PPPoE. Si l'opérateur fournit un routeur, 
c'est lui qui se débrouille, et on garde une MTU normale de 1500 sur 
l'interface Ethernet.



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

Re: [FRnOG] [TECH] Problème FortiGate

[cedric Delaunay]

Bonjour,
Je rebondis sur ce message pour solliciter l'expertise de nombre d'entre 
vous.
Je pense que comme Florian (et moi ;) ), une part des ASR lisant cette 
liste ont à charge des systèmes divers et variés, les empêchant d'être à 
la fois experts Forti + AD + Virtu + ...


Avez vous à partager une littérature des bonnes pratiques en matière de 
config réseau/firewall où nous pourrions retrouver des notions a priori 
basiques comme :

l'ICMP se rate limite, mais ne se filtre pas
même si chaque infra a ses spécificités, ça nous éviterai sans doute des 
écueils.

Merci à tous
Cédric

Le 15/05/2024 à 15:10, Xavier Beaudouin via frnog a écrit :

Hello,


A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
enlevé ce paramètre.

On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
sur pas mal de sujets/problématiques mais on fait appel aux supports quand
on en a besoin ...


Mais quelle excellente idée de changer la MTU de l’interface sans changer
la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)


Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans les 
années
2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...

Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne se
filtre pas

Xavier


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


--
*Cédric Delaunay
*
*Service Infrastructure Systèmes et Réseaux / Direction du Système 
d'Information*

*Admin Réseau / RSSI Suppléant *
Tel. : +33 (0)2 23 23 8568
*INSA Rennes*
20 avenue des Buttes de Coêsmes
CS 70839 - 35 708 RENNES Cedex 7
www.insa-rennes.fr 
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Problème FortiGate

[Toussaint OTTAVI]

Le 15/05/2024 à 14:46, Florian VANNIER a écrit :

Nous avons 2 WAN, un chez Colt, l'autre chez Orange.


Un truc simple à faire, c'est de forcer tout le trafic sur l'un, puis 
sur l'autre. Cà permet déjà de cibler le problème : en amont (coté 
Fortinet / réseau local) ou en aval (chez un fournisseur particulier).



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

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Adrien Versnaeyen]

Bonjour,

Pour le moment je suis plutot d'accord avec votre ressenti.

En revanche je pensais que ce dispositif n'allait s'appliquer que pour des
appels nationaux et que , part conséquent,  la vérification ne serait pas
activée sur les intercos avec des carriers internationaux. Du coup les
appels a destination de clients français en France sont aussi pris en
compte ?

Cdt,

Adrien


Le mer. 15 mai 2024, 09:40, Gérald Vannier  a
écrit :

> Bonjour,
> Je n'ai pas tout à fait le même sentiment.
> L'implémentation rencontre qlq soucis, mais ça reste rare et sans doute
> normal, tout le monde est encore en phase de rodage.
> Prendre un incident (important certes) et s'appuyer dessus pour dire que
> ça se déroule mal me semble abusé.
> Un point pour vous : le projet a dj un bon décalage de planning.
>
> Sur la robustesse de l'infra, nous avons choisi de ne pas faire d'appel en
> temps réel à chq appel, nous rechargeons uniquement lors de changement de
> certificats notifié par le système, cela ne doit pas écrouler la partie
> serveur. C'est vrai que si tous les opérateurs interrogent le service à chq
> appel, ça peut devenir chaud.
>
> Je vous rejoins sur l'implémentation : zones d'ombres restantes,
> interfaces déclarées mais la mise en place réelle est toujours d'actualité
> (certains opérateurs "importants" ont écrit ne pas être tout à fait prêts
> et nous sommes en attente de réalisation de tests sur leurs interco).
> Septembre devra être scruté avec bcp d'attention puisque c'est à ce moment
> que les opérateurs pourraient couper les appels "illégitimes" au sens MAN.
> Je partage vos doutes sur les appels internationaux, les derniers spoofing
> que nous avons traités arrivaient sur notre interco Orange à partir
> d'opérateurs étrangers (j'avoue que je n'ai pas tout le chemin) : les
> opérateurs pourront noter l'appel avec une note basse mais pourra-t-on
> couper, aura-t-on tous les éléments permettant de le faire à bon escient ?
> (et avoir une solution international semble compliqué :
> https://commsrisk.com/global-stir-shaken-is-dead-what-comes-next/)
>
> La documentation gérée par l'APNF me semble très correcte, à quoi
> faites-vous référence ? Nous recevons des notification emails qd il y a des
> mises à jour. Il y a eu qlq visio pour expliquer et répondre aux questions
> (peu nombreuses ces visio, mais je n'ai pas identifié qu'elles n'étaient
> pas suffisantes). Les équipes APNF sont réactives et répondent aux
> questions.
>
> Votre remarque sur le fait que le dispositif soit porté par un groupement
> d'opérateurs : bien vu ! Je n'avais pas mis le doigt dessus. Plus
> généralement, plusieurs services qui devraient relever de l'état sont
> confiés à l'APNF (les urgences...), c'est effectivement un point qui peut
> gratter.
>
> A suivre... mais ça me semble aller un peu plus vitre que l'IPV6 
>
> Gérald
>
> -Original Message-
> From: frnog-requ...@frnog.org  On Behalf Of
> Jeremy
> Sent: mardi 14 mai 2024 23:26
> To: Daniel ; frnog@frnog.org
> Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?
>
> Mais dans la réalité, l'implantation du MAN se déroule extrêmement mal
> autant coté opérateurs que coté APNF.
> Pour exemple, pas plus tard que la semaine dernière, l'un des certificat
> racine permettant d'authentifier les appels n'a pas été renouvelé dans les
> temps par les équipes en charge.
> Heureusement que ce n'est pas encore implémenté chez beaucoup
> d'opérateurs, car évidemment, sans certificat valide, plus d'appels tout
> court.
>
> Nous sommes également plusieurs opérateurs à avoir émis de sérieux doutes
> quand à la capacité de l'infrastructure à tenir la charge des flux lié aux
> demandes d'authentification de la part des opérateurs, ou de
> l’interopérabilité avec les appels venant de l'étranger.
> Je suis également particulièrement agacé que ce dispositif soit porté par
> un groupement d'opérateur (principalement nationaux) qui ont de ce fait
> tout loisir de disposer d'informations, de statistiques et de données liés
> à leur concurrents et à leur volume d'échange d'appels, ou autrement dit,
> leur part de marché. J'ai toujours pensé que ce service aurait du être
> porté par un service d’État pour assurer une neutralité de traitement et
> une anonymisation des données. Évidemment, l'équipe dirigeante m'a assuré
> de cette discrétion mais dans les faits, je n'ai reçu aucune garantie
> technique ou juridique me permettant d'être certain que nos flux ne seront
> pas inspectés en détail. OPA, quand tu nous tiens...
>
> La documentation, l'accompagnement et la définition précise de la nouvelle
> norme MAN semblent être aux abonnés absents puisque nous sommes nombreux à
> être laissé pour compte au bord de la route. Heureusement qu'on est
> accompagné par un infogéreur expérimenté qui s'est déjà amusé sur cette
> technologie, et qui n'a fait que confirmer nos craintes.
>
> Par ailleurs, ça fait déjà plus de 1 an que cette technologie devrait être
> "obligatoire", mais la 

Re: [FRnOG] [TECH] Problème FortiGate

[Erwan David]

Le 15/05/2024 à 15:10, Xavier Beaudouin via frnog a écrit :

Hello,


A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
enlevé ce paramètre.

On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
sur pas mal de sujets/problématiques mais on fait appel aux supports quand
on en a besoin ...


Mais quelle excellente idée de changer la MTU de l’interface sans changer
la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)


Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans les 
années
2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...

Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne se
filtre pas

Xavier

Faire du réseau en bloquant l'ICMP c'est comme aller sur l'autoroute en 
mettant un écran opaque sur le pare-brise pour pas être ébloui



--
Erwan David


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

Re: [FRnOG] [TECH] Problème FortiGate

[Baptiste Chappe]

Salut,
J’ai eu un soucis similaire suite à un upgrade de forti. En 7.2 tu as une
nouvelle features qui vient checker la validité des certificats distants
même quand tu es en défaut.
*Event-Sub-Type : certificate-probe-failed »*

Ça se désactive en cli via la création d’un nouveau template…
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-How-to-allow-HTTPS-port-443-traffic-when/ta-p/200844

Baptiste

Le mer. 15 mai 2024 à 15:36, Florian VANNIER 
a écrit :

> Pour répondre à Richard KLEIN, non, nous n'en avons plus ...
> Aller si, juste un "certificate inpection" ...
> [image: image.png]
>
> Le mer. 15 mai 2024 à 15:22, Nicolas VUILLERMET 
> a écrit :
>
>> On avait dit que le vendredi…
>>
>> Should I block ICMP? 
>> shouldiblockicmp.com
>>  
>>
>> Je dirai que l’icmp se filtre et se rate-limit.
>> Ça fait parti des sujets sensibles avec le NAT, palliatif d’une pénurie
>> d’IPv4, qui est devenu un moyen de sécurité car « l’extérieur peut pas
>> joindre l’intérieur sans règle ».
>>
>> Évidemment combo avec l’ipv6… j’ai un gros client pour les JO, on a fait
>> tout propre dualstack bah… pour des raisons de « sécurité » faut virer
>> l’ipv6, en plus de faire un double nat. Ça va, le client est sympa du coup
>> on lui propose quand même un setup aux oignons! Mais j’ai mal à ma ftto
>> quoi…
>>
>> C’est pénible, mais bon en général les experts réseaux touchent pas aux
>> pare-feux et inversement, so…
>>
>> My vendredi cents,
>> Nicolas
>>
>>
>> Le 15 mai 2024 à 15:11, Xavier Beaudouin via frnog  a
>> écrit :
>>
>> Hello,
>>
>> A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
>>
>> enlevé ce paramètre.
>>
>>
>> On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
>>
>> sur pas mal de sujets/problématiques mais on fait appel aux supports quand
>>
>> on en a besoin ...
>>
>>
>> Mais quelle excellente idée de changer la MTU de l’interface sans changer
>>
>> la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)
>>
>>
>>
>> Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans
>> les années
>> 2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...
>>
>> Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne se
>> filtre pas
>>
>> Xavier
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>
> --
> *Florian VANNIER*
> Administrateur systèmes et réseaux
> Tel : +33 6 83 10 70 09
> E-mail : florian.vannie...@gmail.com
>

Re: [FRnOG] [TECH] Problème FortiGate

[Florian VANNIER]

Pour répondre à Richard KLEIN, non, nous n'en avons plus ...
Aller si, juste un "certificate inpection" ...
[image: image.png]

Le mer. 15 mai 2024 à 15:22, Nicolas VUILLERMET  a
écrit :

> On avait dit que le vendredi…
>
> Should I block ICMP? 
> shouldiblockicmp.com
>  
>
> Je dirai que l’icmp se filtre et se rate-limit.
> Ça fait parti des sujets sensibles avec le NAT, palliatif d’une pénurie
> d’IPv4, qui est devenu un moyen de sécurité car « l’extérieur peut pas
> joindre l’intérieur sans règle ».
>
> Évidemment combo avec l’ipv6… j’ai un gros client pour les JO, on a fait
> tout propre dualstack bah… pour des raisons de « sécurité » faut virer
> l’ipv6, en plus de faire un double nat. Ça va, le client est sympa du coup
> on lui propose quand même un setup aux oignons! Mais j’ai mal à ma ftto
> quoi…
>
> C’est pénible, mais bon en général les experts réseaux touchent pas aux
> pare-feux et inversement, so…
>
> My vendredi cents,
> Nicolas
>
>
> Le 15 mai 2024 à 15:11, Xavier Beaudouin via frnog  a
> écrit :
>
> Hello,
>
> A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
>
> enlevé ce paramètre.
>
>
> On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
>
> sur pas mal de sujets/problématiques mais on fait appel aux supports quand
>
> on en a besoin ...
>
>
> Mais quelle excellente idée de changer la MTU de l’interface sans changer
>
> la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)
>
>
>
> Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans
> les années
> 2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...
>
> Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne se
> filtre pas
>
> Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

-- 
*Florian VANNIER*
Administrateur systèmes et réseaux
Tel : +33 6 83 10 70 09
E-mail : florian.vannie...@gmail.com

Re: [FRnOG] [TECH] Problème FortiGate

[Nicolas VUILLERMET]

On avait dit que le vendredi…Should I block ICMP?shouldiblockicmp.comJe dirai que l’icmp se filtre et se rate-limit.Ça fait parti des sujets sensibles avec le NAT, palliatif d’une pénurie d’IPv4, qui est devenu un moyen de sécurité car « l’extérieur peut pas joindre l’intérieur sans règle ».Évidemment combo avec l’ipv6… j’ai un gros client pour les JO, on a fait tout propre dualstack bah… pour des raisons de « sécurité » faut virer l’ipv6, en plus de faire un double nat. Ça va, le client est sympa du coup on lui propose quand même un setup aux oignons! Mais j’ai mal à ma ftto quoi…C’est pénible, mais bon en général les experts réseaux touchent pas aux pare-feux et inversement, so…My vendredi cents,Nicolas Le 15 mai 2024 à 15:11, Xavier Beaudouin via frnog  a écrit :Hello,A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on aenlevé ce paramètre.On est pas expert réseau FortiNet/M365/Active Directory, on se débrouillesur pas mal de sujets/problématiques mais on fait appel aux supports quandon en a besoin ...Mais quelle excellente idée de changer la MTU de l’interface sans changerla MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans les années 2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne sefiltre pasXavier---Liste de diffusion du FRnOGhttp://www.frnog.org/

Re: [FRnOG] [TECH] Problème FortiGate

[Richard Klein]

Autre questions sur les fortigates , avez-vous du filtrage de sécurité ?
En désactivant le problème persiste?

Richard


> Le 15 mai 2024 à 15:10, Xavier Beaudouin via frnog  a écrit :
> 
> Hello,
> 
>> A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
>> enlevé ce paramètre.
>> 
>> On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
>> sur pas mal de sujets/problématiques mais on fait appel aux supports quand
>> on en a besoin ...
>> 
>>> Mais quelle excellente idée de changer la MTU de l’interface sans changer
>>> la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)
>>> 
> 
> Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans les 
> années
> 2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...
> 
> Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne se
> filtre pas
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problème FortiGate

[Xavier Beaudouin via frnog]

Hello,

> A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
> enlevé ce paramètre.
> 
> On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
> sur pas mal de sujets/problématiques mais on fait appel aux supports quand
> on en a besoin ...
> 
>> Mais quelle excellente idée de changer la MTU de l’interface sans changer
>> la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)
>>

Dans le même genre j'ai eu des soucis avec des gens qui sont restés dans les 
années 
2000, qui filtraient TOUT l'icmp... donc pMTUd : dtc... etc...

Un moment il vas falloir que ça rentre : l'ICMP se rate limite, mais ne se
filtre pas

Xavier


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

Re: [FRnOG] [TECH] Problème FortiGate

[Florian VANNIER]

A vrai dire, on avait une vieille conf qui mettait une MTU à 1492, on a
enlevé ce paramètre.

On est pas expert réseau FortiNet/M365/Active Directory, on se débrouille
sur pas mal de sujets/problématiques mais on fait appel aux supports quand
on en a besoin ...

Le mer. 15 mai 2024 à 14:48, Hugues Voiturier  a
écrit :

> Mais quelle excellente idée de changer la MTU de l’interface sans changer
> la MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)
>
>
> *Hugues Voiturier*Consultant en architecture réseau
> AS2027
>
> On 15 May 2024, at 14:46, Florian VANNIER 
> wrote:
>
> Oui, nous venons de changer la MTU sur notre interface WAN.
> On a demandé aux utilisateurs un retour sur plusieurs jours.
>
> Nous avons 2 WAN, un chez Colt, l'autre chez Orange.
>
> Le mer. 15 mai 2024 à 14:39, Toussaint OTTAVI  a
> écrit :
>
>
>
> Le 15/05/2024 à 13:46, Florian VANNIER a écrit :
>
> On va regarder et remonter cela au support de l'intégrateur pour le MSS.
>
>
> En attendant, fais simplement des essais en réduisant le MTU sur ton
> interface WAN, et regarde si çà change quelque chose.
>
> Si tu as possibilité de faire une levée de doute avec un autre lien WAN
> (routeur 4G), c'est encore mieux.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>
> --
> *Florian VANNIER*
> Administrateur systèmes et réseaux
> Tel : +33 6 83 10 70 09
> E-mail : florian.vannie...@gmail.com
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

-- 
*Florian VANNIER*
Administrateur systèmes et réseaux
Tel : +33 6 83 10 70 09
E-mail : florian.vannie...@gmail.com

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

Re: [FRnOG] [TECH] Problème FortiGate

[Hugues Voiturier]

Mais quelle excellente idée de changer la MTU de l’interface sans changer la 
MSS, c’est un super moyen de s’assurer d’avoir des problèmes :-)

Hugues Voiturier
Consultant en architecture réseau
AS2027

> On 15 May 2024, at 14:46, Florian VANNIER  wrote:
> 
> Oui, nous venons de changer la MTU sur notre interface WAN.
> On a demandé aux utilisateurs un retour sur plusieurs jours.
> 
> Nous avons 2 WAN, un chez Colt, l'autre chez Orange.
> 
> Le mer. 15 mai 2024 à 14:39, Toussaint OTTAVI  a
> écrit :
> 
>> 
>> 
>> Le 15/05/2024 à 13:46, Florian VANNIER a écrit :
>>> On va regarder et remonter cela au support de l'intégrateur pour le MSS.
>> 
>> En attendant, fais simplement des essais en réduisant le MTU sur ton
>> interface WAN, et regarde si çà change quelque chose.
>> 
>> Si tu as possibilité de faire une levée de doute avec un autre lien WAN
>> (routeur 4G), c'est encore mieux.
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> 
> 
> -- 
> *Florian VANNIER*
> Administrateur systèmes et réseaux
> Tel : +33 6 83 10 70 09
> E-mail : florian.vannie...@gmail.com
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Problème FortiGate

[Florian VANNIER]

Oui, nous venons de changer la MTU sur notre interface WAN.
On a demandé aux utilisateurs un retour sur plusieurs jours.

Nous avons 2 WAN, un chez Colt, l'autre chez Orange.

Le mer. 15 mai 2024 à 14:39, Toussaint OTTAVI  a
écrit :

>
>
> Le 15/05/2024 à 13:46, Florian VANNIER a écrit :
> > On va regarder et remonter cela au support de l'intégrateur pour le MSS.
>
> En attendant, fais simplement des essais en réduisant le MTU sur ton
> interface WAN, et regarde si çà change quelque chose.
>
> Si tu as possibilité de faire une levée de doute avec un autre lien WAN
> (routeur 4G), c'est encore mieux.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
*Florian VANNIER*
Administrateur systèmes et réseaux
Tel : +33 6 83 10 70 09
E-mail : florian.vannie...@gmail.com

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

Re: [FRnOG] [TECH] Problème FortiGate

[Toussaint OTTAVI]

Le 15/05/2024 à 13:46, Florian VANNIER a écrit :

On va regarder et remonter cela au support de l'intégrateur pour le MSS.


En attendant, fais simplement des essais en réduisant le MTU sur ton  
interface WAN, et regarde si çà change quelque chose.


Si tu as possibilité de faire une levée de doute avec un autre lien WAN 
(routeur 4G), c'est encore mieux.

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

Re: [FRnOG] [TECH] Problème FortiGate

[Nicolas VUILLERMET]

Hello,

Avant de déléguer la patate chaude à un autre niveau du support, et 
quitte à être dans une démarche technique, pour valider ou invalider la 
thèse de la mss, il est possible de forcer une valeur de mss sur 
Fortinet pour que les paquets SYN TCP soit corrigés avec une bonne 
valeur de MSS.


En gros, faire du clamping :)

Il y a quelques articles à ce sujet sur les internets, je trouve 
celui-là intéressant : 
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Setting-TCP-MSS-value/ta-p/194518


ça permettra d'avoir une réponse un peu plus rapide qu'un énième 
support, et ça permettra (si c'est bien la mss) de mettre une première 
solution palliative en place (et ça semble prendre 2 minutes :D)


My 2 cents,

Nicolas

On 15/05/2024 13:46, Florian VANNIER wrote:

Bonjour à tous
Merci pour vos réponses.
On va regarder et remonter cela au support de l'intégrateur pour le MSS.

Pour le FortiOS, nous sommes en 7.0.15
Nous sommes en Flow mode.

Pour les postes, et bien pour 2 postes sur le même LAN, même navigateur,
l'un fonctionne l'autre non et l'inverse est vrai aussi, l'un sur Edge OK,
l'autre sur Chrome NOK
On a constaté cela sur Firefox/Edge/Chrome.
Bizarrement si on fait un cURL, et bien on voit le code html ...




Le mer. 15 mai 2024 à 13:06, Vincent  a écrit :


Salut,

j'ai eu ce genre de probleme que j'ai mis de temps à débugguer. Les sites
httpS avaient une grande latence à la permiere connexion, (voir certains ne
passaient pas) en passant par notre proxy Squid. Le meme ¨PC vers le meme
site en bypassant  le SQUID yavait pas de probleme.

C'était en fait notre GW/FW Cisco Firepower qui s'amusait avec les
en-tetes TCP et les paquets étaient ensuite jetés au feu par le kernel du
client. Plus précisement:

*Symptom:
Traffic using TCP Fast Open fails when the TLS Server Identity feature is
enabled https://bst.cisco.com/quickview/bug/CSCwf05295*

Conditions:
FTD version 7.0.5
First time reported on FPR9k but can be present in other models.

TLS Server Identity feature enabled under Access Control Policy > Advanced
Settings > TLS Server Identity Discovery > Early application detection and
URL categorization - Enabled

Firepower attempting to process TCP traffic with TCP piggyback enabled.

Workaround:
Disable TLS Server Identity if TCP Fast Open is needed

Mes 20centimes

On Wed, May 15, 2024 at 12:42 PM Frederic Lubrano <
frederic.lubr...@gmail.com> wrote:


Bonjour Florian,

Je suis d'accord avec Hugues, cela me fait également penser à un souci
MSS.
Cependant, tu indiques que cela fonctionne sur un poste sans problème.
Quelle est la différence entre le poste qui fonctionne et ceux qui ne
fonctionnent pas ? Par exemple : la version du navigateur, ce poste est-il
sur le même LAN, etc. Un problème possible pourrait être décrit ici :

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Web-pages-not-loading-or-taking-too-long-to/ta-p/313958
En complément, es-tu Flow ou proxy mode ? Qulle version FortiOS ?

Fred


On Wed, May 15, 2024 at 12:13 PM Hugues Voiturier <
hugues-lis...@milkywan.fr>
wrote:


Bonjour,

La comme ça, les symptômes que tu décris me font penser a un souci de

MTU

/ MSS. Tu as regardé en ce sens ?

Hugues

Hugues Voiturier
Consultant en architecture réseau
AS2027


On 15 May 2024, at 11:59, Florian VANNIER <

florian.vannie...@gmail.com>

wrote:

Bonjour à tous,
Je me permets de jeter une bouteille à la mer car on galère pas mal

sur

un cluster de FortiGate 101F.

Pour résumer la situation, cluster sur un site distant géré par un

FortiManager au niveau du groupe.

Règles communes vers le web. (sur 8 sites distants)
Spécifiquement sur ce site, on rencontre des sites web qui tombent en

timeout (ou très très lent) ou bien des erreurs de certificat

(évidemment

les clients ont le CA Root interne). Constaté aussi sur différents
navigateurs. Sur un poste ça fonctionne, l'autre non ...






On a donc désactivé au fur et à mesure tous les éléments de sécurité

(DeepSSL, IPS, AV ...) vers le web.

Mais on rencontre toujours ces problèmes de façon sporadique :(
On a aussi fait des tests afin d'exclure un problème sur un WAN

spécifique.

Calme plat sur l'utilisation CPU/RAM ...



Notre intégrateur ainsi que le support Fortinet semblent à cours

d'idées.

Avez-vous déjà rencontré ce genre de problème ?
Une idée sur ce qui pourrait causer ce comportement ?

Merci d'avance la liste


---
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ème FortiGate

[Florian VANNIER]

Bonjour à tous
Merci pour vos réponses.
On va regarder et remonter cela au support de l'intégrateur pour le MSS.

Pour le FortiOS, nous sommes en 7.0.15
Nous sommes en Flow mode.

Pour les postes, et bien pour 2 postes sur le même LAN, même navigateur,
l'un fonctionne l'autre non et l'inverse est vrai aussi, l'un sur Edge OK,
l'autre sur Chrome NOK
On a constaté cela sur Firefox/Edge/Chrome.
Bizarrement si on fait un cURL, et bien on voit le code html ...




Le mer. 15 mai 2024 à 13:06, Vincent  a écrit :

> Salut,
>
> j'ai eu ce genre de probleme que j'ai mis de temps à débugguer. Les sites
> httpS avaient une grande latence à la permiere connexion, (voir certains ne
> passaient pas) en passant par notre proxy Squid. Le meme ¨PC vers le meme
> site en bypassant  le SQUID yavait pas de probleme.
>
> C'était en fait notre GW/FW Cisco Firepower qui s'amusait avec les
> en-tetes TCP et les paquets étaient ensuite jetés au feu par le kernel du
> client. Plus précisement:
>
> *Symptom:
> Traffic using TCP Fast Open fails when the TLS Server Identity feature is
> enabled https://bst.cisco.com/quickview/bug/CSCwf05295*
>
> Conditions:
> FTD version 7.0.5
> First time reported on FPR9k but can be present in other models.
>
> TLS Server Identity feature enabled under Access Control Policy > Advanced
> Settings > TLS Server Identity Discovery > Early application detection and
> URL categorization - Enabled
>
> Firepower attempting to process TCP traffic with TCP piggyback enabled.
>
> Workaround:
> Disable TLS Server Identity if TCP Fast Open is needed
>
> Mes 20centimes
>
> On Wed, May 15, 2024 at 12:42 PM Frederic Lubrano <
> frederic.lubr...@gmail.com> wrote:
>
>> Bonjour Florian,
>>
>> Je suis d'accord avec Hugues, cela me fait également penser à un souci
>> MSS.
>> Cependant, tu indiques que cela fonctionne sur un poste sans problème.
>> Quelle est la différence entre le poste qui fonctionne et ceux qui ne
>> fonctionnent pas ? Par exemple : la version du navigateur, ce poste est-il
>> sur le même LAN, etc. Un problème possible pourrait être décrit ici :
>>
>> https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Web-pages-not-loading-or-taking-too-long-to/ta-p/313958
>> En complément, es-tu Flow ou proxy mode ? Qulle version FortiOS ?
>>
>> Fred
>>
>>
>> On Wed, May 15, 2024 at 12:13 PM Hugues Voiturier <
>> hugues-lis...@milkywan.fr>
>> wrote:
>>
>> > Bonjour,
>> >
>> > La comme ça, les symptômes que tu décris me font penser a un souci de
>> MTU
>> > / MSS. Tu as regardé en ce sens ?
>> >
>> > Hugues
>> >
>> > Hugues Voiturier
>> > Consultant en architecture réseau
>> > AS2027
>> >
>> > > On 15 May 2024, at 11:59, Florian VANNIER <
>> florian.vannie...@gmail.com>
>> > wrote:
>> > >
>> > > Bonjour à tous,
>> > > Je me permets de jeter une bouteille à la mer car on galère pas mal
>> sur
>> > un cluster de FortiGate 101F.
>> > > Pour résumer la situation, cluster sur un site distant géré par un
>> > FortiManager au niveau du groupe.
>> > > Règles communes vers le web. (sur 8 sites distants)
>> > > Spécifiquement sur ce site, on rencontre des sites web qui tombent en
>> > timeout (ou très très lent) ou bien des erreurs de certificat
>> (évidemment
>> > les clients ont le CA Root interne). Constaté aussi sur différents
>> > navigateurs. Sur un poste ça fonctionne, l'autre non ...
>> > > 
>> > >
>> > > 
>> > >
>> > >
>> > > On a donc désactivé au fur et à mesure tous les éléments de sécurité
>> > (DeepSSL, IPS, AV ...) vers le web.
>> > > Mais on rencontre toujours ces problèmes de façon sporadique :(
>> > > On a aussi fait des tests afin d'exclure un problème sur un WAN
>> > spécifique.
>> > > Calme plat sur l'utilisation CPU/RAM ...
>> > > 
>> > >
>> > >
>> > > Notre intégrateur ainsi que le support Fortinet semblent à cours
>> d'idées.
>> > >
>> > > Avez-vous déjà rencontré ce genre de problème ?
>> > > Une idée sur ce qui pourrait causer ce comportement ?
>> > >
>> > > Merci d'avance la liste
>> >
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>> >
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

-- 
*Florian VANNIER*
Administrateur systèmes et réseaux
Tel : +33 6 83 10 70 09
E-mail : florian.vannie...@gmail.com

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

Re: [FRnOG] [TECH] Problème FortiGate

[Vincent]

Salut,

j'ai eu ce genre de probleme que j'ai mis de temps à débugguer. Les sites
httpS avaient une grande latence à la permiere connexion, (voir certains ne
passaient pas) en passant par notre proxy Squid. Le meme ¨PC vers le meme
site en bypassant  le SQUID yavait pas de probleme.

C'était en fait notre GW/FW Cisco Firepower qui s'amusait avec les en-tetes
TCP et les paquets étaient ensuite jetés au feu par le kernel du client.
Plus précisement:

*Symptom:
Traffic using TCP Fast Open fails when the TLS Server Identity feature is
enabled https://bst.cisco.com/quickview/bug/CSCwf05295*

Conditions:
FTD version 7.0.5
First time reported on FPR9k but can be present in other models.

TLS Server Identity feature enabled under Access Control Policy > Advanced
Settings > TLS Server Identity Discovery > Early application detection and
URL categorization - Enabled

Firepower attempting to process TCP traffic with TCP piggyback enabled.

Workaround:
Disable TLS Server Identity if TCP Fast Open is needed

Mes 20centimes

On Wed, May 15, 2024 at 12:42 PM Frederic Lubrano <
frederic.lubr...@gmail.com> wrote:

> Bonjour Florian,
>
> Je suis d'accord avec Hugues, cela me fait également penser à un souci MSS.
> Cependant, tu indiques que cela fonctionne sur un poste sans problème.
> Quelle est la différence entre le poste qui fonctionne et ceux qui ne
> fonctionnent pas ? Par exemple : la version du navigateur, ce poste est-il
> sur le même LAN, etc. Un problème possible pourrait être décrit ici :
>
> https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Web-pages-not-loading-or-taking-too-long-to/ta-p/313958
> En complément, es-tu Flow ou proxy mode ? Qulle version FortiOS ?
>
> Fred
>
>
> On Wed, May 15, 2024 at 12:13 PM Hugues Voiturier <
> hugues-lis...@milkywan.fr>
> wrote:
>
> > Bonjour,
> >
> > La comme ça, les symptômes que tu décris me font penser a un souci de MTU
> > / MSS. Tu as regardé en ce sens ?
> >
> > Hugues
> >
> > Hugues Voiturier
> > Consultant en architecture réseau
> > AS2027
> >
> > > On 15 May 2024, at 11:59, Florian VANNIER  >
> > wrote:
> > >
> > > Bonjour à tous,
> > > Je me permets de jeter une bouteille à la mer car on galère pas mal sur
> > un cluster de FortiGate 101F.
> > > Pour résumer la situation, cluster sur un site distant géré par un
> > FortiManager au niveau du groupe.
> > > Règles communes vers le web. (sur 8 sites distants)
> > > Spécifiquement sur ce site, on rencontre des sites web qui tombent en
> > timeout (ou très très lent) ou bien des erreurs de certificat (évidemment
> > les clients ont le CA Root interne). Constaté aussi sur différents
> > navigateurs. Sur un poste ça fonctionne, l'autre non ...
> > > 
> > >
> > > 
> > >
> > >
> > > On a donc désactivé au fur et à mesure tous les éléments de sécurité
> > (DeepSSL, IPS, AV ...) vers le web.
> > > Mais on rencontre toujours ces problèmes de façon sporadique :(
> > > On a aussi fait des tests afin d'exclure un problème sur un WAN
> > spécifique.
> > > Calme plat sur l'utilisation CPU/RAM ...
> > > 
> > >
> > >
> > > Notre intégrateur ainsi que le support Fortinet semblent à cours
> d'idées.
> > >
> > > Avez-vous déjà rencontré ce genre de problème ?
> > > Une idée sur ce qui pourrait causer ce comportement ?
> > >
> > > Merci d'avance la liste
> >
> >
> > ---
> > 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ème FortiGate

[Frederic Lubrano]

Bonjour Florian,

Je suis d'accord avec Hugues, cela me fait également penser à un souci MSS.
Cependant, tu indiques que cela fonctionne sur un poste sans problème.
Quelle est la différence entre le poste qui fonctionne et ceux qui ne
fonctionnent pas ? Par exemple : la version du navigateur, ce poste est-il
sur le même LAN, etc. Un problème possible pourrait être décrit ici :
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Web-pages-not-loading-or-taking-too-long-to/ta-p/313958
En complément, es-tu Flow ou proxy mode ? Qulle version FortiOS ?

Fred


On Wed, May 15, 2024 at 12:13 PM Hugues Voiturier 
wrote:

> Bonjour,
>
> La comme ça, les symptômes que tu décris me font penser a un souci de MTU
> / MSS. Tu as regardé en ce sens ?
>
> Hugues
>
> Hugues Voiturier
> Consultant en architecture réseau
> AS2027
>
> > On 15 May 2024, at 11:59, Florian VANNIER 
> wrote:
> >
> > Bonjour à tous,
> > Je me permets de jeter une bouteille à la mer car on galère pas mal sur
> un cluster de FortiGate 101F.
> > Pour résumer la situation, cluster sur un site distant géré par un
> FortiManager au niveau du groupe.
> > Règles communes vers le web. (sur 8 sites distants)
> > Spécifiquement sur ce site, on rencontre des sites web qui tombent en
> timeout (ou très très lent) ou bien des erreurs de certificat (évidemment
> les clients ont le CA Root interne). Constaté aussi sur différents
> navigateurs. Sur un poste ça fonctionne, l'autre non ...
> > 
> >
> > 
> >
> >
> > On a donc désactivé au fur et à mesure tous les éléments de sécurité
> (DeepSSL, IPS, AV ...) vers le web.
> > Mais on rencontre toujours ces problèmes de façon sporadique :(
> > On a aussi fait des tests afin d'exclure un problème sur un WAN
> spécifique.
> > Calme plat sur l'utilisation CPU/RAM ...
> > 
> >
> >
> > Notre intégrateur ainsi que le support Fortinet semblent à cours d'idées.
> >
> > Avez-vous déjà rencontré ce genre de problème ?
> > Une idée sur ce qui pourrait causer ce comportement ?
> >
> > Merci d'avance la liste
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Problème FortiGate

[Hugues Voiturier]

Bonjour, 

La comme ça, les symptômes que tu décris me font penser a un souci de MTU / 
MSS. Tu as regardé en ce sens ? 

Hugues

Hugues Voiturier
Consultant en architecture réseau
AS2027

> On 15 May 2024, at 11:59, Florian VANNIER  wrote:
> 
> Bonjour à tous,
> Je me permets de jeter une bouteille à la mer car on galère pas mal sur un 
> cluster de FortiGate 101F.
> Pour résumer la situation, cluster sur un site distant géré par un 
> FortiManager au niveau du groupe.
> Règles communes vers le web. (sur 8 sites distants)
> Spécifiquement sur ce site, on rencontre des sites web qui tombent en timeout 
> (ou très très lent) ou bien des erreurs de certificat (évidemment les clients 
> ont le CA Root interne). Constaté aussi sur différents navigateurs. Sur un 
> poste ça fonctionne, l'autre non ...
> 
> 
> 
> 
> 
> On a donc désactivé au fur et à mesure tous les éléments de sécurité 
> (DeepSSL, IPS, AV ...) vers le web.
> Mais on rencontre toujours ces problèmes de façon sporadique :(
> On a aussi fait des tests afin d'exclure un problème sur un WAN spécifique.
> Calme plat sur l'utilisation CPU/RAM ...
> 
> 
> 
> Notre intégrateur ainsi que le support Fortinet semblent à cours d'idées.
> 
> Avez-vous déjà rencontré ce genre de problème ? 
> Une idée sur ce qui pourrait causer ce comportement ?
> 
> Merci d'avance la liste


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

[FRnOG] [TECH] Problème FortiGate

[Florian VANNIER]

Bonjour à tous,
Je me permets de jeter une bouteille à la mer car on galère pas mal sur un
cluster de FortiGate 101F.
Pour résumer la situation, cluster sur un site distant géré par un
FortiManager au niveau du groupe.
Règles communes vers le web. (sur 8 sites distants)
Spécifiquement sur ce site, on rencontre des sites web qui tombent en
timeout (ou très très lent) ou bien des erreurs de certificat (évidemment
les clients ont le CA Root interne). Constaté aussi sur différents
navigateurs. Sur un poste ça fonctionne, l'autre non ...
[image: FRNOG (1).png]

[image: FRNOG (2).png]


On a donc désactivé au fur et à mesure tous les éléments de sécurité
(DeepSSL, IPS, AV ...) vers le web.
Mais on rencontre toujours ces problèmes de façon sporadique :(
On a aussi fait des tests afin d'exclure un problème sur un WAN spécifique.
Calme plat sur l'utilisation CPU/RAM ...
[image: FRNOG (3).png]


Notre intégrateur ainsi que le support Fortinet semblent à cours d'idées.

Avez-vous déjà rencontré ce genre de problème ?
Une idée sur ce qui pourrait causer ce comportement ?

Merci d'avance la liste

Re: [FRnOG] [ALERT] Tempête solaire prévue cette nuit

[Gregory ROCHER]

Le 10/05/2024 à 17:18, Stephane Bortzmeyer a écrit :

La précédente alerte de ce type était en 2005.

https://www.swpc.noaa.gov/news/media-advisory-noaa-forecasts-severe-solar-storm-media-availability-scheduled-friday-may-10


Bonjour

On ne sait pas si une tempête solaire fera tomber l'internet.

Les (bureaucrates) EU et US y arriveront peut-être bien plus rapidement ?

https://labs.ripe.net/author/romain-bosc/sanctions-cybersec-policy-and-the-future-of-telecoms-eu-regulation-update-may-2024/


The RIPE NCC continues to alert decision makers about the *unintended 
consequences of sanctions* on the core operations of the Internet.



It is also worth noting that both EU and US sanctions create technical and 
financial risks to our services and operations. As such, assessing and 
mitigating these risks to ensure the continued integrity and resilience of 
Internet routing is of paramount importance.




--
Grégory Rocher


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

RE: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Gérald Vannier]

Bonjour,
Je n'ai pas tout à fait le même sentiment.
L'implémentation rencontre qlq soucis, mais ça reste rare et sans doute normal, 
tout le monde est encore en phase de rodage.
Prendre un incident (important certes) et s'appuyer dessus pour dire que ça se 
déroule mal me semble abusé. 
Un point pour vous : le projet a dj un bon décalage de planning.

Sur la robustesse de l'infra, nous avons choisi de ne pas faire d'appel en 
temps réel à chq appel, nous rechargeons uniquement lors de changement de 
certificats notifié par le système, cela ne doit pas écrouler la partie 
serveur. C'est vrai que si tous les opérateurs interrogent le service à chq 
appel, ça peut devenir chaud. 

Je vous rejoins sur l'implémentation : zones d'ombres restantes, interfaces 
déclarées mais la mise en place réelle est toujours d'actualité (certains 
opérateurs "importants" ont écrit ne pas être tout à fait prêts et nous sommes 
en attente de réalisation de tests sur leurs interco). 
Septembre devra être scruté avec bcp d'attention puisque c'est à ce moment que 
les opérateurs pourraient couper les appels "illégitimes" au sens MAN.
Je partage vos doutes sur les appels internationaux, les derniers spoofing que 
nous avons traités arrivaient sur notre interco Orange à partir d'opérateurs 
étrangers (j'avoue que je n'ai pas tout le chemin) : les opérateurs pourront 
noter l'appel avec une note basse mais pourra-t-on couper, aura-t-on tous les 
éléments permettant de le faire à bon escient ? (et avoir une solution 
international semble compliqué : 
https://commsrisk.com/global-stir-shaken-is-dead-what-comes-next/)

La documentation gérée par l'APNF me semble très correcte, à quoi faites-vous 
référence ? Nous recevons des notification emails qd il y a des mises à jour. 
Il y a eu qlq visio pour expliquer et répondre aux questions (peu nombreuses 
ces visio, mais je n'ai pas identifié qu'elles n'étaient pas suffisantes). Les 
équipes APNF sont réactives et répondent aux questions.

Votre remarque sur le fait que le dispositif soit porté par un groupement 
d'opérateurs : bien vu ! Je n'avais pas mis le doigt dessus. Plus généralement, 
plusieurs services qui devraient relever de l'état sont confiés à l'APNF (les 
urgences...), c'est effectivement un point qui peut gratter.

A suivre... mais ça me semble aller un peu plus vitre que l'IPV6 

Gérald

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Jeremy
Sent: mardi 14 mai 2024 23:26
To: Daniel ; frnog@frnog.org
Subject: Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

Mais dans la réalité, l'implantation du MAN se déroule extrêmement mal autant 
coté opérateurs que coté APNF.
Pour exemple, pas plus tard que la semaine dernière, l'un des certificat racine 
permettant d'authentifier les appels n'a pas été renouvelé dans les temps par 
les équipes en charge.
Heureusement que ce n'est pas encore implémenté chez beaucoup d'opérateurs, car 
évidemment, sans certificat valide, plus d'appels tout court.

Nous sommes également plusieurs opérateurs à avoir émis de sérieux doutes quand 
à la capacité de l'infrastructure à tenir la charge des flux lié aux demandes 
d'authentification de la part des opérateurs, ou de l’interopérabilité avec les 
appels venant de l'étranger.
Je suis également particulièrement agacé que ce dispositif soit porté par un 
groupement d'opérateur (principalement nationaux) qui ont de ce fait tout 
loisir de disposer d'informations, de statistiques et de données liés à leur 
concurrents et à leur volume d'échange d'appels, ou autrement dit, leur part de 
marché. J'ai toujours pensé que ce service aurait du être porté par un service 
d’État pour assurer une neutralité de traitement et une anonymisation des 
données. Évidemment, l'équipe dirigeante m'a assuré de cette discrétion mais 
dans les faits, je n'ai reçu aucune garantie technique ou juridique me 
permettant d'être certain que nos flux ne seront pas inspectés en détail. OPA, 
quand tu nous tiens...

La documentation, l'accompagnement et la définition précise de la nouvelle 
norme MAN semblent être aux abonnés absents puisque nous sommes nombreux à être 
laissé pour compte au bord de la route. Heureusement qu'on est accompagné par 
un infogéreur expérimenté qui s'est déjà amusé sur cette technologie, et qui 
n'a fait que confirmer nos craintes.

Par ailleurs, ça fait déjà plus de 1 an que cette technologie devrait être 
"obligatoire", mais la date est continuellement repoussée pour tous les 
problèmes cités précédemment.

A noter qu'aux USA, seul 40% des appels sont désormais authentifiés, alors que 
la norme est obligatoire depuis plusieurs années déjà. Les opérateurs sont donc 
contraint de continuer à laisser passer les appels non authentifier au risque 
de ne plus rien recevoir.

En bref, j'ai le sentiment que ce sujet va être encore plus compliqué que ipv6 
à être déployé, sans compte le cout (que je considère) exorbitant pour adhérer 
à l'APNF et à la certification MAN, cout qui 

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Jeremy]

Mais dans la réalité, l'implantation du MAN se déroule extrêmement mal 
autant coté opérateurs que coté APNF.
Pour exemple, pas plus tard que la semaine dernière, l'un des certificat 
racine permettant d'authentifier les appels n'a pas été renouvelé dans 
les temps par les équipes en charge.
Heureusement que ce n'est pas encore implémenté chez beaucoup 
d'opérateurs, car évidemment, sans certificat valide, plus d'appels tout 
court.


Nous sommes également plusieurs opérateurs à avoir émis de sérieux 
doutes quand à la capacité de l'infrastructure à tenir la charge des 
flux lié aux demandes d'authentification de la part des opérateurs, ou 
de l’interopérabilité avec les appels venant de l'étranger.
Je suis également particulièrement agacé que ce dispositif soit porté 
par un groupement d'opérateur (principalement nationaux) qui ont de ce 
fait tout loisir de disposer d'informations, de statistiques et de 
données liés à leur concurrents et à leur volume d'échange d'appels, ou 
autrement dit, leur part de marché. J'ai toujours pensé que ce service 
aurait du être porté par un service d’État pour assurer une neutralité 
de traitement et une anonymisation des données. Évidemment, l'équipe 
dirigeante m'a assuré de cette discrétion mais dans les faits, je n'ai 
reçu aucune garantie technique ou juridique me permettant d'être certain 
que nos flux ne seront pas inspectés en détail. OPA, quand tu nous tiens...


La documentation, l'accompagnement et la définition précise de la 
nouvelle norme MAN semblent être aux abonnés absents puisque nous sommes 
nombreux à être laissé pour compte au bord de la route. Heureusement 
qu'on est accompagné par un infogéreur expérimenté qui s'est déjà amusé 
sur cette technologie, et qui n'a fait que confirmer nos craintes.


Par ailleurs, ça fait déjà plus de 1 an que cette technologie devrait 
être "obligatoire", mais la date est continuellement repoussée pour tous 
les problèmes cités précédemment.


A noter qu'aux USA, seul 40% des appels sont désormais authentifiés, 
alors que la norme est obligatoire depuis plusieurs années déjà. Les 
opérateurs sont donc contraint de continuer à laisser passer les appels 
non authentifier au risque de ne plus rien recevoir.


En bref, j'ai le sentiment que ce sujet va être encore plus compliqué 
que ipv6 à être déployé, sans compte le cout (que je considère) 
exorbitant pour adhérer à l'APNF et à la certification MAN, cout qui ne 
trouve, à mon sens, aucune justification vu la qualité de 
l'accompagnement et du déploiement.


Conclusion, soyez patient, et priez.

Jérémy

Le 14/05/2024 à 15:27, Daniel via frnog a écrit :
Bonjour. Aux dernières nouvelles le MAN devrait être actif 
définitivement en septembre


Le 14/05/2024 à 15:22, Hervé BRY via frnog a écrit :

Bonjour la liste,

Je viens une nouvelle fois, comme probablement nombre d'entre vous, 
d'être
victime d'un spoofing de mon numéro mobile : une personne m'appelle 
en me
disant "qui êtes vous, vous venez de m'appeler ?" alors que bien 
évidemment
je ne l'ai jamais appelé. Cela semble se multiplier ces derniers 
mois. Un
collègue m'a même fait part d'un appel qu'il a reçu usurpant le 
numéro d'un

commissariat parisien et, contactée, la police ne pouvait rien faire
d'autre que confirmer le problème !

J'avais en tête depuis une conférence FRnOG il y a quelques temps 
déjà que
la mise en place des protocoles STIR/SHAKEN et autres joyeusetés 
était en

cours en France. Savez-vous où en est le déploiement ? Y a-t-il une
échéance pour le filtrage des appels non authentifiés ?

Hervé BRY
Head of Infrastructure
Geneanet (http://www.geneanet.org)

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






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

Re: [FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Daniel via frnog]

Bonjour. Aux dernières nouvelles le MAN devrait être actif 
définitivement en septembre


Le 14/05/2024 à 15:22, Hervé BRY via frnog a écrit :

Bonjour la liste,

Je viens une nouvelle fois, comme probablement nombre d'entre vous, d'être
victime d'un spoofing de mon numéro mobile : une personne m'appelle en me
disant "qui êtes vous, vous venez de m'appeler ?" alors que bien évidemment
je ne l'ai jamais appelé. Cela semble se multiplier ces derniers mois. Un
collègue m'a même fait part d'un appel qu'il a reçu usurpant le numéro d'un
commissariat parisien et, contactée, la police ne pouvait rien faire
d'autre que confirmer le problème !

J'avais en tête depuis une conférence FRnOG il y a quelques temps déjà que
la mise en place des protocoles STIR/SHAKEN et autres joyeusetés était en
cours en France. Savez-vous où en est le déploiement ? Y a-t-il une
échéance pour le filtrage des appels non authentifiés ?

Hervé BRY
Head of Infrastructure
Geneanet (http://www.geneanet.org)

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


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

[FRnOG] [MISC] Spoofing téléphonique : où en est-on ?

[Hervé BRY via frnog]

Bonjour la liste,

Je viens une nouvelle fois, comme probablement nombre d'entre vous, d'être
victime d'un spoofing de mon numéro mobile : une personne m'appelle en me
disant "qui êtes vous, vous venez de m'appeler ?" alors que bien évidemment
je ne l'ai jamais appelé. Cela semble se multiplier ces derniers mois. Un
collègue m'a même fait part d'un appel qu'il a reçu usurpant le numéro d'un
commissariat parisien et, contactée, la police ne pouvait rien faire
d'autre que confirmer le problème !

J'avais en tête depuis une conférence FRnOG il y a quelques temps déjà que
la mise en place des protocoles STIR/SHAKEN et autres joyeusetés était en
cours en France. Savez-vous où en est le déploiement ? Y a-t-il une
échéance pour le filtrage des appels non authentifiés ?

Hervé BRY
Head of Infrastructure
Geneanet (http://www.geneanet.org)

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

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

[David Ponzone]

Il me semble que c’est la raison que j’avais évoquée pour expliquer la popup :)
Néanmoins, si on considérait l’intérêt de l’utilisateur:
-l’appel devrait passer en VoWIFI direct
-en envoyant au passage au MNO la loc GPS du téléphone si disponible (si le tel 
a un GPS et s’il est localisé), sans que l’utilisateur ait la possibilité de le 
bloquer dans la conf du téléphone

> Le 14 mai 2024 à 13:10, Arnaud FEIX  a écrit :
> 
> Bonjour,
> 
> Je propose une piste d’analyse un peu différentes
> 
> D’abord les téléphones ne remonte pas forcément les informations GPS quand on 
> passe un coup de fil.
> 
> Donc la triangulation du signal GSM reste la solution pour les opérateurs de 
> fournir la localisation du téléphone aux services d’assistance mais aussi aux 
> services de police.
> 
> Bien à vous 
> 
> Envoyé de mon iPhone
> 
>> Le 14 mai 2024 à 09:28, David Ponzone  a écrit :
>> 
>> Ok tu gagnes :)
>> 
>> C’est vrai que ce popup est perturbant.
>> Je pense que l’idée est justement qu’avec le cellulaire désactivé, la 
>> localisation sera impossible (ou du moins imparfaite/obsolète), mais la 
>> popup est clairement de trop.
>> Je viens d’essayer avec Siri, c’est pareil, 3 sec de compte-rebours, puis 
>> popup :)
>> J’avais espéré qu’un appel Siri, qui peut venir d’un mec qui s’est coupé les 
>> 2 bras avec son taille-haie, allait éviter la popup mais non….
>> 
>> Ceci dit, l’opération consistant à mettre en mode avion, puis de ré-activer 
>> seulement le WIFI, c’est pas vraiment la manip de base pour la plupart des 
>> gens.
>> Pas que ça soit compliqué, mais je pense que 95% des utilisateurs ne savent 
>> pas qu’on peut le faire.
>> 


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

[FRnOG] Re: [MISC] Re: impots.gouv.fr / AS 34177 (Celeste)

[Bertrand FRUCHET via frnog]

Bonjour,

C'est effrayant de voir à quel point certains fournisseurs de services ne sont 
pas rigoureux.

Je trouve pas normal qu'un protecteur d'infrastructures fournissant des 
services pour l'Etat se balade avec un certificat expiré.

Faut admettre que certains sites publics ont le même défaut.

Si on avait la bonne idée de faire la même bourde en province, la collectivité 
nous aurait pendue !

A+

Le 14/05/2024 à 11:01, Stephane Bortzmeyer a écrit :
> On Tue, May 14, 2024 at 10:04:42AM +0200,
>   Stephane Bortzmeyer  wrote
>   a message of 37 lines which said:
> 
>> C'était vrai il n'y a pas si longtemps mais les choses changent :
>> culture.gouv.fr
> Évidemment, si on veut troller (ce qui n'arriverait jamais ici, non),
> on peut noter que, si culture.gouv.fr valide,www.culture.gouv.fr  n'y
> arrive pas, en raison de l'alias qui pointe vers un domaine non
> signé. (La sécurité, c'est faire semblant.)
> 
> % digwww.culture.gouv.fr  A
> 
> ; <<>> DiG 9.18.24-1-Debian <<>>www.culture.gouv.fr  A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38465
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ;; QUESTION SECTION:
> ;www.culture.gouv.fr. IN A
> 
> ;; ANSWER SECTION:
> www.culture.gouv.fr.  600 IN CNAME 
> web-ing01-ext.prd.cloud.culture.fr.225284482311040.app.d.eu-west-2.cloudprotector.com.
> www.culture.gouv.fr.  600 IN RRSIG CNAME 13 4 600 (
>   20240524074123 20240424141852 54016 
> culture.gouv.fr.
>   +UYsVN4p4qFITrRVaQB3exJee0F0PmVjVFTKUfSVB7iq
>   y0UX94KZ7pspDcMWcnz2L2bvQpDn2BvIJN/oIYcdjw== )
> web-ing01-ext.prd.cloud.culture.fr.225284482311040.app.d.eu-west-2.cloudprotector.com.
>  600 IN CNAME 178-33-22-50.lb.d.eu-west-2.cloudprotector.com.
> 178-33-22-50.lb.d.eu-west-2.cloudprotector.com.   600 IN A 178.33.22.50
> 
> ;; Query time: 128 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
> ;; WHEN: Tue May 14 10:58:57 CEST 2024
> ;; MSG SIZE  rcvd: 304
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

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

Re: [FRnOG] Re: [MISC] Re: impots.gouv.fr / AS 34177 (Celeste)

[Bertrand FRUCHET via frnog]

Bonjour,

C'est effrayant de voir à quel point certains fournisseurs de services ne sont 
pas rigoureux.

Je trouve pas normal qu'un protecteur d'infrastructures fournissant des 
services pour l'Etat se balade avec un certificat expiré.

Faut admettre que certains sites publics ont le même défaut.

Si on avait la bonne idée de faire la même bourde en province, la collectivité 
nous aurait pendue !

A+

Le 14/05/2024 à 11:01, Stephane Bortzmeyer a écrit :
> On Tue, May 14, 2024 at 10:04:42AM +0200,
>   Stephane Bortzmeyer  wrote
>   a message of 37 lines which said:
> 
>> C'était vrai il n'y a pas si longtemps mais les choses changent :
>> culture.gouv.fr
> Évidemment, si on veut troller (ce qui n'arriverait jamais ici, non),
> on peut noter que, si culture.gouv.fr valide,www.culture.gouv.fr  n'y
> arrive pas, en raison de l'alias qui pointe vers un domaine non
> signé. (La sécurité, c'est faire semblant.)
> 
> % digwww.culture.gouv.fr  A
> 
> ; <<>> DiG 9.18.24-1-Debian <<>>www.culture.gouv.fr  A
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38465
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ;; QUESTION SECTION:
> ;www.culture.gouv.fr. IN A
> 
> ;; ANSWER SECTION:
> www.culture.gouv.fr.  600 IN CNAME 
> web-ing01-ext.prd.cloud.culture.fr.225284482311040.app.d.eu-west-2.cloudprotector.com.
> www.culture.gouv.fr.  600 IN RRSIG CNAME 13 4 600 (
>   20240524074123 20240424141852 54016 
> culture.gouv.fr.
>   +UYsVN4p4qFITrRVaQB3exJee0F0PmVjVFTKUfSVB7iq
>   y0UX94KZ7pspDcMWcnz2L2bvQpDn2BvIJN/oIYcdjw== )
> web-ing01-ext.prd.cloud.culture.fr.225284482311040.app.d.eu-west-2.cloudprotector.com.
>  600 IN CNAME 178-33-22-50.lb.d.eu-west-2.cloudprotector.com.
> 178-33-22-50.lb.d.eu-west-2.cloudprotector.com.   600 IN A 178.33.22.50
> 
> ;; Query time: 128 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
> ;; WHEN: Tue May 14 10:58:57 CEST 2024
> ;; MSG SIZE  rcvd: 304
> 
> 
> ---
> 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

[Arnaud FEIX]

Bonjour,

Je propose une piste d’analyse un peu différentes

D’abord les téléphones ne remonte pas forcément les informations GPS quand on 
passe un coup de fil.

Donc la triangulation du signal GSM reste la solution pour les opérateurs de 
fournir la localisation du téléphone aux services d’assistance mais aussi aux 
services de police.

Bien à vous 

Envoyé de mon iPhone

> Le 14 mai 2024 à 09:28, David Ponzone  a écrit :
> 
> Ok tu gagnes :)
> 
> C’est vrai que ce popup est perturbant.
> Je pense que l’idée est justement qu’avec le cellulaire désactivé, la 
> localisation sera impossible (ou du moins imparfaite/obsolète), mais la popup 
> est clairement de trop.
> Je viens d’essayer avec Siri, c’est pareil, 3 sec de compte-rebours, puis 
> popup :)
> J’avais espéré qu’un appel Siri, qui peut venir d’un mec qui s’est coupé les 
> 2 bras avec son taille-haie, allait éviter la popup mais non….
> 
> Ceci dit, l’opération consistant à mettre en mode avion, puis de ré-activer 
> seulement le WIFI, c’est pas vraiment la manip de base pour la plupart des 
> gens.
> Pas que ça soit compliqué, mais je pense que 95% des utilisateurs ne savent 
> pas qu’on peut le faire.
> 


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

[FRnOG] Re: [MISC] Re: impots.gouv.fr / AS 34177 (Celeste)

[Stephane Bortzmeyer]

On Tue, May 14, 2024 at 10:04:42AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 37 lines which said:

> C'était vrai il n'y a pas si longtemps mais les choses changent :

> culture.gouv.fr

Évidemment, si on veut troller (ce qui n'arriverait jamais ici, non),
on peut noter que, si culture.gouv.fr valide, www.culture.gouv.fr n'y
arrive pas, en raison de l'alias qui pointe vers un domaine non
signé. (La sécurité, c'est faire semblant.)

% dig www.culture.gouv.fr A

; <<>> DiG 9.18.24-1-Debian <<>> www.culture.gouv.fr A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38465
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.culture.gouv.fr.   IN A

;; ANSWER SECTION:
www.culture.gouv.fr.600 IN CNAME 
web-ing01-ext.prd.cloud.culture.fr.225284482311040.app.d.eu-west-2.cloudprotector.com.
www.culture.gouv.fr.600 IN RRSIG CNAME 13 4 600 (
20240524074123 20240424141852 54016 
culture.gouv.fr.
+UYsVN4p4qFITrRVaQB3exJee0F0PmVjVFTKUfSVB7iq
y0UX94KZ7pspDcMWcnz2L2bvQpDn2BvIJN/oIYcdjw== )
web-ing01-ext.prd.cloud.culture.fr.225284482311040.app.d.eu-west-2.cloudprotector.com.
 600 IN CNAME 178-33-22-50.lb.d.eu-west-2.cloudprotector.com.
178-33-22-50.lb.d.eu-west-2.cloudprotector.com. 600 IN A 178.33.22.50

;; Query time: 128 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue May 14 10:58:57 CEST 2024
;; MSG SIZE  rcvd: 304


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

[FRnOG] [MISC] Re: impots.gouv.fr / AS 34177 (Celeste)

[Stephane Bortzmeyer]

On Tue, May 14, 2024 at 08:54:24AM +0200,
 Alain Thivillon  wrote 
 a message of 36 lines which said:

> Et ce d'autant qu'aucune zone en *.gouv.fr ne semble DNSSEC-signée,
> y compris celle de l'agence qui préconise de le faire.

C'était vrai il n'y a pas si longtemps mais les choses changent :

% python gouv-dnssec.py 202403_OPENDATA_A-NomsDeDomaineEnPointFr.csv
andv.gouv.fr
antai.gouv.fr
ape.gouv.fr
ca.gouv.fr
culture.gouv.fr
cybermalveillance.gouv.fr
dgtresor.gouv.fr
douane.gouv.fr
etalab.gouv.fr
finances.gouv.fr
france-tourisme-durable.gouv.fr
francetourismedurable.gouv.fr
medad.gouv.fr
ofpra.gouv.fr
pacage.gouv.fr
17cyber.gouv.fr
1031 domains in gouv.fr, 16 signed


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

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

[David Ponzone]

> Le 14 mai 2024 à 09:43, Maximus .  a écrit :
> 
> Je ne connais pas la manip avec un Android, mais pour iPhone, si tu es 
> connecté au WiFi, l’activation du mode avion ne le coupe pas
> Il coupe juste le cellulaire+data mobile
> 

Non c’est plus compliqué, il se rappelle de la dernière configuration WIFI que 
tu avais en mode avion.
Si tu avais déjà réactivé manuellement le WIFI en étant en mode avion, il ne 
coupera plus le WIFI à chaque fois que tu passes en mode avion.

David



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

[FRnOG] [MISC] Re: impots.gouv.fr / AS 34177 (Celeste)

[Stephane Bortzmeyer]

On Tue, May 14, 2024 at 08:54:24AM +0200,
 Alain Thivillon  wrote 
 a message of 36 lines which said:

> Le choix d'un serveur "secondaire" d'une telle zone a de lourds
> impacts en termes de sécurité.

Et l'absence d'un secondaire a également de lourds impacts, come on
l'a vu hier.

> Si ns.univ-truc.fr se fait compromettre et qu'une partie des
> contribuables arrive sur un DNS puis un site malveillant, ça ne va
> pas

Cette attaque est bien sûr possible, ceci dit, je n'ai jamais vu de
cas documenté où ça s'était produit (mais, si les Russes lisent FRnog,
cela va leur donner des idées).

La solution est double :

- choisir des secondaires de confiance (c'est plus facile pour le
gouvernement, qui peut prendre d'autres serveurs gouvernementaux),

- signer.

> Et ce d'autant qu'aucune zone en *.gouv.fr ne semble DNSSEC-signée,
> y compris celle de l'agence qui préconise de le faire.

Oui, le fait que impots.gouv.fr ne soit pas signé prouve clairement
que les raisons de ne pas avoir de secondaire externe n'ont rien à
voir avec une préoccupation de sécurité.


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

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

[Erwan David]

Le 14/05/2024 à 09:27, David Ponzone a écrit :

Ok tu gagnes :)

C’est vrai que ce popup est perturbant.
Je pense que l’idée est justement qu’avec le cellulaire désactivé, la 
localisation sera impossible (ou du moins imparfaite/obsolète), mais la popup 
est clairement de trop.
Je viens d’essayer avec Siri, c’est pareil, 3 sec de compte-rebours, puis popup 
:)
J’avais espéré qu’un appel Siri, qui peut venir d’un mec qui s’est coupé les 2 
bras avec son taille-haie, allait éviter la popup mais non….

Ceci dit, l’opération consistant à mettre en mode avion, puis de ré-activer 
seulement le WIFI, c’est pas vraiment la manip de base pour la plupart des gens.
Pas que ça soit compliqué, mais je pense que 95% des utilisateurs ne savent pas 
qu’on peut le faire.



Je l'ai découvert grâce à cette discussion...


--
Erwan David


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

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

[jaxx]

> On 12 May 2024, at 12:56, Clement Cavadore  wrote:
> 
> 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. 
> 

Commerciaux (ou "réglementaires", qui est souvent l'excuse)...
Il y a fort longtemps, tout fraîchement sorti de l'imberbitude, dans une entité 
sise de part le monde, les agents avaient trouvé l'astuce pour joindre leurs 
proches de l'hexagone de passer en sauts de puces via les PABX locaux de part 
et d'autre et le lien (toléré lui) entre chancelleries et Paris... Je ne sais 
pas comment mais les opérateurs nationaux en ont eu vent et se sont fâchés tout 
rouge de se faire griller... fini les appels à coût locaux 路‍♂️ L'internet et 
à fortiori les outils de téléphonie/voip "simples" étaient encore dans son 
adolescence, autant dire que c'était pas très cool 

--
Julien “JaXX” Banchet
j...@jaxx.org


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

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

[Maximus .]

Je ne connais pas la manip avec un Android, mais pour iPhone, si tu es connecté 
au WiFi, l’activation du mode avion ne le coupe pas
Il coupe juste le cellulaire+data mobile

Effectivement peu de personnes concernés, car pas un cas très courant
Par chance la 2G porte quand même vachement bien, le téléphone s’en contente 
pour ne pas vider sa batterie, surtout en veille et avec du WiFi

Mais pour les concernés, avec ceux des zones blanches doivent connaître


> Le 14 mai 2024 à 03:27, David Ponzone  a écrit :
> 
> Ok tu gagnes :)
> 
> C’est vrai que ce popup est perturbant.
> Je pense que l’idée est justement qu’avec le cellulaire désactivé, la 
> localisation sera impossible (ou du moins imparfaite/obsolète), mais la popup 
> est clairement de trop.
> Je viens d’essayer avec Siri, c’est pareil, 3 sec de compte-rebours, puis 
> popup :)
> J’avais espéré qu’un appel Siri, qui peut venir d’un mec qui s’est coupé les 
> 2 bras avec son taille-haie, allait éviter la popup mais non….
> 
> Ceci dit, l’opération consistant à mettre en mode avion, puis de ré-activer 
> seulement le WIFI, c’est pas vraiment la manip de base pour la plupart des 
> gens.
> Pas que ça soit compliqué, mais je pense que 95% des utilisateurs ne savent 
> pas qu’on peut le faire.
> 
> 
>> Le 14 mai 2024 à 02:07, Maximus .  a écrit :
>> 
>> Car tu es à la limite de couverture
>> La VoWiFi fonctionne donc du coupe le cellulaire pour ne pas vider ta 
>> batterie en 4h, sans avoir allumé le téléphone
>> Car pour pouvoir capter cette pauvre barre de réseau et envoyer, il émet à 
>> fond la patate
>> 
>> Et donc si tu laisses le cellulaire, c’est un chargeur et une prise de 
>> courant qu'il va falloir aller cherchez pour appeler les pompiers ;)
>> 
>> 
>>> Le 13 mai 2024 à 15:44, David Ponzone  a écrit :
>>> 
>>> Ok mais pourquoi tu aurais coupé le cellulaire avant de tailler ta haie ?
>>> Ou alors, ça tient du Darwin award….
>>> 
>>> David
>>> 
 Le 13 mai 2024 à 21:16, Alarig Le Lay via frnog  a écrit :
 
 On Sun 12 May 2024 15:52:57 GMT, David Ponzone wrote:
> Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi
> Direct, mais appel vers le 112 provoque une popup pour demander si on
> veut activer le cellulaire ou passer l’appel en wifi
 
 Nickel ça, de devoir répondre à une popup quand tu veux juste appeler
 les pompiers parce que tu es en train de te faire déchiqueter le bras en
 taillant ta haie.
 
 -- 
 Alarig
 
 
 ---
 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/

[FRnOG] [MISC] Re: impots.gouv.fr / AS 34177 (Celeste)

[Stephane Bortzmeyer]

[Déplacement vers -misc car on s'éloigne de l'alerte.]

On Tue, May 14, 2024 at 08:35:06AM +0200,
 jehan procaccia INT  wrote 
 a message of 220 lines which said:

> je suis surpris qu'ils ne soient hebergés que dans un seul AS d'operateur
> privé .

C'est en effet une mauvaise idée (ceci dit, public ou privé, c'est la
diversité des AS qui compte).

> une université ou centre de recherche public ne pourrait pas etre
> secondaire !?

Ou un autre ministère. Contrairement aux boites privées, le
gouvernement peut avoir gratuitement des secondaires de
confiance. Mais ce n'est pas utilisé, probablement pour des raisons
bureaucratiques : il faudrait vingt réunions impliquant dix directeurs
pour qu'une décision soit prise. Et ce n'est de toute façon pas
utile : aucun DSI n'a jamais été viré pour un problème DNS, ils n'ont
aucune raison de faire des efforts.


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

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

[Xavier Beaudouin via frnog]

Hello,


> Ok tu gagnes :)
> 
> C’est vrai que ce popup est perturbant.
> Je pense que l’idée est justement qu’avec le cellulaire désactivé, la
> localisation sera impossible (ou du moins imparfaite/obsolète), mais la popup
> est clairement de trop.
> Je viens d’essayer avec Siri, c’est pareil, 3 sec de compte-rebours, puis 
> popup
> :)
> J’avais espéré qu’un appel Siri, qui peut venir d’un mec qui s’est coupé les 2
> bras avec son taille-haie, allait éviter la popup mais non….
> 
> Ceci dit, l’opération consistant à mettre en mode avion, puis de ré-activer
> seulement le WIFI, c’est pas vraiment la manip de base pour la plupart des
> gens.
> Pas que ça soit compliqué, mais je pense que 95% des utilisateurs ne savent 
> pas
> qu’on peut le faire.
> 

C'est un peu idiot, car bon c'est pas comme s'il n'y avais pas de GPS intégré 
dans
le téléphone. Bon peut-être que le proto VoWifi n'as pas l'option "en cas 
d'appel
d'urgence, envoie AUSSI la position GPS"...

/Xavier


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

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

[David Ponzone]

Ok tu gagnes :)

C’est vrai que ce popup est perturbant.
Je pense que l’idée est justement qu’avec le cellulaire désactivé, la 
localisation sera impossible (ou du moins imparfaite/obsolète), mais la popup 
est clairement de trop.
Je viens d’essayer avec Siri, c’est pareil, 3 sec de compte-rebours, puis popup 
:)
J’avais espéré qu’un appel Siri, qui peut venir d’un mec qui s’est coupé les 2 
bras avec son taille-haie, allait éviter la popup mais non….

Ceci dit, l’opération consistant à mettre en mode avion, puis de ré-activer 
seulement le WIFI, c’est pas vraiment la manip de base pour la plupart des gens.
Pas que ça soit compliqué, mais je pense que 95% des utilisateurs ne savent pas 
qu’on peut le faire.


> Le 14 mai 2024 à 02:07, Maximus .  a écrit :
> 
> Car tu es à la limite de couverture
> La VoWiFi fonctionne donc du coupe le cellulaire pour ne pas vider ta 
> batterie en 4h, sans avoir allumé le téléphone
> Car pour pouvoir capter cette pauvre barre de réseau et envoyer, il émet à 
> fond la patate
> 
> Et donc si tu laisses le cellulaire, c’est un chargeur et une prise de 
> courant qu'il va falloir aller cherchez pour appeler les pompiers ;)
> 
> 
>> Le 13 mai 2024 à 15:44, David Ponzone  a écrit :
>> 
>> Ok mais pourquoi tu aurais coupé le cellulaire avant de tailler ta haie ?
>> Ou alors, ça tient du Darwin award….
>> 
>> David
>> 
>>> Le 13 mai 2024 à 21:16, Alarig Le Lay via frnog  a écrit :
>>> 
>>> On Sun 12 May 2024 15:52:57 GMT, David Ponzone wrote:
 Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi
 Direct, mais appel vers le 112 provoque une popup pour demander si on
 veut activer le cellulaire ou passer l’appel en wifi
>>> 
>>> Nickel ça, de devoir répondre à une popup quand tu veux juste appeler
>>> les pompiers parce que tu es en train de te faire déchiqueter le bras en
>>> taillant ta haie.
>>> 
>>> -- 
>>> Alarig
>>> 
>>> 
>>> ---
>>> 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] impots.gouv.fr / AS 34177 (Celeste)

[David Ponzone]

> Le 14 mai 2024 à 08:35, jehan procaccia INT  a 
> écrit :
> 
> A propos des DNS impots.gouv.fr ce n'est pas le moment qu'ils se plantent, je 
> suis surpris qu'ils ne soient hebergés que dans un seul AS d'operateur privé 
> . Cela ne depend pas de la DINUM les services numeriques des impots ? une 
> université ou centre de recherche public ne pourrait pas etre secondaire !?
> 

Oui, et même on pourrait se demander pourquoi toute l’infra est hébergée par 
une société qui appartient à un fond d’investissement européen.
Ceci dit, les objets route de tous les /24 concernés sont en double dans RIPE 
DB, un vers 34177, l’autre vers 3215.
Il y a donc peut-être une infra de DR chez Orange.

David



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

Re: [FRnOG] Re: [ALERT] impots.gouv.fr / AS 34177 (Celeste)

[Laurent Barme]

Le 14/05/2024 à 08:54, Alain Thivillon a écrit :


  Et  ce d'autant qu'aucune zone en *.gouv.fr ne semble DNSSEC-signée, y
compris celle de l'agence qui préconise de le faire.



:-)))


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

Re: [FRnOG] Re: [ALERT] impots.gouv.fr / AS 34177 (Celeste)

[Alain Thivillon]

Hello,

Le mar. 14 mai 2024 à 08:35, jehan procaccia INT <
jehan.procac...@int-evry.fr> a écrit :

>
> A propos des DNS impots.gouv.fr ce n'est pas le moment qu'ils se
> plantent, je suis surpris qu'ils ne soient hebergés que dans un seul AS
> d'operateur privé . Cela ne depend pas de la DINUM les services
> numeriques des impots ? une université ou centre de recherche public ne
> pourrait pas etre secondaire !?
>

Le choix d'un serveur "secondaire" d'une telle zone a de lourds impacts en
termes de sécurité.

Si ns.univ-truc.fr se fait compromettre et qu'une partie des contribuables
arrive sur un DNS puis un site malveillant, ça ne va pas (et qu'on ne parle
pas de certificats SSL car si un tiers des requêtes DNS arrive sur un DNS
compromis, il y a de bonnes chances que Let'S Encrypt aussi).

 Et  ce d'autant qu'aucune zone en *.gouv.fr ne semble DNSSEC-signée, y
compris celle de l'agence qui préconise de le faire.

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

Re: [FRnOG] Re: [ALERT] impots.gouv.fr / AS 34177 (Celeste)

[jehan procaccia INT]

aie, on serait attaqués ... hier dans paris on a reçu de maniere 
simultané "une alerte extrement grave" à propos du perimetre des JO


on aurai pu croire a une attaque , mais apparement c'est volontaire:

https://rmcsport.bfmtv.com/jeux-olympiques/securite/alerte-extremement-grave-un-message-fr-alert-envoye-sur-des-telephones-a-paris_AN-202405130849.html

A propos des DNS impots.gouv.fr ce n'est pas le moment qu'ils se 
plantent, je suis surpris qu'ils ne soient hebergés que dans un seul AS 
d'operateur privé . Cela ne depend pas de la DINUM les services 
numeriques des impots ? une université ou centre de recherche public ne 
pourrait pas etre secondaire !?


On 13/05/2024 16:55, Stephane Bortzmeyer wrote:

On Mon, May 13, 2024 at 08:42:46AM +0200,
  Stephane Bortzmeyer  wrote
  a message of 34 lines which said:


Depuis hier soir (signalements en


), impots.gouv.fr a un
problème DNS (les résolveurs renvoient SERVFAIL). Vu que cela
n'affecte qu'une partie des opérateurs français

Le problème semble fini. L'examen des mesures Atlas n'indique pas un
problème lié à certains AS (chez les BOFS, des sondes y arrivent et
d'autres pas) donc je penche plutôt maintenant pour une attaque par
déni de service.


---
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 .]

Car tu es à la limite de couverture
La VoWiFi fonctionne donc du coupe le cellulaire pour ne pas vider ta batterie 
en 4h, sans avoir allumé le téléphone
Car pour pouvoir capter cette pauvre barre de réseau et envoyer, il émet à fond 
la patate

Et donc si tu laisses le cellulaire, c’est un chargeur et une prise de courant 
qu'il va falloir aller cherchez pour appeler les pompiers ;)


> Le 13 mai 2024 à 15:44, David Ponzone  a écrit :
> 
> Ok mais pourquoi tu aurais coupé le cellulaire avant de tailler ta haie ?
> Ou alors, ça tient du Darwin award….
> 
> David
> 
>> Le 13 mai 2024 à 21:16, Alarig Le Lay via frnog  a écrit :
>> 
>> On Sun 12 May 2024 15:52:57 GMT, David Ponzone wrote:
>>> Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi
>>> Direct, mais appel vers le 112 provoque une popup pour demander si on
>>> veut activer le cellulaire ou passer l’appel en wifi
>> 
>> Nickel ça, de devoir répondre à une popup quand tu veux juste appeler
>> les pompiers parce que tu es en train de te faire déchiqueter le bras en
>> taillant ta haie.
>> 
>> -- 
>> Alarig
>> 
>> 
>> ---
>> 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] [ALERT] Tempête solaire prévue cette nuit

[Vincent Tondellier via frnog]

Le vendredi 10 mai 2024, 17 h 31 min 25 s CEST Richard Klein a écrit :
> Il serait intéressant d’avoir des RETEX pour savoir si il y a eu des
> conséquences supposés… 

Assez éloigné de l'informatique, mais c'est (a priori) lié a la tempête solaire 
:

https://tech.slashdot.org/story/24/05/13/1648202/

https://landmarkimp.com/news/news/blog/geomagnetic-storm-affecting-gps-signals--may-2024/

> 
> > Le 10 mai 2024 à 17:18, Stephane Bortzmeyer  a écrit :
> > La précédente alerte de ce type était en 2005.
> > 
> > https://www.swpc.noaa.gov/news/media-advisory-noaa-forecasts-severe-solar-
> > storm-media-availability-scheduled-friday-may-10




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

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

[David Ponzone]

Ok mais pourquoi tu aurais coupé le cellulaire avant de tailler ta haie ?
Ou alors, ça tient du Darwin award….

David

> Le 13 mai 2024 à 21:16, Alarig Le Lay via frnog  a écrit :
> 
> On Sun 12 May 2024 15:52:57 GMT, David Ponzone wrote:
>> Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi
>> Direct, mais appel vers le 112 provoque une popup pour demander si on
>> veut activer le cellulaire ou passer l’appel en wifi
> 
> Nickel ça, de devoir répondre à une popup quand tu veux juste appeler
> les pompiers parce que tu es en train de te faire déchiqueter le bras en
> taillant ta haie.
> 
> -- 
> Alarig
> 
> 
> ---
> 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

[Alarig Le Lay via frnog]

On Sun 12 May 2024 15:52:57 GMT, David Ponzone wrote:
> Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi
> Direct, mais appel vers le 112 provoque une popup pour demander si on
> veut activer le cellulaire ou passer l’appel en wifi

Nickel ça, de devoir répondre à une popup quand tu veux juste appeler
les pompiers parce que tu es en train de te faire déchiqueter le bras en
taillant ta haie.

-- 
Alarig


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

[FRnOG] Re: [ALERT] impots.gouv.fr / AS 34177 (Celeste)

[Stephane Bortzmeyer]

On Mon, May 13, 2024 at 08:42:46AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 34 lines which said:

> Depuis hier soir (signalements en
> 
> 
> ), impots.gouv.fr a un
> problème DNS (les résolveurs renvoient SERVFAIL). Vu que cela
> n'affecte qu'une partie des opérateurs français

Le problème semble fini. L'examen des mesures Atlas n'indique pas un
problème lié à certains AS (chez les BOFS, des sondes y arrivent et
d'autres pas) donc je penche plutôt maintenant pour une attaque par
déni de service.


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

[FRnOG] [ALERT] impots.gouv.fr / AS 34177 (Celeste)

[Stephane Bortzmeyer]

Depuis hier soir (signalements en


), impots.gouv.fr a un
problème DNS (les résolveurs renvoient SERVFAIL). Vu que cela
n'affecte qu'une partie des opérateurs français (cf. test avec les
sondes Atlas plus bas), vu que les EDE (Extended DNS Error
) disent "OPT
[{Extended_DNS_Error: NO_REACHABLE_AUTHORITY: delegation
impots.gouv.fr}", on peut supposer un problème de routage, les
(seulement) deux serveurs faisant autorité étant dans le même AS,
34177.

Vu par les sondes Atlas en France :

% blaeu-resolve --requested 100 --country FR --ipv4 --type  SOA  impots.gouv.fr 
[dns0.dgfip.finances.gouv.fr. hostmaster.dgfip.finances.gouv.fr. 2024050700 
14400] : 41 occurrences 
[] : 2 occurrences 
[ERROR: SERVFAIL] : 35 occurrences 
Test #71356328 done at 2024-05-13T06:29:04Z



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

Re: [FRnOG] [ALERT] Tempête solaire prévue cette nuit

[Stéphane Tsacas]

Deux resources bien pratiques :
https://www.spaceweatherlive.com/fr/activite-solaire/eruptions-solaires.html
avec la carte et en « temps réel » : https://twitter.com/_SpaceWeather_

s.

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

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

[David Ponzone]

J’ai pas bien compris la question :)

Si c’est un appel cellulaire, il me semble que la position de la BTS est 
utilisée par le MNO pour traduire le numéro.
En VoWIFI, je suppose que le MNO va utiliser la dernière position connue dans 
le HLR.

En fixe/SIP, c’est l’opérateur qui traduit parce qu’il sait où est son client.

David


> Le 12 mai 2024 à 18:14, l...@netc.fr a écrit :
> 
> ce qui m'interpele c'est comment les appels d'urgence sont localisés, à la 
> fois pour anticiper dans le traitement de la situation, mais également pour 
> transférer l'appel vers le centre local correspondant.. avec "juste du sip" 
> je vois pas comment c'est réalisé.. Notamment sur les appareils VoLTE, qui ne 
> sont ni des iphone, ni basés sur android (ex librem).
> 
> alors que normalement, juste une triangu, ca passait..
> 
> 
>> From: David Ponzone 
>> To: Xavier Claude 
>> Subject: Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger
>> Date: 12/05/2024 15:52:57 Europe/Paris
>> Cc: FRNOG 
>> 
>> Vérifié à l’instant:
>> 
>> Wifi et cellulaire activés : appel vers le 112 passe en cellulaire
>> 
>> Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi 
>> Direct, mais appel vers le 112 provoque une popup pour demander si on veut 
>> activer le cellulaire ou passer l’appel en wifi
>> 
>> David Ponzone
>> 
>> 
>> 
>> > Le 12 mai 2024 à 13:15, Xavier Claude  a écrit :
>> > 
>> > 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 

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

[lm2 via frnog]

ce qui m'interpele c'est comment les appels d'urgence sont localisés, à la fois 
pour anticiper dans le traitement de la situation, mais également pour 
transférer l'appel vers le centre local correspondant.. avec "juste du sip" je 
vois pas comment c'est réalisé.. Notamment sur les appareils VoLTE, qui ne sont 
ni des iphone, ni basés sur android (ex librem).



alors que normalement, juste une triangu, ca passait..



From: David Ponzone 
To: Xavier Claude 
Subject: Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger
Date: 12/05/2024 15:52:57 Europe/Paris
Cc: FRNOG 

Vérifié à l’instant:

Wifi et cellulaire activés : appel vers le 112 passe en cellulaire

Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi Direct, 
mais appel vers le 112 provoque une popup pour demander si on veut activer le 
cellulaire ou passer l’appel en wifi

David Ponzone



> Le 12 mai 2024 à 13:15, Xavier Claude  a écrit :
> 
> 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/


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

Re: [FRnOG] [MISC] JO et Accès datacenter Parisiens

[Jacques Belin]

Le dimanche 12 mai 2024 10:22:11,
Yann Autissier via frnog  a écrit:

> TH2 => sans restriction

Par contre, pour TH1 (rue des jeuneurs), il faudra juste éviter d'y
aller les matinées des 10 et 11 août, car ça sera en plein de la zone
rouge concernée par les deux épreuves de marathon...


A+ Jacques.
-- 
Le dernier Homme connecté sur le Net regardait d'anciens sites Web.
"Vous avez du courrier" apparut sur l'écran...
--- adapté d'une courte histoire de Fredric Brown


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

Re: [FRnOG] [MISC] JO et Accès datacenter Parisiens

[Jacques Belin]

Le dimanche 12 mai 2024 11:00:52,
"Paul Rolland (???·???)"  a écrit:


> Ca semble quand meme concerner qq datacenters qq'un a deja recu une
> communication de leur part ? Ou bien ils laissent gentiment leurs clients
> se debrouiller pour trouver une solution ?

Pour Equinix, je t'assure qu'ils font des trucs : Ils m'ont envoyé il y
a deux jours un mail pour m'inciter à prendre un badge permament. 

Alors que j'en ai déjà un...

Ou alors, ils veulent qu'on les change, car ils ont enfin pensé à y
marquer dessus l'adresse de leurs datacenters parisiens...

Parce que pour l'instant, ça va être folklo en arrivant dans la zone
bleue de Saint-denis de montrer aux flics un badge où il n'y a qu'un
logo sans le nom de la boite, en leur disant qu'il permet d'accéder à
l'immense bâtiment totalement anonyme qui est au bout de la rue

Et les flics, ça change de secteur à chaque service, faudra pas trop espérer
avoir des améliorations au bout de quelques jours...


A+ Jacques.
-- 
Le dernier Homme connecté sur le Net regardait d'anciens sites Web.
"Vous avez du courrier" apparut sur l'écran...
--- adapté d'une courte histoire de Fredric Brown


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

Re: [FRnOG] [MISC] JO et Accès datacenter Parisiens

[Jacques Belin]

Le dimanche 12 mai 2024 12:59:07,
"Paul Rolland (???·???)"  a écrit:

> 
> > https://www.prefecturedepolice.interieur.gouv.fr/mission/des-jeux-securises-pour-tous/les-perimetres-de-securite-autour-des-sites-olympiques-et-paralympiques
> > Sauf que là, le périmètre réglementé est bleu, et pas orange comme sur:
> 
> Et qui fournit des PDF, qui ne permettent meme pas de vraiment zoomer pour
> voir le detail des rues... 

Il faut aller sur le site anticiperlesjeux (vous savez le site dont ils
font la pub avec les grandes affiches qui vous incitent fortement à
rester chez vous en télétravail...) pour avoir les détails de fermetures,
zone par zone et heure par heure (important pour les épreuves de
marathon et de cyclisme, ou la moitié de Paris sera coupé en deux
pendant six ou huit heures) :

https://anticiperlesjeux.gouv.fr/carte-interactive-impacts-deplacements-ile-france



A+ Jacques.
-- 
Le dernier Homme connecté sur le Net regardait d'anciens sites Web.
"Vous avez du courrier" apparut sur l'écran...
--- adapté d'une courte histoire de Fredric Brown


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

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

[lm2 via frnog]

justement, free.


From: David Ponzone 
To: l...@netc.fr
Subject: Re: [FRnOG] [TECH] VoWifi : appels depuis l'étranger
Date: 12/05/2024 16:17:57 Europe/Paris
Cc: clem...@cavadore.net;
   Xavier Claude ;
   FRNOG 

Et donc tu gardes qui ?

Parce qu’officiellement, je ne trouve que Free qui l’autorise (depuis 1 an à 
priori).

David

> Le 12 mai 2024 à 14:04, l...@netc.fr a écrit :
> 
> 
> 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 

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

[David Ponzone]

Et donc tu gardes qui ?

Parce qu’officiellement, je ne trouve que Free qui l’autorise (depuis 1 an à 
priori).

David

> Le 12 mai 2024 à 14:04, l...@netc.fr a écrit :
> 
> 
> 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 VoWiFi quand tu as un problème
>> > > > > de couverture local. L’opérateur n’est pas/plus capable de te
>> > > > > 

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

[David Ponzone]

Vérifié à l’instant:

Wifi et cellulaire activés : appel vers le 112 passe en cellulaire

Mode avion mais WIFI actif: appel vers un numéro normal passe en Wi-Fi Direct, 
mais appel vers le 112 provoque une popup pour demander si on veut activer le 
cellulaire ou passer l’appel en wifi

David Ponzone



> Le 12 mai 2024 à 13:15, Xavier Claude  a écrit :
> 
> 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

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

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] [MISC] JO et Accès datacenter Parisiens

[David Ponzone]

> Le 12 mai 2024 à 12:59, Paul Rolland (ポール・ロラン)  a écrit :
> 
>> Et là, c’est l’inconnu sur le niveau de circulation.
> 
> Tu manques d'imagination ? Penses au pire, encore pire, encore un peu...
> la, tu y es presque... a ce qu'on aura surement de mieux... 
> 

Pas gave, mes pannes tombent toujours la nuit et jamais l’été (je murmure à 
l’oreille des machines avant de partir).

David



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