RE: [FRnOG] [MISC] Services d'urgence et assimile: IPv4 gratuites en aide

[Michel Py]

> thomas brenac a écrit :
> Je peux mettre gratuitement (et pour le temps necessaire)  a disposition pour 
> toute societe de la liste jusqu'a
> deux /22 (divisibles en /24) dans le cadre du support a la lutte contre la 
> pandemie actuelle. Service de secours,
> service d'urgence, de medecine etc etc. Pour etre clair pas pour du VPN de 
> client traditionnel. Gratos si utile.

Vu que c'est pas la première fois que çà arrive, et que c'est la 2ème 
tentative, je demande à Philippe de faire quelque chose.
Les brokers d'IP qui viennent faire de la pub gratos sur la liste, çà commence 
à me gonfler.
Le coronavirus qui va entrainer la fin de l'Internet, tout le monde y croit en 
particulier 01 et JDD, mais pas cette liste.

On en a rien à foutre de tes blocs gratuits pour 3 mois. Cette liste, c'est pas 
pour les vendeurs de pompes usées qui veulent se faire mousser en se présentant 
comme le sauveur de l'Internet Français en fournissant des adresses gratuites.

Philippe, fais quelque chose s'il te plait. Merci,

Michel.


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

[FRnOG] RE: [FRoNG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

Comme par hasard, aujourd'hui les huiles ont décidé qu'il allait falloir 
envoyer des gens travailler à la maison.
On n'est pas dans la baie donc c'est pas (encore) le binzzz, mais je le vois 
arriver.
Pour le sport, j'ai essayé :

Client : Windows 7
VPN : Microsoft SSTP (intégré dans Windows) vers serveur M$.
Softphone : Microsip https://www.microsip.org/
Antivirus : Symantec, désactivé.

Le VPN de Microsoft, contrairement à ce que beaucoup en disent, çà marche très 
bien pour moi.
Le softphone j'en ai volontairement pris un qui n'était pas dans ta liste.
Dans Microsip on peut choisir l'adresse, si on l'ouvre après que le VPN soit 
connecté. Naturellement, j'ai choisi celle du VPN, pas du LAN.

Résultat : çà ne marche pas. Quelle surprise, hein.
Cà se connecte à Astérisk, on peut appeler de l'intérieur vers le poste VPN, 
pas l'inverse.
Je n'ai pas poussé l'expérience plus loin.

>> Michel Py a écrit :
>> Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être 
>> le coup de dépenser
>> 50 balles pour essayer un téléphone de bureau qui a support de VPN. Je 
>> promets pas que çà
>> marcherait mieux (j'ai jamais essayé), mais les Grandstream ont une option 
>> OpenVPN.

> Guillaume LUCAS a écrit :
> C'est un point qui revient souvent alors je vais répondre.
> 1) Je ne pense pas qu'on ait les épaules assez solides pour gérer de la 
> diffusion de SNOM. En termes
> d'inventaire, de suivi, etc. 2) Nous distribuons des 06 à nos VIP 
> (c'est-à-dire des gens reponsables
>  comme on nous le vend à longueur de journée). Nous constatons une 
> corrélation entre chaque date de
> sortie du nouvel iPhone/Samsung et un taux de casse plus élevé des écrans des 
> 06 déjà en circulation.

J'ai les mêmes à la maison !!

> Corrélation ne fait pas causalité, bien entendu. Peut-être que l'excitation
> procurée par la sortie d'un tel joujou rend les mains moites. Mais c'est 
> fâcheux.

Mouais moi je crois que quand il y a de la fumée, il y a généralement du feu. 
Le coup de la batterie qui ne charge plus juste après que le nouveau modèle de 
{Samsung|iPhone|etc} soit sorti, c'est pas la première fois qu'on me le fait.

Mon modèle de base c'est le GXP2130v2 :
http://www.grandstream.com/products/ip-voice-telephony/high-end-ip-phones/product/gxp2130-v2
Très content, 1 seul DOA sur plusieurs centaines, aucune emmerde depuis 3 ans. 
Par les quantités qui nous intéressent toi et moi (des centaines), on les 
trouves à 50 balles si on sait s'y prendre.
Je commence mon programme pilote demain; çà va aller vers un serveur OpenVPN, 
j'ai pas encore testé cette config particulière mais j'écrirai une MAJ.

Michel.


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

Re: [FRnOG] [TECH] Vérifier que le trafic IPsec est bien autorisé

[Jonathan Leroy - Inikup via frnog]

Le lun. 16 mars 2020 à 18:48, Richard Klein  a écrit :
> Les lb pro possèdent un client serveur vpn
> L'un des deux ne seraient pas actif ?
> Tu as tenté de placer ton serveur vpn dans la dmz quelques minutes histoire 
> de tester ?

Pas de VPN actif sur la box.
J'ai finalement trouvé la cause du problème : un firewall sur le poste
client qui a du mal avec la fragmentation UDP. Dès que le client
désactive son AV, ça passe.


-- 
Jonathan Leroy


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

Re: [FRnOG] [TECH] Upgrade fortinet erreur enregistrement support

[Ludovic RAMOSFILIPE]

Si je ne dit pas de bêtise il te faut un compte avec licence/support pour
télécharger


Le mar. 17 mars 2020 à 22:43, Sébastien 65  a écrit :

> Bonsoir,
>
> J'essaye désespérément de m'enregistrer sur le site support fortinet afin
> de pouvoir regarder la mise à jour d'un 60E FortiOS v6.0.1 build0131.
>
> Impossible de m'enregistrer car j'ai une erreur à la con "Something wrong.
> Please try again later"... Après une dizaine d’essais je laisse tomber !
>
> Est-ce que le firmware est librement téléchargeable sur leur site ou
> faut-il passer par l'achat d'une licence upgrade ?
>
> Merci
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [MISC] Services d'urgence et assimile: IPv4 gratuites en aide

[thomas brenac via frnog]

Hello la liste,

Je peux mettre gratuitement (et pour le temps necessaire)  a disposition 
pour toute societe de la liste jusqu'a deux /22 (divisibles en /24) dans 
le cadre du support a la lutte contre la pandemie actuelle. Service de 
secours, service d'urgence, de medecine etc etc. Pour etre clair pas 
pour du VPN de client traditionnel.Gratos si utile.


Me contacter en MP pour ce sujet.

Thomas BRENAC
https://brenac.eu
 +33686263575


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

Re: [FRnOG] [TECH] IPs blacklistées sur certains sites/matériels

[thomas brenac via frnog]

Les filtres geolocalisation sont en effet de moins en moins fiables, 
IMHO, les echanges inter RIR etant de plus en plus actif (meme si LACNIC 
vient de dire 'non' a l'inter RIR de peur, certainement, de se faire 
piller, les IP etant las-bas entre 5-10$,). Je pense aussi a une 
certaine tendance a monnetiser la donnee geoloc pour du ciblage 
marketing, du coup la donnee 'gratuite' est mal suivie...


Pour simplifier le seul assez fiable, et encore son taux de 
rafraichissement est aleatoire est Maxmind, qui a un lien avec RIPE pour 
cela (comme on peux le voir sur estat)


Ton route objet est a priori tres recent (10/3/20), pour un transfert 
plus ancien (5/4/19). Sans route et sans annonce les bases de donnees de 
geoloc, deja pas rapides, ne font rien.


Donc deja quand on transfert, ce que je conseille est de rapidement 
faire un objet et annoncer (bis repetitas). Deja cela evite les 
squatteurs et accessoirement cela initialise la geoloc poussive.


Ensuite en effet pour accelerer le processus, faut faire un petit mot 
doux  quelques bases de geoloc.


Avec le temps cela disparait, sauf les 'institutions institutionelles' 
qui n'ont de rien de dynamique.


Le probleme est plus embettant quand le subnet est sur une droplist, ou 
pire vient du yemen ou d'iran, ou twitter et google bloquent sans rien 
vouloir savoir.


Mais comme c'est moi que vous l'ai vendu, tu peux me contacter hors 
liste, j'accompagne, meme si cela avait bien ete explique chez toi. :)


Thomas BRENAC

https://brenac.eu




On 17/03/2020 12:20, David Ponzone wrote:

Je te souhaite bon courage :)
J’ai déjà vu le cas d’un bloc venant du Japon et 2 ans après son transfert au 
RIPE, certaines banques (suisses) continuent de la refuser pour des accès VPN 
car hors-EU.
Après, c’est marginal. Pour le reste, ça se résorbe naturellement. Le problème 
est que certains ne mettent à jour leurs filtres géo que rarement.
Tu peux essayer d’ajouter ta géolocalisation dans le RIPE, mais je suis pas sûr 
que ça aide beaucoup.


Le 17 mars 2020 à 12:13, g.roux via frnog  a écrit :

Bonjour,
Nous avons racheté un pool d'IP auprès du RIPE : 185.194.120.0/22.
Au niveau des RIRs, tout est ok. Au niveau de la plupart des sites de
réputation, de géolocalisation, ont est ok.
Cependant certains sites de geoIP continuent de nous localiser en
Ukraine (ancienne localisation), et plusieurs clients nous remontent des
sites inaccessibles avec ce pool (en changeant l'IP publique, ça
fonctionne).
Quelqu'un sait m'aiguiller ? Quelqu'un chez un fabricant qui voit que la
base est pas à jour ?
Je contacte les hebergeurs au cas par cas mais c'est un peu fastidieux
donc je vous sollicite pour un peu d'aide :)
Merci d'avance,
[1] [2] [3] [4]
Guillaume ROUX
Ingénieur Réseau - Backbone & Edge
Responsable technique MER/Support
g.r...@netcom-group.fr
+33 (0)1.71.29.27.31
Hotline +33 (0)8.26.10.56.05

Links:
--
[1] https://www.facebook.com/pages/Netcom-Group/307065979420252
[2] https://twitter.com/netcom_group
[3] https://fr.linkedin.com/company/netcom-group
[4] https://www.youtube.com/user/NetcomGroupTV
---
Liste de diffusion du FRnOG
http://www.frnog.org/


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


--
Thomas BRENAC
+33686263575


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

[FRnOG] [TECH] Upgrade fortinet erreur enregistrement support

[Sébastien 65]

Bonsoir,

J'essaye désespérément de m'enregistrer sur le site support fortinet afin de 
pouvoir regarder la mise à jour d'un 60E FortiOS v6.0.1 build0131.

Impossible de m'enregistrer car j'ai une erreur à la con "Something wrong. 
Please try again later"... Après une dizaine d’essais je laisse tomber !

Est-ce que le firmware est librement téléchargeable sur leur site ou faut-il 
passer par l'achat d'une licence upgrade ?

Merci

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 

> Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être 
> le coup de dépenser 50 balles pour essayer un téléphone de bureau qui a 
> support de VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), 
> mais les Grandstream ont une option OpenVPN.

