RE : Re: RE : Re: RE : Re: VPN sous Ubuntu 7.10
Même config, voilà ce que syslog a sorti: Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1500 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8096) Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:03:29 Le-grand-bleu pppd[8097]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:03:29 Le-grand-bleu pppd[8097]: nm-pppd-plugin: plugin initialized. Feb 12 20:03:29 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: pppd 2.4.4 started by root, uid 0 Feb 12 20:03:29 Le-grand-bleu pptp[8103]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:03:29 Le-grand-bleu pppd[8101]: using channel 3 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Using interface ppp0 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: nm-pppd-plugin: CHAP check hook. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 46452). Feb 12 20:03:33 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:39 Le-grand-bleu last message repeated 2 times Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Terminating on signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Modem hangup Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Connection terminated. Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8102) terminated with signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Exit. Précisons que le signal 15 sort d'habitude quand le routeur ne laisse pas passer le PPTP. Ici, les deux routeurs sont configurés pour laisser passer. En remettant le MTU à 1000 comme montrait JF, ça donne ça: Feb 12 20:07:17 Le-grand-bleu NetworkManager: <debug> [1202864837.961055] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'UdeM' Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1000 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8127) Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: nm-pppd-plugin: plugin initialized. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:07:38 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: pppd 2.4.4 started by root, uid 0 Feb 12 20:07:38 Le-grand-bleu pptp[8134]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:07:38 Le-grand-bleu pppd[8132]: using channel 4 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Using interface ppp0 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: nm-pppd-plugin: CHAP check hook. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 54958). Feb 12 20:07:42 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:48 Le-grand-bleu last message repeated 2 times Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Terminating on signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Modem hangup Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Connection terminated. Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8133) terminated with signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Exit. pas plus de succès. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Bonjour, Dans les paramètres de la connexion, active l'option debug. Le syslog devrait alors contenir plus d'informations sur ce qui se passe avec le PPTP. Pour ma part, la connexion fonctionne. J'ai configuré MTU et MRU à 1500. Eric Tobby Cleps a écrit : Alors j'ai testé sur la machine de mon père, un Ubuntu 7.10 aussi. Les mêmes symptômes que moi au début, il m'a fallu redémarrer 2 fois avant que ça n'apparaisse dans la liste. Par contre, ça ne se connecte toujours pas. On a remplacé un problème par un autre. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Bon, alors vérifions une hypothèse bien simpliste mais qui est possible tout de même. Au lieu d'appeler ta connexion Université de Montréal, appelle-la UdeM. Qui sait si les accents et les espaces ne gênent pas NM... Eric Tobby Cleps a écrit : Mes réponses à tous... Jean-François Fortin Tam <jf.fortin.tam@umontreal.ca> a écrit : > puis...rien du tout! En cliquant sur l'icône de nm-applet je vois bien > "connexions VPN" sur lequel je passe la souris, le petit sous-menu > s'affiche, et...la connexion tout juste configurée n'est pas là ! C'est peut-être une question bête mais... t'as pris le temps de faire un logout-login? Parce que à mon souvenir certains trucs ne s'appliquaient pas toujours instantanément dans ubuntu 7.04, mais il me semblait pourtant que dans 7.10 ça marchait mieux. Hm. Enfin c'est p'tet pas ça. Sinon, tente la suggestion de Mathieu de resetter les configs. Si ça marche, j'aimerais que tu me le dises pour que je rajoute ça à l'article. Logout login n'a rien changé. J'ai ajouté la même configuration pour le VPN à la main, comme montré sur les captures d'écran du tutoriel (qui sont faites avec une ancienne version de nm-applet!) Le mardi 12 février 2008 à 09:28 -0500, Eric Buist a écrit : Peut-être le format du fichier de paramètres à importer a changé entre Feisty et Gutsy. Ça c'est peut-être possible. J'y avais pas pensé. Faudrait que je versionne mes fichiers, mais pourtant à voir la date du fichier pcf, j'avais dû le créer pour goatsy: 2007-09-10 10:41 VPN umontreal.pcf 2007-02-11 16:30 VPN umontreal.pcf.old Juste avant d'établir la connexion VPN, ouvre une console. Ensuite, connecte-toi puis tape ifconfig sur la console, le plus rapidement possible. Tape-le plusieurs fois et vérifie qu'un moment donné, ppp0 apparaît. Si ppp0 est apparue, la connexion est établie. Quelques secondes après, réessaie ifconfig et assure-toi que ppp0 reste là. S'il a disparu, c'est que la connexion s'est coupée. Si la connexion VPN semble s'établir puis se couper quelques secondes après, il y a peut-être un problème au niveau de l'authentification. Dans les propriétés de la connexion, active le débogage et regarde les fichiers log dans /var/log. Wow, ça c'est hardcore, moi j'utilisais simplement le visionneur de journaux pour observer en temps réel /var/log/syslog (parce que, va savoir pourquoi, network-manager crache ses infos dedans). De toute manière ppp0 n'apparaît pas. En regardant le contenu de syslog, j'ai ajouté la connexion, et ça est apparu dans syslog: Feb 12 13:20:44 Le-grand-bleu NetworkManager: <debug> [1202840444.352124] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'Université de Montréal' Ce n'est pas très parlant. Décidément, VPN sous Linux, ce n'est vraiment mais vraiment pas stable. Ça fonctionne sur certaines machines, sur certains réseaux tandis que sur d'autres, rien à faire. Je me souviens de quelqu'un qui avait été bloqué par une config de son routeur qui bloquait les pptp passthrough. Personnellement, moi ça marche sur mon laptop autant chez moi qu'à l'université (mais bon ça fait un bon bout de temps que je l'ai utilisé). Là je viens d'essayer à l'instant et ça ne marche plus en sans-fil, seulement si je suis connecté en filaire. What the heck. J'ai même lu sur un forum qu'une personne arrivait à se connecter par VPN de chez elle tandis que depuis l'université, ça ne fonctionnait pas. Probablement que certains détails du protocole PPTP qui sert au VPN de Microsoft ne sont pas bien implantés dans le noyau. Je ne suis donc pas certain que même après l'établissement de la connexion, l'accès fonctionnera. J'y pense, étant pro-libre, ne devrait-on pas embêter la dgtic pour du OpenVPN? ;) Une bien bonne idée, mais ils ont la tête dure...Déjà qu'ils aient les spécificatiosn exactes de leurs propres protocoles serait un énorme progrès; y'en a trop à la DGTIC qui ne savent que cliquer sans comprendre. JF, il faudrait penser à ajouter ces spécifités dans tes instructions sur ta page Web. Y'a tellement de spécificités réparties dans plusieurs mails que je sais pas trop quoi mettre et comment le rendre compréhensible. Si t'as des suggestions des points spécifiques que je devrais ajouter... ou alors il va y avoir 15 annexes en bas de page que je serais pas mal tenté de copier coller. Faudrait même que je rajoute une petite mention firestarter avec network manag--ah non, rien à voir avec vpn j'suppose. Le courriel précédent de la liste demandait de vérifier en fonction de ma connexion internet...je n'ai pas la malchance d'avoir l'ADSL dont pas de ppp de déjà présent; de toute manière, ma machine est derrière deux routeurs, qui tous deux laissent passer le PPTP, mais je n'en suis même pas encore là! La connexion s'affiche dans la boîte de dialogue "Connexions VPN" qui apparaît en cliquant sur "configurer le réseau VPN", mais pas au-dessus de "configurer le réseau vpn" Pat --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- _______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- Devenez un meilleur amigo grâce à Yahoo! Courriel
Afficher les réponses par date
On dirait qu'à un moment donné, le processus en charge d'établir la connexion VPN est tué. Soit quelque chose (une règle IPTable par exemple) bloque des paquets et force le processus de connexion à s'arrêter, soit il y a un bogue avec NetworkManager. Pour traiter la première possibilité, vérifie qu'aucun firewall n'est installé. En particulier, Firestarter n'est pas du tout compatible avec VPN, car il se plante totalement dès qu'il y a plus d'une interface réseau dans le système. Pour vérifier qu'il n'y a aucune règle IPTables: sudo iptables -L Si INPUT, OUTPUT et FORWARD sont réglées sur ACCEPT et qu'aucune règle IPTables n'est affichée, c'est bel et bien qu'il y a un bogue dans NetworkManager. En attendant avril où Ubuntu 8.04 verra le jour, il ne reste à peu près que PPTPClient comme solution simple, dans ce cas. Eric Tobby Cleps a écrit :
Même config, voilà ce que syslog a sorti:
Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1500 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8096) Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:03:29 Le-grand-bleu pppd[8097]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:03:29 Le-grand-bleu pppd[8097]: nm-pppd-plugin: plugin initialized. Feb 12 20:03:29 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: pppd 2.4.4 started by root, uid 0 Feb 12 20:03:29 Le-grand-bleu pptp[8103]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:03:29 Le-grand-bleu pppd[8101]: using channel 3 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Using interface ppp0 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: nm-pppd-plugin: CHAP check hook. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 46452). Feb 12 20:03:33 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:39 Le-grand-bleu last message repeated 2 times Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Terminating on signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Modem hangup Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Connection terminated. Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8102) terminated with signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Exit.
Précisons que le signal 15 sort d'habitude quand le routeur ne laisse pas passer le PPTP. Ici, les deux routeurs sont configurés pour laisser passer.
En remettant le MTU à 1000 comme montrait JF, ça donne ça:
Feb 12 20:07:17 Le-grand-bleu NetworkManager: <debug> [1202864837.961055] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'UdeM' Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1000 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8127) Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: nm-pppd-plugin: plugin initialized. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:07:38 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: pppd 2.4.4 started by root, uid 0 Feb 12 20:07:38 Le-grand-bleu pptp[8134]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:07:38 Le-grand-bleu pppd[8132]: using channel 4 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Using interface ppp0 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: nm-pppd-plugin: CHAP check hook. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 54958). Feb 12 20:07:42 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:48 Le-grand-bleu last message repeated 2 times Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Terminating on signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Modem hangup Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Connection terminated. Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8133) terminated with signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Exit.
pas plus de succès.
*/Eric Buist <buisteri@iro.umontreal.ca>/* a écrit :
Bonjour, Dans les paramètres de la connexion, active l'option debug. Le syslog devrait alors contenir plus d'informations sur ce qui se passe avec le PPTP. Pour ma part, la connexion fonctionne. J'ai configuré MTU et MRU à 1500.
Eric
Tobby Cleps a écrit :
Alors j'ai testé sur la machine de mon père, un Ubuntu 7.10 aussi. Les mêmes symptômes que moi au début, il m'a fallu redémarrer 2 fois avant que ça n'apparaisse dans la liste. Par contre, ça ne se connecte toujours pas.
On a remplacé un problème par un autre.
*/Eric Buist <buisteri@iro.umontreal.ca>/* a écrit :
Bon, alors vérifions une hypothèse bien simpliste mais qui est possible tout de même. Au lieu d'appeler ta connexion Université de Montréal, appelle-la UdeM. Qui sait si les accents et les espaces ne gênent pas NM... Eric
Tobby Cleps a écrit :
Mes réponses à tous...
*/Jean-François Fortin Tam <jf.fortin.tam@umontreal.ca>/* a écrit :
> puis...rien du tout! En cliquant sur l'icône de nm-applet je vois bien > "connexions VPN" sur lequel je passe la souris, le petit sous-menu > s'affiche, et...la connexion tout juste configurée n'est pas là !
C'est peut-être une question bête mais... t'as pris le temps de faire un logout-login? Parce que à mon souvenir certains trucs ne s'appliquaient pas toujours instantanément dans ubuntu 7.04, mais il me semblait pourtant que dans 7.10 ça marchait mieux. Hm. Enfin c'est p'tet pas ça. Sinon, tente la suggestion de Mathieu de resetter les configs. Si ça marche, j'aimerais que tu me le dises pour que je rajoute ça à l'article.
Logout login n'a rien changé. J'ai ajouté la même configuration pour le VPN à la main, comme montré sur les captures d'écran du tutoriel (qui sont faites avec une ancienne version de nm-applet!)
Le mardi 12 février 2008 à 09:28 -0500, Eric Buist a écrit :
Peut-être le format du fichier de paramètres à importer a changé entre Feisty et Gutsy.
Ça c'est peut-être possible. J'y avais pas pensé. Faudrait que je versionne mes fichiers, mais pourtant à voir la date du fichier pcf, j'avais dû le créer pour goatsy:
2007-09-10 10:41 VPN umontreal.pcf 2007-02-11 16:30 VPN umontreal.pcf.old
Juste avant d'établir la connexion VPN, ouvre une console. Ensuite, connecte-toi puis tape ifconfig sur la console, le plus rapidement possible. Tape-le plusieurs fois et vérifie qu'un moment donné, ppp0 apparaît. Si ppp0 est apparue, la connexion est établie. Quelques secondes après, réessaie ifconfig et assure-toi que ppp0 reste là. S'il a disparu, c'est que la connexion s'est coupée. Si la connexion VPN semble s'établir puis se couper quelques secondes après, il y a peut-être un problème au niveau de l'authentification. Dans les propriétés de la connexion, active le débogage et regarde les fichiers log dans /var/log.
Wow, ça c'est hardcore, moi j'utilisais simplement le visionneur de journaux pour observer en temps réel /var/log/syslog (parce que, va savoir pourquoi, network-manager crache ses infos dedans).
De toute manière ppp0 n'apparaît pas. En regardant le contenu de syslog, j'ai ajouté la connexion, et ça est apparu dans syslog: Feb 12 13:20:44 Le-grand-bleu NetworkManager: <debug> [1202840444.352124] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'Université de Montréal' Ce n'est pas très parlant.
Décidément, VPN sous Linux, ce n'est vraiment mais vraiment pas stable. Ça fonctionne sur certaines machines, sur certains réseaux tandis que sur d'autres, rien à faire.
Je me souviens de quelqu'un qui avait été bloqué par une config de son routeur qui bloquait les pptp passthrough. Personnellement, moi ça marche sur mon laptop autant chez moi qu'à l'université (mais bon ça fait un bon bout de temps que je l'ai utilisé). Là je viens d'essayer à l'instant et ça ne marche plus en sans-fil, seulement si je suis connecté en filaire. What the heck.
J'ai même lu sur un forum qu'une personne arrivait à se connecter par VPN de chez elle tandis que depuis l'université, ça ne fonctionnait pas. Probablement que certains détails du protocole PPTP qui sert au VPN de Microsoft ne sont pas bien implantés dans le noyau. Je ne suis donc pas certain que même après l'établissement de la connexion, l'accès fonctionnera.
J'y pense, étant pro-libre, ne devrait-on pas embêter la dgtic pour du OpenVPN? ;)
Une bien bonne idée, mais ils ont la tête dure...Déjà qu'ils aient les spécificatiosn exactes de leurs propres protocoles serait un énorme progrès; y'en a trop à la DGTIC qui ne savent que cliquer sans comprendre.
JF, il faudrait penser à ajouter ces spécifités dans tes instructions sur ta page Web.
Y'a tellement de spécificités réparties dans plusieurs mails que je sais pas trop quoi mettre et comment le rendre compréhensible. Si t'as des suggestions des points spécifiques que je devrais ajouter... ou alors il va y avoir 15 annexes en bas de page que je serais pas mal tenté de copier coller. Faudrait même que je rajoute une petite mention firestarter avec network manag--ah non, rien à voir avec vpn j'suppose.
Le courriel précédent de la liste demandait de vérifier en fonction de ma connexion internet...je n'ai pas la malchance d'avoir l'ADSL dont pas de ppp de déjà présent; de toute manière, ma machine est derrière deux routeurs, qui tous deux laissent passer le PPTP, mais je n'en suis même pas encore là! La connexion s'affiche dans la boîte de dialogue "Connexions VPN" qui apparaît en cliquant sur "configurer le réseau VPN", mais pas au-dessus de "configurer le réseau vpn"
Pat ------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/> ------------------------------------------------------------------------
_______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team
------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/>
------------------------------------------------------------------------ Devenez un meilleur amigo grâce à *Yahoo! Courriel* <http://cf.promos.yahoo.com/courriel/visiteguidee2/>
Alors j'ai désinstallé Firestarter, qui n'était pas activé de toute manière. Comme je suis pas un pro de Linux, j'avoue ne pas trop comprendre ce que sort la commande donnée,: cubytus@Le-grand-bleu:~/FAH$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- 192.168.1.1 anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT udp -- 192.168.1.1 anywhere ACCEPT 0 -- anywhere anywhere ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 DROP 0 -- anywhere 255.255.255.255 DROP 0 -- anywhere 192.168.1.255 DROP 0 -- BASE-ADDRESS.MCAST.NET/8 anywhere DROP 0 -- anywhere BASE-ADDRESS.MCAST.NET/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID LSI 0 -f anywhere anywhere limit: avg 10/min burst 5 INBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Input' Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Forward' Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- 192.168.1.105 192.168.1.1 tcp dpt:domain ACCEPT udp -- 192.168.1.105 192.168.1.1 udp dpt:domain ACCEPT 0 -- anywhere anywhere DROP 0 -- BASE-ADDRESS.MCAST.NET/8 anywhere DROP 0 -- anywhere BASE-ADDRESS.MCAST.NET/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID OUTBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Output' Chain INBOUND (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED LSI 0 -- anywhere anywhere Chain LOG_FILTER (5 references) target prot opt source destination Chain LSI (2 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP icmp -- anywhere anywhere icmp echo-request LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound ' DROP 0 -- anywhere anywhere Chain LSO (0 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound ' REJECT 0 -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTBOUND (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere Eric Buist <buisteri@iro.umontreal.ca> a écrit : On dirait qu'à un moment donné, le processus en charge d'établir la connexion VPN est tué. Soit quelque chose (une règle IPTable par exemple) bloque des paquets et force le processus de connexion à s'arrêter, soit il y a un bogue avec NetworkManager. Pour traiter la première possibilité, vérifie qu'aucun firewall n'est installé. En particulier, Firestarter n'est pas du tout compatible avec VPN, car il se plante totalement dès qu'il y a plus d'une interface réseau dans le système. Pour vérifier qu'il n'y a aucune règle IPTables: sudo iptables -L Si INPUT, OUTPUT et FORWARD sont réglées sur ACCEPT et qu'aucune règle IPTables n'est affichée, c'est bel et bien qu'il y a un bogue dans NetworkManager. En attendant avril où Ubuntu 8.04 verra le jour, il ne reste à peu près que PPTPClient comme solution simple, dans ce cas. Eric Tobby Cleps a écrit : Même config, voilà ce que syslog a sorti: Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1500 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8096) Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:03:29 Le-grand-bleu pppd[8097]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:03:29 Le-grand-bleu pppd[8097]: nm-pppd-plugin: plugin initialized. Feb 12 20:03:29 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: pppd 2.4.4 started by root, uid 0 Feb 12 20:03:29 Le-grand-bleu pptp[8103]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:03:29 Le-grand-bleu pppd[8101]: using channel 3 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Using interface ppp0 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: nm-pppd-plugin: CHAP check hook. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 46452). Feb 12 20:03:33 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:39 Le-grand-bleu last message repeated 2 times Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Terminating on signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Modem hangup Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Connection terminated. Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8102) terminated with signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Exit. Précisons que le signal 15 sort d'habitude quand le routeur ne laisse pas passer le PPTP. Ici, les deux routeurs sont configurés pour laisser passer. En remettant le MTU à 1000 comme montrait JF, ça donne ça: Feb 12 20:07:17 Le-grand-bleu NetworkManager: <debug> [1202864837.961055] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'UdeM' Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1000 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8127) Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: nm-pppd-plugin: plugin initialized. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:07:38 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: pppd 2.4.4 started by root, uid 0 Feb 12 20:07:38 Le-grand-bleu pptp[8134]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:07:38 Le-grand-bleu pppd[8132]: using channel 4 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Using interface ppp0 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: nm-pppd-plugin: CHAP check hook. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 54958). Feb 12 20:07:42 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:48 Le-grand-bleu last message repeated 2 times Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Terminating on signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Modem hangup Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Connection terminated. Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8133) terminated with signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Exit. pas plus de succès. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Bonjour, Dans les paramètres de la connexion, active l'option debug. Le syslog devrait alors contenir plus d'informations sur ce qui se passe avec le PPTP. Pour ma part, la connexion fonctionne. J'ai configuré MTU et MRU à 1500. Eric Tobby Cleps a écrit : Alors j'ai testé sur la machine de mon père, un Ubuntu 7.10 aussi. Les mêmes symptômes que moi au début, il m'a fallu redémarrer 2 fois avant que ça n'apparaisse dans la liste. Par contre, ça ne se connecte toujours pas. On a remplacé un problème par un autre. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Bon, alors vérifions une hypothèse bien simpliste mais qui est possible tout de même. Au lieu d'appeler ta connexion Université de Montréal, appelle-la UdeM. Qui sait si les accents et les espaces ne gênent pas NM... Eric Tobby Cleps a écrit : Mes réponses à tous... Jean-François Fortin Tam <jf.fortin.tam@umontreal.ca> a écrit : > puis...rien du tout! En cliquant sur l'icône de nm-applet je vois bien > "connexions VPN" sur lequel je passe la souris, le petit sous-menu > s'affiche, et...la connexion tout juste configurée n'est pas là ! C'est peut-être une question bête mais... t'as pris le temps de faire un logout-login? Parce que à mon souvenir certains trucs ne s'appliquaient pas toujours instantanément dans ubuntu 7.04, mais il me semblait pourtant que dans 7.10 ça marchait mieux. Hm. Enfin c'est p'tet pas ça. Sinon, tente la suggestion de Mathieu de resetter les configs. Si ça marche, j'aimerais que tu me le dises pour que je rajoute ça à l'article. Logout login n'a rien changé. J'ai ajouté la même configuration pour le VPN à la main, comme montré sur les captures d'écran du tutoriel (qui sont faites avec une ancienne version de nm-applet!) Le mardi 12 février 2008 à 09:28 -0500, Eric Buist a écrit : Peut-être le format du fichier de paramètres à importer a changé entre Feisty et Gutsy. Ça c'est peut-être possible. J'y avais pas pensé. Faudrait que je versionne mes fichiers, mais pourtant à voir la date du fichier pcf, j'avais dû le créer pour goatsy: 2007-09-10 10:41 VPN umontreal.pcf 2007-02-11 16:30 VPN umontreal.pcf.old Juste avant d'établir la connexion VPN, ouvre une console. Ensuite, connecte-toi puis tape ifconfig sur la console, le plus rapidement possible. Tape-le plusieurs fois et vérifie qu'un moment donné, ppp0 apparaît. Si ppp0 est apparue, la connexion est établie. Quelques secondes après, réessaie ifconfig et assure-toi que ppp0 reste là. S'il a disparu, c'est que la connexion s'est coupée. Si la connexion VPN semble s'établir puis se couper quelques secondes après, il y a peut-être un problème au niveau de l'authentification. Dans les propriétés de la connexion, active le débogage et regarde les fichiers log dans /var/log. Wow, ça c'est hardcore, moi j'utilisais simplement le visionneur de journaux pour observer en temps réel /var/log/syslog (parce que, va savoir pourquoi, network-manager crache ses infos dedans). De toute manière ppp0 n'apparaît pas. En regardant le contenu de syslog, j'ai ajouté la connexion, et ça est apparu dans syslog: Feb 12 13:20:44 Le-grand-bleu NetworkManager: <debug> [1202840444.352124] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'Université de Montréal' Ce n'est pas très parlant. Décidément, VPN sous Linux, ce n'est vraiment mais vraiment pas stable. Ça fonctionne sur certaines machines, sur certains réseaux tandis que sur d'autres, rien à faire. Je me souviens de quelqu'un qui avait été bloqué par une config de son routeur qui bloquait les pptp passthrough. Personnellement, moi ça marche sur mon laptop autant chez moi qu'à l'université (mais bon ça fait un bon bout de temps que je l'ai utilisé). Là je viens d'essayer à l'instant et ça ne marche plus en sans-fil, seulement si je suis connecté en filaire. What the heck. J'ai même lu sur un forum qu'une personne arrivait à se connecter par VPN de chez elle tandis que depuis l'université, ça ne fonctionnait pas. Probablement que certains détails du protocole PPTP qui sert au VPN de Microsoft ne sont pas bien implantés dans le noyau. Je ne suis donc pas certain que même après l'établissement de la connexion, l'accès fonctionnera. J'y pense, étant pro-libre, ne devrait-on pas embêter la dgtic pour du OpenVPN? ;) Une bien bonne idée, mais ils ont la tête dure...Déjà qu'ils aient les spécificatiosn exactes de leurs propres protocoles serait un énorme progrès; y'en a trop à la DGTIC qui ne savent que cliquer sans comprendre. JF, il faudrait penser à ajouter ces spécifités dans tes instructions sur ta page Web. Y'a tellement de spécificités réparties dans plusieurs mails que je sais pas trop quoi mettre et comment le rendre compréhensible. Si t'as des suggestions des points spécifiques que je devrais ajouter... ou alors il va y avoir 15 annexes en bas de page que je serais pas mal tenté de copier coller. Faudrait même que je rajoute une petite mention firestarter avec network manag--ah non, rien à voir avec vpn j'suppose. Le courriel précédent de la liste demandait de vérifier en fonction de ma connexion internet...je n'ai pas la malchance d'avoir l'ADSL dont pas de ppp de déjà présent; de toute manière, ma machine est derrière deux routeurs, qui tous deux laissent passer le PPTP, mais je n'en suis même pas encore là! La connexion s'affiche dans la boîte de dialogue "Connexions VPN" qui apparaît en cliquant sur "configurer le réseau VPN", mais pas au-dessus de "configurer le réseau vpn" Pat --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- _______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- Devenez un meilleur amigo grâce à Yahoo! Courriel --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars
Holy crap, c'est énorme. Juste à première vue (et j'ai jamais regardé de règles iptables) j'ai l'impression que t'as un bazillion de trucs bloqués. Pour référence, ça donne ceci sur mon laptop: jeff@kaname:~$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination /me réfléchit deux secondes oooooooh c'est pour ça que mon vpn ne fonctionnait plus qu'en wired.... firestarter s'active quand je suis en wifi. Je suppose que ça devait être ça mon problème. Faudra que je teste.
Tu as eu ce output avant ou après avoir désinstallé Firestarter? Je suis que Firestarter crée une énorme quantité de règles IPTables. Et le plus "beau", c'est qu'il va se réactiver tout seul quand tu vas faire ta connexion VPN. Il y a une ligne dans les scripts de connexion qui le part! J'ai regardé quand j'essayais de comprendre pourquoi ça ne fonctionnait pas. Bref, Firestarter, c'est à bannir. La seule chose à faire avec ça: sudo apt-get remove firestarter! Voilà! :) Dommage, car le concept était bon, s'il s'était généralisé à plus d'une interface réseau. Donc, enlève Firestarter, reboote, réexécute la commande iptables et dis-moi s'il y a encore toutes ces règles. Si tel n'est plus le cas, il y a de bonnes chances pour que ton VPN fonctionne comme un charme, du moins comme ça peut fonctionner avec l'implantation sous Linux. Eric Tobby Cleps a écrit :
Alors j'ai désinstallé Firestarter, qui n'était pas activé de toute manière. Comme je suis pas un pro de Linux, j'avoue ne pas trop comprendre ce que sort la commande donnée,:
cubytus@Le-grand-bleu:~/FAH$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- 192.168.1.1 anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT udp -- 192.168.1.1 anywhere ACCEPT 0 -- anywhere anywhere ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 DROP 0 -- anywhere 255.255.255.255 DROP 0 -- anywhere 192.168.1.255 DROP 0 -- BASE-ADDRESS.MCAST.NET/8 anywhere DROP 0 -- anywhere BASE-ADDRESS.MCAST.NET/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID LSI 0 -f anywhere anywhere limit: avg 10/min burst 5 INBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Input'
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Forward'
Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- 192.168.1.105 192.168.1.1 tcp dpt:domain ACCEPT udp -- 192.168.1.105 192.168.1.1 udp dpt:domain ACCEPT 0 -- anywhere anywhere DROP 0 -- BASE-ADDRESS.MCAST.NET/8 anywhere DROP 0 -- anywhere BASE-ADDRESS.MCAST.NET/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID OUTBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Output'
Chain INBOUND (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED LSI 0 -- anywhere anywhere
Chain LOG_FILTER (5 references) target prot opt source destination
Chain LSI (2 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP icmp -- anywhere anywhere icmp echo-request LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound ' DROP 0 -- anywhere anywhere
Chain LSO (0 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound ' REJECT 0 -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTBOUND (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere
*/Eric Buist <buisteri@iro.umontreal.ca>/* a écrit :
On dirait qu'à un moment donné, le processus en charge d'établir la connexion VPN est tué. Soit quelque chose (une règle IPTable par exemple) bloque des paquets et force le processus de connexion à s'arrêter, soit il y a un bogue avec NetworkManager. Pour traiter la première possibilité, vérifie qu'aucun firewall n'est installé. En particulier, Firestarter n'est pas du tout compatible avec VPN, car il se plante totalement dès qu'il y a plus d'une interface réseau dans le système. Pour vérifier qu'il n'y a aucune règle IPTables: sudo iptables -L Si INPUT, OUTPUT et FORWARD sont réglées sur ACCEPT et qu'aucune règle IPTables n'est affichée, c'est bel et bien qu'il y a un bogue dans NetworkManager. En attendant avril où Ubuntu 8.04 verra le jour, il ne reste à peu près que PPTPClient comme solution simple, dans ce cas. Eric
Tobby Cleps a écrit :
Même config, voilà ce que syslog a sorti:
Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1500 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8096) Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:03:29 Le-grand-bleu pppd[8097]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:03:29 Le-grand-bleu pppd[8097]: nm-pppd-plugin: plugin initialized. Feb 12 20:03:29 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: pppd 2.4.4 started by root, uid 0 Feb 12 20:03:29 Le-grand-bleu pptp[8103]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:03:29 Le-grand-bleu pppd[8101]: using channel 3 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Using interface ppp0 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: nm-pppd-plugin: CHAP check hook. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 46452). Feb 12 20:03:33 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:39 Le-grand-bleu last message repeated 2 times Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Terminating on signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Modem hangup Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Connection terminated. Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8102) terminated with signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Exit.
Précisons que le signal 15 sort d'habitude quand le routeur ne laisse pas passer le PPTP. Ici, les deux routeurs sont configurés pour laisser passer.
En remettant le MTU à 1000 comme montrait JF, ça donne ça:
Feb 12 20:07:17 Le-grand-bleu NetworkManager: <debug> [1202864837.961055] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'UdeM' Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1000 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8127) Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: nm-pppd-plugin: plugin initialized. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:07:38 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: pppd 2.4.4 started by root, uid 0 Feb 12 20:07:38 Le-grand-bleu pptp[8134]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:07:38 Le-grand-bleu pppd[8132]: using channel 4 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Using interface ppp0 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: nm-pppd-plugin: CHAP check hook. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 54958). Feb 12 20:07:42 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:48 Le-grand-bleu last message repeated 2 times Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Terminating on signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Modem hangup Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Connection terminated. Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8133) terminated with signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Exit.
pas plus de succès.
*/Eric Buist <buisteri@iro.umontreal.ca>/* a écrit :
Bonjour, Dans les paramètres de la connexion, active l'option debug. Le syslog devrait alors contenir plus d'informations sur ce qui se passe avec le PPTP. Pour ma part, la connexion fonctionne. J'ai configuré MTU et MRU à 1500.
Eric
Tobby Cleps a écrit :
Alors j'ai testé sur la machine de mon père, un Ubuntu 7.10 aussi. Les mêmes symptômes que moi au début, il m'a fallu redémarrer 2 fois avant que ça n'apparaisse dans la liste. Par contre, ça ne se connecte toujours pas.
On a remplacé un problème par un autre.
*/Eric Buist <buisteri@iro.umontreal.ca>/* a écrit :
Bon, alors vérifions une hypothèse bien simpliste mais qui est possible tout de même. Au lieu d'appeler ta connexion Université de Montréal, appelle-la UdeM. Qui sait si les accents et les espaces ne gênent pas NM... Eric
Tobby Cleps a écrit :
Mes réponses à tous...
*/Jean-François Fortin Tam <jf.fortin.tam@umontreal.ca>/* a écrit :
> puis...rien du tout! En cliquant sur l'icône de nm-applet je vois bien > "connexions VPN" sur lequel je passe la souris, le petit sous-menu > s'affiche, et...la connexion tout juste configurée n'est pas là !
C'est peut-être une question bête mais... t'as pris le temps de faire un logout-login? Parce que à mon souvenir certains trucs ne s'appliquaient pas toujours instantanément dans ubuntu 7.04, mais il me semblait pourtant que dans 7.10 ça marchait mieux. Hm. Enfin c'est p'tet pas ça. Sinon, tente la suggestion de Mathieu de resetter les configs. Si ça marche, j'aimerais que tu me le dises pour que je rajoute ça à l'article.
Logout login n'a rien changé. J'ai ajouté la même configuration pour le VPN à la main, comme montré sur les captures d'écran du tutoriel (qui sont faites avec une ancienne version de nm-applet!)
Le mardi 12 février 2008 à 09:28 -0500, Eric Buist a écrit :
Peut-être le format du fichier de paramètres à importer a changé entre Feisty et Gutsy.
Ça c'est peut-être possible. J'y avais pas pensé. Faudrait que je versionne mes fichiers, mais pourtant à voir la date du fichier pcf, j'avais dû le créer pour goatsy:
2007-09-10 10:41 VPN umontreal.pcf 2007-02-11 16:30 VPN umontreal.pcf.old
Juste avant d'établir la connexion VPN, ouvre une console. Ensuite, connecte-toi puis tape ifconfig sur la console, le plus rapidement possible. Tape-le plusieurs fois et vérifie qu'un moment donné, ppp0 apparaît. Si ppp0 est apparue, la connexion est établie. Quelques secondes après, réessaie ifconfig et assure-toi que ppp0 reste là. S'il a disparu, c'est que la connexion s'est coupée. Si la connexion VPN semble s'établir puis se couper quelques secondes après, il y a peut-être un problème au niveau de l'authentification. Dans les propriétés de la connexion, active le débogage et regarde les fichiers log dans /var/log.
Wow, ça c'est hardcore, moi j'utilisais simplement le visionneur de journaux pour observer en temps réel /var/log/syslog (parce que, va savoir pourquoi, network-manager crache ses infos dedans).
De toute manière ppp0 n'apparaît pas. En regardant le contenu de syslog, j'ai ajouté la connexion, et ça est apparu dans syslog: Feb 12 13:20:44 Le-grand-bleu NetworkManager: <debug> [1202840444.352124] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'Université de Montréal' Ce n'est pas très parlant.
Décidément, VPN sous Linux, ce n'est vraiment mais vraiment pas stable. Ça fonctionne sur certaines machines, sur certains réseaux tandis que sur d'autres, rien à faire.
Je me souviens de quelqu'un qui avait été bloqué par une config de son routeur qui bloquait les pptp passthrough. Personnellement, moi ça marche sur mon laptop autant chez moi qu'à l'université (mais bon ça fait un bon bout de temps que je l'ai utilisé). Là je viens d'essayer à l'instant et ça ne marche plus en sans-fil, seulement si je suis connecté en filaire. What the heck.
J'ai même lu sur un forum qu'une personne arrivait à se connecter par VPN de chez elle tandis que depuis l'université, ça ne fonctionnait pas. Probablement que certains détails du protocole PPTP qui sert au VPN de Microsoft ne sont pas bien implantés dans le noyau. Je ne suis donc pas certain que même après l'établissement de la connexion, l'accès fonctionnera.
J'y pense, étant pro-libre, ne devrait-on pas embêter la dgtic pour du OpenVPN? ;)
Une bien bonne idée, mais ils ont la tête dure...Déjà qu'ils aient les spécificatiosn exactes de leurs propres protocoles serait un énorme progrès; y'en a trop à la DGTIC qui ne savent que cliquer sans comprendre.
JF, il faudrait penser à ajouter ces spécifités dans tes instructions sur ta page Web.
Y'a tellement de spécificités réparties dans plusieurs mails que je sais pas trop quoi mettre et comment le rendre compréhensible. Si t'as des suggestions des points spécifiques que je devrais ajouter... ou alors il va y avoir 15 annexes en bas de page que je serais pas mal tenté de copier coller. Faudrait même que je rajoute une petite mention firestarter avec network manag--ah non, rien à voir avec vpn j'suppose.
Le courriel précédent de la liste demandait de vérifier en fonction de ma connexion internet...je n'ai pas la malchance d'avoir l'ADSL dont pas de ppp de déjà présent; de toute manière, ma machine est derrière deux routeurs, qui tous deux laissent passer le PPTP, mais je n'en suis même pas encore là! La connexion s'affiche dans la boîte de dialogue "Connexions VPN" qui apparaît en cliquant sur "configurer le réseau VPN", mais pas au-dessus de "configurer le réseau vpn"
Pat ------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/> ------------------------------------------------------------------------
_______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team
------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/>
------------------------------------------------------------------------ Devenez un meilleur amigo grâce à *Yahoo! Courriel* <http://cf.promos.yahoo.com/courriel/visiteguidee2/>
------------------------------------------------------------------------ Découvrez les styles qui font sensation sur * Yahoo! Québec Avatars* <http://cf.avatars.yahoo.com/>
Salut, le problème justement est que c'est apparu après que Firestarter ait été désinstallé, la première chose que j'ai faite après le précédent message. Je vais redémarrer encore une fois et envoyer des nouvelles. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Tu as eu ce output avant ou après avoir désinstallé Firestarter? Je suis que Firestarter crée une énorme quantité de règles IPTables. Et le plus "beau", c'est qu'il va se réactiver tout seul quand tu vas faire ta connexion VPN. Il y a une ligne dans les scripts de connexion qui le part! J'ai regardé quand j'essayais de comprendre pourquoi ça ne fonctionnait pas. Bref, Firestarter, c'est à bannir. La seule chose à faire avec ça: sudo apt-get remove firestarter! Voilà! :) Dommage, car le concept était bon, s'il s'était généralisé à plus d'une interface réseau. Donc, enlève Firestarter, reboote, réexécute la commande iptables et dis-moi s'il y a encore toutes ces règles. Si tel n'est plus le cas, il y a de bonnes chances pour que ton VPN fonctionne comme un charme, du moins comme ça peut fonctionner avec l'implantation sous Linux. Eric Tobby Cleps a écrit : Alors j'ai désinstallé Firestarter, qui n'était pas activé de toute manière. Comme je suis pas un pro de Linux, j'avoue ne pas trop comprendre ce que sort la commande donnée,: cubytus@Le-grand-bleu:~/FAH$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- 192.168.1.1 anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT udp -- 192.168.1.1 anywhere ACCEPT 0 -- anywhere anywhere ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 DROP 0 -- anywhere 255.255.255.255 DROP 0 -- anywhere 192.168.1.255 DROP 0 -- BASE-ADDRESS.MCAST.NET/8 anywhere DROP 0 -- anywhere BASE-ADDRESS.MCAST.NET/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID LSI 0 -f anywhere anywhere limit: avg 10/min burst 5 INBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Input' Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Forward' Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- 192.168.1.105 192.168.1.1 tcp dpt:domain ACCEPT udp -- 192.168.1.105 192.168.1.1 udp dpt:domain ACCEPT 0 -- anywhere anywhere DROP 0 -- BASE-ADDRESS.MCAST.NET/8 anywhere DROP 0 -- anywhere BASE-ADDRESS.MCAST.NET/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID OUTBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Output' Chain INBOUND (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED LSI 0 -- anywhere anywhere Chain LOG_FILTER (5 references) target prot opt source destination Chain LSI (2 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP icmp -- anywhere anywhere icmp echo-request LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound ' DROP 0 -- anywhere anywhere Chain LSO (0 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound ' REJECT 0 -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTBOUND (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere Eric Buist <buisteri@iro.umontreal.ca> a écrit : On dirait qu'à un moment donné, le processus en charge d'établir la connexion VPN est tué. Soit quelque chose (une règle IPTable par exemple) bloque des paquets et force le processus de connexion à s'arrêter, soit il y a un bogue avec NetworkManager. Pour traiter la première possibilité, vérifie qu'aucun firewall n'est installé. En particulier, Firestarter n'est pas du tout compatible avec VPN, car il se plante totalement dès qu'il y a plus d'une interface réseau dans le système. Pour vérifier qu'il n'y a aucune règle IPTables: sudo iptables -L Si INPUT, OUTPUT et FORWARD sont réglées sur ACCEPT et qu'aucune règle IPTables n'est affichée, c'est bel et bien qu'il y a un bogue dans NetworkManager. En attendant avril où Ubuntu 8.04 verra le jour, il ne reste à peu près que PPTPClient comme solution simple, dans ce cas. Eric Tobby Cleps a écrit : Même config, voilà ce que syslog a sorti: Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1500 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8096) Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:03:29 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:03:29 Le-grand-bleu pppd[8097]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:03:29 Le-grand-bleu pppd[8097]: nm-pppd-plugin: plugin initialized. Feb 12 20:03:29 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: pppd 2.4.4 started by root, uid 0 Feb 12 20:03:29 Le-grand-bleu pptp[8103]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:03:29 Le-grand-bleu pppd[8101]: using channel 3 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Using interface ppp0 Feb 12 20:03:29 Le-grand-bleu pppd[8101]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:03:29 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: nm-pppd-plugin: CHAP check hook. Feb 12 20:03:30 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:03:30 Le-grand-bleu pptp[8106]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 46452). Feb 12 20:03:33 Le-grand-bleu pppd[8101]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x88c9ddf> <pcomp> <accomp>] Feb 12 20:03:39 Le-grand-bleu last message repeated 2 times Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Terminating on signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:03:40 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:03:40 Le-grand-bleu pptp[8106]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Modem hangup Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Connection terminated. Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8102) terminated with signal 15 Feb 12 20:03:40 Le-grand-bleu pppd[8101]: Exit. Précisons que le signal 15 sort d'habitude quand le routeur ne laisse pas passer le PPTP. Ici, les deux routeurs sont configurés pour laisser passer. En remettant le MTU à 1000 comme montrait JF, ça donne ça: Feb 12 20:07:17 Le-grand-bleu NetworkManager: <debug> [1202864837.961055] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'UdeM' Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> Will activate VPN connection 'UdeM', service 'org.freedesktop.NetworkManager.ppp_starter', user_name 'cubytus', vpn_data 'ppp-connection-type / pptp / pptp-remote / vpn.cc.umontreal.ca / usepeerdns / yes / encrypt-mppe / no / encrypt-mppe-128 / yes / encrypt-mppe-stateful / yes / compress-mppc / no / compress-deflate / no / compress-bsd / no / ppp-lock / yes / ppp-auth-peer / no / ppp-refuse-eap / yes / ppp-refuse-chap / no / ppp-refuse-mschap / no / mtu / 1000 / mru / 1500 / lcp-echo-failure / 10 / lcp-echo-interval / 10 / ppp-extra / / ppp-debug / yes / usepeerdns-overtunnel / yes / routes / / use-routes / no', route ''. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.ppp_starter (PID 8127) Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 1 of 4 (Connection Prepare) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 1 -> 6. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) waiting... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 2 of 4 (Connection Prepare Wait) complete. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) scheduled... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) sending connect request. Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) request sent, waiting for reply... Feb 12 20:07:36 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 6 -> 3. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: Plugin nm-pppd-plugin.so loaded. Feb 12 20:07:38 Le-grand-bleu pppd[8128]: nm-pppd-plugin: plugin initialized. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) reply received. Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 4 of 4 (IP Config Get) timeout scheduled... Feb 12 20:07:38 Le-grand-bleu NetworkManager: <info> VPN Activation (UdeM) Stage 3 of 4 (Connect) complete, waiting for IP configuration... Feb 12 20:07:38 Le-grand-bleu modprobe: WARNING: Not loading blacklisted module ipv6 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: pppd 2.4.4 started by root, uid 0 Feb 12 20:07:38 Le-grand-bleu pptp[8134]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Feb 12 20:07:38 Le-grand-bleu pppd[8132]: using channel 4 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Using interface ppp0 Feb 12 20:07:38 Le-grand-bleu pppd[8132]: Connect: ppp0 <--> /dev/pts/2 Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Feb 12 20:07:38 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: nm-pppd-plugin: CHAP check hook. Feb 12 20:07:39 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Feb 12 20:07:39 Le-grand-bleu pptp[8137]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 54958). Feb 12 20:07:42 Le-grand-bleu pppd[8132]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0945c2c> <pcomp> <accomp>] Feb 12 20:07:48 Le-grand-bleu last message repeated 2 times Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Terminating on signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: sent [LCP TermReq id=0x2 "User request"] Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.ppp_starter', signal 'ConnectFailed', with message 'VPN Connection failed'. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 5. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 5 -> 6. Feb 12 20:07:49 Le-grand-bleu NetworkManager: <WARN> nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.ppp_starter): could not stop connection 'UdeM' because service was 6. Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Feb 12 20:07:49 Le-grand-bleu pptp[8137]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Modem hangup Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Connection terminated. Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Child process /usr/sbin/pptp 132.204.2.20 --nolaunchpppd (pid 8133) terminated with signal 15 Feb 12 20:07:49 Le-grand-bleu pppd[8132]: Exit. pas plus de succès. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Bonjour, Dans les paramètres de la connexion, active l'option debug. Le syslog devrait alors contenir plus d'informations sur ce qui se passe avec le PPTP. Pour ma part, la connexion fonctionne. J'ai configuré MTU et MRU à 1500. Eric Tobby Cleps a écrit : Alors j'ai testé sur la machine de mon père, un Ubuntu 7.10 aussi. Les mêmes symptômes que moi au début, il m'a fallu redémarrer 2 fois avant que ça n'apparaisse dans la liste. Par contre, ça ne se connecte toujours pas. On a remplacé un problème par un autre. Eric Buist <buisteri@iro.umontreal.ca> a écrit : Bon, alors vérifions une hypothèse bien simpliste mais qui est possible tout de même. Au lieu d'appeler ta connexion Université de Montréal, appelle-la UdeM. Qui sait si les accents et les espaces ne gênent pas NM... Eric Tobby Cleps a écrit : Mes réponses à tous... Jean-François Fortin Tam <jf.fortin.tam@umontreal.ca> a écrit :
puis...rien du tout! En cliquant sur l'icône de nm-applet je vois bien "connexions VPN" sur lequel je passe la souris, le petit sous-menu s'affiche, et...la connexion tout juste configurée n'est pas là ! C'est peut-être une question bête mais... t'as pris le temps de faire un logout-login? Parce que à mon souvenir certains trucs ne s'appliquaient pas toujours instantanément dans ubuntu 7.04, mais il me semblait pourtant que dans 7.10 ça marchait mieux. Hm. Enfin c'est p'tet pas ça. Sinon, tente la suggestion de Mathieu de resetter les configs. Si ça marche, j'aimerais que tu me le dises pour que je rajoute ça à l'article.
Logout login n'a rien changé. J'ai ajouté la même configuration pour le VPN à la main, comme montré sur les captures d'écran du tutoriel (qui sont faites avec une ancienne version de nm-applet!) Le mardi 12 février 2008 à 09:28 -0500, Eric Buist a écrit : Peut-être le format du fichier de paramètres à importer a changé entre Feisty et Gutsy. Ça c'est peut-être possible. J'y avais pas pensé. Faudrait que je versionne mes fichiers, mais pourtant à voir la date du fichier pcf, j'avais dû le créer pour goatsy: 2007-09-10 10:41 VPN umontreal.pcf 2007-02-11 16:30 VPN umontreal.pcf.old Juste avant d'établir la connexion VPN, ouvre une console. Ensuite, connecte-toi puis tape ifconfig sur la console, le plus rapidement possible. Tape-le plusieurs fois et vérifie qu'un moment donné, ppp0 apparaît. Si ppp0 est apparue, la connexion est établie. Quelques secondes après, réessaie ifconfig et assure-toi que ppp0 reste là. S'il a disparu, c'est que la connexion s'est coupée. Si la connexion VPN semble s'établir puis se couper quelques secondes après, il y a peut-être un problème au niveau de l'authentification. Dans les propriétés de la connexion, active le débogage et regarde les fichiers log dans /var/log. Wow, ça c'est hardcore, moi j'utilisais simplement le visionneur de journaux pour observer en temps réel /var/log/syslog (parce que, va savoir pourquoi, network-manager crache ses infos dedans). De toute manière ppp0 n'apparaît pas. En regardant le contenu de syslog, j'ai ajouté la connexion, et ça est apparu dans syslog: Feb 12 13:20:44 Le-grand-bleu NetworkManager: <debug> [1202840444.352124] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'Université de Montréal' Ce n'est pas très parlant. Décidément, VPN sous Linux, ce n'est vraiment mais vraiment pas stable. Ça fonctionne sur certaines machines, sur certains réseaux tandis que sur d'autres, rien à faire. Je me souviens de quelqu'un qui avait été bloqué par une config de son routeur qui bloquait les pptp passthrough. Personnellement, moi ça marche sur mon laptop autant chez moi qu'à l'université (mais bon ça fait un bon bout de temps que je l'ai utilisé). Là je viens d'essayer à l'instant et ça ne marche plus en sans-fil, seulement si je suis connecté en filaire. What the heck. J'ai même lu sur un forum qu'une personne arrivait à se connecter par VPN de chez elle tandis que depuis l'université, ça ne fonctionnait pas. Probablement que certains détails du protocole PPTP qui sert au VPN de Microsoft ne sont pas bien implantés dans le noyau. Je ne suis donc pas certain que même après l'établissement de la connexion, l'accès fonctionnera. J'y pense, étant pro-libre, ne devrait-on pas embêter la dgtic pour du OpenVPN? ;) Une bien bonne idée, mais ils ont la tête dure...Déjà qu'ils aient les spécificatiosn exactes de leurs propres protocoles serait un énorme progrès; y'en a trop à la DGTIC qui ne savent que cliquer sans comprendre. JF, il faudrait penser à ajouter ces spécifités dans tes instructions sur ta page Web. Y'a tellement de spécificités réparties dans plusieurs mails que je sais pas trop quoi mettre et comment le rendre compréhensible. Si t'as des suggestions des points spécifiques que je devrais ajouter... ou alors il va y avoir 15 annexes en bas de page que je serais pas mal tenté de copier coller. Faudrait même que je rajoute une petite mention firestarter avec network manag--ah non, rien à voir avec vpn j'suppose. Le courriel précédent de la liste demandait de vérifier en fonction de ma connexion internet...je n'ai pas la malchance d'avoir l'ADSL dont pas de ppp de déjà présent; de toute manière, ma machine est derrière deux routeurs, qui tous deux laissent passer le PPTP, mais je n'en suis même pas encore là! La connexion s'affiche dans la boîte de dialogue "Connexions VPN" qui apparaît en cliquant sur "configurer le réseau VPN", mais pas au-dessus de "configurer le réseau vpn" Pat --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- _______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- Devenez un meilleur amigo grâce à Yahoo! Courriel --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars
Bref, Firestarter, c'est à bannir. La seule chose à faire avec ça: sudo apt-get remove firestarter! Voilà! :) Dommage, car le concept était bon, s'il s'était généralisé à plus d'une interface réseau. Donc, enlève Firestarter, reboote, réexécute la commande iptables et dis-moi s'il y a encore toutes ces règles. Si tel n'est plus le cas, il y a de bonnes chances pour que ton VPN fonctionne comme un charme, du moins comme ça peut fonctionner avec l'implantation sous Linux.
Hold yer seahorses matey! Firestarter (malgré que ce soit un peu de l'abandonware depuis deux ans ;__;) est excellent et n'est pas à bannir pour si peu. Il a un gros bouton rouge «Arrêter le pare-feu» et ce n'est pas pour rien. Je viens de le tester. Effectivement, en wifi firestarter protégeait mon interface réseau mais bloquait vpn. En le désactivant, tout d'un coup ça passe sans problèmes. Pas besoin de désinstaller. Voici le output iptables avant et après que je désactive le firewall. J'ai aussi trouvé une autre solution (ajouter une règle dans firestarter lui demandant d'accepter toute connexion en provenance de vpn.cc.umontreal.ca; voir screenshot attaché à ce courriel), mais elle ne semble pas fonctionner pleinement: la connexion vpn s'établit sans problèmes, mais il est alors impossible de surfer sur le web (alors que ça fonctionne si on désactive entièrement firestarter). Toutefois, je viens de trouver ceci: http://www.fs-security.com/docs/vpn.php je viens d'essayer, ça ne semble pas fonctionner à première vue.
jeff@kaname:~$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- routeur anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT udp -- routeur anywhere ACCEPT 0 -- anywhere anywhere ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 DROP 0 -- anywhere 255.255.255.255 DROP 0 -- anywhere 192.168.1.255 DROP 0 -- base-address.mcast.net/8 anywhere DROP 0 -- anywhere base-address.mcast.net/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID LSI 0 -f anywhere anywhere limit: avg 10/min burst 5 INBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Input'
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Forward'
Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- kaname routeur tcp dpt:domain ACCEPT udp -- kaname routeur udp dpt:domain ACCEPT 0 -- anywhere anywhere DROP 0 -- base-address.mcast.net/8 anywhere DROP 0 -- anywhere base-address.mcast.net/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID OUTBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Output'
Chain INBOUND (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED LSI 0 -- anywhere anywhere
Chain LOG_FILTER (5 references) target prot opt source destination
Chain LSI (2 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP icmp -- anywhere anywhere icmp echo-request LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound ' DROP 0 -- anywhere anywhere
Chain LSO (0 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound ' REJECT 0 -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTBOUND (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere
======= soudainement je clique sur «Arrêter le pare-feu» ========
jeff@kaname:~$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT)Mais qu'est donc la vraie solution? target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Jean-François Fortin Tam wrote:
Bref, Firestarter, c'est à bannir. La seule chose à faire avec ça: sudo apt-get remove firestarter! Voilà! :) Dommage, car le concept était bon, s'il s'était généralisé à plus d'une interface réseau. Donc, enlève Firestarter, reboote, réexécute la commande iptables et dis-moi s'il y a encore toutes ces règles. Si tel n'est plus le cas, il y a de bonnes chances pour que ton VPN fonctionne comme un charme, du moins comme ça peut fonctionner avec l'implantation sous Linux.
Hold yer seahorses matey! Firestarter (malgré que ce soit un peu de l'abandonware depuis deux ans ;__;) est excellent et n'est pas à bannir pour si peu. Il a un gros bouton rouge «Arrêter le pare-feu» et ce n'est pas pour rien. Je viens de le tester. Effectivement, en wifi firestarter protégeait mon interface réseau mais bloquait vpn. En le désactivant, tout d'un coup ça passe sans problèmes. Pas besoin de désinstaller.
Un firewall efficace ne devrait pas avoir besoin d'un bouton "arrête toute protection parce que je suis trop poche pour faire ce que tu veux sur ce port là en particulier" ou comme dirait l'autre "bah la protection c'est trop chiant ça empêche plein de choses--**--viens me violer" tk, je trouve que ça fait "firewall" à la windows.. un vrai capitaine de navire est capable de forger les règles IPTABLES avec une main et un crochet tout en disant YARR! les règles de firestarter ont l'air relativement correctes mais je trouve ça vraiment poche que ça scale pas à plus qu'une interface.. linux et unix ont un historique de flexibilité de ce côté là et ça vient un peu gâcher les choses.. y'a shorewall qui a l'air de bien faire la job. mais encore une fois c'est juste une interface aux règles iptables.
Voici le output iptables avant et après que je désactive le firewall. J'ai aussi trouvé une autre solution (ajouter une règle dans firestarter lui demandant d'accepter toute connexion en provenance de vpn.cc.umontreal.ca; voir screenshot attaché à ce courriel), mais elle ne semble pas fonctionner pleinement: la connexion vpn s'établit sans problèmes, mais il est alors impossible de surfer sur le web (alors que ça fonctionne si on désactive entièrement firestarter).
Toutefois, je viens de trouver ceci: http://www.fs-security.com/docs/vpn.php je viens d'essayer, ça ne semble pas fonctionner à première vue.
jeff@kaname:~$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- routeur anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT udp -- routeur anywhere ACCEPT 0 -- anywhere anywhere ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 DROP 0 -- anywhere 255.255.255.255 DROP 0 -- anywhere 192.168.1.255 DROP 0 -- base-address.mcast.net/8 anywhere DROP 0 -- anywhere base-address.mcast.net/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID LSI 0 -f anywhere anywhere limit: avg 10/min burst 5 INBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Input'
Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Forward'
Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- kaname routeur tcp dpt:domain ACCEPT udp -- kaname routeur udp dpt:domain ACCEPT 0 -- anywhere anywhere DROP 0 -- base-address.mcast.net/8 anywhere DROP 0 -- anywhere base-address.mcast.net/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID OUTBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Output'
Chain INBOUND (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED LSI 0 -- anywhere anywhere
Chain LOG_FILTER (5 references) target prot opt source destination
Chain LSI (2 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP icmp -- anywhere anywhere icmp echo-request LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound ' DROP 0 -- anywhere anywhere
Chain LSO (0 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound ' REJECT 0 -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTBOUND (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere
======= soudainement je clique sur «Arrêter le pare-feu» ========
jeff@kaname:~$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT)Mais qu'est donc la vraie solution? target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
donc avant, avec protection, après, open house -- Gabriel Filion --------------------------- Responsable Séminaires Unix A.E.I.R.O.U.M.
Agreed. Firestarter est mort (à première vue) depuis plus de deux ans, on a sérieusement besoin d'un *bon* logiciel dans le genre adapté aux besoins de réseau modernes à la ubuntu. Si j'étais developer extraordinaire, je forkerais firestarter. Mais c'est pas le cas.
C'est en effet quelque chose qui manque à Ubuntu. Avec Fedora Core, il y a un GUI pour configurer des règles IPTables. Un linuxien est susceptible de passer du temps à essayer différents logiciels pour configurer le firewall, voire écrire ses propres règles IPTables manuellement, mais monsieur tout le monde ne va pas se badrer à faire cela, surtout quelqu'un qui n'est pas sensibilisé à la sécurité des réseaux. Eric Jean-François Fortin Tam a écrit :
Agreed. Firestarter est mort (à première vue) depuis plus de deux ans, on a sérieusement besoin d'un *bon* logiciel dans le genre adapté aux besoins de réseau modernes à la ubuntu. Si j'étais /developer extraordinaire/, je forkerais firestarter. Mais c'est pas le cas. ------------------------------------------------------------------------
_______________________________________________ Gulum-team mailing list Gulum-team@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gulum-team
Bonjour à la liste, Je ne peux pas tester d'atres manières de faire pour le moment, car la carte vidéo Geforce 6600GT de l'ordi a pété. (Avis aux consommateurs: ça fait la 4e WinFast qui claque dans cet ordi...dla vraie marde en canne, cette marque; Avis aux donateurs: c'est une PCI Express ^^). Par contre, Firestarter désinstallé (moi protégé par firewall hardware) ne m'a toujours pas permis d'accéder au VPN de l'université. Est-ce que quelqu'un a ses spécifications précises, pour qu'on arrête de cocher des options un peu au hasard ? JF, y a-t-il une configuration du profil qui fonctionne de façon fiable dans Gutsy? Jean-François Fortin Tam <jf.fortin.tam@umontreal.ca> a écrit : Bref, Firestarter, c'est à bannir. La seule chose à faire avec ça: sudo apt-get remove firestarter! Voilà! :) Dommage, car le concept était bon, s'il s'était généralisé à plus d'une interface réseau. Donc, enlève Firestarter, reboote, réexécute la commande iptables et dis-moi s'il y a encore toutes ces règles. Si tel n'est plus le cas, il y a de bonnes chances pour que ton VPN fonctionne comme un charme, du moins comme ça peut fonctionner avec l'implantation sous Linux. Hold yer seahorses matey! Firestarter (malgré que ce soit un peu de l'abandonware depuis deux ans ;__;) est excellent et n'est pas à bannir pour si peu. Il a un gros bouton rouge «Arrêter le pare-feu» et ce n'est pas pour rien. Je viens de le tester. Effectivement, en wifi firestarter protégeait mon interface réseau mais bloquait vpn. En le désactivant, tout d'un coup ça passe sans problèmes. Pas besoin de désinstaller. Voici le output iptables avant et après que je désactive le firewall. J'ai aussi trouvé une autre solution (ajouter une règle dans firestarter lui demandant d'accepter toute connexion en provenance de vpn.cc.umontreal.ca; voir screenshot attaché à ce courriel), mais elle ne semble pas fonctionner pleinement: la connexion vpn s'établit sans problèmes, mais il est alors impossible de surfer sur le web (alors que ça fonctionne si on désactive entièrement firestarter). Toutefois, je viens de trouver ceci: http://www.fs-security.com/docs/vpn.php je viens d'essayer, ça ne semble pas fonctionner à première vue. jeff@kaname:~$ sudo iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT tcp -- routeur anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT udp -- routeur anywhere ACCEPT 0 -- anywhere anywhere ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 DROP 0 -- anywhere 255.255.255.255 DROP 0 -- anywhere 192.168.1.255 DROP 0 -- base-address.mcast.net/8 anywhere DROP 0 -- anywhere base-address.mcast.net/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID LSI 0 -f anywhere anywhere limit: avg 10/min burst 5 INBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Input' Chain FORWARD (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5 LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Forward' Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- kaname routeur tcp dpt:domain ACCEPT udp -- kaname routeur udp dpt:domain ACCEPT 0 -- anywhere anywhere DROP 0 -- base-address.mcast.net/8 anywhere DROP 0 -- anywhere base-address.mcast.net/8 DROP 0 -- 255.255.255.255 anywhere DROP 0 -- anywhere 0.0.0.0 DROP 0 -- anywhere anywhere state INVALID OUTBOUND 0 -- anywhere anywhere LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere LOG level info prefix `Unknown Output' Chain INBOUND (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED LSI 0 -- anywhere anywhere Chain LOG_FILTER (5 references) target prot opt source destination Chain LSI (2 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN LOG tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/RST LOG icmp -- anywhere anywhere icmp echo-request limit: avg 1/sec burst 5 LOG level info prefix `Inbound ' DROP icmp -- anywhere anywhere icmp echo-request LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Inbound ' DROP 0 -- anywhere anywhere Chain LSO (0 references) target prot opt source destination LOG_FILTER 0 -- anywhere anywhere LOG 0 -- anywhere anywhere limit: avg 5/sec burst 5 LOG level info prefix `Outbound ' REJECT 0 -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTBOUND (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT 0 -- anywhere anywhere ======= soudainement je clique sur «Arrêter le pare-feu» ======== jeff@kaname:~$ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT)Mais qu'est donc la vraie solution? target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination --------------------------------- Découvrez les styles qui font sensation sur Yahoo! Québec Avatars
participants (4)
-
Eric Buist -
Gabriel Filion -
Jean-François Fortin Tam -
Tobby Cleps