Re: [FRnOG] [TECH] LCP Timeout PPTP

2017-09-05 Par sujet Charles Koprowski 
Bonjour,

Le 5 septembre 2017 à 10:08, Eliott Trouillet <
e.trouil...@europrocurement.net> a écrit :
>
>
> Cela m’amène logiquement à penser que le soucis viens de notre Stormshield
> (SN200) sur Brest, ou alors de notre fournisseur. Ce dernier m’as cependant
> affirmé (et je ne vois pas de raison pour qu’il nous raconte n’importe
> quoi)
> qu’il ne filtrait rien.


J'ai le même genre de problème : impossible de connecter plusieurs postes
derrière un Stormhield vers un même VPN PPTP / GRE.

Malheureusement, je n'ai pas encore eu le temps de remonter le problème au
support.

-- 
Charles Koprowski

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

Re: [FRnOG] [TECH] LCP Timeout PPTP

2017-09-05 Par sujet Dominique Rousseau 
Le Tue, Sep 05, 2017 at 10:08:51AM +0200, Eliott Trouillet 
[e.trouil...@europrocurement.net] a écrit:
[...]
> 
> Ça se gâte quand une deuxième personne de Brest tente de se connecter sur
> x.x.x.x. On a un LCP timeout. Par contre, si il se connecte sur y.y.y.y ou
> z.z.z.z, tout fonctionne. Mais rebelotte si deux personnes se connectent sur
> y.y.y.y en même temps.

Comme ca, je dirais que le firewall "de Brest" se prend les pieds dans
le NAT du GRE, et qu'il ne sait pas nater 2 sessions GRE differents pour
2 ips "inside" vers la meme ip exterieure.
Donc soit les brestois vont devoir disposer d'une autre techno de VPN,
soit il faut une ip de terminaison par utilisateur (simultané), soit il
faut changer leur firewall :)


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

Re: [FRnOG] [TECH] LCP Timeout PPTP

2017-09-05 Par sujet David Ponzone 
Cherche pas plus longtemps.
PPTP, c'est la merde.
Le routeur côté client doit le gérer pour le laisser passer (PPTP passthrough), 
et un seul client peut se connecter à une seule IP au même moment, ce qui est 
ton problème:
https://doc.pfsense.org/index.php/What_are_the_limitations_of_PPTP_in_pfSense

Sincèrement, tu commandes un Mikrotik à 50€ et tu migres ça en L2TP/IPsec en 2h.
Ou si tu as un serveur MS, tu migres en SSTP mais bon, c'est si t'es maso.

Le 5 sept. 2017 à 10:08, Eliott Trouillet a écrit :

> Bonjour la liste,
> 
> 
> 
> Je ne suis pas habitué à poster ce genre de problème, puisqu’en principe un
> peu de recherche sur le web me permet de les résoudre. Mais celui-ci me pose
> une colle.
> 
> 
> 
> Nous avons un site à Paris qui héberge pas mal de nos serveurs, et un accès
> distant est souvent nécessaire. Ce dernier se fait au moyen d’un VPN PPTP
> (je sais, c’est mal, c’était comment ça quand je suis arrivé, promis, ça va
> disparaitre un jour) sur leur firewall cyberoam.
> 
> 
> 
> A Paris nous avons 3 liens (fibre, VDSL, SDSL), les deux derniers étant en
> principe utilisées en backup. On dira que leur ip sont x.x.x.x, y.y.y.y et
> z.z.z.z
> 
> 
> 
> Nous avons 4 développeurs à Brest, et ils ont régulièrement besoin de se
> connecter à Paris, pour cela, ils utilisent donc le super-vpn-unsecure, en
> se connectant sur la fibre (x.x.x.x). Cela fonctionne, à peu près.
> 
> 
> 
> En effet, quand une seule personne est connectée, tout se passe bien.
> Connexion établie, tout ça, LCP link established, PAP authentification
> successful, IPCP ip allocated, c’est génial.
> 
> 
> 
> Ça se gâte quand une deuxième personne de Brest tente de se connecter sur
> x.x.x.x. On a un LCP timeout. Par contre, si il se connecte sur y.y.y.y ou
> z.z.z.z, tout fonctionne. Mais rebelotte si deux personnes se connectent sur
> y.y.y.y en même temps.
> 
> Vu qu’ils sont 4 et qu’on a 3 IP à Paris, la solution temporaire va devoir
> le rester.
> 
> 
> 
> Je précise que seul notre site de Brest a le problème, si plusieurs
> personnes se connectent depuis le site de Lyon, aucun soucis.
> 
> 
> 
> Cela m’amène logiquement à penser que le soucis viens de notre Stormshield
> (SN200) sur Brest, ou alors de notre fournisseur. Ce dernier m’as cependant
> affirmé (et je ne vois pas de raison pour qu’il nous raconte n’importe quoi)
> qu’il ne filtrait rien.
> 
> 
> 
> Au niveau config sur le Stormshield, j’ai eu un problème initial, j’ai dû
> autoriser le protocole GRE (47), car même avec un allow any any, ça passait
> pas. Et donc la règle allow GRE doit rester au-dessus, sinon, rebelotte.
> 
> 
> 
> Niveau schéma ça donnerais quelque chose comme ça :
> 
> 
> 
> User ==> SN200 ==> MikrotikFAI ==> *l’internet mondial* ==> cyberoam paris
> ==> Réseau lan paris
> 
> 
> 
> Si quelqu’un a déjà rencontré ce genre de problème, je suis preneur.
> 
> 
> 
> PS1 : SN200 last version de l’OS (ça doit être genre 3.2.1 de tête, j’ai pas
> d’accès direct à la conf jdoit me connecter sur un pc de là-bas)
> 
> PS2 : Vu que notre FAI nous fournis un accès Fibre à Brest avec redondance
> Wi-Fi, il nous a pas bridgé le routeur (j’ai pas les détails techniques,
> mais je suppose que la manière dont il gère ça l’en empêche), la patte WAN
> du Stormshield est donc sur la patte LAN  du mikrotik. Quand on a besoin
> d’un forward de port on les appelle et ça passe très bien comme ça. Je
> soupçonne fortement que ça ait un lien avec notre problème.
> 
> PS3 : Il y a un tunnel IPsec monté entre Brest et une infra louée chez OVH.
> Mais les plans d’adressage sont différents entre paris, Brest, et l’infra
> OVH.
> 
> 
> 
> La bise,
> 
> 
> 
> Eliott T.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] LCP Timeout PPTP