C'est un point qui revient souvent alors je vais répondre.

1) Je ne pense pas qu'on ait les épaules assez solides pour gérer de la 
diffusion de SNOM. En termes d'inventaire, de suivi, etc.
2) Nous distribuons des 06 à nos VIP (c'est-à-dire des gens reponsables 
comme on nous le vend à longueur de journée). Nous constatons une corrélation 
entre chaque date de sortie du nouvel iPhone/Samsung et un taux de casse plus 
élevé des écrans des 06 déjà en circulation. Corrélation ne fait pas causalité, 
bien entendu. Peut-être que l'excitation procurée par la sortie d'un tel joujou 
rend les mains moites. Mais c'est fâcheux.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 22:04, Michel Py a écrit :

[...]

C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le 
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.

Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient 
ce genre de limitation; c'est bizarre que personne n'ait pensé a çà avant.

Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être le 
coup de dépenser 50 balles pour essayer un téléphone de bureau qui a support de 
VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), mais les 
Grandstream ont une option OpenVPN.


Les SNOM également et avec ces deux fabricants je n'ai *jamais* eu de 
problème en utilisant leur VPN. Ceci dit avec les Softphones non plus ...


Ce que je ferais:

. tester avec csipsimple qui est très stable

. passer en IAX avec Zoiper. IAX c'est bien ;)

PS: mon dialplan qui sauve mes journées:
...
same = n,Dial(PJSIP/xxx@mytrunk,,)
same = n,ExecIf($["${DIALSTATUS}" = "CHANUNAVAIL" | "${DIALSTATUS}" = 
"CONGESTION"]?Dial(IAX2/mytrunk/xxx,,))

...

--
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] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

> Guillaume LUCAS a écrit :
> Perso, je ne veux pas qu'Asterisk soit relais RTP, car il
> faut dimensionner le serveur pour la montée en chargée

C'est ce que je fais avec 500 utilisateurs, avec une bécane pas trop pourrie 
aucun problème.
Je me rappelle plus trop l'option, mais j'ai choisi de garder Asterisk entre 
les postes. Un flux audio, même HD, c'est pas grand-chose ces jours-ci.

>> Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il 
>> est lié
>> à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur VPN lui 
>> envoie.

> C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le 
> choix de
> l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.

Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient 
ce genre de limitation; c'est bizarre que personne n'ait pensé a çà avant.

Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être le 
coup de dépenser 50 balles pour essayer un téléphone de bureau qui a support de 
VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), mais les 
Grandstream ont une option OpenVPN.

Michel.



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Raphael Mazelier]

Cela me ramène quelque année en arrière. Et cela me rappelle aussi 
pourquoi on posait des box chez les clients.  (coucou les ex-B3G, 
Ipnotic, Paritel)


Faire de la Voip si tu ne maîtrise pas le lan client c'est possible mais 
source d'emmerdements infinis.


Comme déjà mentionné il faut absolument que ton RTP soit in path de ton 
asterisk (rtp proxy , whatever).


Au final je me demande si tu ne t’embête pas plus avec un vpn que sans. 
(alors surtout un ASA qui si tu n'y prend pas garde va joyeusement faire 
n'importe quoi avec tes paquets SIP, a se demander d'ailleurs pourquoi 
on a crée des ALGs SIP pour qu'au final la 1ere chose à faire c'est de 
les désactiver).


En public ICE/STUN/TURN peuvent définitivement aider. Après si pour X 
raison tu es obligé d'utiliser un VPN, bin bon courage. Wireshark va 
être ton ami proche des prochains jours.


Good luck.

--

Raphael Mazelier

On 17/03/2020 18:43, Guillaume LUCAS wrote:

- Mail original -
De: "frnog" 
Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce 
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.


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



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Ouki, merci.

Du coup, je retiens :
  * nat=yes n'a pas fonctionné, c'est très bizarre, donc sortir tcpdump ;
  * session-timers=refuse n'a pas fonctionné, c'est bizarre, preuve 
supplémentaire d'un filtrage ;
  * monter un autre VPN vite-fait ;
  * désactiver RTP learning pour voir. J'ai déjà vu un interlocuteur envoyer 
son RTP à Asterisk et pas l'autre, du coup, ça ne fonctionnait pas.


- Mail original -
De: "David Ponzone" 
À: "Guillaume LUCAS" 
Cc: "frnog" 
Envoyé: Mardi 17 Mars 2020 20:55:48
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Faut fouiner, je connais pas assez Asterisk et encore moins les versions 
récentes. Et côté doc, c’est comment dire….

> Le 17 mars 2020 à 20:53, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>>> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> 
>> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
>> localnet.
> 
> Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
> N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce 
> scénario que j'ai pas compris.
> 
> 
> ---
> 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] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Faut fouiner, je connais pas assez Asterisk et encore moins les versions 
récentes. Et côté doc, c’est comment dire….

> Le 17 mars 2020 à 20:53, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>>> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> 
>> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
>> localnet.
> 
> Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
> N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce 
> scénario que j'ai pas compris.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> > Qu'est-ce qui peut expliquer les échecs de l'autolearn ?

> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
> localnet.

Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce scénario 
que j'ai pas compris.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> Le 17 mars 2020 à 20:46, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
> De: "David Ponzone" 
> 
>> Ah non, en autolearn, il est forcément dans le path RTP.
> 
> Attends, attends, attends.
> 
> Il se passe quoi quand l'autolearn marche que pour l'un des deux 
> interlocuteurs ? Ça donnerait pas une conversation où un seule interlocuteur 
> entend l'autre, par hasard ?

C’est pas gênant: autolean pour un des 2, pas pour l’autre, mais relais RTP 
forcément.

> Genre là, dans le journal, je vois un Strict learning complete pour un 
> interlocuteur sur les deux (on va le nommer Toto). Pour l'autre interlocuteur 
> (Titi), le learning voit qu'une IP 192.168.0.X… . Et ça correspond pile à un 
> essai où l'un des deux ne s'entendait pas. Juste après, Toto m'a téléphoné. À 
> nouveau, il a eu un Strict learning complete et moi aussi, donc on pouvait 
> converser… 
> 
> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?

Que l’IP que présente le softphone est une IP que Asterisk a dans son localnet.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
De: "David Ponzone" 

> Ah non, en autolearn, il est forcément dans le path RTP.

Attends, attends, attends.

Il se passe quoi quand l'autolearn marche que pour l'un des deux interlocuteurs 
? Ça donnerait pas une conversation où un seule interlocuteur entend l'autre, 
par hasard ?
Genre là, dans le journal, je vois un Strict learning complete pour un 
interlocuteur sur les deux (on va le nommer Toto). Pour l'autre interlocuteur 
(Titi), le learning voit qu'une IP 192.168.0.X… . Et ça correspond pile à un 
essai où l'un des deux ne s'entendait pas. Juste après, Toto m'a téléphoné. À 
nouveau, il a eu un Strict learning complete et moi aussi, donc on pouvait 
converser… 

Qu'est-ce qui peut expliquer les échecs de l'autolearn ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> Le 17 mars 2020 à 20:31, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>> Ah non, en autolearn, il est forcément dans le path RTP.
> 
> Moi je parle de ça dans le journal :
> « Strict RTP learning after remote address set to: 10.30.1.4:7078
> Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »
> 
> À ce moment-là, il me semble que les flux RTP étaient directs.

Non non.
Enfin j’ai jamais vu faire. Ca serait compliqué, faudrait renvoyer des SIP 
UPDATE aux 2 endpoints, mais si tu changes le SDP en cours d’appel, il est 
possible, probable même, voir certain, que le port va changer à cause du NAT 
devant le endpoint, donc c’est mort.
L’autolearn repose sur le fait d’apprendre le vrai couple IP/PORT du flux, qui 
ne changera plus tant que l’appel dure, pareil pour l’autre endpoint, et tu 
fais le relais entre les 2.

> 
> Comment puis-je activer/désactiver l'autolearn ? Juste pour voir la diff'…
> 

Je sais pas, j’ai abandonné Asterisk pour FreeSWITCH, il y a longtemps.

> 
>> Mais du relais RTP sans transcoding, ça prend que dalle.
>> T’as beaucoup de monde comme ça ?
> 
> Si on généralisait le télétravail au max du max (ce qui n'arrivera pas 
> puisqu'on a un écrit officiel nous informant qu'il n'y aura pas de perte de 
> rémunération si refus du télétravail, donc autant rien faire), on aurait 800 
> personnes.


800 personnes, c’est max 120-150 appels simultanés si c’est un usage entreprise 
standard, ça tient sur 4 coeurs.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Stéphane Rivière]

Merci pour ce diag. :)


On est tous arrivé au même.

Quand la colère va me prendre, 


Ou la lassitude...


je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas d'ACL 
ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.


La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup 
d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui 
tombe en marche à tous les coups.


Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit 
par un colistier). C'est ainsi. Et au moins, on est désormais dans une 
techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris.


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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Ah non, en autolearn, il est forcément dans le path RTP.

Moi je parle de ça dans le journal :
« Strict RTP learning after remote address set to: 10.30.1.4:7078
Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »

À ce moment-là, il me semble que les flux RTP étaient directs.

Comment puis-je activer/désactiver l'autolearn ? Juste pour voir la diff'…


> Mais du relais RTP sans transcoding, ça prend que dalle.
> T’as beaucoup de monde comme ça ?

Si on généralisait le télétravail au max du max (ce qui n'arrivera pas 
puisqu'on a un écrit officiel nous informant qu'il n'y aura pas de perte de 
rémunération si refus du télétravail, donc autant rien faire), on aurait 800 
personnes.


J'aimerais bien l'avis de la liste : un TURN résoudrait à coup sûr mon 
problème, mais, c'est crade, non ? :(


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 

> Installer une route vers le réseau local c'est pas une solution, car tu vas 
> de retrouver avec une ribambelle de 192.168.0.0.

