Connexion Impossible Au Vpn

[CoolRaoul]

Sous Android, j'ai mis type:PPTP et j'ai coché MPPE, adresse du serveur : l'adresse IP externe de la box.

Sur le NAS, Authentification : MSCHAP v2, Chiffrement : Require MPPE, Le bon MTU (1400 par défaut) et j'ai coché "utiliser le DNS manuel" avec l'adresse IP interne de ma Box pour etre sur que les requetes sortent le plus directement possible.

Ca fonctionne aussi pour toi ?

Pour le login, j'utilise un nom d'utilisateur "interne" au nas (pas radius, ldap...)

Meme setup,

En fait ça fonctionne lorsque je suis connecté à un réseau wifi mais pas en mode 3G, franchement chelou donc..

[sonson]

En wifi ca veut dire que tu es sur le meme reseau.

Donc peut etre une config incomplete au niveau de la box ? si openvpn fonctionne c'est que le port 1194 est bien redirigé. Il n'y a pas de raison que le port 1723 pour le PPTP ne le soit pas bien redirigé aussi. non ?

[CoolRaoul]

En wifi ca veut dire que tu es sur le meme reseau.

Ben non, pas forcément.

De toutes façon je viens de faire le test en 3G avec un *autre* téléphone et sur ce dernier ça se connecte.

Le problème n'est donc pas coté NAS, mais je ne comprend pas ou ça coince.

**EDIT**

Je viens de tomber la dessus (suis chez orange), me demande si ce n'est pas le même probleme:

http://entraide.orange.fr/assistance/messages/index/8959/iphone-vpn-pptp-bloque.html

[sonson]

Par "le meme reseau", je voulais dire que tu ne passe pas par l'adresse externe de ta livebox.

Tu as probablement trouvé la réponse au problème ! Orange bloque le port 1723 !

Essaie de rediriger sur la livebox un autre port externe (exemple 41723) vers le 1723 interne. Mais la question est : le client VPN Android sait-il utiliser le port 41723 ?

Edit : Je viens de tester, ca ne fonctionne pas avec le client integré à Android. Meme si on met l'adresse du serveur à IPExterneBox:41723, la connexion renvoie un "Expiation du delai".

Faudra essayer un client PPTP qui sait indiquer un autre port que le 1723.

Mais là, pourquoi ne pas utiliser OpenVPN si tu dois utiliser un logiciel supplémentaire....

Modifié le 29 juin 2013 par sonson

[PiwiLAbruti]

Lorsque j'étais chez Orange (iPhone), le VPN PPTP avec le NAS fonctionnait bien.
Si le trafic sur le port tcp/1723 rentre bien sur le NAS, alors c'est peut-être le protocole d'encapsulation GRE (47) qui ne passe pas.

Modifié le 1 juillet 2013 par PiwiLAbruti

[CoolRaoul]

Par "le meme reseau", je voulais dire que tu ne passe pas par l'adresse externe de ta livebox.

Comprend toujours pas: quand mon téléphone est connecté à un réseau wifi (pas forcément le mien hein!), pour arriver sur mon NAS le flux réseau va bien passer par l’adresse externe de ma box!

Tu as probablement trouvé la réponse au problème ! Orange bloque le port 1723 !

Pas exactement pourtant puisque en sniffant le traffic IP (avec la commande "tcpdump") je vois bien passer du trafic sur le port 1723 (et dans le deux sens qui plus est) lors de mes essais en 3G, si le port était bloqué je n'aurais que des timeouts, et de plus on voit bien dans "/var/log/messages" que le dialogue s'établit avant de se retrouver bloqué.

Me demande si ça ne serait pas une histoire de MTU.

Modifié le 29 juin 2013 par CoolRaoul

[CoolRaoul]

Si le trafic sur le port tcp/1723 rentre bien sur le NAS, alors c'est peut-être le protocole d'encapsulation GRE (48) qui ne passe pas.

"GRE": là tu me parle chinois!

Je vais peut-être un peu temporiser: le 1er juillet je dois basculer vers un nouveau forfait (toujours chez Orange), on verra si ça coince toujours et si c'est le cas faudra que je contacte le service client.

