RE: [FRnOG] [TECH] Questions Nexus 3000

[Michel Py]

> Raphael Mazelier a écrit :
> Cisco et les autres poussent leurs propres technologies/protocoles plus dans 
> une logique de locking 
> des utilisateurs que dans une vraie réflexion de fond sur les besoins du 
> réseau de nos jours.

C'est moins pire que dans le passé, je pense. Par exemple, ils ont publié les 
specs d'EIGRP, dans le temps c'était mentalement pas possible.

> Il est indéniable que Cisco a été vecteur d'innovation dans le réseau. Mais 
> s'il n'avait pas été la
> quelqu'un l'autre fait différemment et on aurait peut être des protocoles 
> mieux foutu ?
> Dans bien des cas on a normalisé un protocole propriétaire cisco quasi à 
> l'identique. Bien ou pas ?

Cà dépend du protocole. ISL et HSRP, çà marchait plutôt bien. Les bousins que 
Cisco a produit personne ne les a copiés !


> Guillaume Barrot a écrit :
> Voire même ... quand je pense qu'il y en a qui ont monté des backbones en 
> EiGRP quoi !

Pour quelques malheureuses centaines de routes c'est parfait ceci dit.


> Olivier Benghozi a écrit :
> T'as pas saisi le point, Michel. Le point c'est :
> Si tu utilises un protocole pour propager les définitions de vlans et 
> associations automagiques
> sur les trunks ; propriétaire ou pas [VTP, GVRP, MVRP] ; alors quand ça va 
> t'exploser entre les
> mains pour une raison ou une autre, ce sera triste mais inévitable.

Je me suis fais avoir une fois, je le connais le coup du switch que tu sors du 
circuit, bidouille la config, et le remet dans le réseau avec une révision plus 
grande que celle du réseau de prod et pouf voila tous les VLANs qui se barrent 
en cacahouète. Michel a testé pour vous :P

Si j'ai envie de continuer a vivre dans le même danger qu'il y a 20 ans, c'est 
mon réseau. Pour 3 switches je vais pas installer une usine à gaz, donc je vais 
faire du copier / coller, et çà c'est encore plus dangereux que n'importe quel 
protocole.

Michel.
 



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

[FRnOG] [JOBS] Jeune diplômé recherche poste d'ingénieur réseau

[Mohammed El Amine REZINE]

Bonjour à tous,

Actuellement en stage de fin d'études de mastère spécialisé à Télécom
SudParis, je suis à la recherche d'un premier job pour entamer une belle
carrière d'ingénieur réseau :)

Mon sujet de stage consistait à valider les protocoles réseaux sur un
nouvel OLT Huawei pour un opérateur télécom BtoB.

Certifié CCNP, j'ai pu travailler avec différents équipementiers tels que
Cisco, Huawei, Nokia, je saurais m'adapter à différents environnements
techniques.

Etant étranger sous visa étudiant, un changement de statut est nécessaire
pour pouvoir travailler.

Si vous êtes intéressé par mon profil, n’hésitez pas à me contacter pour en
discuter davantage par mail ou par téléphone.

Merci à tous,
*Mohammed El Amine REZINE*
Ingénieur Réseau CCNP

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

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[Julien Escario]

Le 11/07/2017 à 16:50, David Ponzone a écrit :
> Tu y vas fort :)
> 
> Je dis ça parce que tu as lancé le sujet en disant que le Mikrotik te donnait 
> « could not determine local IP address » .
> Ou alors c’était le message d’erreur du côté du client PPP après la déco ?

Très juste. Je pense que c'était un message de la part du LNS qui ne parvenait
pas à négocier la session L2TP et à monter l'interface virtuelle. Donc 'could
not determine local IP address' après un timeout autour de 90s.

Sans debug fin, oui, c'est assez capillotracté.

Julien



smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [misc] Mikrotik en tant que LNS (L2TP)

[Julien Escario]

Le 11/07/2017 à 16:50, Sébastien Lesimple a écrit :
> On 11/07/2017 16:43, Julien Escario wrote:
>> Le 11/07/2017 à 16:37, David Ponzone a écrit :
>>> Ouais et merci à Mikrotik pour son message d’erreur sans rapport avec le 
>>> problème :)
>> Bah pour le coup, je te trouve plutôt langue de pute :
> On aime bien faire les LDP de temps en temps.
> Mais c par méchant :))

Ah mais chuis pas vexé ;-) Mon LNS par contre, faudra pas essayer de se logguer
dessus maintenant (il lit cette-liste-dont-il-faut-taire-le-nom).

Pis faire la LDP de temps en temps, ça fait du bien et les constructeurs, quels
qu'ils soient le méritent bien de temps à autre.

Ceci étant dit, j'en conviens, c'eût été plus simple avec du Cisco. Il y a des
masses d'exemples de conf partout.

Julien



smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [misc] Mikrotik en tant que LNS (L2TP)

[Sébastien Lesimple]

On 11/07/2017 16:43, Julien Escario wrote:
> Le 11/07/2017 à 16:37, David Ponzone a écrit :
>> Ouais et merci à Mikrotik pour son message d’erreur sans rapport avec le 
>> problème :)
> Bah pour le coup, je te trouve plutôt langue de pute :
On aime bien faire les LDP de temps en temps.
Mais c par méchant :))

> sent LCP ConfRej id=0x4c
> 
>
> Ca me paraît plutôt parlant non ? ConfRej / ConfAck.
>
> Julien
>
>>> Le 11 juil. 2017 à 16:18, Julien Escario  a écrit :
>>>
>>> Le 11/07/2017 à 14:14, Julien Escario a écrit :
 Le 11/07/2017 à 13:24, David Ponzone a écrit :
> Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie 
> une requête pour le realm seul avant de t’envoyer une requête pour le 
> login complet ?
 Je ne suis pas certain de savoir le dire précisément mais, à priori, non.

 J'ai bien deux requêtes Accept-Request mais elles intègrent à chaque fois :
 User-Name = "t...@azylog.ptel.ipadsl"

 Et mon radius répond bien Access-Accept les deux fois.

 Est-ce c'est utile que je fasse un découpage propre des logs de freeradius 
 ?
 J'ai tendance à dire que le problème est après (aka côté krotik) et que ça 
 va
 surtout générer beaucoup de bruit si je copie/colle ça ici.
>>> Found it ! Un problème de négociation du MRRU :
>>>
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : rcvd LCP 
>>> ConfReq id=0x4c
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : sent LCP 
>>> ConfRej id=0x4c
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>>
>>> J'ai passé le MRRU à 1600 côté krotik et c'est passé tout droit cette fois 
>>> (ppp
>>> / interface / l2tp server). Pour info, avec une valeur à 2500, ça fonctionne
>>> tout aussi bien. On doit parler de valeur maximale pour cette négociation.
>>>
>>> Il a quand même fallu que je me paluche le debug du l2tp ligne par ligne ...
>>>
>>> 'fin, bref, merci pour l'aide à la réflexion.
>>>
>>> Julien
>>>
>


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

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[David Ponzone]

Tu y vas fort :)

Je dis ça parce que tu as lancé le sujet en disant que le Mikrotik te donnait « 
could not determine local IP address » .
Ou alors c’était le message d’erreur du côté du client PPP après la déco ?

> Le 11 juil. 2017 à 16:43, Julien Escario  a écrit :
> 
> Le 11/07/2017 à 16:37, David Ponzone a écrit :
>> Ouais et merci à Mikrotik pour son message d’erreur sans rapport avec le 
>> problème :)
> 
> Bah pour le coup, je te trouve plutôt langue de pute :
> sent LCP ConfRej id=0x4c
> 
> 
> Ca me paraît plutôt parlant non ? ConfRej / ConfAck.
> 
> Julien
> 
>>> Le 11 juil. 2017 à 16:18, Julien Escario  a écrit :
>>> 
>>> Le 11/07/2017 à 14:14, Julien Escario a écrit :
 Le 11/07/2017 à 13:24, David Ponzone a écrit :
> Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie 
> une requête pour le realm seul avant de t’envoyer une requête pour le 
> login complet ?
 
 Je ne suis pas certain de savoir le dire précisément mais, à priori, non.
 
 J'ai bien deux requêtes Accept-Request mais elles intègrent à chaque fois :
 User-Name = "t...@azylog.ptel.ipadsl"
 
 Et mon radius répond bien Access-Accept les deux fois.
 
 Est-ce c'est utile que je fasse un découpage propre des logs de freeradius 
 ?
 J'ai tendance à dire que le problème est après (aka côté krotik) et que ça 
 va
 surtout générer beaucoup de bruit si je copie/colle ça ici.
>>> 
>>> Found it ! Un problème de négociation du MRRU :
>>> 
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : rcvd LCP 
>>> ConfReq id=0x4c
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : sent LCP 
>>> ConfRej id=0x4c
>>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>> 
>>> J'ai passé le MRRU à 1600 côté krotik et c'est passé tout droit cette fois 
>>> (ppp
>>> / interface / l2tp server). Pour info, avec une valeur à 2500, ça fonctionne
>>> tout aussi bien. On doit parler de valeur maximale pour cette négociation.
>>> 
>>> Il a quand même fallu que je me paluche le debug du l2tp ligne par ligne ...
>>> 
>>> 'fin, bref, merci pour l'aide à la réflexion.
>>> 
>>> Julien
>>> 
>> 
> 
> 


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

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[Julien Escario]

Le 11/07/2017 à 16:37, David Ponzone a écrit :
> Ouais et merci à Mikrotik pour son message d’erreur sans rapport avec le 
> problème :)

Bah pour le coup, je te trouve plutôt langue de pute :
sent LCP ConfRej id=0x4c


Ca me paraît plutôt parlant non ? ConfRej / ConfAck.

Julien

>> Le 11 juil. 2017 à 16:18, Julien Escario  a écrit :
>>
>> Le 11/07/2017 à 14:14, Julien Escario a écrit :
>>> Le 11/07/2017 à 13:24, David Ponzone a écrit :
 Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie 
 une requête pour le realm seul avant de t’envoyer une requête pour le 
 login complet ?
>>>
>>> Je ne suis pas certain de savoir le dire précisément mais, à priori, non.
>>>
>>> J'ai bien deux requêtes Accept-Request mais elles intègrent à chaque fois :
>>> User-Name = "t...@azylog.ptel.ipadsl"
>>>
>>> Et mon radius répond bien Access-Accept les deux fois.
>>>
>>> Est-ce c'est utile que je fasse un découpage propre des logs de freeradius ?
>>> J'ai tendance à dire que le problème est après (aka côté krotik) et que ça 
>>> va
>>> surtout générer beaucoup de bruit si je copie/colle ça ici.
>>
>> Found it ! Un problème de négociation du MRRU :
>>
>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : rcvd LCP ConfReq 
>> id=0x4c
>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : sent LCP ConfRej 
>> id=0x4c
>> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
>>
>> J'ai passé le MRRU à 1600 côté krotik et c'est passé tout droit cette fois 
>> (ppp
>> / interface / l2tp server). Pour info, avec une valeur à 2500, ça fonctionne
>> tout aussi bien. On doit parler de valeur maximale pour cette négociation.
>>
>> Il a quand même fallu que je me paluche le debug du l2tp ligne par ligne ...
>>
>> 'fin, bref, merci pour l'aide à la réflexion.
>>
>> Julien
>>
> 




smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[David Ponzone]

Ouais et merci à Mikrotik pour son message d’erreur sans rapport avec le 
problème :)


> Le 11 juil. 2017 à 16:18, Julien Escario  a écrit :
> 
> Le 11/07/2017 à 14:14, Julien Escario a écrit :
>> Le 11/07/2017 à 13:24, David Ponzone a écrit :
>>> Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie 
>>> une requête pour le realm seul avant de t’envoyer une requête pour le login 
>>> complet ?
>> 
>> Je ne suis pas certain de savoir le dire précisément mais, à priori, non.
>> 
>> J'ai bien deux requêtes Accept-Request mais elles intègrent à chaque fois :
>> User-Name = "t...@azylog.ptel.ipadsl"
>> 
>> Et mon radius répond bien Access-Accept les deux fois.
>> 
>> Est-ce c'est utile que je fasse un découpage propre des logs de freeradius ?
>> J'ai tendance à dire que le problème est après (aka côté krotik) et que ça va
>> surtout générer beaucoup de bruit si je copie/colle ça ici.
> 
> Found it ! Un problème de négociation du MRRU :
> 
> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : rcvd LCP ConfReq 
> id=0x4c
> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : sent LCP ConfRej 
> id=0x4c
> Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
> 
> J'ai passé le MRRU à 1600 côté krotik et c'est passé tout droit cette fois 
> (ppp
> / interface / l2tp server). Pour info, avec une valeur à 2500, ça fonctionne
> tout aussi bien. On doit parler de valeur maximale pour cette négociation.
> 
> Il a quand même fallu que je me paluche le debug du l2tp ligne par ligne ...
> 
> 'fin, bref, merci pour l'aide à la réflexion.
> 
> Julien
> 


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

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[Julien Escario]

Le 11/07/2017 à 14:14, Julien Escario a écrit :
> Le 11/07/2017 à 13:24, David Ponzone a écrit :
>> Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie une 
>> requête pour le realm seul avant de t’envoyer une requête pour le login 
>> complet ?
> 
> Je ne suis pas certain de savoir le dire précisément mais, à priori, non.
> 
> J'ai bien deux requêtes Accept-Request mais elles intègrent à chaque fois :
> User-Name = "t...@azylog.ptel.ipadsl"
> 
> Et mon radius répond bien Access-Accept les deux fois.
> 
> Est-ce c'est utile que je fasse un découpage propre des logs de freeradius ?
> J'ai tendance à dire que le problème est après (aka côté krotik) et que ça va
> surtout générer beaucoup de bruit si je copie/colle ça ici.

Found it ! Un problème de négociation du MRRU :

Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : rcvd LCP ConfReq 
id=0x4c
Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
Jul/11/2017 14:59:06 l2tp,ppp,debug,packet
Jul/11/2017 14:59:06 l2tp,ppp,debug,packet  : sent LCP ConfRej 
id=0x4c
Jul/11/2017 14:59:06 l2tp,ppp,debug,packet