Et il faut ajouter ces routes chez tous les clients VPN, et donc avoir des 
collisions (genre si on dit à un usager avec une connexion Numericable 
d'envoyer 192.168.0.0/24 dans le VPN, vlam).


> Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il 
> est lié à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur 
> VPN lui envoie.

C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent  sur le 
choix de l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> Le 17 mars 2020 à 20:17, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans 
>> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et 
>> faisant le relais RTP.
> 
> Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn et tout, mais 
> ça marche pas.
> De même, l'activation infructueuse de nat=yes me laisse très dubitatif. Si 
> Asterisk réécrit les SDP, ça devrait fonctionner, sauf si les softphones sont 
> bind() uniquement sur l'IP RFC1918 locale (non VPN). Je vais revenir sur ça 
> demain.
> 
> Quand tu parles de relais RTP, tu veux parler de relais SDP, non ?
> Perso, je ne veux pas qu'Asterisk soit relais RTP, car il faut dimensionner 
> le serveur pour la montée en chargée.
> C'est aussi pour ça que je n'ai pas installé de serveur TURN, qui serait une 
> solution vite-fait-bien-fait à mon problème.
> 

Ah non, en autolearn, il est forcément dans le path RTP.
Mais du relais RTP sans transcoding, ça prend que dalle.
T’as beaucoup de monde comme ça ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans 
> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et 
> faisant le relais RTP.

Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn et tout, mais ça 
marche pas.
De même, l'activation infructueuse de nat=yes me laisse très dubitatif. Si 
Asterisk réécrit les SDP, ça devrait fonctionner, sauf si les softphones sont 
bind() uniquement sur l'IP RFC1918 locale (non VPN). Je vais revenir sur ça 
demain.

Quand tu parles de relais RTP, tu veux parler de relais SDP, non ?
Perso, je ne veux pas qu'Asterisk soit relais RTP, car il faut dimensionner le 
serveur pour la montée en chargée.
C'est aussi pour ça que je n'ai pas installé de serveur TURN, qui serait une 
solution vite-fait-bien-fait à mon problème.


> Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk 
> si nécessaire, et comprendre ce qui merde.

Je n'ai pas de capture réseau des essais avec nat=yes, et oui, c'est 
problématique.


> Ca permettrait au moins d’incriminer l’ASA une fois pour toute.

Ben ça, j'ai du wireshark sur les clients et du tcpdump sur l'Asterisk donc 
j'vois bien que la SDP part avec une IP "invalide" d'un softphone, qu'Asterisk 
la relaie et que le client la reçoit. Et inversement, quand ça marche, je vois 
des SDP avec la "bonne" IP. Ces captures datent d'avant l'activation de nat=yes 
sur quelques comptes SIP, bien entendu.

Ce qui m'étonne le plus, c'est le softphone qui utilise STUN, puis en fait non, 
puis qui ne tient plus compte de la réponse STUN pour forger sa SDP, puis si, 
puis non, puis après il ne tient pas compte d'une SDP valide reçue donc il 
envoie le flux audio au mauvais endroit, puis ça marche, puis retour case 
départ…


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

RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

> Guillaume LUCAS a écrit :
> Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
> toujours
> parce que les softphones ne mettaient pas leur "bonne" IP dans le message 
> SIP/SDP,
> forcément que le softphone d'en face ne pourra pas leur envoyer de RTP. Genre 
> "viens
> me causer sur 127.0.0.1" ça va pas marcher. "Viens me causer sur 
> 192.168.0.14" non
> plus. Je dis la même chose que toi quand tu écris « problème de binding ».

J'avais pas percuté avant, mais en effet c'est probablement un de tes 
problèmes. Dans ton softphone, il faut que tu puisses choisir l'interface VPN 
et que le softphone comprenne que c'est celle à utiliser. Installer une route 
vers le réseau local c'est pas une solution, car tu vas de retrouver avec une 
ribambelle de 192.168.0.0.

>> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
> Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 
> pour NC-SFR,
> 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 pour 
> MacDo, etc.
> etc. On ne s'en sort plus. Je ne vais pas définir tous les réseaux privés que 
> chacun
> peut avoir chez soi ou au cybercafé dans mes localnets, si ? 

Non, ton analyse est bonne.

> Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, pas l'IP 
> qu'il a à sa maison.

Correct, contrairement à ce que j'ai écrit plus tot.

Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il est 
lié à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur VPN 
lui envoie.

A part çà, changer de système de VPN çà serait à essayer, si ce n'est que pour 
savoir ou ton problème est.

Michel.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans tous 
les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et faisant 
le relais RTP.
Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk 
si nécessaire, et comprendre ce qui merde.
Ca permettrait au moins d’incriminer l’ASA une fois pour toute.

> Le 17 mars 2020 à 19:26, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "Thierry Chich" 
> 
> 
>> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN 
>> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup 
>> avec du jitsi. Le p2p, c’est bien joli, mais bon.
> 
> À mon avis, une partie du problème est dans le mot « partiellement », en 
> effet.
> Quand ça fonctionne, les flux RTP circulent bien d'IP attribuée par le VPN à 
> IP attribuée par le VPN ;
> ping entre deux clients VPN OK ;
> http entre deux clients VPN OK ;
> netcat udp entre deux clients VPN OK.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Thierry Chich" 


> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN 
> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup 
> avec du jitsi. Le p2p, c’est bien joli, mais bon.

À mon avis, une partie du problème est dans le mot « partiellement », en effet.
 Quand ça fonctionne, les flux RTP circulent bien d'IP attribuée par le VPN à 
IP attribuée par le VPN ;
 ping entre deux clients VPN OK ;
 http entre deux clients VPN OK ;
 netcat udp entre deux clients VPN OK.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Définitivement pour moi problème de NAT ou Pare-Feu

Merci pour ce diag. :)
Quand la colère va me prendre, je vais monter un VPN OpenVPN tout neuf sur 
lequel je serai sûr que y'a pas d'ACL ni rien et hop hop hop. Pas envie de 
démerder un Cisco ASA.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que 
> ton rtp se perd si le client envois une IP injoignable au PABX