S'agissant d'un forfait entreprise, ça serait étonnant que le VPN soit bloqué volontairement (d'autant plus étrange qu'OpenVPN ne l'est pas!)

[PiwiLAbruti]

"GRE": là tu me parle chinois!

[CoolRaoul]

Ca reste quand même obscur pour moi: si le protocole est au même niveau que TCP et UDP, par quelle magie une box ADSL serait capable de deviner vers quel équipement du réseau local rediriger les paquets de ce type puisque seuls TCP et UDP peuvent être explicitement routés via la table de redirection de ports?

[sonson]

Je pense qu'une fois la connexion etablie de l'exterieur vers l'interieur par le port 1723, c'est le serveur VPN qui initie le transfert en sortie grace au protocole GRE. Et ca ce n'est pas bloqué normalement.

au 1er juillet pour la suite des tests !!!

[PiwiLAbruti]

@CoolRaoul : c'est justement la différence entre NAT et PAT. On parle toujours à tort de NAT pour la redirection de ports alors qu'il s'agit de PAT. Un routeur sait gérer n'importe quel autre protocole que TCP/UDP grâce au NAT.

Je ne vais pas faire un cours sur les réseaux, si ça t'intéresse il y a tout plein de ressources disponibles à ce sujet.

[bud77]

@CoolRaoul : c'est justement la différence entre NAT et PAT. On parle toujours à tort de NAT pour la redirection de ports alors qu'il s'agit de PAT. Un routeur sait gérer n'importe quel autre protocole que TCP/UDP grâce au NAT.

Je ne vais pas faire un cours sur les réseaux, si ça t'intéresse il y a tout plein de ressources disponibles à ce sujet.

Oué mais PiwiPédia est tellement plus clair que Wikipedia

[CoolRaoul]

@CoolRaoul : c'est justement la différence entre NAT et PAT. On parle toujours à tort de NAT pour la redirection de ports alors qu'il s'agit de PAT. Un routeur sait gérer n'importe quel autre protocole que TCP/UDP grâce au NAT.

Je ne vais pas faire un cours sur les réseaux, si ça t'intéresse il y a tout plein de ressources disponibles à ce sujet.

Mouais.. faudra que je demande a mes collègues spécialiste au bureau parce que je suis toujours perplexe: le NAT dynamique (celui implémenté dans les routeurs et BOX ADSL) ) à besoin de s'appuyer les ports pour savoir router les paquets entrants vers le bon équipement et ne pas Et le protocole GRE ne contient pas de concept de port.

Lorsque l'on fait du NAT pour faire communiquer un réseau local avec internet par l'intermédiaire d'une IP externe unique le PAT est inévitable, c'est bien expliqué ici: http://blog.boson.com/bid/53313/NAT-and-PAT-What-s-the-Difference

Faire du NAT sans faire de PAT impliquerai de n'utiliser que des addresses enregistrées sur son réseau local ("In order to use traditional NAT in this scenario, you would need to purchase a registered IP address for each host on your internal network.")

Autre référence;

http://kb.radware.com/questions/2999/A+Note+about+PPTP%2C+NAT+and+Linkproof

As GRE is an IP based connection, it can not traverse dynamic NAT. Dynamic NAT performs port translation and assumes Layer 4 whereas GRE uses Layer 3 information

PS: je viens de consolider mon test wifi, contrairement à ce que je pensait ça ne marche pas à partir d'un autre réseau wifi que le mien ce qui semblerait indiquer qu'en effet il s'agit bien d'une histoire de routage.

Vais mettre le NAS en DMZ sur la box le temps de valider tout ça

[CoolRaoul]

Avec le NAT en DMZ, je vois bien passer le traffic sur le protocole "GRE" (dans les deux sens) donc ce n'est pas Orange qui filtre
mais ça échoue toujours:

fserv> tcpdump proto gre
12:21:42.607288 IP fserv > 193.253.141.153: GREv1, call 25893, seq 0, length 41: LCP, Conf-Request (0x01), id 1, length 27
12:21:42.747571 IP 193.253.141.153 > fserv: GREv1, call 1408, seq 0, length 40: LCP, Conf-Request (0x01), id 1, length 26
12:21:42.747887 IP fserv > 193.253.141.153: GREv1, call 25893, seq 1, ack 0, length 28: LCP, Conf-Reject (0x04), id 1, length 10
12:21:45.607692 IP fserv > 193.253.141.153: GREv1, call 25893, seq 2, length 41: LCP, Conf-Request (0x01), id 1, length 27
12:21:45.969963 IP 193.253.141.153 > fserv: GREv1, call 1408, seq 1, length 40: LCP, Conf-Request (0x01), id 1, length 26
etc ...

Note: pour que tcpdump comprenne faut ajouter la ligne

gre 47 GRE # Generic Routing Encapsulation

à /etc/protocols

A noter: lors du meme test mais avec le téléphone connecté en freewifi (considéré donc comme réseau wifi externe) tcpdump sur le protocole "GRE" ne voit que des paquets *sortants*, pas les réponses donc (malgres la config DMZ)

Va comprendre!

[CoolRaoul]

Je continue a avancer