J'ai passé le MRRU à 1600 côté krotik et c'est passé tout droit cette fois (ppp
/ interface / l2tp server). Pour info, avec une valeur à 2500, ça fonctionne
tout aussi bien. On doit parler de valeur maximale pour cette négociation.

Il a quand même fallu que je me paluche le debug du l2tp ligne par ligne ...

'fin, bref, merci pour l'aide à la réflexion.

Julien



smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Radu-Adrian Feurdean]

Bonjour,

Si "association 1901" ca va pas pour certains, et "societe commerciale"
va pas pour d'autres, je trouve que le melange des deux, tel qu'il est
en place chez France-IX par exemple, va pas si mal que ca: il y a une
association qui est seul actionnaire d'une SAS. Les clients de la SAS
deviennent (de memoire par contrat) membres de l'association. Le
resultat est pas mal, les prix de la SAS ont une tendance a la baisse.

Apres bon, l'APNF est lie a des services "voix", ou de base les usines a
gas sont la regle, et faire des choses simples et efficaces ne semble
pas possible par principe


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

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Sébastien Lesimple]

On 11/07/2017 14:31, Francois Demeyer wrote:
> Donc, si je te comprends, tu préférerait une SA comemrciale, qui ferait des 
> bénefs et verserait des dividendes aux actionnaires, plutot qu’une 
> association a bénefice nul, et dont tu sous-entends que les permanents tapent 
> dans la caisse ?
Je ne sous entend rien, encore moins que quelqu'un "tape dans la caisse".
Je considère que quitte a avoir une activité commerciale, autant le
faire dans le cadre d'une structure juridique assumant sa forme commerciale.

Cela éviterait justement que d'aucuns s'interrogent sur la structure
tarifaire d'une offre de service, vis à vis de ses coûts
(réels/supposés/fantasmagoriques et imaginaires), lorsque tout cela est
rendu, "à but non lucratif".

A présent, si les écritures comptables sont à la disposition du public,
curieux que je suis, je veux bien jeter un oeil ;)

> Tu aurais la compta ou des faits a nous montrer pour étayer ta vision de 
> l’affaire ?
>
>> Le 11 juil. 2017 à 14:17, Sébastien Lesimple 
>>  a écrit :
>>
>> On 11/07/2017 13:59, Francois Demeyer wrote:
 Le 11 juil. 2017 à 13:40, Sébastien Lesimple 
  a écrit :

 Bon ben, David, je te laisses piloter hein ;)

 RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
 Une entreprise commerciale, qui assume sa nature au lieu d'une
 association à but pseudo "non" lucratif.
>>> pourquoi « pseudo » ? elle fait des bénéf l’APNF ? Association loi 1901.. 
>>> no benef..
>> Une association peut faire des bénéfices ce n'est pas incompatible avec
>> son statut, c'est l'usage qui en est fait qui peut etre tendancieux.
>> Les utiliser pour son objet associatif, constituer de la réserve de
>> trésorerie, c'est normal.
>>
>> La distribution sous forme de primes, commissions, salaires, prestations
>> de services externes, véhicules, et j'en passe, sont autants de moyens
>> de "fuiter" des ressources, qui fait intelligemment n’enfreins pas les
>> règles comptables et fiscales.
>> Mais là on tombe dans le biais du "c'est légal j'ai le droit" vs
>> entubage intellectuel...
>>
>> Et donc plutôt que de biaiser, je trouve bien plus efficace d’être
>> entreprise commerciale, d'annoncer la couleur des le début, et gérer un
>> set de services aux fins de profits et d'y associer l'ensemble des
>> utilisateurs qui, en l'espèce, utiliseront le service pour
>> l'amélioration de leur propre business.
>>
>> Le plan association a but non lucratif dans nos métier, cela me parait
>> antinomique.
>>
 Chaque client devenant actionnaire de l'entité en question en proportion
 de son usage et participant aux coûts mais aussi au résultats avec une
 représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
 modestes…
>>> Même dans des organisation de l’univers open hors de France, j’ai comme 
>>> l’impression que les gros emportent souvent le pompon.. suffit de voir les 
>>> normalisations 802 par exemple…. 
>>>
 Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
 Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
 retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
 à cette organisation hypothétique serait bien plus sage.
 D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
 piloter un bon gros stack de virtualisation (your choice of the flavor).
 Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
 grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)

 Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
 dézinguer les surcharges d'opérateur de transit, par exemple.
 Et une solution de parutions annuaires, parce-que ca aussi c'est bien
 daubé dans le genre.

 Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
 tous nettement plus simple.
 J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
 opensource mais ca me démange...


 On 11/07/2017 12:29, David Ponzone wrote:
> Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de 
> l’année, on redistribue l’argent aux membres.
>>> Pas de benef dans une associaiton, donc pas de redistribution.
>>>
> Les membres devraient bien sûr si possible avoir le même poids quelque 
> soit leur taille.
> Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
> 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
> Evidemment, la structure de coût devrait être la plus saine possible en 
> limitant  l’appel à la sous-traitance..
>>> Sur ce point, c’est toujours discutable en effet… des employés permanents 
>>> vs de la sous-traitance.. on en reparle après la nouvelle loi travail ? ;-)
>>>
> Et la structure devrait faire appel autant que possible aux ressources 
> déjà payées en partie par l’Etat (Cloudwatt, Numergy, 

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[David Ponzone]

Sébastien,

hmm je suis pas trop d’accord avec l’idée d’une société commerciale.
Il me semble qu’il serait trop complexe de faire entrer/sortir un nouvel 
actionnaire donc ça me semble contradictoire avec ton idée précédente: «  
Chaque client devenant actionnaire de l’entité »..
Tu reviens donc à une société commerciale qui fournit un service à des clients 
qui paient un service non ?
Mais est-ce que ça ne devrait pas plutôt être un service public, 
supervisé/intégré par l’ARCEP ?

Pour Cloudwatt/Numergy, je ne pensais pas déclencher un tel emportement: je 
pensais juste que l’entité en question pouvait avoir de la colo/cloud chez 
différents acteurs pour fournir un service redondant. Mais effectivement, 
j’avais oublié qu’on s’était fait encore avoir et que ces 2 là étaient 
maintenant purement privés.


> Le 11 juil. 2017 à 14:17, Sébastien Lesimple 
>  a écrit :
> 
> On 11/07/2017 13:59, Francois Demeyer wrote:
>>> Le 11 juil. 2017 à 13:40, Sébastien Lesimple 
>>>  a écrit :
>>> 
>>> Bon ben, David, je te laisses piloter hein ;)
>>> 
>>> RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
>>> Une entreprise commerciale, qui assume sa nature au lieu d'une
>>> association à but pseudo "non" lucratif.
>> pourquoi « pseudo » ? elle fait des bénéf l’APNF ? Association loi 1901.. no 
>> benef..
> Une association peut faire des bénéfices ce n'est pas incompatible avec
> son statut, c'est l'usage qui en est fait qui peut etre tendancieux.
> Les utiliser pour son objet associatif, constituer de la réserve de
> trésorerie, c'est normal.
> 
> La distribution sous forme de primes, commissions, salaires, prestations
> de services externes, véhicules, et j'en passe, sont autants de moyens
> de "fuiter" des ressources, qui fait intelligemment n’enfreins pas les
> règles comptables et fiscales.
> Mais là on tombe dans le biais du "c'est légal j'ai le droit" vs
> entubage intellectuel...
> 
> Et donc plutôt que de biaiser, je trouve bien plus efficace d’être
> entreprise commerciale, d'annoncer la couleur des le début, et gérer un
> set de services aux fins de profits et d'y associer l'ensemble des
> utilisateurs qui, en l'espèce, utiliseront le service pour
> l'amélioration de leur propre business.
> 
> Le plan association a but non lucratif dans nos métier, cela me parait
> antinomique.
> 
>> 
>>> Chaque client devenant actionnaire de l'entité en question en proportion
>>> de son usage et participant aux coûts mais aussi au résultats avec une
>>> représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
>>> modestes…
>> Même dans des organisation de l’univers open hors de France, j’ai comme 
>> l’impression que les gros emportent souvent le pompon.. suffit de voir les 
>> normalisations 802 par exemple…. 
>> 
>>> Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
>>> Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
>>> retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
>>> à cette organisation hypothétique serait bien plus sage.
>>> D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
>>> piloter un bon gros stack de virtualisation (your choice of the flavor).
>>> Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
>>> grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)
>>> 
>>> Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
>>> dézinguer les surcharges d'opérateur de transit, par exemple.
>>> Et une solution de parutions annuaires, parce-que ca aussi c'est bien
>>> daubé dans le genre.
>>> 
>>> Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
>>> tous nettement plus simple.
>>> J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
>>> opensource mais ca me démange...
>>> 
>>> 
>>> On 11/07/2017 12:29, David Ponzone wrote:
 Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de 
 l’année, on redistribue l’argent aux membres.
>> Pas de benef dans une associaiton, donc pas de redistribution.
>> 
 Les membres devraient bien sûr si possible avoir le même poids quelque 
 soit leur taille.
 Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
 Evidemment, la structure de coût devrait être la plus saine possible en 
 limitant  l’appel à la sous-traitance..
>> Sur ce point, c’est toujours discutable en effet… des employés permanents vs 
>> de la sous-traitance.. on en reparle après la nouvelle loi travail ? ;-)
>> 
 Et la structure devrait faire appel autant que possible aux ressources 
 déjà payées en partie par l’Etat (Cloudwatt, Numergy, etc..).
>> Ahem.. si on pouvais jeter un voile pudique sur ces deux gouffres, ils n’ont 
>> rien a voir avec la porta et autres bases d’urgence
>> 
 Et la même structure pour le fixe et le mobile 

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Jérôme Marteaux]

Surtout qu'il y aurait alors un problème de conflit d'intérêt manifeste.

Cette structure aurait la fâcheuse tendance à prioriser les demandes émanant
de ces actionnaires au détriment de ces clients lambda. Une forme de lobying en 
quelque sorte.

Dans tous les cœurs de métiers (autre que télécom), les tiers de confiance
sont souvent des co-entreprises ou des GIE.


Le 11/07/2017 à 14:31, Francois Demeyer a écrit :
> Donc, si je te comprends, tu préférerait une SA comemrciale, qui ferait des 
> bénefs et verserait des dividendes aux actionnaires, plutot qu’une 
> association a bénefice nul, et dont tu sous-entends que les permanents tapent 
> dans la caisse ?
> Tu aurais la compta ou des faits a nous montrer pour étayer ta vision de 
> l’affaire ?
>
>> Le 11 juil. 2017 à 14:17, Sébastien Lesimple 
>>  a écrit :
>>
>> On 11/07/2017 13:59, Francois Demeyer wrote:
 Le 11 juil. 2017 à 13:40, Sébastien Lesimple 
  a écrit :

 Bon ben, David, je te laisses piloter hein ;)

 RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
 Une entreprise commerciale, qui assume sa nature au lieu d'une
 association à but pseudo "non" lucratif.
>>> pourquoi « pseudo » ? elle fait des bénéf l’APNF ? Association loi 1901.. 
>>> no benef..
>> Une association peut faire des bénéfices ce n'est pas incompatible avec
>> son statut, c'est l'usage qui en est fait qui peut etre tendancieux.
>> Les utiliser pour son objet associatif, constituer de la réserve de
>> trésorerie, c'est normal.
>>
>> La distribution sous forme de primes, commissions, salaires, prestations
>> de services externes, véhicules, et j'en passe, sont autants de moyens
>> de "fuiter" des ressources, qui fait intelligemment n’enfreins pas les
>> règles comptables et fiscales.
>> Mais là on tombe dans le biais du "c'est légal j'ai le droit" vs
>> entubage intellectuel...
>>
>> Et donc plutôt que de biaiser, je trouve bien plus efficace d’être
>> entreprise commerciale, d'annoncer la couleur des le début, et gérer un
>> set de services aux fins de profits et d'y associer l'ensemble des
>> utilisateurs qui, en l'espèce, utiliseront le service pour
>> l'amélioration de leur propre business.
>>
>> Le plan association a but non lucratif dans nos métier, cela me parait
>> antinomique.
>>
 Chaque client devenant actionnaire de l'entité en question en proportion
 de son usage et participant aux coûts mais aussi au résultats avec une
 représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
 modestes…
>>> Même dans des organisation de l’univers open hors de France, j’ai comme 
>>> l’impression que les gros emportent souvent le pompon.. suffit de voir les 
>>> normalisations 802 par exemple…. 
>>>
 Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
 Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
 retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
 à cette organisation hypothétique serait bien plus sage.
 D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
 piloter un bon gros stack de virtualisation (your choice of the flavor).
 Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
 grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)

 Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
 dézinguer les surcharges d'opérateur de transit, par exemple.
 Et une solution de parutions annuaires, parce-que ca aussi c'est bien
 daubé dans le genre.

 Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
 tous nettement plus simple.
 J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
 opensource mais ca me démange...


 On 11/07/2017 12:29, David Ponzone wrote:
> Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de 
> l’année, on redistribue l’argent aux membres.
>>> Pas de benef dans une associaiton, donc pas de redistribution.
>>>
> Les membres devraient bien sûr si possible avoir le même poids quelque 
> soit leur taille.
> Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
> 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
> Evidemment, la structure de coût devrait être la plus saine possible en 
> limitant  l’appel à la sous-traitance..
>>> Sur ce point, c’est toujours discutable en effet… des employés permanents 
>>> vs de la sous-traitance.. on en reparle après la nouvelle loi travail ? ;-)
>>>
> Et la structure devrait faire appel autant que possible aux ressources 
> déjà payées en partie par l’Etat (Cloudwatt, Numergy, etc..).
>>> Ahem.. si on pouvais jeter un voile pudique sur ces deux gouffres, ils 
>>> n’ont rien a voir avec la porta et autres bases d’urgence
>>>
> Et la même structure pour le fixe et le 

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Jérôme Marteaux]

Jusqu'ici seul le rôle de coordinateur administratif des portabilités a été 
évoqué.