Tout à fait, je comprends.
Je corrige un truc : le client envoie, en SDP, une IP injoignable au PABX, mais 
aussi à son interlocuteur.
Donc en fait, tous nos clients VPN devraient avoir une route pour (dans 
l'exemple que je prends depuis le début) 192.168.0.24, ce qui va forcément 
faire collision avec des réseaux domestiques qui utilisent cette plage. D'où 
l'ajout de routes n'est pas une bonne idée, c'est au softphone de sélectionner 
la bonne IP pour la filer en SDP, avec ICE, STUN, autre…

Ce qui me dépasse, c'est quand le softphone fait des requêtes STUN, mets bien 
son IP VPN dans SDP (donc l'appel fonctionne) puis, des heures plus tard, sans 
aucun changement de conf' ni redémarrage du softphone ni… cesse de faire du 
STUN ou émet des requêtes STUN, reçoit la réponse, mais n'intègre pas l'IP dans 
SDP… ou autre… Si y'avait pas ça, la solution STUN, bien que crade, 
fonctionnerait.


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

Re: [FRnOG] [MISC] Profitons bien de l'épidémie pour violer un peu la neutralité

[Thierry Chich]

Le CNED ? Pourquoi voudriez-vous qu’ils aient des éléments ?

Thierry 

> Le 16 mars 2020 à 14:35, Wallace  a écrit :
> 
> Pour ma part ce qui me révolte c'est que j'avais refusé Pronote et
> consors depuis toujours car ce sont des entreprises privées et qu'on
> nous a inscrit de force, du coup requête RGPD pour suppression des accès
> / données et lettre saignante aux chefs d'établissement qui se donnent
> le droit de divulguer nos coordonnées sans notre accord.
> ?
> Et là avec ce confinement des enfants, on nous laisse pas du tout le
> choix que de laisser nos données à ces entreprises...
> 
> Effectivement le CNED a déjà des éléments, c'est vraiment dommage de ne
> pas les utiliser.
> 
>> Le 16/03/2020 à 14:16, David Ponzone a écrit :
>> Dans le cas particulier de l'enseignement, je suis sidéré que l’Etat n’ait 
>> pas été capable de proposer une offre complète et cohérente pour tous les 
>> établissements scolaires (en utilisant bien sûr l’expérience du CNED entre 
>> autres). A cause de ce manquement, chaque école a choisi son acteur privé 
>> pour combler ce vide (Pronote, Ecole Directe, etc…), et la réalité c’est 
>> qu’aucun ne tient la route dans une telle situation.
>> Espérons que cela pousse l’Etat à revoir son implication dans ce domaine, ou 
>> plutôt sa non-implication. On ne peut pas tout sous-traiter.
>> 
 Le 16 mars 2020 à 14:07, Sebastien CHATEAU-DUTIER  a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Le soucis viens toujours du "sous dimensionnement" des serveurs Web/BDD (ou 
>>> des grappes de serveurs...) bref rien de nouveau sur la planète.
>>> 
>>> Bonne journée.
>>> 
>>> Seb
>>> 
>>> Le 16/03/2020 à 13:28, Alarig Le Lay a écrit :
 Le souci ne vient toujours pas de la taille des tuyaux. Ils ont résisté
 à la coupe du monde des 11 glandus derrière un ballon, ils résisterons à
 ça.
 
 On lun. 16 mars 12:50:06 2020, Nico G wrote:
> Le core ça doit tenir sans problème. Certains lien edge peut être pas.
> Le peering vers Netflix ou Google c’est du privé et c’est largement 
> dimensionné. Le transit généraliste vers tel ou tel hébergeur c’est moins 
> sur. D’autant plus qu’Orange n’a pas le peering dans le sang.
> 
> Nicolas
> 
>> Le 16 mars 2020 à 12:30, Richard Klein  a écrit :
>> 
>> @David
>> La question est de savoir si la saturation est sur le cœur et si les
>> opérateurs et acteurs des télécoms seront tirer la leçon pour investir
>> Et si payer une fibre un bras et se retrouver avec des ralentissements
>> c'est les prochaines questions qui seront abordés par les clients...
>> 
>>> Le lun. 16 mars 2020 à 12:25, David Ponzone  a
>>> écrit :
>>> 
>>> J’ai pas bien compris le rapport entre ma fibre et les sites web de
>>> support scolaire des écoles….
>>> 
> Le 16 mars 2020 à 12:06, Richard Klein  a 
> écrit :
 Bonjour a tous depuis la maison pendant ma pause déjeuné.
 Je me fais l'avocat du diable...
 Question lorsque vous payez une fibre 500euros et lorsque vous payez 30
 euros en GP vos debits sont garantis pour la ligne GP ou Pro?
 :-)
 
 Richard
 
 Le lun. 16 mars 2020 à 11:44, GROS Jérôme  a écrit
>>> :
> Pour l'école primaire chez moi :
> https://beneylu.com/fr/beneylu-school-met-les-bouchees-doubles/
> Bon là, même le message d'alerte ne fonctionne plus.
> 
> On Mon, Mar 16, 2020 at 10:10:53AM +0100, David Ponzone wrote:
>> Des sources de quoi ?
>> Ben EcoleDirecte de mon fils: inutilisable à l’heure actuelle.
>> VieScolaire de ma fille: inutilisable
>> Kwyk dont se sert la prof de maths de mon fils: inutilisable toute à
> l’heure, ça a l’air d’aller un peu mieux là.
>> Paris Classe Numérique marchait pas ce matin (accès prof), mais ça
>>> semble
> s’améliorer.
>> Y a donc pas grand chose qui support les accès massifs et comme rien
>>> n’a
> été fait pour les étaler dans le temps...
>>> Le 16 mars 2020 à 10:03, Michel Guillou  a écrit 
>>> :
>>> 
>>> Le Mon, 16 Mar 2020 09:52:07 +0100, vous écrivîtes :
>>> 
 S’ils font ça, ils sont morts.
 Même certains profs comptent sur Youtube pour fournir le contenu 
 que
> le Ministère n’a pas.
 Je parle même pas des serveurs type EcoleDirect et autres, qui ont
> gentiment explosé ce matin.
>>> Tu as des sources là-dessus ? Ça m'intéresse...
>>> 
>>> Merci.
>>> 
>>> --
>>> Michel Guillou
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
>> ---
>> Liste de diffusion du FRnOG
>> 

Re: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Oliver varenne" 

> A mon avis, linphone liste les interfaces accessibles, et du coup si ton VPN 
> monte apres, linphone n'utilise pas cette interface.

Yep. Mais, comme dit : durant mes tests, j'ai bien demandé à tous les 
participants d'être vigilants, de bien monter le VPN avant. Et quand j'avais un 
doute, j'ai fait redémarrer Linphone.

En vrai, depuis le début, le comportement de Linphone ne me semble pas absurde 
: sélectionner l'interface qui a la route par défaut, ça va faire le job pour > 
80 % des utilisateurs.


> Si ça fonctionne avec d'autres softphone, et que seul linphone est impacté, 
> tu as ta réponse 

Comme dit, Zoiper, Blink et Jitsi se prennent aussi les pieds dans le tapis de 
manière aléatoire (ça marche puis des heures après non, puis oui… alors que le 
logiciel a pas été touché, ni sa conf' et que le PC n'a pas changé de réseau, 
ne s'est pas déconnecté du VPN, n'a pas été arrêté/mis en veille prolongée…).


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce 
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir 
> le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide 
> linphone à envoyer un SDP correct ?

J'essaye de dépiler mes mails dans l'ordre.

Alors ça, c'est la première chose que j'ai testé vendredi. Avant STUN, ICE et 
compagnie. Et ça marchait. Il restait le problème de "ça raccroche auto après 
30 secs" mais au moins les flux RTP montaient. J'ai pas testé aussi longuement 
que ICE et STUN, donc si ça se trouve, ça marche pas sur le long terme, comme 
STUN.

Pourquoi j'ai pas gardé ? Parce que l'adressage IP de notre VPN est dynamique. 
Pas statique. Pas d'IP préférée. Rien, du pur dynamique. J'ai oublié de le dire 
ici.


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

Re: [FRnOG] [TECH] Vérifier que le trafic IPsec est bien autorisé

[Thierry Chich]

J’ai eu beaucoup de soucis avec des problèmes de fragmentation sur les paquets 
isakmp trop grand. Comme c’est de l’UDP, toutes les astuces à base de 
bidouilles sur la MSS ne fonctionnent pas, et il faut espérer que le PMTUD 
fonctionne bien. Ça relève plus de la foi qu’autre chose. Et certaines livebox 
ou routeurs ont eu par moment des bugs et droppaient les fragments. 

Si les paquets isakmp sont petits, ça passe bien, mais dès  qu’on fait du 
certificat, ça peut être compliqué.

Thierry 

> Le 16 mars 2020 à 18:49, Guillaume Genty (Waycom)  a écrit 
> :
> 
> C'est marrant comme coïncidence ! J'ai le même problème de mon côté...
> 
> 
> Je viens de passer une bonne heure à débugger le client VPN IPSec d'un 
> administratif de chez nous, pour avoir fini par trouver que certains paquets 
> n'arrivent pas !
> 
> C'est justement du FTTH Orange grand public avec Livebox
> (J'ai testé avec un partage de connexion 4G, c'est monté tout de suite)
> 
> La phase 1 monte bien en NAT-T (UDP ports 500 puis 4500) mais impossible de 
> monter la phase 2.
> Une fois descendu dans le débug, les trames de setup SA de la phase 2 
> n'arrivent jamais en face, alors que les keepalive de la phase 1 passent sans 
> problème au même moment.
> Sauf que comme la première phase passe bien, aucun indicateur d'erreur sur 
> l'UI du client VPN qui indique juste que la connexion a réussi...
> 
> Franchement c'est tellement tordu comme problème, j'ai des doutes que ça soit 
> volontaire de la part d'Orange !
> 
> Quelqu'un d'autre a déjà eu ces symptômes ?
> 
> -- 
> Guillaume Genty | WAYCOM
> Directeur Innovation et Expertise
> 1 quai Marcel Dassault | 92150 Suresnes, FRANCE
> T. : +33 (0)1 41 44 83 00 | F. : +33 (0)1 41 44 00 22
> gge...@waycom.net | www.waycom.net
> 
>> Le 16/03/2020 à 18:09, Jonathan Leroy - Inikup via frnog a écrit :
>>> Le lun. 16 mars 2020 à 18:00, David Ponzone  a 
>>> écrit :
>>> Ben tu prends une trace sur tes ports egress.
>> Ah oui au fait, le routeur est une Livebox. :D
>> Je cherchais une solution plus simple que de monter un tunnel IPsec
>> moi-même juste pour vérifier que le trafic passe bien.
>> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir 
le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide linphone 
à envoyer un SDP correct ?

> Le 17 mars 2020 à 18:29, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "frnog" 
> 
> Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
>> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou 
>> autre.
> 
> Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation 
> foireuse et comme ça me semble quand même trop gros, j'viens demander ici si 
> c'est normal.
> En vrai, ça me semble aberrant… Mais comme j'ai déjà vu ces 10 dernières 
> années de la part de plusieurs softphones…
> 
> 
> 
>> Une solution serait de mettre le réseau 192.168.0/24 dans localnet et de 
>> faire une route sur le PABX qui enverrait le trafic vers l'interface VPN. 
>> C'est du bricolage
> 
> Oui et non. Je ne sais pas comment marche un Cisco ASA, mais, avec OpenVPN, 
> si tu routes, vers un client, une IP/réseau que tu n'as pas défini dans la 
> conf' OpenVPN (iroute, etc.), le trafic arrivera pas au client. Donc, si je 
> faisais ça, faudrait vérifier ça.
> 
> Et oui, ça serait du bricolage… Mais ça fonctionnerait très probablement…
> 
> 
> 
>> Comme dit par d'autres STUN ou ICE ne devriaent pas être nécessaires
> 
> Ce qui pré-suppose que le softphone sélectionne la "bonne IP" pour la mettre 
> dans SDP. Linphone, Jitsi, Zoiper, Blink, tous échouent par moments (Jitsi) 
> ou tout le temps sans STUN (Linphone) ou tout le temps même avec STUN 
> (Zoiper).
> 
> 
> 
>> As tu fais les modifs au niveau localnet ?
> 
> Nope, du coup.
> 
> 
> 
>> Soit tu as 2 problèmes, Pare-Feu et Softphone
> 
> Vrai…
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Thierry Chich]

Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN ne 
se voient pas entre elles, ou partiellement ? On vient d’avoir le coup avec du 
jitsi. Le p2p, c’est bien joli, mais bon.

Thierry Chich

> Le 17 mars 2020 à 18:19, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
> De: "frnog" 
> 
>> Donc session timeout: Essaye en mettant session-timers=refuse dans la  
>> config d'un client qui génère cette erreur
> 
> J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça 
> ne fonctionne pas, ça coupe toujours après 32 secs.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou 
> autre.

Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation 
foireuse et comme ça me semble quand même trop gros, j'viens demander ici si 
c'est normal.
En vrai, ça me semble aberrant… Mais comme j'ai déjà vu ces 10 dernières années 
de la part de plusieurs softphones…



> Une solution serait de mettre le réseau 192.168.0/24 dans localnet et de 
> faire une route sur le PABX qui enverrait le trafic vers l'interface VPN. 
> C'est du bricolage

Oui et non. Je ne sais pas comment marche un Cisco ASA, mais, avec OpenVPN, si 
tu routes, vers un client, une IP/réseau que tu n'as pas défini dans la conf' 
OpenVPN (iroute, etc.), le trafic arrivera pas au client. Donc, si je faisais 
ça, faudrait vérifier ça.

Et oui, ça serait du bricolage… Mais ça fonctionnerait très probablement…



> Comme dit par d'autres STUN ou ICE ne devriaent pas être nécessaires

Ce qui pré-suppose que le softphone sélectionne la "bonne IP" pour la mettre 
dans SDP. Linphone, Jitsi, Zoiper, Blink, tous échouent par moments (Jitsi) ou 
tout le temps sans STUN (Linphone) ou tout le temps même avec STUN (Zoiper).



> As tu fais les modifs au niveau localnet ?

Nope, du coup.



> Soit tu as 2 problèmes, Pare-Feu et Softphone

Vrai…


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 18:18, Guillaume LUCAS a écrit :

- Mail original -
De: "frnog" 


Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
d'un client qui génère cette erreur

J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne 
fonctionne pas, ça coupe toujours après 32 secs.

Définitivement pour moi problème de NAT ou Pare-Feu

--
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] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
De: "frnog" 

> Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
> d'un client qui génère cette erreur

J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne 
fonctionne pas, ça coupe toujours après 32 secs.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Un autre article qui parle de ça, et qui donne le bon paramètre pour le 
linphonerc, utilisable évidemment seulement si le VPN attribue une IP fixe:

https://linphone-users.nongnu.narkive.com/g4m2kB9q/how-to-tell-linphone-which-ip-address-to-use
 


> Le 17 mars 2020 à 17:43, Daniel via frnog  a écrit :
> 
> 
> Le 17/03/2020 à 15:05, Guillaume LUCAS a écrit :
>> 
>> [...]
>>> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
>> Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 
>> pour NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 
>> 172.16 pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir 
>> tous les réseaux privés que chacun peut avoir chez soi ou au cybercafé dans 
>> mes localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans 
>> notre VPN, pas l'IP qu'il a à sa maison.
> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que ton 
> rtp se perd si le client envois une IP injoignable au PABX
> 
> [...]
> 
> -- 
> Daniel Huhardeaux
> +33.368460...@tootai.netsip:8...@sip.tootai.net
> +41.445532...@swiss-itech.ch  tootaiNET
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 15:05, Guillaume LUCAS a écrit :


[...]

Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour 
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 
pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir tous les 
réseaux privés que chacun peut avoir chez soi ou au cybercafé dans mes 
localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, 
pas l'IP qu'il a à sa maison.
J'avais bien compris que tu ne veux pas le faire, tu comprends donc que 
ton rtp se perd si le client envois une IP injoignable au PABX


[...]

--
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] [TECH] Vérifier que le trafic IPsec est bien autorisé

[professor geek]

Ca serait pas un pb de mtu ?

On 16 March 2020 at 18:49:58, Guillaume Genty (Waycom) (gge...@waycom.net)
wrote:

C'est marrant comme coïncidence ! J'ai le même problème de mon côté...