Si j'en croie ce qui est écrit ici, VPN PPTP derrière freebox V5, hors DMZ point de salut:

"De toute manière le PPTP c'est fichu pour moi, la freebox ne redirige que les protocole TCP et UDP, pas de GRE sauf si je mets mon serveur dans la DMZ."

A noter que c'est quand meme contradictoire avec mon test en connexion 3G ou j'ai bien vu du traffic GRE dans les deux sens, comme quoi rien n'est simple

Modifié le 30 juin 2013 par CoolRaoul

[PiwiLAbruti]

Lorsque j'avais une Freebox v5 le PPTP passait aussi bien que sur la v6 que j'ai maintenant.

[CoolRaoul]

Lorsque j'avais une Freebox v5 le PPTP passait aussi bien que sur la v6 que j'ai maintenant.

Résumons:

• en 3G tcpdump voit bien passer le traffic "GRE" dans les 2 sens, donc ce n'est pas Orange qui bloque. Mais la connexion échoue. (me faudrait trouver quelqu'un de suffisamment compétent pour analyser ma capture).
• via freewifi je ne vois que des paquets GRE sortants: serait-il possible que free filtre ce protocole dans le cas du wifi "communautaire"?
• sur mon réseau local en wifi ça fonctionne (c'est quand même la moindre des choses, mais on conviendra que l'utilité pratique de cette configuration est discutable :-> )
• en OpenVPN ça passe dans toutes les situations.

Enfin, pour aller plus avant avec cette histoire de "natting" du protocole "GRE" je pense avoir trouvé l'explication définitive ici: http://think-like-a-computer.com/2011/09/28/vpn-passthrough/

En pratique, un routeur adsl ne sait pas nativement gérer les VPN ("Both PPTP and IPsec VPNs don’t work with NAT natively")

Pour que cela fonctionne il est nécessaire qu'il implémente ce que l'on appelle "VPN Passthrough" (et plus spécifiquement dans le cas qui me pose problème, le "PPTP passthrough".

J'imagine que tous les routeurs suffisamment récent (y compris les Freebox) implémentent désormais ce système.

Me reste plus qu'a comprendre pourquoi, alors que ni GRE et TCP/1723 sont apparemment bloqués, la connexion échoue chez moi. je ne dispose pour cela que des messages syslog pppd et ma capture tcpdump.

Modifié le 30 juin 2013 par CoolRaoul

[CoolRaoul]

Compléments:

Suis tombé sur d'autres témoignages disant que la Freebox V5 n'est *pas* VPN Passthrough, tel que celui-la:

http://forum.hardware.fr/hfr/WindowsSoftware/autoriser-vpn-freebox-sujet_213402_1.htm

Mais comme ça date un peu peut-être que ça a été implémenté depuis dans le firmware V5 (et a fortiori V6)

[PiwiLAbruti]

Oui, en FreeWifi GRE n'est pas supporté.

[CoolRaoul]

Pour compléter la matrice des cas de tests, j'ai eu la possibilité ce matin de me connecter sur un autre wifi privé que le mien et dans cette configuration la connexion VPN PPTP aboutit avec succès.

Donc le problème est bien localisé chez Orange. Reste à comprendre pourquoi, étant donné que mes traces montrent bien que le flux GRE n'est pas filtré.

Modifié le 1 juillet 2013 par CoolRaoul

[bud77]

Tu as quel forfait chez orange ? (perso, je suis chez Sosh)

Je vais tenter de tester dans la semaine voir si j'aboutit au même résultat

[CoolRaoul]

Tu as quel forfait chez orange ? (perso, je suis chez Sosh)

Je vais tenter de tester dans la semaine voir si j'aboutit au même résultat

C'est un forfait orange entreprise, géré par ma boite.

En plus je dois basculer de forfait dans la journée, je n'ai pas l'intitulé du type de forfait.

[PiwiLAbruti]

C'est un forfait orange entreprise, géré par ma boite.

En plus je dois basculer de forfait dans la journée, je n'ai pas l'intitulé du type de forfait.

Ça serait une explication au problème que tu rencontres.

Ceci dit ça serait quand même surprenant car nos commerciaux n'ont pas cette restriction (SFR Business).

[CoolRaoul]

Ma bascule vient de s'effectuer, mon forfait est un forfait entreprise avec l'option "Business pour Smartphone" (ne me demandez pas se que cela signifie)

Et le test échoue toujours

Modifié le 1 juillet 2013 par CoolRaoul

[bud77]

Je viens de tester, et tout marche du premier coup

J'ai ouvert le 1723 en TCP sur le syno, et connexion direct réussie

Forfait : (Orange) Sosh à 19,90€