Mais l'APNF joue également le rôle de plateforme de "normalisation" des
flux technique et monétaire entre les opérateurs.
Elle prépare, concerte, met en place et opère avec les opérateurs les réformes, 
par
exemple la dernière en date: la réforme C+S des SVA.

De mon point de vue, c'est un bien plus gros morceau que de maintenir
une base de données des numéros portés.
Vu certains schémas technique et financiers de numéros SVA portés, c'est
bien galère. (on pourra s'interroger sur le fait que 99% des numéros portés sont
sur un schéma simple et pour les 1% de bizarrerie on va complexifie à l’extrême
l'ensemble du modèle).

J'ai l'impression que l'ARCEP a créé l'APNF pour un gain d'efficacité.
Les opérateurs discutant entre membres compétents sans reproduire le schéma 
habituel
des consultations, réponses, projet de réglementation, réglementation et on 
recommence.
(les cycles de consultation de l'ARCEP, c'est quoi ? 3 ans ? 5 ans ?)

En supprimant la paperasserie, l'APNF permet d'aller assez vite dans ces 
discutions et
dans l'application des nouveaux textes.
Je me demande combien de temps aurait pris la réforme C+S si elle avait été 
menée par
l'ARCEP, combien de cycles  auraient été nécessaires avant le passage réel à 
C+S ?


Ceux qui font vivre et qui animent (participent activement aux travaux de) 
l'APNF sont
les opérateurs qui ont un intérêt économique à le faire, regardez la liste des 
membres
fondateurs.
N'oubliez pas que ces membres sont des historiques de la téléphonie dont leur 
ADN
est basé sur:
 * la tarification à la minute et suivant la destination
 * où la moindre opération/option est payante
 * le churn est maintenu le plus petit possible par certaines pratiques que 
l'on connaît

Donc pourquoi faciliter à l’extrême les opérations administratives ? 
L'efficience n'est pas
l'objectif de ces opérateurs.
L'objectif est que tous les acteurs de la chaîne de valeurs arrivent à se 
rémunérer:
opérateur cédant, prenant, intermédiaire, transitaire, éditeur, opérateur 
technique, ...

Concernant l'émergence d'une alternative, ça me paraît difficile, car vous 
n'adressez
que la partie administrative et opérationnelle de la portabilité et pas tous 
les travaux
annexes.
N'attendez pas que l'APNF fasse la révolution, l'APNF est une émanation des 
opérateurs
de téléphonie fixe et par là même, l'APNF va défendre leurs intérêts.
Les opérateurs établis ne vont pas se tirer une balle dans le pied !


Le régulateur étant soucieux de développer l'économie du marché en question, le 
régulateur
n'a qu'une oreille attentive aux gros du marché. Les petits n'ont pas 
d'importance.

La révolution ne peut venir que par l'émergence d'une nouvelle technologie ou 
bien
par le politique (qui va imposer au régulateur, qui l'imposera aux acteurs).
Le politique a l'oreille qui écoute encore une fois les gros du marché (parfois 
les consommateurs
mais c'est rare, exemple le roaming en Europe), donc perdu de ce côté-là.

Ne reste que l'émergence d'une nouvelle technologie et qui devra être porté par
des acteurs différents des acteurs déjà en place (à savoir les gros opérateurs 
actuels),
donc à vos claviers !


Le 10/07/2017 à 16:28, Sébastien Lesimple a écrit :
> C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
> hors controle du régulateur.
>
> On 10/07/2017 16:02, Guillaume wrote:
>> Te donner libre accès à un outil qui est nécessaire à tout opérateur
>> pour pouvoir faire correctement son travail ? Mais tu es fou, ça
>> serait s'asseoir sur une manne financière qui tombe gracieusement
>> chaque mois, un peu comme les majors qui se font payer leur lutte
>> anti-piratage par l'état (et les contribuables) avec la Hadopi ...
>>
>> Guillaume
>>
>> Le 10/07/2017 à 15:57, Sébastien Lesimple a écrit :
>>> Une association auto proclamée détentrice de la vérité universelle,
>>> constituée par les opérateurs puissant, sans aucun controle
>>> reglementaire ou tarifaire...
>>> Rien n'impose la mainmise de l'APNF sur la gestion de la portabilité
>>> hormis le refus de ses fondateurs de permettre l'emergence d'une
>>> alternative.
>>> C'est encore un mal qui s'est crée par défaillance du régulateur à
>>> imposer des règles qui ne soient pas discrinimatoires.
>>>
>>> Et entre nous à ce tarif là, faudrait voir a pas pousser mémé dans les
>>> horties!
>>>
>>>
>>> On 10/07/2017 15:48, Guillaume wrote:
 De quoi te plains-tu, tu as l'APNF :p

 Fut une époque, tu pouvais porter ton numéro mais tu n'avais aucun
 moyen d'être certain de l'opérateur réel d'un numéro mobile et cela ne
 choquait personne :)

 Tu auras peut-être ce que tu demandes le jour où il n'y aura plus de
 lignes cuivre en production.

Guillaume

 Le 10/07/2017 à 14:32, Sébastien Lesimple a écrit :
> Je considere que cette tache devrait etre prise en charge par le
> régulateur.
>
> Qu'elle relève, par 

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[Wagab]

Alors pour ce cas, comme je l'ai dit, je n'ai pas mis en place de NAT.
Mon NAT est en place pour cacher le réseau derrière le routeur. Si tu
n'as pas besoin de "cacher" ce dernier, ajoute un route sur ton pfSense
devant routeur disant que pour pointer vers le réseau derrière le
routeur, tu dois passer par la gateway routeur.

Si on reprend mon cas, sur le pfSense Site distant, j'ai ajouté :
1 GW (dans System / Routing / Gateways) avec l'IP de mon routeur
(192.168.2.10 dans mon cas)
1 route (dans System / Routing / Static Routes) indiquant que pour aller
sur le réseau distant (172.16.1.0/24 dans mon cas), je devais passer par
la GW_192.168.2.10 via l'interface LAN.

Y.

Le 2017-07-11 14:25, Mohamadou DIAGANA a écrit :
> Bonjour,
> Franchement je suis confronté au même problème depuis plusieurs jours.
> 
> Quand les équipements sont places derrière le pfsense ça passe mais des que
> ça passe par le routeur derrière le pfsense ça bloque.
> Et pourtant le tunnel est bien monté je vous le trafic au niveau du tunnel.
> 
> Peut tu me dire comment tu as mis en place le nat stp.
> 
> Merci.
> 
> 
> 
> Bien Cordialement,
> 
> Mohamadou DIAGANA
> 
> 
> Notre environnement est fragile, merci de n’imprimer ce mail qu’en cas de
> nécessité.
> 
> 
> Le 11 juil. 2017 13:46, "Wagab"  a écrit :
> 
>> David,
>>
>> j'aurais bien voulu mais on n'a pas la main, le site distant n'est pas
>> sous notre responsabilité.
>>
>> Bon, j'ai trouvé tout seul ma solution. Quelques jours sur cette
>> problématique, 1h pour écrire le mail, 1h pour résoudre le problème.
>>
>> J'ai configuré mon NAT à l'intérieur du tunnel IPSec sur le pfSense Site
>> Distant. J'ai déclaré mon subnet naté dans la phase 2 sur mon pfSense_Az
>> et en avant Guingamp.
>>
>> Merci et désolé pour le dérangement.
>> Y.
>>
>> Le 2017-07-11 11:34, David Ponzone a écrit :
>> > Sincèrement, renumérote les autres sites.
>> > Un jour ou l’autre, ça va être ingérable.
>> >
>> >
>> >
>> >> Le 11 juil. 2017 à 11:15, Wagab  a écrit :
>> >>
>> >> Bonjour,
>> >>
>> >> pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
>> >> distant que je croyais avoir déjà testée mais vu que maintenant cela
>> >> fonctionne, j'imagine que j'avais fait des conneries.
>> >>
>> >> Maintenant je suis sur ma problématique de NAT.
>> >>
>> >> Cordialement,
>> >> Yann
>> >>
>> >>
>> >> Le 2017-07-11 08:48, Wagab a écrit :
>> >>> Bonjour la liste,
>> >>>
>> >>> Cela fait quelques années que je suis la liste mais n'ayant que très
>> peu
>> >>> d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
>> >>> contribuer.
>> >>> Cependant, je suis confronté à un soucis sur lequel vous pourriez
>> >>> m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
>> >>> J'ai deux problématique.
>> >>>
>> >>> La première :
>> >>>
>> >>> Le besoin :
>> >>> Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
>> >>> mettre en place des tunnels IPSec.
>> >>> J'ai monté une maquette le plus représentatif possible d'un cas
>> concret.
>> >>>
>> >>>
>> >>> | AZURE |   | ACCES Internet | Site Distant
>>|
>> >>>   Non maitrisé
>> >>> Console_Az -|   ||
>> >>> |-- @ --|-- ... -- ... --|pfSense Site
>> Distant|--|routeur|-- |Réseau
>> >>> Cible|
>> >>> pfSense_Az -|   ||
>> >>>
>> >>> Réseau AZURE : 10.8.0.0/24
>> >>> pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP
>> Client
>> >>> (192.168.0.110/24)
>> >>> pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
>> >>> Default GW : 192.168.2.10
>> >>> routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
>> >>> (192.168.2.0/24)
>> >>> routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
>> >>>
>> >>>
>> >>> Quand les machines auxquelles la Console_Az doit accéder sont
>> >>> positionnées juste derrière le pfSense Site Distant, aucun problème.
>> >>> Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
>> >>> et le pfSense Site Distant.
>> >>>
>> >>> Lorsque je lance un ping depuis la Console_Az vers une machine du
>> réseau
>> >>> cible, ce dernier ne passe pas.
>> >>> Un ping depuis une machine du Réseau Cible, ce dernier passe.
>> >>>
>> >>> J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
>> >>> et le routeur lors d'un ping de la Console_Az vers une machine du
>> réseau
>> >>> cible. Je le vois bien transiter dans le tunnel (log sur les 2
>> pfSense).
>> >>> A priori, rien sur le routeur (l'interface de log du routeur n'est pas
>> >>> très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
>> >>> ping d'une machine du Réseau Cible depuis le pfSense Site Distant.
>> Celui
>> >>> n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
>> >>> m'indique qu'aucun ping n'arrive.
>> >>>
>> >>> A priori, on est dans une 

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Francois Demeyer]

Donc, si je te comprends, tu préférerait une SA comemrciale, qui ferait des 
bénefs et verserait des dividendes aux actionnaires, plutot qu’une association 
a bénefice nul, et dont tu sous-entends que les permanents tapent dans la 
caisse ?
Tu aurais la compta ou des faits a nous montrer pour étayer ta vision de 
l’affaire ?

> Le 11 juil. 2017 à 14:17, Sébastien Lesimple 
>  a écrit :
> 
> On 11/07/2017 13:59, Francois Demeyer wrote:
>>> Le 11 juil. 2017 à 13:40, Sébastien Lesimple 
>>>  a écrit :
>>> 
>>> Bon ben, David, je te laisses piloter hein ;)
>>> 
>>> RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
>>> Une entreprise commerciale, qui assume sa nature au lieu d'une
>>> association à but pseudo "non" lucratif.
>> pourquoi « pseudo » ? elle fait des bénéf l’APNF ? Association loi 1901.. no 
>> benef..
> Une association peut faire des bénéfices ce n'est pas incompatible avec
> son statut, c'est l'usage qui en est fait qui peut etre tendancieux.
> Les utiliser pour son objet associatif, constituer de la réserve de
> trésorerie, c'est normal.
> 
> La distribution sous forme de primes, commissions, salaires, prestations
> de services externes, véhicules, et j'en passe, sont autants de moyens
> de "fuiter" des ressources, qui fait intelligemment n’enfreins pas les
> règles comptables et fiscales.
> Mais là on tombe dans le biais du "c'est légal j'ai le droit" vs
> entubage intellectuel...
> 
> Et donc plutôt que de biaiser, je trouve bien plus efficace d’être
> entreprise commerciale, d'annoncer la couleur des le début, et gérer un
> set de services aux fins de profits et d'y associer l'ensemble des
> utilisateurs qui, en l'espèce, utiliseront le service pour
> l'amélioration de leur propre business.
> 
> Le plan association a but non lucratif dans nos métier, cela me parait
> antinomique.
> 
>> 
>>> Chaque client devenant actionnaire de l'entité en question en proportion
>>> de son usage et participant aux coûts mais aussi au résultats avec une
>>> représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
>>> modestes…
>> Même dans des organisation de l’univers open hors de France, j’ai comme 
>> l’impression que les gros emportent souvent le pompon.. suffit de voir les 
>> normalisations 802 par exemple…. 
>> 
>>> Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
>>> Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
>>> retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
>>> à cette organisation hypothétique serait bien plus sage.
>>> D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
>>> piloter un bon gros stack de virtualisation (your choice of the flavor).
>>> Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
>>> grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)
>>> 
>>> Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
>>> dézinguer les surcharges d'opérateur de transit, par exemple.
>>> Et une solution de parutions annuaires, parce-que ca aussi c'est bien
>>> daubé dans le genre.
>>> 
>>> Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
>>> tous nettement plus simple.
>>> J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
>>> opensource mais ca me démange...
>>> 
>>> 
>>> On 11/07/2017 12:29, David Ponzone wrote:
 Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de 
 l’année, on redistribue l’argent aux membres.
>> Pas de benef dans une associaiton, donc pas de redistribution.
>> 
 Les membres devraient bien sûr si possible avoir le même poids quelque 
 soit leur taille.
 Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
 Evidemment, la structure de coût devrait être la plus saine possible en 
 limitant  l’appel à la sous-traitance..
>> Sur ce point, c’est toujours discutable en effet… des employés permanents vs 
>> de la sous-traitance.. on en reparle après la nouvelle loi travail ? ;-)
>> 
 Et la structure devrait faire appel autant que possible aux ressources 
 déjà payées en partie par l’Etat (Cloudwatt, Numergy, etc..).
>> Ahem.. si on pouvais jeter un voile pudique sur ces deux gouffres, ils n’ont 
>> rien a voir avec la porta et autres bases d’urgence
>> 
 Et la même structure pour le fixe et le mobile non ?