Je viens de passer une bonne heure à débugger le client VPN IPSec d'un
administratif de chez nous, pour avoir fini par trouver que certains
paquets n'arrivent pas !

C'est justement du FTTH Orange grand public avec Livebox
(J'ai testé avec un partage de connexion 4G, c'est monté tout de suite)

La phase 1 monte bien en NAT-T (UDP ports 500 puis 4500) mais impossible de
monter la phase 2.
Une fois descendu dans le débug, les trames de setup SA de la phase 2
n'arrivent jamais en face, alors que les keepalive de la phase 1 passent
sans problème au même moment.
Sauf que comme la première phase passe bien, aucun indicateur d'erreur sur
l'UI du client VPN qui indique juste que la connexion a réussi...

Franchement c'est tellement tordu comme problème, j'ai des doutes que ça
soit volontaire de la part d'Orange !

Quelqu'un d'autre a déjà eu ces symptômes ?

-- 
Guillaume Genty | WAYCOM
Directeur Innovation et Expertise
1 quai Marcel Dassault | 92150 Suresnes, FRANCE
T. : +33 (0)1 41 44 83 00 | F. : +33 (0)1 41 44 00 22
gge...@waycom.net | www.waycom.net

Le 16/03/2020 à 18:09, Jonathan Leroy - Inikup via frnog a écrit :
> Le lun. 16 mars 2020 à 18:00, David Ponzone  a
écrit :
>> Ben tu prends une trace sur tes ports egress.
> Ah oui au fait, le routeur est une Livebox. :D
> Je cherchais une solution plus simple que de monter un tunnel IPsec
> moi-même juste pour vérifier que le trafic passe bien.
>


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

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Stéphane Rivière]

> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers 
> d'un VPN je ne vois pas pourquoi çà ne marcherait pas.

+1

>> Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
>> autre.

+1

-- 
Be Seeing You
Number Six


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

[FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Kevin CHAILLY | Service Technique]

Bonjour,

Installe sngrep et regarde les entête coté serveur, 

Si l'appel s'effectue, la partie SIP de la communication s'établit.

Si la voix ne passe pas, les trames RTP sont sans doute perdues,

Attention aux méchants routeurs faisant du "SIP ALG" et par ce moyen réécrivant 
les entêtes.

Kévin

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Guillaume 
LUCAS
Envoyé : mardi 17 mars 2020 16:01
À : frnog-tech 
Objet : Re: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il 
vraiment autant de bugs que ça dans les implémentations SIP ?!)

> - Mail original -
> De: "Oliver varenne" 
> À: "frnog-tech" 
> Envoyé: Mardi 17 Mars 2020 15:52:23
> Objet: [FRnOG] [TECH]  RE: Télétravail = VPN = fête du SIP (ou 
> y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP 
> ?!)

> Mais tu as mis l'option force,comedia sur tes extensions distantes? 
> (nat=force,comedia) Si ton softphone envoie une IP locale au lieu de mettre 
> l'IP de ton VPN, ça résoudra normalement tes soucis.

Dans l'interface web XiVo, à la recherche du nat = yes proposé par Florent, 
j'ai mis nat = « Oui (force rport + comedia) » sur les quatre comptes SIP de 
test. J'ai demandé à tout le monde de redémarrer son Linphone. Ça ne fonctionne 
pas… Deux personnes ne s'entendent pas, comme avant. Deux personnes s'entendent 
mais s'entendaient déjà avant.


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

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

Re: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Guillaume,

Ca serait intéressant que tu essaies de monter le VPN avec le VPN comme route 
par défaut (pas de split-horizon donc), pour voir si Linphone s’en sort mieux…

> Le 17 mars 2020 à 16:30, Oliver varenne  a écrit :
> 
> A mon avis, linphone liste les interfaces accessibles, et du coup si ton VPN 
> monte apres, linphone n'utilise pas cette interface.
> 
> Ou un truc du genre.
> 
> 
> 
> Si ça fonctionne avec d'autres softphone, et que seul linphone est impacté, 
> tu as ta réponse 
> 
> 
> 
> 
> 
> 
> 
> Cordialement,
> 
> 
> 
> 
> 
> 
> 
> Olivier Varenne
> 
> Co-gérant, Commercial & Développeur
> 
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> 
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de 
> Guillaume LUCAS
> Envoyé : mardi 17 mars 2020 16:18
> À : frnog 
> Objet : Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> 
> 
> 
>> - Mail original -
> 
>> De: "David Ponzone" mailto:david.ponz...@gmail.com>>
> 
> 
> 
>> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et 
>> APRÈS de lancer Linphone ?
> 
> 
> 
> Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le 
> VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai testé pour toi et, 
> forcément, ça foire bien. Au début impossible d'être destinataire d'un appel, 
> le PABX dit que le user n'est pas là. En laissant Linphone se rendre compte 
> de la réalité (> 10 minutes), il s'enregistre à nouveau. Les appels ne 
> fonctionnent pas (personne s'entend ou un des deux seulement et vu l'IP 
> RFC1918 hors VPN dans le message SDP… … …), même avec les personnes avec 
> lesquelles cela fonctionnait juste avant et avec lesquels ça a fonctionné 
> après avoir redémarré Linphone pour conclure le test.
> 
> 
> 
> Donc oui, il faut bien monter le VPN avant d'ouvrir Linphone.
> 
> Et ça pose un souci. En cas de coupure ADSL (ou autre), notre VPN va remonter 
> auto. L'utilisateur changera d'IP. Linphone sera perdu. Je me vois mal 
> demander à mes utilisateurs de redémarrer Linphone en permanence.
> 
> 
> 
> 
> 
>> Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces 
>> clients là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto 
>> learn) et ne pas faire confiance au SDP.
> 
> 
> 
> A priori, c'est ce que j'ai testé en activant nat = « Oui (force rport + 
> comedia) » dans XiVo + redémarrer les softphones puis tester, non ?
> 
> 
> 
> 
> 
> 
> 
> ---
> 
> Liste de diffusion du FRnOG
> 
> http://www.frnog.org/
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Oliver varenne]

A mon avis, linphone liste les interfaces accessibles, et du coup si ton VPN 
monte apres, linphone n'utilise pas cette interface.

Ou un truc du genre.



Si ça fonctionne avec d'autres softphone, et que seul linphone est impacté, tu 
as ta réponse 







Cordialement,







Olivier Varenne

Co-gérant, Commercial & Développeur

T +33 (0)4 27 04 40 00 | ipconnect.fr



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Guillaume 
LUCAS
Envoyé : mardi 17 mars 2020 16:18
À : frnog 
Objet : Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
vraiment autant de bugs que ça dans les implémentations SIP ?!)



> - Mail original -

> De: "David Ponzone" mailto:david.ponz...@gmail.com>>



> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et 
> APRÈS de lancer Linphone ?



Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le 
VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai testé pour toi et, 
forcément, ça foire bien. Au début impossible d'être destinataire d'un appel, 
le PABX dit que le user n'est pas là. En laissant Linphone se rendre compte de 
la réalité (> 10 minutes), il s'enregistre à nouveau. Les appels ne 
fonctionnent pas (personne s'entend ou un des deux seulement et vu l'IP RFC1918 
hors VPN dans le message SDP… … …), même avec les personnes avec lesquelles 
cela fonctionnait juste avant et avec lesquels ça a fonctionné après avoir 
redémarré Linphone pour conclure le test.



Donc oui, il faut bien monter le VPN avant d'ouvrir Linphone.

Et ça pose un souci. En cas de coupure ADSL (ou autre), notre VPN va remonter 
auto. L'utilisateur changera d'IP. Linphone sera perdu. Je me vois mal demander 
à mes utilisateurs de redémarrer Linphone en permanence.





> Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces clients 
> là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto learn) et ne 
> pas faire confiance au SDP.



A priori, c'est ce que j'ai testé en activant nat = « Oui (force rport + 
comedia) » dans XiVo + redémarrer les softphones puis tester, non ?







---

Liste de diffusion du FRnOG

http://www.frnog.org/

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et 
> APRÈS de lancer Linphone ?

Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le 
VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai testé pour toi et, 
forcément, ça foire bien. Au début impossible d'être destinataire d'un appel, 
le PABX dit que le user n'est pas là. En laissant Linphone se rendre compte de 
la réalité (> 10 minutes), il s'enregistre à nouveau. Les appels ne 
fonctionnent pas (personne s'entend ou un des deux seulement et vu l'IP RFC1918 
hors VPN dans le message SDP… … …), même avec les personnes avec lesquelles 
cela fonctionnait juste avant et avec lesquels ça a fonctionné après avoir 
redémarré Linphone pour conclure le test.

Donc oui, il faut bien monter le VPN avant d'ouvrir Linphone.
Et ça pose un souci. En cas de coupure ADSL (ou autre), notre VPN va remonter 
auto. L'utilisateur changera d'IP. Linphone sera perdu. Je me vois mal demander 
à mes utilisateurs de redémarrer Linphone en permanence.


> Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces clients 
> là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto learn) et ne 
> pas faire confiance au SDP.

A priori, c'est ce que j'ai testé en activant nat = « Oui (force rport + 
comedia) » dans XiVo + redémarrer les softphones puis tester, non ?



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

Re: [FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Oliver varenne" 
> À: "frnog-tech" 
> Envoyé: Mardi 17 Mars 2020 15:52:23
> Objet: [FRnOG] [TECH]  RE: Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Mais tu as mis l'option force,comedia sur tes extensions distantes? 
> (nat=force,comedia)
> Si ton softphone envoie une IP locale au lieu de mettre l'IP de ton VPN, ça 
> résoudra normalement tes soucis.

Dans l'interface web XiVo, à la recherche du nat = yes proposé par Florent, 
j'ai mis nat = « Oui (force rport + comedia) » sur les quatre comptes SIP de 
test. J'ai demandé à tout le monde de redémarrer son Linphone. Ça ne fonctionne 
pas… Deux personnes ne s'entendent pas, comme avant. Deux personnes s'entendent 
mais s'entendaient déjà avant.


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

[FRnOG] [TECH] RE: Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Oliver varenne]

J'ai pas tout suivi, et je vais peut-être dire une connerie parce que j'ai pas 
tout lu. (trop de texte !)
Mais tu as mis l'option force,comedia sur tes extensions distantes? 
(nat=force,comedia)
Si ton softphone envoie une IP locale au lieu de mettre l'IP de ton VPN, ça 
résoudra normalement tes soucis.




Cordialement,
 


Olivier Varenne
Co-gérant, Commercial & Développeur
T +33 (0)4 27 04 40 00 | ipconnect.fr

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Guillaume 
LUCAS
Envoyé : mardi 17 mars 2020 15:05
À : frnog 
Objet : Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
vraiment autant de bugs que ça dans les implémentations SIP ?!)

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 14:24:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu pars du principe de ta configuration. Asterisk doit connaitre son  
> external IP qu'il met dans les entêtes SIP/RTP si l'IP du client n'est 
> pas définie dans ses localnet

