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/