>> Ca, j’ai comme l’impression que ca pourrait venir dans pas bien longtemps…
>> 
> Le 11 juil. 2017 à 11:49, Francois Demeyer  a écrit 
> :
> 
> Tu pourrais nous décrire l’alternative à l’APNF telle que tu l’imagines ?
> 
>> Le 10 juil. 2017 à 16:28, Sébastien Lesimple 
>>  a écrit :
>> 
>> C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
>> hors controle du 

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[Wagab]

C'était fait mais merci beaucoup :).

Le 2017-07-11 13:59, David Ponzone a écrit :
> Le fait d’exposer un problème par écrit permet souvent de voir les
> choses avec un peu de perspective et de trouver la solution.
> 
> Juste au cas où, tu as pensé au NAT dans l’autre sens ?
> (si 192.168.1.0/24 sur site A a besoin d’accéder à 192.168.1.0/24 sur
> site B, il devra donc le faire en utilisant 192.168.2.0/24, donc dans
> ce cas là, l’ideal est sur site B, de mettre un NAT 1-1 de
> 192.168.1.0/24 vers 192.168.2.0/24)
> 
> 
> 
>> Le 11 juil. 2017 à 13:45, Wagab  a écrit :
>>
>> David,
>>
>> j'aurais bien voulu mais on n'a pas la main, le site distant n'est pas
>> sous notre responsabilité.
>>
>> Bon, j'ai trouvé tout seul ma solution. Quelques jours sur cette
>> problématique, 1h pour écrire le mail, 1h pour résoudre le problème.
>>
>> J'ai configuré mon NAT à l'intérieur du tunnel IPSec sur le pfSense Site
>> Distant. J'ai déclaré mon subnet naté dans la phase 2 sur mon pfSense_Az
>> et en avant Guingamp.
>>
>> Merci et désolé pour le dérangement.
>> Y.
>>
>> Le 2017-07-11 11:34, David Ponzone a écrit :
>>> Sincèrement, renumérote les autres sites.
>>> Un jour ou l’autre, ça va être ingérable.
>>>
>>>
>>>
 Le 11 juil. 2017 à 11:15, Wagab  a écrit :

 Bonjour,

 pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
 distant que je croyais avoir déjà testée mais vu que maintenant cela
 fonctionne, j'imagine que j'avais fait des conneries.

 Maintenant je suis sur ma problématique de NAT.

 Cordialement,
 Yann


 Le 2017-07-11 08:48, Wagab a écrit :
> Bonjour la liste,
>
> Cela fait quelques années que je suis la liste mais n'ayant que très peu
> d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
> contribuer.
> Cependant, je suis confronté à un soucis sur lequel vous pourriez
> m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
> J'ai deux problématique.
>
> La première :
>
> Le besoin :
> Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
> mettre en place des tunnels IPSec.
> J'ai monté une maquette le plus représentatif possible d'un cas concret.
>
>
> | AZURE | | ACCES Internet | Site Distant 
>   |
> Non maitrisé
> Console_Az -|   |  |
>   |-- @ --|-- ... -- ... --|pfSense Site 
> Distant|--|routeur|-- |Réseau
> Cible|
> pfSense_Az -|   |  |
>
> Réseau AZURE : 10.8.0.0/24
> pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP Client
> (192.168.0.110/24)
> pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
> Default GW : 192.168.2.10
> routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
> (192.168.2.0/24)
> routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
>
>
> Quand les machines auxquelles la Console_Az doit accéder sont
> positionnées juste derrière le pfSense Site Distant, aucun problème.
> Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
> et le pfSense Site Distant.
>
> Lorsque je lance un ping depuis la Console_Az vers une machine du réseau
> cible, ce dernier ne passe pas.
> Un ping depuis une machine du Réseau Cible, ce dernier passe.
>
> J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
> et le routeur lors d'un ping de la Console_Az vers une machine du réseau
> cible. Je le vois bien transiter dans le tunnel (log sur les 2 pfSense).
> A priori, rien sur le routeur (l'interface de log du routeur n'est pas
> très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
> ping d'une machine du Réseau Cible depuis le pfSense Site Distant. Celui
> n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
> m'indique qu'aucun ping n'arrive.
>
> A priori, on est dans une problèmatique de débutant en terme de réseau.
> Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
> mais sans succès et à force je me mélange.
> Voici la conf de mes tunnels IPSec :
>
> pfSense Site Distant :
>
> Configuration  :
>   Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
> Description
> IKE V1WAN mainAES (256 bits)  SHA1
> Test IPSec VPN
>   52.164.243.95
>
> Mode  Local SubnetRemote Subnet   P2 Protocol P2 Transforms   
> P2 Auth
> Methods
> tunnel192.168.2.0/24  10.8.0.0/24 ESP AES (auto)  
> SHA1
> tunnel172.16.1.0/24   10.8.0.0/24 ESP AES (auto)  
> SHA1
>
> 

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[Mohamadou DIAGANA]

Bonjour,
Franchement je suis confronté au même problème depuis plusieurs jours.

Quand les équipements sont places derrière le pfsense ça passe mais des que
ça passe par le routeur derrière le pfsense ça bloque.
Et pourtant le tunnel est bien monté je vous le trafic au niveau du tunnel.

Peut tu me dire comment tu as mis en place le nat stp.

Merci.



Bien Cordialement,

Mohamadou DIAGANA


Notre environnement est fragile, merci de n’imprimer ce mail qu’en cas de
nécessité.


Le 11 juil. 2017 13:46, "Wagab"  a écrit :

> David,
>
> j'aurais bien voulu mais on n'a pas la main, le site distant n'est pas
> sous notre responsabilité.
>
> Bon, j'ai trouvé tout seul ma solution. Quelques jours sur cette
> problématique, 1h pour écrire le mail, 1h pour résoudre le problème.
>
> J'ai configuré mon NAT à l'intérieur du tunnel IPSec sur le pfSense Site
> Distant. J'ai déclaré mon subnet naté dans la phase 2 sur mon pfSense_Az
> et en avant Guingamp.
>
> Merci et désolé pour le dérangement.
> Y.
>
> Le 2017-07-11 11:34, David Ponzone a écrit :
> > Sincèrement, renumérote les autres sites.
> > Un jour ou l’autre, ça va être ingérable.
> >
> >
> >
> >> Le 11 juil. 2017 à 11:15, Wagab  a écrit :
> >>
> >> Bonjour,
> >>
> >> pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
> >> distant que je croyais avoir déjà testée mais vu que maintenant cela
> >> fonctionne, j'imagine que j'avais fait des conneries.
> >>
> >> Maintenant je suis sur ma problématique de NAT.
> >>
> >> Cordialement,
> >> Yann
> >>
> >>
> >> Le 2017-07-11 08:48, Wagab a écrit :
> >>> Bonjour la liste,
> >>>
> >>> Cela fait quelques années que je suis la liste mais n'ayant que très
> peu
> >>> d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
> >>> contribuer.
> >>> Cependant, je suis confronté à un soucis sur lequel vous pourriez
> >>> m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
> >>> J'ai deux problématique.
> >>>
> >>> La première :
> >>>
> >>> Le besoin :
> >>> Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
> >>> mettre en place des tunnels IPSec.
> >>> J'ai monté une maquette le plus représentatif possible d'un cas
> concret.
> >>>
> >>>
> >>> | AZURE |   | ACCES Internet | Site Distant
>|
> >>>   Non maitrisé
> >>> Console_Az -|   ||
> >>> |-- @ --|-- ... -- ... --|pfSense Site
> Distant|--|routeur|-- |Réseau
> >>> Cible|
> >>> pfSense_Az -|   ||
> >>>
> >>> Réseau AZURE : 10.8.0.0/24
> >>> pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP
> Client
> >>> (192.168.0.110/24)
> >>> pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
> >>> Default GW : 192.168.2.10
> >>> routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
> >>> (192.168.2.0/24)
> >>> routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
> >>>
> >>>
> >>> Quand les machines auxquelles la Console_Az doit accéder sont
> >>> positionnées juste derrière le pfSense Site Distant, aucun problème.
> >>> Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
> >>> et le pfSense Site Distant.
> >>>
> >>> Lorsque je lance un ping depuis la Console_Az vers une machine du
> réseau
> >>> cible, ce dernier ne passe pas.
> >>> Un ping depuis une machine du Réseau Cible, ce dernier passe.
> >>>
> >>> J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
> >>> et le routeur lors d'un ping de la Console_Az vers une machine du
> réseau
> >>> cible. Je le vois bien transiter dans le tunnel (log sur les 2
> pfSense).
> >>> A priori, rien sur le routeur (l'interface de log du routeur n'est pas
> >>> très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
> >>> ping d'une machine du Réseau Cible depuis le pfSense Site Distant.
> Celui
> >>> n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
> >>> m'indique qu'aucun ping n'arrive.
> >>>
> >>> A priori, on est dans une problèmatique de débutant en terme de réseau.
> >>> Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
> >>> mais sans succès et à force je me mélange.
> >>> Voici la conf de mes tunnels IPSec :
> >>>
> >>> pfSense Site Distant :
> >>>
> >>> Configuration  :
> >>> Remote Gateway  ModeP1 Protocol P1 Transforms   P1
> Description
> >>> IKE V1  WAN mainAES (256 bits)  SHA1
>   Test IPSec VPN
> >>> 52.164.243.95
> >>>
> >>> ModeLocal SubnetRemote Subnet   P2 Protocol P2
> Transforms   P2 Auth
> >>> Methods
> >>> tunnel  192.168.2.0/24  10.8.0.0/24 ESP AES
> (auto)  SHA1
> >>> tunnel  172.16.1.0/24   10.8.0.0/24 ESP AES
> (auto)  SHA1
> >>>
> >>> SADs :
> >>> Source  Destination ProtocolSPI
>  Enc. alg. 

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Sébastien Lesimple]

On 11/07/2017 13:59, Francois Demeyer wrote:
>> Le 11 juil. 2017 à 13:40, Sébastien Lesimple 
>>  a écrit :
>>
>> Bon ben, David, je te laisses piloter hein ;)
>>
>> RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
>> Une entreprise commerciale, qui assume sa nature au lieu d'une
>> association à but pseudo "non" lucratif.
> pourquoi « pseudo » ? elle fait des bénéf l’APNF ? Association loi 1901.. no 
> benef..
Une association peut faire des bénéfices ce n'est pas incompatible avec
son statut, c'est l'usage qui en est fait qui peut etre tendancieux.
Les utiliser pour son objet associatif, constituer de la réserve de
trésorerie, c'est normal.

La distribution sous forme de primes, commissions, salaires, prestations
de services externes, véhicules, et j'en passe, sont autants de moyens
de "fuiter" des ressources, qui fait intelligemment n’enfreins pas les
règles comptables et fiscales.
Mais là on tombe dans le biais du "c'est légal j'ai le droit" vs
entubage intellectuel...

Et donc plutôt que de biaiser, je trouve bien plus efficace d’être
entreprise commerciale, d'annoncer la couleur des le début, et gérer un
set de services aux fins de profits et d'y associer l'ensemble des
utilisateurs qui, en l'espèce, utiliseront le service pour
l'amélioration de leur propre business.

Le plan association a but non lucratif dans nos métier, cela me parait
antinomique.

>
>> Chaque client devenant actionnaire de l'entité en question en proportion
>> de son usage et participant aux coûts mais aussi au résultats avec une
>> représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
>> modestes…
> Même dans des organisation de l’univers open hors de France, j’ai comme 
> l’impression que les gros emportent souvent le pompon.. suffit de voir les 
> normalisations 802 par exemple…. 
>
>> Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
>> Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
>> retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
>> à cette organisation hypothétique serait bien plus sage.
>> D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
>> piloter un bon gros stack de virtualisation (your choice of the flavor).
>> Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
>> grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)
>>
>> Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
>> dézinguer les surcharges d'opérateur de transit, par exemple.
>> Et une solution de parutions annuaires, parce-que ca aussi c'est bien
>> daubé dans le genre.
>>
>> Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
>> tous nettement plus simple.
>> J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
>> opensource mais ca me démange...
>>
>>
>> On 11/07/2017 12:29, David Ponzone wrote:
>>> Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de l’année, 
>>> on redistribue l’argent aux membres.
> Pas de benef dans une associaiton, donc pas de redistribution.
>
>>> Les membres devraient bien sûr si possible avoir le même poids quelque soit 
>>> leur taille.
>>> Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
>>> 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
>>> Evidemment, la structure de coût devrait être la plus saine possible en 
>>> limitant  l’appel à la sous-traitance..
> Sur ce point, c’est toujours discutable en effet… des employés permanents vs 
> de la sous-traitance.. on en reparle après la nouvelle loi travail ? ;-)
>
>>> Et la structure devrait faire appel autant que possible aux ressources déjà 
>>> payées en partie par l’Etat (Cloudwatt, Numergy, etc..).
> Ahem.. si on pouvais jeter un voile pudique sur ces deux gouffres, ils n’ont 
> rien a voir avec la porta et autres bases d’urgence
>
>>> Et la même structure pour le fixe et le mobile non ?
> Ca, j’ai comme l’impression que ca pourrait venir dans pas bien longtemps…
>
 Le 11 juil. 2017 à 11:49, Francois Demeyer  a écrit :

 Tu pourrais nous décrire l’alternative à l’APNF telle que tu l’imagines ?

> Le 10 juil. 2017 à 16:28, Sébastien Lesimple 
>  a écrit :
>
> C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
> hors controle du régulateur.
>
> On 10/07/2017 16:02, Guillaume wrote:
>> Te donner libre accès à un outil qui est nécessaire à tout opérateur
>> pour pouvoir faire correctement son travail ? Mais tu es fou, ça
>> serait s'asseoir sur une manne financière qui tombe gracieusement
>> chaque mois, un peu comme les majors qui se font payer leur lutte
>> anti-piratage par l'état (et les contribuables) avec la Hadopi ...
>>
>> Guillaume
>>
>> Le 10/07/2017 à 15:57, Sébastien Lesimple a écrit :
>>> Une association auto proclamée 

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[Julien Escario]

Le 11/07/2017 à 13:24, David Ponzone a écrit :
> Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie une 
> requête pour le realm seul avant de t’envoyer une requête pour le login 
> complet ?