Ben il a une seule IP, lui. Et elle est joignable depuis les VPN et depuis les 
SNOM. J'ai mtr, netcat, etc.



> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour 
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 
pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir tous les 
réseaux privés que chacun peut avoir chez soi ou au cybercafé dans mes 
localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, 
pas l'IP qu'il a à sa maison.



> Mets le sur tous les clients

D'acc.


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

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 14:24:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu pars du principe de ta configuration. Asterisk doit connaitre son  
> external IP qu'il met dans les entêtes SIP/RTP si l'IP du client n'est 
> pas définie dans ses localnet

Ben il a une seule IP, lui. Et elle est joignable depuis les VPN et depuis les 
SNOM. J'ai mtr, netcat, etc.



> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour 
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 
pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir tous les 
réseaux privés que chacun peut avoir chez soi ou au cybercafé dans mes 
localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, 
pas l'IP qu'il a à sa maison.



> Mets le sur tous les clients

D'acc.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 14:08, Guillaume LUCAS a écrit :

- Mail original -
De: "frnog" 
À: "frnog" 
Envoyé: Mardi 17 Mars 2020 09:23:08
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)



Je pense que Linphone est à mettre en cause. Le problème n'est pas que
le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP.

Peux-tu expliquer, stp ? Dans mes souvenirs. Un interlocuteur lance un appel. SIP 
INVITE vers le PABX qui transmet à l'interlocuteur (je passe trying/ringing, etc.). 
Si ça décroche, y'a échange des SDP en passant par le PABX. Au début, le PABX 
connecte chaque interlocuteur à lui (donc la connaissance de sa propre IP suffit 
pour dire "viens me causer sur cette IP+port avec tels codecs), puis il 
connecte les deux interlocuteurs directement en relayant simplement le SDP émis par 
chaque softphone. Dedans y'a l'IP+port et les codecs à utiliser. Pour moi Asterisk 
devient neutre à ce stade-là.


Tu pars du principe de ta configuration. Asterisk doit connaitre son 
external IP qu'il met dans les entêtes SIP/RTP si l'IP du client n'est 
pas définie dans ses localnet


https://www.voip-info.org/asterisk-sip-externip/


Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a
une zone réseau local: le VPN en /16 doit y être défini

On a rien défini. Pas même le /16 RFC1918 qui héberge nos SNOM. Pas même le 
VLAN des passerelles T2.
Au niveau système, il y a une route par défaut, pas de routes vers les VLANs 
(VPN, SNOM, passerelles T2, etc.).

Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
d'un client qui génère cette erreur

D'acc. Mais… Comment j'identifie ce client ?

Mets le sur tous les clients

Comme dit, y'a trop de bruit, je n'arrive pas à corréler…
La modif' se fait côté Asterisk, on est d'accord ?

Oui

--
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] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et APRÈS 
de lancer Linphone ?

Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces clients 
là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto learn) et ne 
pas faire confiance au SDP.


> Le 17 mars 2020 à 13:46, Guillaume LUCAS  a 
> écrit :
> 
> Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
> toujours parce que les softphones ne mettaient pas leur "bonne" IP dans le 
> message SIP/SDP, forcément que le softphone d'en face ne pourra pas leur 
> envoyer de RTP. Genre "viens me causer sur 127.0.0.1" ça va pas marcher. 
> "Viens me causer sur 192.168.0.14" non plus. Je dis la même chose que toi 
> quand tu écris « problème de binding ».
> 
> 
> - Mail original -
> De: "David Ponzone" 
> À: "Guillaume LUCAS" 
> Cc: "frnog" 
> Envoyé: Mardi 17 Mars 2020 13:42:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> 
>> 
>> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente 
>> de la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses 
>> IP qui sont échangées dans SDP…
>> 
> 
> 
> Je ne comprends pas le sens de cette phrase (put…je vieillis) :)
> 
> ---
> 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] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 09:23:08
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)


> Je pense que Linphone est à mettre en cause. Le problème n'est pas que 
> le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP.

Peux-tu expliquer, stp ? Dans mes souvenirs. Un interlocuteur lance un appel. 
SIP INVITE vers le PABX qui transmet à l'interlocuteur (je passe 
trying/ringing, etc.). Si ça décroche, y'a échange des SDP en passant par le 
PABX. Au début, le PABX connecte chaque interlocuteur à lui (donc la 
connaissance de sa propre IP suffit pour dire "viens me causer sur cette 
IP+port avec tels codecs), puis il connecte les deux interlocuteurs directement 
en relayant simplement le SDP émis par chaque softphone. Dedans y'a l'IP+port 
et les codecs à utiliser. Pour moi Asterisk devient neutre à ce stade-là.



> Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a 
> une zone réseau local: le VPN en /16 doit y être défini

On a rien défini. Pas même le /16 RFC1918 qui héberge nos SNOM. Pas même le 
VLAN des passerelles T2.
Au niveau système, il y a une route par défaut, pas de routes vers les VLANs 
(VPN, SNOM, passerelles T2, etc.).



> Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
> d'un client qui génère cette erreur

D'acc. Mais… Comment j'identifie ce client ? Comme dit, y'a trop de bruit, je 
n'arrive pas à corréler…
La modif' se fait côté Asterisk, on est d'accord ?


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

Re: [FRnOG] [TECH] IPs blacklistées sur certains sites/matériels

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

Bonjour,

On Tue, 17 Mar 2020 12:20:45 +0100
David Ponzone  wrote:

> Je te souhaite bon courage :)
> J’ai déjà vu le cas d’un bloc venant du Japon et 2 ans après son
> transfert au RIPE, certaines banques (suisses) continuent de la refuser
> pour des accès VPN car hors-EU. Après, c’est marginal. Pour le reste, ça
> se résorbe naturellement. Le problème est que certains ne mettent à jour
> leurs filtres géo que rarement. Tu peux essayer d’ajouter ta
> géolocalisation dans le RIPE, mais je suis pas sûr que ça aide beaucoup.

Le vrai souci, c'est que la plupart des gens qui filtrent par GeoIP ne te
permettent pas de savoir quel filtre / quelle source de GeoIP ils
utilisent. Et du coup, difficile de remonter a la source pour faire
corriger de maniere globale.

Du coup, a part contacter les sites inaccessibles pour essayer d'avoir des
infos sur leur produit pour remonter la piste, pas evident.
Et les sites de GeoIP, curieusement, ne repondent pas forcement aux
demandes de correction qui leur sont faites.

Bref, comme dit David, "bon courage"... mais on a du temps, hein, on est
tous a la maison...

Paul


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 13:47, Daniel via frnog a écrit :

[..] Je donne les preuves suivantes :
   * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: 
Registered SIP 'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien 
une IP VPN. Je vois bien une IP 10.30/16 différente par softphone ;
   * Quand ils fonctionnent, les flux RTP circulent bien entre deux 
IP 10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux 
clients VPN ;
   * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, 
le serveur lui-même. mtr entre le serveur et mon ordi+VPN : un seul 
saut, mon IP VPN (10.30.1.175).
Ca c'est de l'IP, pas du SIP. Le routage IP est bon puisque les 
paquets partent et arrivent la ou ils doivent. Le problème est avec SIP

Correction, RDP

--
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] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
toujours parce que les softphones ne mettaient pas leur "bonne" IP dans le 
message SIP/SDP, forcément que le softphone d'en face ne pourra pas leur 
envoyer de RTP. Genre "viens me causer sur 127.0.0.1" ça va pas marcher. "Viens 
me causer sur 192.168.0.14" non plus. Je dis la même chose que toi quand tu 
écris « problème de binding ».


- Mail original -
De: "David Ponzone" 
À: "Guillaume LUCAS" 
Cc: "frnog" 
Envoyé: Mardi 17 Mars 2020 13:42:12
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

> 
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
> qui sont échangées dans SDP…
> 


Je ne comprends pas le sens de cette phrase (put…je vieillis) :)

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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> 
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
> qui sont échangées dans SDP…
> 


Je ne comprends pas le sens de cette phrase (put…je vieillis) :)

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 
> À: "Guillaume LUCAS" 
> Cc: "frnog" 
> Envoyé: Mardi 17 Mars 2020 07:34:53
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu es visiblement pas le seul à avoir ce problème de binding.

En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
qui sont échangées dans SDP…


> Ca vaut quand même le coup de tester Zoiper ou Bria au moins pour avoir la 
> confirmation que ça vient bien de Linphone, et ensuite tu pourras déterminer 
> si t’as envie de debugguer leur truc.

Mes collègues ont testé Zoiper sous winwin : ça ne chemar pas, personne 
s'entend, y compris quand STUN est activé. Je n'ai pas plus d'éléments, 
notamment pas de capture réseau des SDP.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

En interne, dans un VPN routé sans NAT, tu devais jamais avoir besoin de STUN.
Déjà que même avec du NAT, c’est pas nécessaire avec un SBC « intelligent » .

Tu veux pas juste essayer Zoiper gratuit ou autre, parce que perdre du temps 
sur un Linphone qui est peut-être une grosse bouze….
Opensource n’est pas synonyme de qualité.