2017-09-05 Par sujet Eliott Trouillet 
Bonjour la liste,

 

Je ne suis pas habitué à poster ce genre de problème, puisqu’en principe un
peu de recherche sur le web me permet de les résoudre. Mais celui-ci me pose
une colle.

 

Nous avons un site à Paris qui héberge pas mal de nos serveurs, et un accès
distant est souvent nécessaire. Ce dernier se fait au moyen d’un VPN PPTP
(je sais, c’est mal, c’était comment ça quand je suis arrivé, promis, ça va
disparaitre un jour) sur leur firewall cyberoam.

 

A Paris nous avons 3 liens (fibre, VDSL, SDSL), les deux derniers étant en
principe utilisées en backup. On dira que leur ip sont x.x.x.x, y.y.y.y et
z.z.z.z

 

Nous avons 4 développeurs à Brest, et ils ont régulièrement besoin de se
connecter à Paris, pour cela, ils utilisent donc le super-vpn-unsecure, en
se connectant sur la fibre (x.x.x.x). Cela fonctionne, à peu près.

 

En effet, quand une seule personne est connectée, tout se passe bien.
Connexion établie, tout ça, LCP link established, PAP authentification
successful, IPCP ip allocated, c’est génial.

 

Ça se gâte quand une deuxième personne de Brest tente de se connecter sur
x.x.x.x. On a un LCP timeout. Par contre, si il se connecte sur y.y.y.y ou
z.z.z.z, tout fonctionne. Mais rebelotte si deux personnes se connectent sur
y.y.y.y en même temps.

Vu qu’ils sont 4 et qu’on a 3 IP à Paris, la solution temporaire va devoir
le rester.

 

Je précise que seul notre site de Brest a le problème, si plusieurs
personnes se connectent depuis le site de Lyon, aucun soucis.

 

Cela m’amène logiquement à penser que le soucis viens de notre Stormshield
(SN200) sur Brest, ou alors de notre fournisseur. Ce dernier m’as cependant
affirmé (et je ne vois pas de raison pour qu’il nous raconte n’importe quoi)
qu’il ne filtrait rien.

 

Au niveau config sur le Stormshield, j’ai eu un problème initial, j’ai dû
autoriser le protocole GRE (47), car même avec un allow any any, ça passait
pas. Et donc la règle allow GRE doit rester au-dessus, sinon, rebelotte.

 

Niveau schéma ça donnerais quelque chose comme ça :

 

User ==> SN200 ==> MikrotikFAI ==> *l’internet mondial* ==> cyberoam paris
==> Réseau lan paris

 

Si quelqu’un a déjà rencontré ce genre de problème, je suis preneur.

 

PS1 : SN200 last version de l’OS (ça doit être genre 3.2.1 de tête, j’ai pas
d’accès direct à la conf jdoit me connecter sur un pc de là-bas)

PS2 : Vu que notre FAI nous fournis un accès Fibre à Brest avec redondance
Wi-Fi, il nous a pas bridgé le routeur (j’ai pas les détails techniques,
mais je suppose que la manière dont il gère ça l’en empêche), la patte WAN
du Stormshield est donc sur la patte LAN  du mikrotik. Quand on a besoin
d’un forward de port on les appelle et ça passe très bien comme ça. Je
soupçonne fortement que ça ait un lien avec notre problème.

PS3 : Il y a un tunnel IPsec monté entre Brest et une infra louée chez OVH.
Mais les plans d’adressage sont différents entre paris, Brest, et l’infra
OVH.

 

La bise,

 

Eliott T.

 

 

 

 


 

 

 


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