Je ne suis pas certain de savoir le dire précisément mais, à priori, non.

J'ai bien deux requêtes Accept-Request mais elles intègrent à chaque fois :
User-Name = "t...@azylog.ptel.ipadsl"

Et mon radius répond bien Access-Accept les deux fois.

Est-ce c'est utile que je fasse un découpage propre des logs de freeradius ?
J'ai tendance à dire que le problème est après (aka côté krotik) et que ça va
surtout générer beaucoup de bruit si je copie/colle ça ici.

Julien



smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Francois Demeyer]

> Le 11 juil. 2017 à 13:40, Sébastien Lesimple 
>  a écrit :
> 
> Bon ben, David, je te laisses piloter hein ;)
> 
> RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
> Une entreprise commerciale, qui assume sa nature au lieu d'une
> association à but pseudo "non" lucratif.

pourquoi « pseudo » ? elle fait des bénéf l’APNF ? Association loi 1901.. no 
benef..

> Chaque client devenant actionnaire de l'entité en question en proportion
> de son usage et participant aux coûts mais aussi au résultats avec une
> représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
> modestes…

Même dans des organisation de l’univers open hors de France, j’ai comme 
l’impression que les gros emportent souvent le pompon.. suffit de voir les 
normalisations 802 par exemple…. 

> 
> Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
> Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
> retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
> à cette organisation hypothétique serait bien plus sage.
> D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
> piloter un bon gros stack de virtualisation (your choice of the flavor).
> Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
> grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)
> 
> Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
> dézinguer les surcharges d'opérateur de transit, par exemple.
> Et une solution de parutions annuaires, parce-que ca aussi c'est bien
> daubé dans le genre.
> 
> Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
> tous nettement plus simple.
> J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
> opensource mais ca me démange...
> 
> 
> On 11/07/2017 12:29, David Ponzone wrote:
>> Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de l’année, 
>> on redistribue l’argent aux membres.

Pas de benef dans une associaiton, donc pas de redistribution.

>> Les membres devraient bien sûr si possible avoir le même poids quelque soit 
>> leur taille.
>> Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
>> 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
>> Evidemment, la structure de coût devrait être la plus saine possible en 
>> limitant  l’appel à la sous-traitance..

Sur ce point, c’est toujours discutable en effet… des employés permanents vs de 
la sous-traitance.. on en reparle après la nouvelle loi travail ? ;-)

>> Et la structure devrait faire appel autant que possible aux ressources déjà 
>> payées en partie par l’Etat (Cloudwatt, Numergy, etc..).

Ahem.. si on pouvais jeter un voile pudique sur ces deux gouffres, ils n’ont 
rien a voir avec la porta et autres bases d’urgence

>> Et la même structure pour le fixe et le mobile non ?

Ca, j’ai comme l’impression que ca pourrait venir dans pas bien longtemps…

>> 
>>> Le 11 juil. 2017 à 11:49, Francois Demeyer  a écrit :
>>> 
>>> Tu pourrais nous décrire l’alternative à l’APNF telle que tu l’imagines ?
>>> 
 Le 10 juil. 2017 à 16:28, Sébastien Lesimple 
  a écrit :
 
 C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
 hors controle du régulateur.
 
 On 10/07/2017 16:02, Guillaume wrote:
> Te donner libre accès à un outil qui est nécessaire à tout opérateur
> pour pouvoir faire correctement son travail ? Mais tu es fou, ça
> serait s'asseoir sur une manne financière qui tombe gracieusement
> chaque mois, un peu comme les majors qui se font payer leur lutte
> anti-piratage par l'état (et les contribuables) avec la Hadopi ...
> 
> Guillaume
> 
> Le 10/07/2017 à 15:57, Sébastien Lesimple a écrit :
>> Une association auto proclamée détentrice de la vérité universelle,
>> constituée par les opérateurs puissant, sans aucun controle
>> reglementaire ou tarifaire...
>> Rien n'impose la mainmise de l'APNF sur la gestion de la portabilité
>> hormis le refus de ses fondateurs de permettre l'emergence d'une
>> alternative.
>> C'est encore un mal qui s'est crée par défaillance du régulateur à
>> imposer des règles qui ne soient pas discrinimatoires.
>> 
>> Et entre nous à ce tarif là, faudrait voir a pas pousser mémé dans les
>> horties!
>> 
>> 
>> On 10/07/2017 15:48, Guillaume wrote:
>>> De quoi te plains-tu, tu as l'APNF :p
>>> 
>>> Fut une époque, tu pouvais porter ton numéro mais tu n'avais aucun
>>> moyen d'être certain de l'opérateur réel d'un numéro mobile et cela ne
>>> choquait personne :)
>>> 
>>> Tu auras peut-être ce que tu demandes le jour où il n'y aura plus de
>>> lignes cuivre en production.
>>> 
>>> Guillaume
>>> 
>>> Le 10/07/2017 à 14:32, Sébastien Lesimple a écrit :
 Je 

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[David Ponzone]

Le fait d’exposer un problème par écrit permet souvent de voir les choses avec 
un peu de perspective et de trouver la solution.

Juste au cas où, tu as pensé au NAT dans l’autre sens ?
(si 192.168.1.0/24 sur site A a besoin d’accéder à 192.168.1.0/24 sur site B, 
il devra donc le faire en utilisant 192.168.2.0/24, donc dans ce cas là, 
l’ideal est sur site B, de mettre un NAT 1-1 de 192.168.1.0/24 vers 
192.168.2.0/24)



> Le 11 juil. 2017 à 13:45, Wagab  a écrit :
> 
> David,
> 
> j'aurais bien voulu mais on n'a pas la main, le site distant n'est pas
> sous notre responsabilité.
> 
> Bon, j'ai trouvé tout seul ma solution. Quelques jours sur cette
> problématique, 1h pour écrire le mail, 1h pour résoudre le problème.
> 
> J'ai configuré mon NAT à l'intérieur du tunnel IPSec sur le pfSense Site
> Distant. J'ai déclaré mon subnet naté dans la phase 2 sur mon pfSense_Az
> et en avant Guingamp.
> 
> Merci et désolé pour le dérangement.
> Y.
> 
> Le 2017-07-11 11:34, David Ponzone a écrit :
>> Sincèrement, renumérote les autres sites.
>> Un jour ou l’autre, ça va être ingérable.
>> 
>> 
>> 
>>> Le 11 juil. 2017 à 11:15, Wagab  a écrit :
>>> 
>>> Bonjour,
>>> 
>>> pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
>>> distant que je croyais avoir déjà testée mais vu que maintenant cela
>>> fonctionne, j'imagine que j'avais fait des conneries.
>>> 
>>> Maintenant je suis sur ma problématique de NAT.
>>> 
>>> Cordialement,
>>> Yann
>>> 
>>> 
>>> Le 2017-07-11 08:48, Wagab a écrit :
 Bonjour la liste,
 
 Cela fait quelques années que je suis la liste mais n'ayant que très peu
 d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
 contribuer.
 Cependant, je suis confronté à un soucis sur lequel vous pourriez
 m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
 J'ai deux problématique.
 
 La première :
 
 Le besoin :
 Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
 mettre en place des tunnels IPSec.
 J'ai monté une maquette le plus représentatif possible d'un cas concret.
 
 
 | AZURE |  | ACCES Internet | Site Distant 
   |
  Non maitrisé
 Console_Az -|   |   |
|-- @ --|-- ... -- ... --|pfSense Site 
 Distant|--|routeur|-- |Réseau
 Cible|
 pfSense_Az -|   |   |
 
 Réseau AZURE : 10.8.0.0/24
 pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP Client
 (192.168.0.110/24)
 pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
 Default GW : 192.168.2.10
 routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
 (192.168.2.0/24)
 routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
 
 
 Quand les machines auxquelles la Console_Az doit accéder sont
 positionnées juste derrière le pfSense Site Distant, aucun problème.
 Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
 et le pfSense Site Distant.
 
 Lorsque je lance un ping depuis la Console_Az vers une machine du réseau
 cible, ce dernier ne passe pas.
 Un ping depuis une machine du Réseau Cible, ce dernier passe.
 
 J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
 et le routeur lors d'un ping de la Console_Az vers une machine du réseau
 cible. Je le vois bien transiter dans le tunnel (log sur les 2 pfSense).
 A priori, rien sur le routeur (l'interface de log du routeur n'est pas
 très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
 ping d'une machine du Réseau Cible depuis le pfSense Site Distant. Celui
 n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
 m'indique qu'aucun ping n'arrive.
 
 A priori, on est dans une problèmatique de débutant en terme de réseau.
 Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
 mais sans succès et à force je me mélange.
 Voici la conf de mes tunnels IPSec :
 
 pfSense Site Distant :
 
 Configuration  :
Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
 Description
 IKE V1 WAN mainAES (256 bits)  SHA1
 Test IPSec VPN
52.164.243.95
 
 Mode   Local SubnetRemote Subnet   P2 Protocol P2 Transforms   
 P2 Auth
 Methods
 tunnel 192.168.2.0/24  10.8.0.0/24 ESP AES (auto)  
 SHA1
 tunnel 172.16.1.0/24   10.8.0.0/24 ESP AES (auto)  
 SHA1
 
 SADs :
 Source Destination ProtocolSPI Enc. 
 alg.   Auth. alg.  Data
 192.168.0.110  IP Pub AzureESP 

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[Wagab]

David,

j'aurais bien voulu mais on n'a pas la main, le site distant n'est pas
sous notre responsabilité.

Bon, j'ai trouvé tout seul ma solution. Quelques jours sur cette
problématique, 1h pour écrire le mail, 1h pour résoudre le problème.

J'ai configuré mon NAT à l'intérieur du tunnel IPSec sur le pfSense Site
Distant. J'ai déclaré mon subnet naté dans la phase 2 sur mon pfSense_Az
et en avant Guingamp.

Merci et désolé pour le dérangement.
Y.

Le 2017-07-11 11:34, David Ponzone a écrit :
> Sincèrement, renumérote les autres sites.
> Un jour ou l’autre, ça va être ingérable.
> 
> 
> 
>> Le 11 juil. 2017 à 11:15, Wagab  a écrit :
>>
>> Bonjour,
>>
>> pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
>> distant que je croyais avoir déjà testée mais vu que maintenant cela
>> fonctionne, j'imagine que j'avais fait des conneries.
>>
>> Maintenant je suis sur ma problématique de NAT.
>>
>> Cordialement,
>> Yann
>>
>>
>> Le 2017-07-11 08:48, Wagab a écrit :
>>> Bonjour la liste,
>>>
>>> Cela fait quelques années que je suis la liste mais n'ayant que très peu
>>> d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
>>> contribuer.
>>> Cependant, je suis confronté à un soucis sur lequel vous pourriez
>>> m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
>>> J'ai deux problématique.
>>>
>>> La première :
>>>
>>> Le besoin :
>>> Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
>>> mettre en place des tunnels IPSec.
>>> J'ai monté une maquette le plus représentatif possible d'un cas concret.
>>>
>>>
>>> | AZURE |   | ACCES Internet | Site Distant 
>>>   |
>>>   Non maitrisé
>>> Console_Az -|   ||
>>> |-- @ --|-- ... -- ... --|pfSense Site 
>>> Distant|--|routeur|-- |Réseau
>>> Cible|
>>> pfSense_Az -|   ||
>>>
>>> Réseau AZURE : 10.8.0.0/24
>>> pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP Client
>>> (192.168.0.110/24)
>>> pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
>>> Default GW : 192.168.2.10
>>> routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
>>> (192.168.2.0/24)
>>> routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
>>>
>>>
>>> Quand les machines auxquelles la Console_Az doit accéder sont
>>> positionnées juste derrière le pfSense Site Distant, aucun problème.
>>> Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
>>> et le pfSense Site Distant.
>>>
>>> Lorsque je lance un ping depuis la Console_Az vers une machine du réseau
>>> cible, ce dernier ne passe pas.
>>> Un ping depuis une machine du Réseau Cible, ce dernier passe.
>>>
>>> J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
>>> et le routeur lors d'un ping de la Console_Az vers une machine du réseau
>>> cible. Je le vois bien transiter dans le tunnel (log sur les 2 pfSense).
>>> A priori, rien sur le routeur (l'interface de log du routeur n'est pas
>>> très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
>>> ping d'une machine du Réseau Cible depuis le pfSense Site Distant. Celui
>>> n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
>>> m'indique qu'aucun ping n'arrive.
>>>
>>> A priori, on est dans une problèmatique de débutant en terme de réseau.
>>> Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
>>> mais sans succès et à force je me mélange.
>>> Voici la conf de mes tunnels IPSec :
>>>
>>> pfSense Site Distant :
>>>
>>> Configuration  :
>>> Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
>>> Description
>>> IKE V1  WAN mainAES (256 bits)  SHA1
>>> Test IPSec VPN
>>> 52.164.243.95
>>>
>>> ModeLocal SubnetRemote Subnet   P2 Protocol P2 Transforms   
>>> P2 Auth
>>> Methods
>>> tunnel  192.168.2.0/24  10.8.0.0/24 ESP AES (auto)  
>>> SHA1
>>> tunnel  172.16.1.0/24   10.8.0.0/24 ESP AES (auto)  
>>> SHA1
>>>
>>> SADs :
>>> Source  Destination ProtocolSPI Enc. 
>>> alg.   Auth. alg.  Data
>>> 192.168.0.110   IP Pub AzureESP cafd79ae
>>> rijndael-cbchmac-sha1   0
>>> B
>>> IP Pub Azure192.168.0.110   ESP c2fbf651
>>> rijndael-cbchmac-sha1
>>> 17340 B
>>> 192.168.0.110   IP Pub AzureESP cb6200d5
>>> rijndael-cbchmac-sha1
>>> 240 B
>>> IP Pub Azure192.168.0.110   ESP c34cc1f1
>>> rijndael-cbchmac-sha1
>>> 120 B
>>>
>>> SPDs :
>>> Source  Destination Direction   ProtocolTunnel 
>>> endpoints
>>> 10.8.0.0/24 192.168.2.0/24  ◄ Inbound   ESP IP Pub 
>>> Azure ->
>>> 192.168.0.110

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Sébastien Lesimple]

Bon ben, David, je te laisses piloter hein ;)