> Le 17 mars 2020 à 13:32, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "Michel Py" 
>> À: "Daniel" , "frnog" 
>> Envoyé: Mardi 17 Mars 2020 01:19:26
>> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
>> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> 
>> Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec 
>> RFC1918, donc l'adresse du softphone est bien celle du lien physique. 
>> Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il 
>> ne devrait pas y avoir de NAT donc aucun besoin d'avoir STUN.
> 
> Raisonnement :
> 1) Notre PABX n'est pas joignable en IP depuis Internet ;
> 
> 2) D'où il faut le VPN pour s'enregistrer sur le PABX et plus si affinité ;
> 
> 3) Donc l'ordi sur lequel est installé un softphone a au moins deux 
> interfaces : eth0|wlan0 et vpn0 ;
> 
> 4) Notre VPN n'installe pas de route par défaut, juste les routes vers nos 
> réseaux internes ;
> 
> 5) Sur vpn0, il y aura une IP 10.30.x.x/16, réseau de tous nos clients VPN ;
> 
> 6) Sur eth0|wlan0, il aura l'IPv4 RFC1918 attribuée par le DHCP de sa box 
> genre 192.168.0.14/24 ;
> 
> 7) Lors de l'enregistrement sur le PABX, le softphone va émettre un SIP 
> REGISTER avec ip dst=. Le VPN offre une route /24 pour le réseau qui 
> contient le PABX, donc ça passe forcément par le VPN, donc le système 
> d'exploit' va sélectionner l'IP sur l'interface vpn0 pour la mettre dans ip 
> src du paquet IP ;
> 
> 8) Lors d'un appel, je constate, avec wireshark/tcpdump, que le softphone met 
> parfois l'IP de vpn0 (10.30.x.x) dans le paquet SDP et donc, là, ça marche de 
> base (comme ça semblait fonctionner depuis 6 mois pour les quelques 
> utilisateurs), car c'est du routage de base. Mais, souvent, il met l'IP de 
> eth0. Forcément, l'interlocuteur à l'autre bout ne peut pas envoyer de RTP 
> avec ip dst=192.168.0.14…
> 
> 9) Avec un serveur STUN sur le réseau local, la requête STUN sera contrainte, 
> par le routage, de passer dans le VPN (comme le SIP vers le PABX, voir point 
> 7) donc retournera toujours l'IP RFC1918 de vpn0. Et donc les flux RTP 
> monteront. Et c'est ce qui se passe quand les softphones ne 
> choisissent pas d'ignorer la réponse qu'ils ont eu du serveur STUN 
> et/ou qu'ils n'ignorent pas la dernière SDP reçue et/ou…
> 
> 
> Je sais qu'il ne faut plus utiliser seulement STUN, que ICE c'est mieux. Mais 
> avant d'installer un serveur STUN à l'arrache, j'ai testé ICE et ça ne 
> fonctionnait pas. Dans mes souvenirs, ICE est une méthodo qui consiste à 
> s'échanger, dans SDP, tous les couples IP+port possibles, qu'on nomme 
> candidats. On a activé ça sur les softphones et c'est activé de base dans 
> XiVo. Quand j'analyse les SDP avec tcpdump, je vois qu'une seule proposition 
> dans SDP, l'IP RFC1918 de eth0…
> 
> 
>> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au 
>> travers d'un VPN je ne vois pas pourquoi çà ne marcherait pas.
> 
> Idem ! C'est bien ce qui me prend la tête ! :)
> 
> 
>> Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT 
>> a plein nez, ceci dit.
>> Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.
> 
> Je donne les preuves suivantes :
>  * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: Registered 
> SIP 'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien une IP VPN. Je vois 
> bien une IP 10.30/16 différente par softphone ;
>  * Quand ils fonctionnent, les flux RTP circulent bien entre deux IP 
> 10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux clients VPN 
> ;
>  * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, le serveur 
> lui-même. mtr entre le serveur et mon ordi+VPN : un seul saut, mon IP VPN 
> (10.30.1.175).
> 
> 
> Pare-feu, je commence à y croire vu le merdier dans nos ACL Cisco ASA… Mais 
> comment expliquer que, sans y toucher, nos tests soient concluants de temps 
> en temps avec Linphone GNU/Linux ? Là, pour moi, ça échappe à toute 
> rationalité. Soit tu bloques constamment, soit tu laisses passer, mais pas 
> les deux.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 
> À: "Daniel" , "frnog" 
> Envoyé: Mardi 17 Mars 2020 01:19:26
> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec 
> RFC1918, donc l'adresse du softphone est bien celle du lien physique. 
> Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il 
> ne devrait pas y avoir de NAT donc aucun besoin d'avoir STUN.

Raisonnement :
1) Notre PABX n'est pas joignable en IP depuis Internet ;

2) D'où il faut le VPN pour s'enregistrer sur le PABX et plus si affinité ;

3) Donc l'ordi sur lequel est installé un softphone a au moins deux interfaces 
: eth0|wlan0 et vpn0 ;

4) Notre VPN n'installe pas de route par défaut, juste les routes vers nos 
réseaux internes ;

5) Sur vpn0, il y aura une IP 10.30.x.x/16, réseau de tous nos clients VPN ;

6) Sur eth0|wlan0, il aura l'IPv4 RFC1918 attribuée par le DHCP de sa box genre 
192.168.0.14/24 ;

7) Lors de l'enregistrement sur le PABX, le softphone va émettre un SIP 
REGISTER avec ip dst=. Le VPN offre une route /24 pour le réseau qui 
contient le PABX, donc ça passe forcément par le VPN, donc le système 
d'exploit' va sélectionner l'IP sur l'interface vpn0 pour la mettre dans ip src 
du paquet IP ;

8) Lors d'un appel, je constate, avec wireshark/tcpdump, que le softphone met 
parfois l'IP de vpn0 (10.30.x.x) dans le paquet SDP et donc, là, ça marche de 
base (comme ça semblait fonctionner depuis 6 mois pour les quelques 
utilisateurs), car c'est du routage de base. Mais, souvent, il met l'IP de 
eth0. Forcément, l'interlocuteur à l'autre bout ne peut pas envoyer de RTP avec 
ip dst=192.168.0.14…

9) Avec un serveur STUN sur le réseau local, la requête STUN sera contrainte, 
par le routage, de passer dans le VPN (comme le SIP vers le PABX, voir point 7) 
donc retournera toujours l'IP RFC1918 de vpn0. Et donc les flux RTP monteront. 
Et c'est ce qui se passe quand les softphones ne choisissent pas 
d'ignorer la réponse qu'ils ont eu du serveur STUN et/ou qu'ils n'ignorent pas 
la dernière SDP reçue et/ou…


Je sais qu'il ne faut plus utiliser seulement STUN, que ICE c'est mieux. Mais 
avant d'installer un serveur STUN à l'arrache, j'ai testé ICE et ça ne 
fonctionnait pas. Dans mes souvenirs, ICE est une méthodo qui consiste à 
s'échanger, dans SDP, tous les couples IP+port possibles, qu'on nomme 
candidats. On a activé ça sur les softphones et c'est activé de base dans XiVo. 
Quand j'analyse les SDP avec tcpdump, je vois qu'une seule proposition dans 
SDP, l'IP RFC1918 de eth0…


> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers 
> d'un VPN je ne vois pas pourquoi çà ne marcherait pas.

Idem ! C'est bien ce qui me prend la tête ! :)


> Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT 
> a plein nez, ceci dit.
> Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.

Je donne les preuves suivantes :
  * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: Registered SIP 
'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien une IP VPN. Je vois bien 
une IP 10.30/16 différente par softphone ;
  * Quand ils fonctionnent, les flux RTP circulent bien entre deux IP 
10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux clients VPN ;
  * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, le serveur 
lui-même. mtr entre le serveur et mon ordi+VPN : un seul saut, mon IP VPN 
(10.30.1.175).


Pare-feu, je commence à y croire vu le merdier dans nos ACL Cisco ASA… Mais 
comment expliquer que, sans y toucher, nos tests soient concluants de temps en 
temps avec Linphone GNU/Linux ? Là, pour moi, ça échappe à toute rationalité. 
Soit tu bloques constamment, soit tu laisses passer, mais pas les deux.


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

Re: [FRnOG] [TECH] IPs blacklistées sur certains sites/matériels

[David Ponzone]

Je te souhaite bon courage :)
J’ai déjà vu le cas d’un bloc venant du Japon et 2 ans après son transfert au 
RIPE, certaines banques (suisses) continuent de la refuser pour des accès VPN 
car hors-EU.
Après, c’est marginal. Pour le reste, ça se résorbe naturellement. Le problème 
est que certains ne mettent à jour leurs filtres géo que rarement.
Tu peux essayer d’ajouter ta géolocalisation dans le RIPE, mais je suis pas sûr 
que ça aide beaucoup.

> Le 17 mars 2020 à 12:13, g.roux via frnog  a écrit :
> 
> Bonjour, 
> Nous avons racheté un pool d'IP auprès du RIPE : 185.194.120.0/22.
> Au niveau des RIRs, tout est ok. Au niveau de la plupart des sites de
> réputation, de géolocalisation, ont est ok. 
> Cependant certains sites de geoIP continuent de nous localiser en
> Ukraine (ancienne localisation), et plusieurs clients nous remontent des
> sites inaccessibles avec ce pool (en changeant l'IP publique, ça
> fonctionne). 
> Quelqu'un sait m'aiguiller ? Quelqu'un chez un fabricant qui voit que la
> base est pas à jour ? 
> Je contacte les hebergeurs au cas par cas mais c'est un peu fastidieux
> donc je vous sollicite pour un peu d'aide :) 
> Merci d'avance,  
> [1] [2] [3] [4] 
> Guillaume ROUX 
> Ingénieur Réseau - Backbone & Edge 
> Responsable technique MER/Support 
> g.r...@netcom-group.fr 
> +33 (0)1.71.29.27.31 
> Hotline +33 (0)8.26.10.56.05 
> 
> Links:
> --
> [1] https://www.facebook.com/pages/Netcom-Group/307065979420252
> [2] https://twitter.com/netcom_group
> [3] https://fr.linkedin.com/company/netcom-group
> [4] https://www.youtube.com/user/NetcomGroupTV
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] IPs blacklistées sur certains sites/matériels

[g.roux via frnog]

Bonjour, 


Nous avons racheté un pool d'IP auprès du RIPE : 185.194.120.0/22.
Au niveau des RIRs, tout est ok. Au niveau de la plupart des sites de
réputation, de géolocalisation, ont est ok. 


Cependant certains sites de geoIP continuent de nous localiser en
Ukraine (ancienne localisation), et plusieurs clients nous remontent des
sites inaccessibles avec ce pool (en changeant l'IP publique, ça
fonctionne). 


Quelqu'un sait m'aiguiller ? Quelqu'un chez un fabricant qui voit que la
base est pas à jour ? 


Je contacte les hebergeurs au cas par cas mais c'est un peu fastidieux
donc je vous sollicite pour un peu d'aide :) 

Merci d'avance,  

[1] [2] [3] [4] 

Guillaume ROUX 

Ingénieur Réseau - Backbone & Edge 

Responsable technique MER/Support 

g.r...@netcom-group.fr 

+33 (0)1.71.29.27.31 

Hotline +33 (0)8.26.10.56.05 

 


Links:
--
[1] https://www.facebook.com/pages/Netcom-Group/307065979420252
[2] https://twitter.com/netcom_group
[3] https://fr.linkedin.com/company/netcom-group
[4] https://www.youtube.com/user/NetcomGroupTV
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] FRnOG 34.0 - RC3

[Arnaud Launay]

Le Tue, Mar 17, 2020 at 09:42:20AM +0100, Francois Demeyer a écrit:
> Ne reste plus à Philippe que passer à l’étape suivante 
> -> Un iFRnOG… 100% virtuel … édition spéciale … CRnOG

Avec de la Corona au bar.

Arnaud.


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

Re: [FRnOG] [MISC] Annonce OWF et portail plazza

[Mickael Cerqueira]

C'est une bonne surprise ! En effet !

Le lun. 16 mars 2020 à 23:38, David Ponzone  a
écrit :

