CoolRaoul

Si tu te sens d'utiliser la ligne de commande, activer ssh et supprimer "a la main" apres s'être connecté de cette façon. Sinon, il est possible que ça se passe avec moins de douleur en ftp. Autre piste: désactiver provisoirement la corbeille sur les dossiers partagés dans lequels tu veux faire les suppressions.

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

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.

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é.

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)

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.

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

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!

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

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?

"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!)

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! 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.

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

Damned, je le savais en plus! J'ai du avoir une fuite de neurones hier.

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

s/blocahe/blocage/ Possible ou pas?

Pour ma part j'utilise un autre port que le 22 pour ssh (via la redirecttion de ports sur la box), ca limite de façon significative les tentatives d'intrusion. De fait, c'est quasiment la première alerte notable que je constate dans mes logs.

J'ai réussi à me connecter avec OpenVPN, c'est déja ça Mais j'aurais préféré pouvoir utiliser le PPTP qui est natif sous android (pas besoin d'ajouter un soft client)

Un tunnel ssh, faut spécifier tous les ports à "tunneller" et ça ne laisse pas passer les broadcasts ni l'UDP

C'est mieux mais pas encore tout à fait ça, voici ce que j'obtiens dans la log Jun 28 14:23:52 pptpd[5862]: CTRL: Client nnn.ppp.qqq.rrr control connection started Jun 28 14:23:52 pptpd[5862]: CTRL: Starting call (launching pppd, opening GRE) Jun 28 14:23:52 pppd[5863]: Plugin /var/packages/VPNCenter/target/lib/pppd/2.4.5/radius.so loaded. Jun 28 14:23:52 pppd[5863]: RADIUS plugin initialized. Jun 28 14:23:52 pppd[5863]: Plugin /var/packages/VPNCenter/target/lib/pppd/2.4.5/radattr.so loaded. Jun 28 14:23:52 pppd[5863]: RADATTR plugin initialized. Jun 28 14:23:52 pppd[5863]: Using interface ppp0 Jun 28 14:24:22 pppd[5863]: LCP: timeout sending Config-Requests Jun 28 14:24:22 pppd[5863]: Exit. Jun 28 14:24:22 pptpd[5862]: GRE: read(fd=6,buffer=25b84,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs Jun 28 14:24:22 pptpd[5862]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7) Jun 28 14:24:22 pptpd[5862]: CTRL: Client nnn.ppp.qqq.rrr control connection finished J'ai trouvé des témoignages d'utilisateurs ayant résolu ce probleme en désinstallant/reinstallant le package VPN Server. J'ai tenté l'opération mais ça continue à merder.

Je me raccroche à ce fil car moi aussi j'ai un probleme avec de VPN J'essaie de me connecter sur mon NAS avec un smartphone android (PPTP) Connecté en shell sur le NAS je capture les paquets TCP sur le port 1723 ("tcpdump port 1723") Je vois bien les paquets entrants venant du téléphone mais aucun paquet sortant n'est émis par le NAS! Et bien entendu, coté androïd ça se termine en timeout! Si quelqu'un savait au moins comment augmenter la verbosité de pptpd (je ne vois quasiment rien dans var/log/messages) peut-être que je pourrais avancer.. ***EDIT*** Trouvé: c'est le firewall qui bloquait

Je découvre à l'instant dans mes logs de multiples tentatives successives de connexions ssh: etrangement ça n'a pas fait tilter le blocage d'IP, pourtant configuré comme suit: Le blocage ne s'applique donc pas à SSH? ***EDIT*** Bon, je me repond: les tentatives étaient suffisamment espacées pour ne pas attendre la limite (5 en 5 minutes) Je vais resserer la config

+1 Je me demande par quel raisonnement tu es parvenu à l'idée qu'il fallait rediriger le port 6690 (cloudstation)? Quel peut-bien être le rapport avec DDNS?

Peut-être du nouveau coté API Freebox http://dev.freebox.fr/blog/?p=1279

Peut-être aurait-il fallu commencer par la: https://forum.dedikam.com/piplette/index.php/topic,976.0.html