RIPE like yes, sur le modèle d'Intelsat d'avant la privatisation.
Une entreprise commerciale, qui assume sa nature au lieu d'une
association à but pseudo "non" lucratif.
Chaque client devenant actionnaire de l'entité en question en proportion
de son usage et participant aux coûts mais aussi au résultats avec une
représentativité simple 1 actionaire = 1 vote pour éviter d'écraser les
modestes...

Pour la partie Numergy/Cloudwatt, je m'abstiendrai.
Vu ce que cela nous a déjà coûté en argent public pour in finé que cela
retombe dans l'escarcelle de SFR et Orange, je pense qu'une archi propre
à cette organisation hypothétique serait bien plus sage.
D'autant qu'on est quand même quelques uns a savoir monter, maintenir et
piloter un bon gros stack de virtualisation (your choice of the flavor).
Je resterais toujours adepte de "mieux vaut un petit chez sois, qu'un
grand chez les autres" lorsqu'il s'agit d'infra "critiques" ;)

Et a la suite, tu peux aussi envisager un "SIP Exchange" histoire de
dézinguer les surcharges d'opérateur de transit, par exemple.
Et une solution de parutions annuaires, parce-que ca aussi c'est bien
daubé dans le genre.

Bref, y'a pleins de petits trucs qui permettraient de rendre la vie de
tous nettement plus simple.
J'irais pas jusqu'à suggérer un outils de gestion Frontal Operateur
opensource mais ca me démange...


On 11/07/2017 12:29, David Ponzone wrote:
> Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de l’année, 
> on redistribue l’argent aux membres.
> Les membres devraient bien sûr si possible avoir le même poids quelque soit 
> leur taille.
> Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
> 1000€/mois pour 10 portas et un dump de la liste des numéros portés.
> Evidemment, la structure de coût devrait être la plus saine possible en 
> limitant  l’appel à la sous-traitance..
> Et la structure devrait faire appel autant que possible aux ressources déjà 
> payées en partie par l’Etat (Cloudwatt, Numergy, etc..).
> Et la même structure pour le fixe et le mobile non ?
>
>> Le 11 juil. 2017 à 11:49, Francois Demeyer  a écrit :
>>
>> Tu pourrais nous décrire l’alternative à l’APNF telle que tu l’imagines ?
>>
>>> Le 10 juil. 2017 à 16:28, Sébastien Lesimple 
>>>  a écrit :
>>>
>>> C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
>>> hors controle du régulateur.
>>>
>>> On 10/07/2017 16:02, Guillaume wrote:
 Te donner libre accès à un outil qui est nécessaire à tout opérateur
 pour pouvoir faire correctement son travail ? Mais tu es fou, ça
 serait s'asseoir sur une manne financière qui tombe gracieusement
 chaque mois, un peu comme les majors qui se font payer leur lutte
 anti-piratage par l'état (et les contribuables) avec la Hadopi ...

 Guillaume

 Le 10/07/2017 à 15:57, Sébastien Lesimple a écrit :
> Une association auto proclamée détentrice de la vérité universelle,
> constituée par les opérateurs puissant, sans aucun controle
> reglementaire ou tarifaire...
> Rien n'impose la mainmise de l'APNF sur la gestion de la portabilité
> hormis le refus de ses fondateurs de permettre l'emergence d'une
> alternative.
> C'est encore un mal qui s'est crée par défaillance du régulateur à
> imposer des règles qui ne soient pas discrinimatoires.
>
> Et entre nous à ce tarif là, faudrait voir a pas pousser mémé dans les
> horties!
>
>
> On 10/07/2017 15:48, Guillaume wrote:
>> De quoi te plains-tu, tu as l'APNF :p
>>
>> Fut une époque, tu pouvais porter ton numéro mais tu n'avais aucun
>> moyen d'être certain de l'opérateur réel d'un numéro mobile et cela ne
>> choquait personne :)
>>
>> Tu auras peut-être ce que tu demandes le jour où il n'y aura plus de
>> lignes cuivre en production.
>>
>>  Guillaume
>>
>> Le 10/07/2017 à 14:32, Sébastien Lesimple a écrit :
>>> Je considere que cette tache devrait etre prise en charge par le
>>> régulateur.
>>>
>>> Qu'elle relève, par extention, du plan national de numerotation et
>>> devrait etre accessible a tous gratuitement au meme titre que le reste
>>> des infos sur les ressources de numéroation.
>>>
>>> De meme que les No portés d'opérateurs devraient etre eux aussi
>>> accessibles a tous mais c'est un autre sujet.
>>> Laissons leur le bonheur de nous surfacturer les appels vers leurs
>>> Numéros portés histoire de faire de la bonne marge...
>>>
>>> T!
>>>
>>>
>>> On 10/07/2017 14:01, David Ponzone wrote:
 Oh tu sais, je pense que la majorité des opérateurs alternatifs de
 taille modeste qui font de la traduction sont conscients du problème.
 Il y a aussi Rouen, qui est séparé en RD/RG, et on peut trouver
 d’autres cas, surtout dans les grandes 

Re: [FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[David Ponzone]

Juste pour situer le contexte, ton fournisseur de collecte ADSL t’envoie une 
requête pour le realm seul avant de t’envoyer une requête pour le login complet 
?


> Le 11 juil. 2017 à 12:40, Julien Escario  a écrit :
> 
> Bonjour la liste,
> Je me heurte à un problème marrant : je voudrais utiliser un mikrotik pour la
> terminaison d'une collecte l2tp 'classique'.
> 
> J'ai donc monté un freeradius qui semble répondre à peu près tout ce qu'il et
> mes sessions L2TP sont bien acheminées jusqu'à mon LNS.
> 
> Mais là, c'est plus chiant : les sessions montent et retombent au bout de
> quelques secondes avec un joli 'could not determine local IP address'.
> 
> Si je tente de monter un tunnel directement via un client L2TP, ça passe tout
> droit. Il doit me manquer un attribut dans la réponse radius.
> 
> Je rajouterais que dans le profil L2TP utilisé, j'ai bien précisé la 'local
> address' (confirmé sur le forum krotik).
> 
> Il me manque un truc mais je ne mets pas la main dessus et ça fait plusieurs 
> jours.
> 
> Maintenant que parler de Mikrotik ici n'est plus un gros mot, il y a bien
> quelqu'un qui s'est amusé à faire ça ? La petite piste serait la bienvenue.
> 
> Merci,
> Julien
> 


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

[FRnOG] [TECH] Mikrotik en tant que LNS (L2TP)

[Julien Escario]

Bonjour la liste,
Je me heurte à un problème marrant : je voudrais utiliser un mikrotik pour la
terminaison d'une collecte l2tp 'classique'.

J'ai donc monté un freeradius qui semble répondre à peu près tout ce qu'il et
mes sessions L2TP sont bien acheminées jusqu'à mon LNS.

Mais là, c'est plus chiant : les sessions montent et retombent au bout de
quelques secondes avec un joli 'could not determine local IP address'.

Si je tente de monter un tunnel directement via un client L2TP, ça passe tout
droit. Il doit me manquer un attribut dans la réponse radius.

Je rajouterais que dans le profil L2TP utilisé, j'ai bien précisé la 'local
address' (confirmé sur le forum krotik).

Il me manque un truc mais je ne mets pas la main dessus et ça fait plusieurs 
jours.

Maintenant que parler de Mikrotik ici n'est plus un gros mot, il y a bien
quelqu'un qui s'est amusé à faire ça ? La petite piste serait la bienvenue.

Merci,
Julien



smime.p7s
Description: Signature cryptographique S/MIME

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[David Ponzone]

Moi j’aime bien le modèle RIPE: si on est bénéficiaire à la fin de l’année, on 
redistribue l’argent aux membres.
Les membres devraient bien sûr si possible avoir le même poids quelque soit 
leur taille.
Peut-être une facturation à l’usage aussi, de sorte que tu ne paies pas 
1000€/mois pour 10 portas et un dump de la liste des numéros portés.
Evidemment, la structure de coût devrait être la plus saine possible en 
limitant  l’appel à la sous-traitance..
Et la structure devrait faire appel autant que possible aux ressources déjà 
payées en partie par l’Etat (Cloudwatt, Numergy, etc..).
Et la même structure pour le fixe et le mobile non ?

> Le 11 juil. 2017 à 11:49, Francois Demeyer  a écrit :
> 
> Tu pourrais nous décrire l’alternative à l’APNF telle que tu l’imagines ?
> 
>> Le 10 juil. 2017 à 16:28, Sébastien Lesimple 
>>  a écrit :
>> 
>> C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
>> hors controle du régulateur.
>> 
>> On 10/07/2017 16:02, Guillaume wrote:
>>> Te donner libre accès à un outil qui est nécessaire à tout opérateur
>>> pour pouvoir faire correctement son travail ? Mais tu es fou, ça
>>> serait s'asseoir sur une manne financière qui tombe gracieusement
>>> chaque mois, un peu comme les majors qui se font payer leur lutte
>>> anti-piratage par l'état (et les contribuables) avec la Hadopi ...
>>> 
>>> Guillaume
>>> 
>>> Le 10/07/2017 à 15:57, Sébastien Lesimple a écrit :
 Une association auto proclamée détentrice de la vérité universelle,
 constituée par les opérateurs puissant, sans aucun controle
 reglementaire ou tarifaire...
 Rien n'impose la mainmise de l'APNF sur la gestion de la portabilité
 hormis le refus de ses fondateurs de permettre l'emergence d'une
 alternative.
 C'est encore un mal qui s'est crée par défaillance du régulateur à
 imposer des règles qui ne soient pas discrinimatoires.
 
 Et entre nous à ce tarif là, faudrait voir a pas pousser mémé dans les
 horties!
 
 
 On 10/07/2017 15:48, Guillaume wrote:
> De quoi te plains-tu, tu as l'APNF :p
> 
> Fut une époque, tu pouvais porter ton numéro mais tu n'avais aucun
> moyen d'être certain de l'opérateur réel d'un numéro mobile et cela ne
> choquait personne :)
> 
> Tu auras peut-être ce que tu demandes le jour où il n'y aura plus de
> lignes cuivre en production.
> 
>  Guillaume
> 
> Le 10/07/2017 à 14:32, Sébastien Lesimple a écrit :
>> Je considere que cette tache devrait etre prise en charge par le
>> régulateur.
>> 
>> Qu'elle relève, par extention, du plan national de numerotation et
>> devrait etre accessible a tous gratuitement au meme titre que le reste
>> des infos sur les ressources de numéroation.
>> 
>> De meme que les No portés d'opérateurs devraient etre eux aussi
>> accessibles a tous mais c'est un autre sujet.
>> Laissons leur le bonheur de nous surfacturer les appels vers leurs
>> Numéros portés histoire de faire de la bonne marge...
>> 
>> T!
>> 
>> 
>> On 10/07/2017 14:01, David Ponzone wrote:
>>> Oh tu sais, je pense que la majorité des opérateurs alternatifs de
>>> taille modeste qui font de la traduction sont conscients du problème.
>>> Il y a aussi Rouen, qui est séparé en RD/RG, et on peut trouver
>>> d’autres cas, surtout dans les grandes villes.
>>> 
>>> Idéalement, on devrait utiliser les coordonnées GPS du téléphone
>>> appelant, ou éventuellement le code RIVOLI ou autre, et on devrait
>>> disposer d’un WebService mis à disposition à un prix raisonnable
>>> (coûtant) pour traduire.
>>> Vraiment idéalement, ça ne devrait pas être aux opérateurs de
>>> traduire.
>>> 
>>> Mais on en est pas là, faudra attendre encore 10 ou 20 ans.
>>> 
>>> D’ici là, tu traduis d’après le code INSEE, et tu gères les
>>> exceptions :)
>>> 
>>> 
 Le 10 juil. 2017 à 13:42, Grygoriy Dobrovolskyy  a
 écrit :
 
 Je me permet de vous attirer sur un problème national sur les
 numéros urgences, au delà de format des fichiers envoyé par
 certaines préfectures en mode "démerde toi" nous avons des gagnants
 qui mettent la vie des gens en danger. Comment ça doit fonctionner
 ? Chaque personne est attribue à une zone géographique avec numéro
 INSEE de la commune/arrondissement et son appel vers les numéro
 d'urgences est traduit vers la bonne destination. INSEE est un
 numéro unique, un exemple sur Paris:
 
 
 
 Par le principe nous ne pouvons pas avoir la répétition de INSEE
 dans le document. Mais voila les gagnants:
 
 A NIMES je dois demander à mes clients de voir un plan
 
 
 
 Pour la Corse je dois demander si c'est 

Re: [FRnOG] [MISC] Numéros Urgences ou vous pouvez tous *******

[Francois Demeyer]

Tu pourrais nous décrire l’alternative à l’APNF telle que tu l’imagines ?

> Le 10 juil. 2017 à 16:28, Sébastien Lesimple 
>  a écrit :
> 
> C'est bien le souci et la raison pour laquelle ce ne devrait etre laissé
> hors controle du régulateur.
> 
> On 10/07/2017 16:02, Guillaume wrote:
>> Te donner libre accès à un outil qui est nécessaire à tout opérateur
>> pour pouvoir faire correctement son travail ? Mais tu es fou, ça
>> serait s'asseoir sur une manne financière qui tombe gracieusement
>> chaque mois, un peu comme les majors qui se font payer leur lutte
>> anti-piratage par l'état (et les contribuables) avec la Hadopi ...
>> 
>> Guillaume
>> 
>> Le 10/07/2017 à 15:57, Sébastien Lesimple a écrit :
>>> Une association auto proclamée détentrice de la vérité universelle,
>>> constituée par les opérateurs puissant, sans aucun controle
>>> reglementaire ou tarifaire...
>>> Rien n'impose la mainmise de l'APNF sur la gestion de la portabilité
>>> hormis le refus de ses fondateurs de permettre l'emergence d'une
>>> alternative.
>>> C'est encore un mal qui s'est crée par défaillance du régulateur à
>>> imposer des règles qui ne soient pas discrinimatoires.
>>> 
>>> Et entre nous à ce tarif là, faudrait voir a pas pousser mémé dans les
>>> horties!
>>> 
>>> 
>>> On 10/07/2017 15:48, Guillaume wrote:
 De quoi te plains-tu, tu as l'APNF :p
 
 Fut une époque, tu pouvais porter ton numéro mais tu n'avais aucun
 moyen d'être certain de l'opérateur réel d'un numéro mobile et cela ne
 choquait personne :)
 
 Tu auras peut-être ce que tu demandes le jour où il n'y aura plus de
 lignes cuivre en production.
 
   Guillaume
 
 Le 10/07/2017 à 14:32, Sébastien Lesimple a écrit :