> Oui ça devait être ça.
> En plus, le zip en PJ du mail était un peu foireux.
> Plusieurs décompresseurs signalaient une erreur (problème de charset dans
> le nom des fichiers), c’est au bout du 3eme que j’ai pu ouvrir le zip.
>
> Finalement c’est quand même une bonne nouvelle: grosse grosse baisse
> (jusqu’à 42% sur les plus bas débits), et Orange shoot les CELAN 2/4Mbps
> puisqu’ils sont maintenant au même prix que le 10Mbps.
> Ils deviennent carrément compétitifs maintenant sur la zone O1, ça va pas
> faire plaisir aux alternatifs qui déploient massivement sur ce secteur.
>
> > Le 16 mars 2020 à 21:10, Gary BLUM  a écrit :
> >
> > Bonjour,
> > Plazza (Comme Stéphane, pas piazza) est le "réseau social/SharePoint"
> interne à l'entreprise.
> > Seul les salariés y ont accès.
> >
> > Surement un problème de lien de la comm pour le mail reçu.
> > (Si tu l'as pas eu d'ici là et qu'il n'est pas confidentiel, communique
> moi le lien en privé)
> >
> >
> > --
> > Gary
> >
> >> -Message d'origine-
> >> De : frnog-requ...@frnog.org  De la part de
> David
> >> Ponzone
> >> Envoyé : lundi 16 mars 2020 17:54
> >> À : Frnog misc 
> >> Objet : [FRnOG] [MISC] Annonce OWF et portail plazza
> >>
> >> Aux clients OWF qui ont reçu comme moi un mail il y a quelques minutes,
> >>
> >> Vous avez compris pourquoi le lien pointait sur piazza.orange.com,
> pour lequel
> >> nous n’avons pas d’identifiant (et quand on demande à en créer un, il
> se passe
> >> pas grand chose….).
> >>
> >> Un raté au niveau du lien ?
> >>
> >> Le mail parle d’une mise à jour des tarifs en O1, mais il n’y a aucune
> mise à jour
> >> dans l’espace Documentation des offres de référence.
> >>
> >>
> >> ---
> >> 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] FRnOG 34.0 - RC3

[Jérôme Nicolle]

Plop,

> Du coup on fait quoi pour les pas farouches qui ont déjà booké le
> déplacement ? Contre-événement officieux ?

Bon, objectivement, on fait rien vendredi.

@+

-- 
Jérôme Nicolle
+33 6 19 31 27 14


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Bonjour

Le 17/03/2020 à 00:11, Guillaume LUCAS a écrit :

Bonsoir Daniel,

Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 .
A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.


sip show peers => chan_sip

pjsip list endpoints => pjsip



Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur 
le VPN avec next hop le routeur de site. Une route statique avec next hop = VPN 
existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, ce 
qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone 
(Linphone) pour que ça fonctionne… mais que sur un seul système d'exploitation.
Je pense que Linphone est à mettre en cause. Le problème n'est pas que 
le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP. 
Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a 
une zone réseau local: le VPN en /16 doit y être défini


Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with 
no response », mais je ne vois pas comment les corréler avec nos essais ? Je ne 
vois pas d'ID / chaînes de caractères en commun avec le reste du journal. Y'a 
trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ?
Donc session timeout: Essaye en mettant session-timers=refuse dans la 
config d'un client qui génère cette erreur


Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un 
collègue à la rescousse.

Voir ci dessus


Je confirme que nos postes SNOM juste marchent depuis 5 ans.

Merci.

Bonne nuit.


- Mail original -
De: "Daniel via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 16 Mars 2020 22:53:47
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Bonsoir,

tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des
différences importantes entre chan_sip et pjsip.

. les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre
sont dus à des problèmes de NAT

. les timeout peuvent être dus au session-timer et doivent se voir dans
les logs du type no response received [bla bla]

. concernant les différents échanges, les réseaux VPN sont ils définis
dans localnet (chan_sip) local_net (pjsip) ?

. j'ai rencontré pas mal de soucis à une certaine époque avec Linphone,
j'ai abandonné. Je passe en iax dès que c'est possible (zoiper). Il
semble que les problèmes rencontrés viennent de softphone, j'installe du
SNOM (sauf DECT) et du GrandStream et n'ai jamais rencontré de tels
problèmes, poste en interne ou externe.

. en dehors de cela oui, SIP est un protocole que chacun peut mettre à
sa sauce qui fait que infine la compatibilité n'est plus au RDV
(Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...)

Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit :

Bonjour à tous,

Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
j'aimerais un avis et surtout être réconforté.
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 1645 
octets arrivait du WAN. Je me souviens des erreurs de segmentation aléatoires de 
Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes à la norme et à la 
validation approximative des messages SIP reçus. Etc.
=> Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
amplitude) soit normal.
=> Je suis dans une démarche de compréhension technique des problèmes 
rencontrés, donc je ne suis pas intéressé par des alternatives à des softphones.


Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution XiVo. 
Nous avons des postes téléphoniques SNOM, des téléphones analogiques, des T2, 
etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur (en IP).

Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux internes 
sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas d'IPv6. Accès aux 
réseaux internes, pas d'accès à Internet. Pas de filtrage particulier (oui, 
n'importe quel utilisateur du VPN peut se promener dans tous les réseaux 
internes, ça va changer).

Depuis 6 mois environ, nous avons de très rares softphones Linphone 
majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN.

Jusque-là, personne nous a fait remonter des problèmes sur les softphones+VPN. 
Mais vu le peu d'utilisateurs…
Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus pour 
tout le monde.


Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit un 
seul entend l'autre.
=> Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[pisrateurboun]

Bonjour à tous,


On mixte du softphone (Zoiper) et du téléphone IP depuis 15 ans en IPsec/VPN 
SSL,anciennement MPLS sur du Asterix/Xivo/Mitel et anciennement Ericson sur des 
réseaux internes pas RFC 1918 (quelle idée mais c'est historique)
Au tout début j'ai eu des problèmes d'implémentations à cause du NAT et/ou des 
ACL, parfois parce qu'il n'y a pas que du 5060 mais du 5061 ou parce que les 
communications coupaient au bout de 15 minutes à cause du routeur central. 
Depuis qu'on a éliminé le NAT je n'ai plus ce soucis, SAUF lors d'une 
expérimentions en TSE multi-utilisateur avec 1 IP par utilisateur.
Petite précision, pas besoin d'utiliser de STUN ou de proxy NAT SBC.

Ah si, j'ai encore un site avec passerelle externe et NAT qui me fait des 
communications blanches sur certains SDA et opérateurs.


@+

Clément


- Mail original -
De: "Guillaume LUCAS" 
À: frnog-t...@frnog.org
Envoyé: Lundi 16 Mars 2020 22:05:07
Objet: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Bonjour à tous, 

Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
j'aimerais un avis et surtout être réconforté. 
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 
1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation 
aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes à 
la norme et à la validation approximative des messages SIP reçus. Etc. 
=> Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
amplitude) soit normal. 
=> Je suis dans une démarche de compréhension technique des problèmes 
rencontrés, donc je ne suis pas intéressé par des alternatives à des 
softphones. 


Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution XiVo. 
Nous avons des postes téléphoniques SNOM, des téléphones analogiques, des T2, 
etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur (en IP). 

Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux internes 
sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas d'IPv6. Accès aux 
réseaux internes, pas d'accès à Internet. Pas de filtrage particulier (oui, 
n'importe quel utilisateur du VPN peut se promener dans tous les réseaux 
internes, ça va changer). 

Depuis 6 mois environ, nous avons de très rares softphones Linphone 
majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN. 

Jusque-là, personne nous a fait remonter des problèmes sur les softphones+VPN. 
Mais vu le peu d'utilisateurs… 
Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus pour 
tout le monde. 


Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit un 
seul entend l'autre. 
=> Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas. 
=> On installe un serveur STUN dans le réseau de l'organisation. On configure 
STUN dans les paramètres de Linphone et ça fonctionne. 
=> Notons que certains Linphone fonctionnent aléatoirement et temporairement 
sans STUN. Même chose avec Jitsi. Comment est-ce possible ? 
=> Un Wireshark nous montre qu'une fois l'échange SIP initié, le client cause 
en STUN au PABX et que celui-ci répond. Pourquoi ça ne suffit pas toujours ? 
C'est d'ailleurs bizarre, car aucun serveur STUN écoute en permanence, on 
dirait que c'est fait à la demande ? 


Deuxième problème. Lors d'une conversation entre un Linphone 3.11 empaqueté 
dans Debian GNU/Linux ou Ubuntu GNU/Linux et un Linphone 4.1.1 GNU/Linux 
distribué via Flatpak, si c'est le Linphone 4.1.1 qui initie la conversation, 
la conversation durera 31/32 secs au maximum avant raccrochage auto. 
=> Pas de soucis si c'est le Linphone 3.11 qui initie la conversation. 
=> Pas de problème quand le Linphone 4.1.1 cause à un SNOM ou à un 06/09 
externe. 
=> Rien d'évident dans le journal des deux Linphone. 
=> Côté Asterisk, on voit que le Linphone 4.1.1 quitte le « 'native_rtp' 
basic_bridge », donc Asterisk nettoie, à raison, avec code retour != 0. 
=> Wireshark montre un Asterisk qui envoie, au Linphone 4.1.1, un SIP BYE avec 
un entête « X-Asterisk-HangupCause: no user responding ». 
=> Pas de pare-feu, pas de NAT. 
=> Nous pensons que le Linphone 3.11 n'envoie pas un message SIP attendu par 
son interlocuteur. Ou paquet malformé. Ou Linphone 4.1.1 plus strict. Ou… 
==> Solution : sur GNU/Linux, utiliser Linphone 3.12 (+STUN, bien entendu) 
partout. Ça fonctionne impec', sans exception. 


Troisième problème. Le journal du VPN nous montre parfois des paquets UDP 
bloqués entre le serveur Asterisk et un client VPN. C'est très peu 

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

https://superuser.com/questions/1133293/linphone-sip-invite-providing-wrong-ip-on-multi-nic-system

Tu es visiblement pas le seul à avoir ce problème de binding.
Pas beaucoup de discussion sur ce sujet néanmoins.
Ca vaut quand même le coup de tester Zoiper ou Bria au moins pour avoir la 
confirmation que ça vient bien de Linphone, et ensuite tu pourras déterminer si 
t’as envie de debugguer leur truc.

David Ponzone



> Le 17 mars 2020 à 00:12, Guillaume LUCAS  a 
> écrit :
> 
> Bonsoir Daniel,
> 
> Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 .
> A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.
> 
> Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
> autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur 
> le VPN avec next hop le routeur de site. Une route statique avec next hop = 
> VPN existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, 
> ce qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone 
> (Linphone) pour que ça fonctionne… mais que sur un seul système 
> d'exploitation.
> 
> Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with 
> no response », mais je ne vois pas comment les corréler avec nos essais ? Je 
> ne vois pas d'ID / chaînes de caractères en commun avec le reste du journal. 
> Y'a trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ?
> 
> Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un 
> collègue à la rescousse.
> 
> Je confirme que nos postes SNOM juste marchent depuis 5 ans.

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