> Je considere que cette tache devrait etre prise en charge par le
> régulateur.
> 
> Qu'elle relève, par extention, du plan national de numerotation et
> devrait etre accessible a tous gratuitement au meme titre que le reste
> des infos sur les ressources de numéroation.
> 
> De meme que les No portés d'opérateurs devraient etre eux aussi
> accessibles a tous mais c'est un autre sujet.
> Laissons leur le bonheur de nous surfacturer les appels vers leurs
> Numéros portés histoire de faire de la bonne marge...
> 
> T!
> 
> 
> On 10/07/2017 14:01, David Ponzone wrote:
>> Oh tu sais, je pense que la majorité des opérateurs alternatifs de
>> taille modeste qui font de la traduction sont conscients du problème.
>> Il y a aussi Rouen, qui est séparé en RD/RG, et on peut trouver
>> d’autres cas, surtout dans les grandes villes.
>> 
>> Idéalement, on devrait utiliser les coordonnées GPS du téléphone
>> appelant, ou éventuellement le code RIVOLI ou autre, et on devrait
>> disposer d’un WebService mis à disposition à un prix raisonnable
>> (coûtant) pour traduire.
>> Vraiment idéalement, ça ne devrait pas être aux opérateurs de
>> traduire.
>> 
>> Mais on en est pas là, faudra attendre encore 10 ou 20 ans.
>> 
>> D’ici là, tu traduis d’après le code INSEE, et tu gères les
>> exceptions :)
>> 
>> 
>>> Le 10 juil. 2017 à 13:42, Grygoriy Dobrovolskyy  a
>>> écrit :
>>> 
>>> Je me permet de vous attirer sur un problème national sur les
>>> numéros urgences, au delà de format des fichiers envoyé par
>>> certaines préfectures en mode "démerde toi" nous avons des gagnants
>>> qui mettent la vie des gens en danger. Comment ça doit fonctionner
>>> ? Chaque personne est attribue à une zone géographique avec numéro
>>> INSEE de la commune/arrondissement et son appel vers les numéro
>>> d'urgences est traduit vers la bonne destination. INSEE est un
>>> numéro unique, un exemple sur Paris:
>>> 
>>> 
>>> 
>>> Par le principe nous ne pouvons pas avoir la répétition de INSEE
>>> dans le document. Mais voila les gagnants:
>>> 
>>> A NIMES je dois demander à mes clients de voir un plan
>>> 
>>> 
>>> 
>>> Pour la Corse je dois demander si c'est le sud ou le nord, aucun
>>> plan est donné, boussole non plus
>>> 
>>> 
>>> Pour cette ville j'ai du mettre ALBITRECCIA NORD et ALBITRECCIA SUD
>>> car les numéros vers 18 sont différents! (c'est pas le seul exemple
>>> pour la Corse)
>>> 
>>> Je ne suis pas contre que les communes fusionnent par exemple en
>>> 1973 Le Puy-Saint-Bonnet est rattachée à Cholet (fusion
>>> association). mais ils ont supprimé numéro INSEE mais pal le nom!
>>> 
>>> 49099;Cholet
>>> 49099;Puy Saint Bonnet (Le)
>>> 
>>> Je ne vais pas tout lister mais vous voyez la situation.
>>> 
>>> Aucune idée comment font les opérateurs portables, à mon avis ils
>>> sont dans la même situation.
>>> En tout cas je vous souhaite bonne chance en appelant sur le 15 de
>>> votre 

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[David Ponzone]

Sincèrement, renumérote les autres sites.
Un jour ou l’autre, ça va être ingérable.



> Le 11 juil. 2017 à 11:15, Wagab  a écrit :
> 
> Bonjour,
> 
> pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
> distant que je croyais avoir déjà testée mais vu que maintenant cela
> fonctionne, j'imagine que j'avais fait des conneries.
> 
> Maintenant je suis sur ma problématique de NAT.
> 
> Cordialement,
> Yann
> 
> 
> Le 2017-07-11 08:48, Wagab a écrit :
>> Bonjour la liste,
>> 
>> Cela fait quelques années que je suis la liste mais n'ayant que très peu
>> d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
>> contribuer.
>> Cependant, je suis confronté à un soucis sur lequel vous pourriez
>> m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
>> J'ai deux problématique.
>> 
>> La première :
>> 
>> Le besoin :
>> Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
>> mettre en place des tunnels IPSec.
>> J'ai monté une maquette le plus représentatif possible d'un cas concret.
>> 
>> 
>> | AZURE || ACCES Internet | Site Distant 
>>   |
>>Non maitrisé
>> Console_Az -|   | |
>>  |-- @ --|-- ... -- ... --|pfSense Site 
>> Distant|--|routeur|-- |Réseau
>> Cible|
>> pfSense_Az -|   | |
>> 
>> Réseau AZURE : 10.8.0.0/24
>> pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP Client
>> (192.168.0.110/24)
>> pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
>> Default GW : 192.168.2.10
>> routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
>> (192.168.2.0/24)
>> routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
>> 
>> 
>> Quand les machines auxquelles la Console_Az doit accéder sont
>> positionnées juste derrière le pfSense Site Distant, aucun problème.
>> Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
>> et le pfSense Site Distant.
>> 
>> Lorsque je lance un ping depuis la Console_Az vers une machine du réseau
>> cible, ce dernier ne passe pas.
>> Un ping depuis une machine du Réseau Cible, ce dernier passe.
>> 
>> J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
>> et le routeur lors d'un ping de la Console_Az vers une machine du réseau
>> cible. Je le vois bien transiter dans le tunnel (log sur les 2 pfSense).
>> A priori, rien sur le routeur (l'interface de log du routeur n'est pas
>> très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
>> ping d'une machine du Réseau Cible depuis le pfSense Site Distant. Celui
>> n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
>> m'indique qu'aucun ping n'arrive.
>> 
>> A priori, on est dans une problèmatique de débutant en terme de réseau.
>> Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
>> mais sans succès et à force je me mélange.
>> Voici la conf de mes tunnels IPSec :
>> 
>> pfSense Site Distant :
>> 
>> Configuration  :
>>  Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
>> Description
>> IKE V1   WAN mainAES (256 bits)  SHA1
>> Test IPSec VPN
>>  52.164.243.95
>> 
>> Mode Local SubnetRemote Subnet   P2 Protocol P2 Transforms   
>> P2 Auth
>> Methods
>> tunnel   192.168.2.0/24  10.8.0.0/24 ESP AES (auto)  
>> SHA1 
>> tunnel   172.16.1.0/24   10.8.0.0/24 ESP AES (auto)  
>> SHA1 
>> 
>> SADs :
>> Source   Destination ProtocolSPI Enc. 
>> alg.   Auth. alg.  Data 
>> 192.168.0.110IP Pub AzureESP cafd79ae
>> rijndael-cbchmac-sha1   0
>> B 
>> IP Pub Azure 192.168.0.110   ESP c2fbf651
>> rijndael-cbchmac-sha1
>>  17340 B 
>> 192.168.0.110IP Pub AzureESP cb6200d5
>> rijndael-cbchmac-sha1
>>  240 B 
>> IP Pub Azure 192.168.0.110   ESP c34cc1f1
>> rijndael-cbchmac-sha1
>>  120 B
>> 
>> SPDs :
>> Source   Destination Direction   ProtocolTunnel 
>> endpoints
>> 10.8.0.0/24  192.168.2.0/24  ◄ Inbound   ESP IP Pub Azure ->
>> 192.168.0.110
>> 10.8.0.0/24  172.16.1.0/24   ◄ Inbound   ESP IP Pub Azure ->
>> 192.168.0.110
>> 192.168.2.0/24   10.8.0.0/24 ► Outbound  ESP 
>> 192.168.0.110 -> IP Pub
>> Azure
>> 172.16.1.0/2410.8.0.0/24 ► Outbound  ESP 
>> 192.168.0.110 -> IP Pub
>> Azure 
>> 
>> pfSense_Az :
>> 
>> Configuration :
>>  Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
>> Description
>> IKE V1   WAN mainAES (256 bits)  SHA1
>> Test IPSec VPN
>>  78.155.157.245
>> 
>> Mode  

Re: [FRnOG] [TECH] Problématique IPSec sous pfSense

[Wagab]

Bonjour,

pour info, j'ai corrigé mon problème 1. Une simple route sur le pfSense
distant que je croyais avoir déjà testée mais vu que maintenant cela
fonctionne, j'imagine que j'avais fait des conneries.

Maintenant je suis sur ma problématique de NAT.

Cordialement,
Yann


Le 2017-07-11 08:48, Wagab a écrit :
> Bonjour la liste,
> 
> Cela fait quelques années que je suis la liste mais n'ayant que très peu
> d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
> contribuer.
> Cependant, je suis confronté à un soucis sur lequel vous pourriez
> m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
> J'ai deux problématique.
> 
> La première :
> 
> Le besoin :
> Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
> mettre en place des tunnels IPSec.
> J'ai monté une maquette le plus représentatif possible d'un cas concret.
> 
> 
> | AZURE | | ACCES Internet | Site Distant 
>   |
> Non maitrisé
> Console_Az -|   |  |
>   |-- @ --|-- ... -- ... --|pfSense Site 
> Distant|--|routeur|-- |Réseau
> Cible|
> pfSense_Az -|   |  |
> 
> Réseau AZURE : 10.8.0.0/24
> pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP Client
> (192.168.0.110/24)
> pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
> Default GW : 192.168.2.10
> routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
> (192.168.2.0/24)
> routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24
> 
> 
> Quand les machines auxquelles la Console_Az doit accéder sont
> positionnées juste derrière le pfSense Site Distant, aucun problème.
> Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
> et le pfSense Site Distant.
> 
> Lorsque je lance un ping depuis la Console_Az vers une machine du réseau
> cible, ce dernier ne passe pas.
> Un ping depuis une machine du Réseau Cible, ce dernier passe.
> 
> J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
> et le routeur lors d'un ping de la Console_Az vers une machine du réseau
> cible. Je le vois bien transiter dans le tunnel (log sur les 2 pfSense).
> A priori, rien sur le routeur (l'interface de log du routeur n'est pas
> très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
> ping d'une machine du Réseau Cible depuis le pfSense Site Distant. Celui
> n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
> m'indique qu'aucun ping n'arrive.
> 
> A priori, on est dans une problèmatique de débutant en terme de réseau.
> Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
> mais sans succès et à force je me mélange.
> Voici la conf de mes tunnels IPSec :
> 
> pfSense Site Distant :
> 
> Configuration  :
>   Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
> Description
> IKE V1WAN mainAES (256 bits)  SHA1
> Test IPSec VPN
>   52.164.243.95
> 
> Mode  Local SubnetRemote Subnet   P2 Protocol P2 Transforms   P2 Auth
> Methods
> tunnel192.168.2.0/24  10.8.0.0/24 ESP AES (auto)  
> SHA1 
> tunnel172.16.1.0/24   10.8.0.0/24 ESP AES (auto)  
> SHA1 
> 
> SADs :
> SourceDestination ProtocolSPI Enc. 
> alg.   Auth. alg.  Data 
> 192.168.0.110 IP Pub AzureESP cafd79ae
> rijndael-cbchmac-sha1   0
> B 
> IP Pub Azure  192.168.0.110   ESP c2fbf651rijndael-cbc
> hmac-sha1
>   17340 B 
> 192.168.0.110 IP Pub AzureESP cb6200d5
> rijndael-cbchmac-sha1
>   240 B 
> IP Pub Azure  192.168.0.110   ESP c34cc1f1rijndael-cbc
> hmac-sha1
>   120 B
> 
> SPDs :
> SourceDestination Direction   ProtocolTunnel 
> endpoints
> 10.8.0.0/24   192.168.2.0/24  ◄ Inbound   ESP IP Pub Azure ->
> 192.168.0.110
> 10.8.0.0/24   172.16.1.0/24   ◄ Inbound   ESP IP Pub Azure ->
> 192.168.0.110
> 192.168.2.0/2410.8.0.0/24 ► Outbound  ESP 
> 192.168.0.110 -> IP Pub
> Azure
> 172.16.1.0/24 10.8.0.0/24 ► Outbound  ESP 
> 192.168.0.110 -> IP Pub
> Azure 
> 
> pfSense_Az :
> 
> Configuration :
>   Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
> Description
> IKE V1WAN mainAES (256 bits)  SHA1
> Test IPSec VPN
>   78.155.157.245
> 
> Mode  Local SubnetRemote Subnet   P2 Protocol P2 Transforms   P2 Auth
> Methods
> tunnel10.8.0.0/24 192.168.2.0/24  ESP AES (auto)  
> SHA1 
> tunnel10.8.0.0/24 172.16.1.0/24   ESP AES (auto)  
> SHA1 
> 
> SADs :
> Source

Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Olivier Cochard-Labbé]

2017-07-11 8:51 GMT+02:00 Sébastien 65 :

> Je trouve étrange que keep ou carp ne fonctionnent pas sur du bond... Car
> si on veux une tolérance aux pannes + de débit rien ne vaut un bond/lacp
> avec du switch !
>
>
> J'ai du mal à comprendre le fonctionnement des deux softs... Il va peut
> être falloir migrer sous BSD pour faire bond+vrrp@vmac !!
>
>
>
​Bonjour Sébastien,
pour ta conversion vers FreeBSD et te guider vers la lumière, voici comment
le faire ;-)

Soit une machine avec 2 cartes réseaux Intel (drivers igb).
Pour la première machine (master):

sysrc hostname=depenguinator1
sysrc cloned_interfaces="lagg0"
sysrc ifconfig_igb0="up"
sysrc ifconfig_igb1="up"
sysrc ifconfig_lagg0="inet 10.0.0.1/29 laggproto loadbalance laggport igb0
laggport ibg1"
sysrc ifconfig_lagg0_alias0="inet 10.0.0.6/32 vhid 1 advskew 100 pass
abcd123"
echo 'carp_load="YES"' >> /boot/loader.conf
kldload carp
service netif restart

Pour la seconde machine (backup):

sysrc hostname=depenguinator2
sysrc cloned_interfaces="lagg0"
sysrc ifconfig_igb0="up"
sysrc ifconfig_igb1="up"
sysrc ifconfig_lagg0="inet 10.0.0.2/29 laggproto loadbalance laggport igb0
laggport igb1"
sysrc ifconfig_lagg0_alias0="inet 10.0.0.6/32 vhid 1 advskew 200 pass
abcd123"
echo 'carp_load="YES"' >> /boot/loader.conf
kldload carp
service netif restart

Et comme demandé: pas de preempt d'activé, pour éviter que la master
reprenne son rôle de master suite à un reboot de celui-ci.

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

Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX

[Fabien H]

Très intéressant tout ça, merci pour les retours


Le 11 juillet 2017 à 10:26, Xavier Beaudouin  a écrit :

> Hello,
>
> > 3 raisons de plus :
> > - permet de gérer son trafic au cas où sont tuyaux sur le IX est plein
> (depeerer
> > peer par peer)
> > - certain demande une sorte de contrat morale peer par peer. (des gros
> > français...) (ils demandent de pas faire transiter du trafic forbiden ou
> > moralement inacceptable...) rejoint un peu le point 5  de Nicolas je
> crois.
> > - backup les routes serveurs pour ne pas dépendre d'eux (certains clients
> > demande la liste des peerings direct) j'en avais parlé sur cette liste
> il y a
> > qque année :-)
> > - et surement d'autre...
>
> Une autre pratique, en cas de DDoS ca permet de limiter les effets de
> bords surtout quand la connection a l'IX est à faible débit...
>
> Xavier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX

[Xavier Beaudouin]

Hello,

> 3 raisons de plus :
> - permet de gérer son trafic au cas où sont tuyaux sur le IX est plein 
> (depeerer
> peer par peer)
> - certain demande une sorte de contrat morale peer par peer. (des gros
> français...) (ils demandent de pas faire transiter du trafic forbiden ou
> moralement inacceptable...) rejoint un peu le point 5  de Nicolas je crois.
> - backup les routes serveurs pour ne pas dépendre d'eux (certains clients
> demande la liste des peerings direct) j'en avais parlé sur cette liste il y a
> qque année :-)
> - et surement d'autre...

Une autre pratique, en cas de DDoS ca permet de limiter les effets de bords 
surtout quand la connection a l'IX est à faible débit...

Xavier


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

Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Vincent Bernat]

 ❦ 11 juillet 2017 06:51 GMT, Sébastien 65  :

> Avec la configuration préconisée dans les docs de keep voici l'arp sur le 
> master Deb1 :
>
>
> 10.0.0.2 (incomplete)  
> vrrp.1
> 10.0.0.2 ether   00:60:e0:6b:13:2a   C 
> bond0
>
>
> Sur Deb2 :
>
>
> 10.0.0.6 ether   00:1b:21:9f:cd:95   C 
> bond0
> 10.0.0.1 ether   00:1b:21:9f:cd:95   C 
> bond0

La conf préconisée dans la doc ne peut fonctionner que si bond0 n'a pas
d'IP propre ou si la VIP est une /32 (et non une /29). Sinon, passer
arp_announce à 2 devrait aussi résoudre le problème.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


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

RE: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Sébastien 65]

Je trouve étrange que keep ou carp ne fonctionnent pas sur du bond... Car si on 
veux une tolérance aux pannes + de débit rien ne vaut un bond/lacp avec du 
switch !


J'ai du mal à comprendre le fonctionnement des deux softs... Il va peut être 
falloir migrer sous BSD pour faire bond+vrrp@vmac !!


Deb1 = 10.0.0.1/29 => bond0

Deb2 = 10.0.0.2/29 => bond0

IP Virtuelle = 10.0.0.6/29 => vrrp.1 via bond0


vrrp_instance VI_TEST_1 {
interface bond0
state BACKUP
virtual_router_id 1
priority 150
advert_int 1
unicast_src_ip 10.0.0.1 # Deb_1
unicast_peer {
10.0.0.2  # Deb_2
}

authentication {
auth_type PASS
auth_pass abcd123
}
virtual_ipaddress {
10.0.0.6/29
}
nopreempt
use_vmac
#vmac_xmit_base
#garp_master_delay 1
}


@MAC virtuelle vrrp.1 : 00:00:5e:00:01:01


Avec la configuration préconisée dans les docs de keep voici l'arp sur le 
master Deb1 :


10.0.0.2 (incomplete)  
vrrp.1
10.0.0.2 ether   00:60:e0:6b:13:2a   C bond0


Sur Deb2 :


10.0.0.6 ether   00:1b:21:9f:cd:95   C bond0
10.0.0.1 ether   00:1b:21:9f:cd:95   C bond0



De : frnog-requ...@frnog.org  de la part de Jean Théry 

Envoyé : mardi 11 juillet 2017 03:42:23
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème


Attention, il est possible que le mode bond en question ne fonctionne
pas avec CARP non plus

(perso j'ai déjà eu le problème sur du vxlan)


Le 10.07.2017 à 22:17, David Ponzone a écrit :
> Je reste pantois.
>
>> Le 10 juil. 2017 à 22:12, Sébastien 65  a écrit :
>>
>> Oui j'utilise bien des interfaces ethernet et pas wifi. Ici j'utilise le 
>> mode bond avec deux eth pour vrrp... Les machines ne sont pas virtuelle, du 
>> pur hardware connecté sur un switch.
>> 
>> De : Robin Cordier 
>> Envoyé : lundi 10 juillet 2017 21:56:26
>> À : frnog@frnog.org; Sébastien 65; frnog@frnog.org
>> Objet : RE: [FRnOG] [TECH] UCARP/VRRP avec Debian problème
>>
>> Réponse très rapide, tu fais bien ça sur une interface ethernet? Ça ne 
>> marchera pas avec le wifi (vu que la plupart des nouveaux macs non plus 
>> dethernet)
>>
>> Sinan Je laisse les spécialistes Mac te répondre concernant ce test.
>>
>> ++
>>
>> Le 10 juillet 2017 14:06:34 GMT-04:00, "Sébastien 65"  
>> a écrit :
>>
>> Dans la série pas de chance avec Keepalived ! Je me suis essayé a vouloir 
>> utiliser une adresse mac virtuelle sur l'IP virtuelle... Bin ça marche pas 
>> pourtant je force l'utilisation avec use_vmac...Tuning du arp & RP_filter 
>> dans le sysctl.conf et tout le touintoin !!!
>>
>> J'ai bien une interface vrrp.ID qui monte avec une mac RFC vrrp, cependant 
>> si je ping l'IP virtuelle je vois la mac de l'interface physique et non 
>> celle de vrrp.ID :(
>>
>> Je dois être maudit c'pa' possible Lé ou mon routeur Cisco ou ça marche 
>> nickel !
>> 
>>
>> De : frnog-requ...@frnog.org  de la part de Raphael 
>> Mazelier 
>> Envoyé : dimanche 9 juillet 2017 18:45:44
>> À : frnog@frnog.org
>> Objet : Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème
>>
>>
>>
>> On 07/07/2017 19:33, David Ponzone wrote:
>> Je sais pas si c’est encore d’actualité, mais en cherchant vite fait pour 
>> aider Sébastien, j’ai trouvé ça concernant uCARP:
>>
>> http://www.syawar.com/2013/01/16/ucarp-prevent-re-assertion-of-original-master/
>>  
>> 
>>
>> A priori, le monsieur a aussi eu besoin de déclarer les 2 en SLAVE pour que 
>> ça tombe en marche, avec un inconvénient.
>>
>>
>>
>> Cela vaut ce que vaut comme retour, mais j'avais eu exactement le meme
>> genre de soucis quand j'avais évaluer ucarp à l'époque. Après avoir lu
>> le code source en partie j'avais conclu sur le fait que cela ne faisait
>> pas ce qui était annoncé. Étonnant pour un truc codé par Franck Denis
>> mais bref j'étais passé sur keepalived. (et pourtant j'étais fan du
>> truc, simple et efficace sur le papier).
>>
>> Sinon s'il y a des gens aventureux ils peuvent tester mon essai d'un
>> démon de HA : https://github.com/ut0mt8/simple-ha-go ; ça marchait pour
>> moi :)
>>
>>
>> --
>> Raphael Mazelier
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>> --
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
>> brièveté.
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de 

[FRnOG] [TECH] Problématique IPSec sous pfSense

[Wagab]

Bonjour la liste,

Cela fait quelques années que je suis la liste mais n'ayant que très peu
d'expertise dans vos domaines, je n'ai jamais eu l'occasion de
contribuer.
Cependant, je suis confronté à un soucis sur lequel vous pourriez
m'aider. Je pense que c'est quelque chose de simple mais pas pour moi.
J'ai deux problématique.

La première :

Le besoin :
Accéder depuis un cloud Azure à des sites distants. Il a été décidé de
mettre en place des tunnels IPSec.
J'ai monté une maquette le plus représentatif possible d'un cas concret.


| AZURE |   | ACCES Internet | Site Distant 
  |
  Non maitrisé
Console_Az -|   ||
|-- @ --|-- ... -- ... --|pfSense Site 
Distant|--|routeur|-- |Réseau
Cible|  
pfSense_Az -|   ||

Réseau AZURE : 10.8.0.0/24
pfSense Site Distant / Interface WAN (côté ACCES INTERNET) : DHCP Client
(192.168.0.110/24)
pfSense Site Distant / Interface LAN (côté routeur) : 192.168.2.9/24 -
Default GW : 192.168.2.10
routeur / Interface WAN (côté pfSense Site Distant) : DHCP Client
(192.168.2.0/24)
routeur / Interface LAN (côté Réseau Cible) : 172.16.1.9/24


Quand les machines auxquelles la Console_Az doit accéder sont
positionnées juste derrière le pfSense Site Distant, aucun problème.
Ma problématique réside dans l'ajout d'un routeur entre le réseau cible
et le pfSense Site Distant.

Lorsque je lance un ping depuis la Console_Az vers une machine du réseau
cible, ce dernier ne passe pas.
Un ping depuis une machine du Réseau Cible, ce dernier passe.

J'ai réalisé quelques traces sur le pfSense_Az, le pfSense Site Distant
et le routeur lors d'un ping de la Console_Az vers une machine du réseau
cible. Je le vois bien transiter dans le tunnel (log sur les 2 pfSense).
A priori, rien sur le routeur (l'interface de log du routeur n'est pas
très bavarde ...). Afin de valider ce dernier point, j'ai réalisé un
ping d'une machine du Réseau Cible depuis le pfSense Site Distant. Celui
n'a pas fonctionné. Le wireshark lancé sur la machine du réseau cible
m'indique qu'aucun ping n'arrive.

A priori, on est dans une problèmatique de débutant en terme de réseau.
Malgré tout, je sèche. J'ai réalisé quelques manips d'ajout de route
mais sans succès et à force je me mélange.
Voici la conf de mes tunnels IPSec :

pfSense Site Distant :

Configuration  :
Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
Description
IKE V1  WAN mainAES (256 bits)  SHA1Test 
IPSec VPN  
52.164.243.95

ModeLocal SubnetRemote Subnet   P2 Protocol P2 Transforms   P2 Auth
Methods
tunnel  192.168.2.0/24  10.8.0.0/24 ESP AES (auto)  SHA1
tunnel  172.16.1.0/24   10.8.0.0/24 ESP AES (auto)  SHA1 

SADs :
Source  Destination ProtocolSPI Enc. alg.   
Auth. alg.  Data
192.168.0.110   IP Pub AzureESP cafd79aerijndael-cbc
hmac-sha1   0
B   
IP Pub Azure192.168.0.110   ESP c2fbf651rijndael-cbc
hmac-sha1
17340 B 
192.168.0.110   IP Pub AzureESP cb6200d5rijndael-cbc
hmac-sha1
240 B   
IP Pub Azure192.168.0.110   ESP c34cc1f1rijndael-cbc
hmac-sha1
120 B

SPDs :
Source  Destination Direction   ProtocolTunnel endpoints
10.8.0.0/24 192.168.2.0/24  ◄ Inbound   ESP IP Pub Azure ->
192.168.0.110
10.8.0.0/24 172.16.1.0/24   ◄ Inbound   ESP IP Pub Azure ->
192.168.0.110
192.168.2.0/24  10.8.0.0/24 ► Outbound  ESP 192.168.0.110 
-> IP Pub
Azure
172.16.1.0/24   10.8.0.0/24 ► Outbound  ESP 192.168.0.110 
-> IP Pub
Azure 

pfSense_Az :

Configuration :
Remote Gateway  ModeP1 Protocol P1 Transforms   P1 
Description
IKE V1  WAN mainAES (256 bits)  SHA1Test 
IPSec VPN
78.155.157.245

ModeLocal SubnetRemote Subnet   P2 Protocol P2 Transforms   P2 Auth
Methods
tunnel  10.8.0.0/24 192.168.2.0/24  ESP AES (auto)  SHA1
tunnel  10.8.0.0/24 172.16.1.0/24   ESP AES (auto)  SHA1 

SADs :
Source  Destination ProtocolSPI Enc. alg.   
Auth. alg.  
10.8.0.5IP Pub Distant  ESP cbcd362arijndael-cbc
hmac-sha1
IP Pub Distant  10.8.0.5ESP ccc761e7rijndael-cbc
hmac-sha1
10.8.0.5IP Pub Distant  ESP c8b22c38rijndael-cbc
hmac-sha1
IP Pub Distant  10.8.0.5ESP c7c85925rijndael-cbc
hmac-sha1

SPDs :
Source  Destination Direction   ProtocolTunnel endpoints