Nouvel abonné Alice (depuis 3 mois), je tente d'établir une connexion VPN
sur ma connexion Alice. Ceci est rendu impossible dans la mesure ou je ne
peux pas router le protocole GRE vers une ip de mon lan.
Habituellement et suivant les modèle de routeur, ce routage de ce protocole
doit se faire soit :
- par l'interface de configuration du modem/routeur
- en ligne de commande via une commande telnet
L'interface du modem fourni par Alice ne permet pas celà.
La commande telnet a été bridée de façon à ne pas pouvoir l'utiliser.
Lorsque j'appelle le service commercial en me faisant passer pour un nouveau
client, on me répond (après que l'interlocuteur se soit renseigné au service
technique) qu'il n'y a pas de problème et que je pourrais utiliser le
protocole GRE.
Lorsque j'appelle le service technique, on me demande si je peux naviguer
sur internet, ce à quoi je réponds oui et on me répond que je n'ai donc pas
de problème de connexion et que le service technique s'arrête là.
J'ai l'impression de tourner en rond ...
Pire, si j'appelle le service de résiliation, on me dit que je ne peux pas
résilier mon contrat avant la fin des 1 an ... même moyennant des frais de
résiliation.
Je ne peux donc pas utiliser pleinement ma connexion internet. (Notons que
ce genre de manipulation bien qu'un peu délicate et probablement peu
fréquente se réalise sans soucis chez Free, Wanadoo, Télé2, Nérim, ...)
On Wed, 06 Sep 2006 20:07:37 +0200, Pascal Hambourg wrote:
Qu'entends-tu exactement par "gérer le GRE en passthtru" stp ? Ce que savent faire l'immense majorité des routeurs SOHO depuis... de
nombreuses années. Je vais prendre le cas de PPTP que j'ai longtemps pratiqué : en redirigeant le port 1723 vers une machine interne, ça fonctionne. J'ai appris l'existence et l'utilité de GRE le jour où ça n'a pas fonctionné : c'était un des premiers routeurs à intégrer ses propres fonctions de VPN, et il laissait visiblement GRE à la porte. A cette même (lointaine) époque le "VPN pass through" était même spécifié dans les docs des routeurs. Je soupconne donc les routeurs NAT de se préoccuper en priorité de TCP et d'UDP (ce qui semble logique...) et de ne faire des choses avec pas mal d'autres protocoles IP que si on leur spécifie. Et je pense que cette notion de VPN pass through est liée à un truc genre : "tiens, elle a redirigé le port 1723 vers la machine 192.168.0.100, elle doit vouloir faire du PPTP, je vais lui envoyer du protocole 47 si j'en croise" :-) Mais je peux aussi me tromper... -- Nina
Qu'entends-tu exactement par "gérer le GRE en passthtru" stp ?
Ce que savent faire l'immense majorité des routeurs SOHO depuis... de
nombreuses années.
Je vais prendre le cas de PPTP que j'ai longtemps pratiqué : en
redirigeant le port 1723 vers une machine interne, ça fonctionne.
J'ai appris l'existence et l'utilité de GRE le jour où ça n'a pas
fonctionné : c'était un des premiers routeurs à intégrer ses propres
fonctions de VPN, et il laissait visiblement GRE à la porte.
A cette même (lointaine) époque le "VPN pass through" était même
spécifié dans les docs des routeurs.
Je soupconne donc les routeurs NAT de se préoccuper en priorité de TCP
et d'UDP (ce qui semble logique...) et de ne faire des choses avec pas
mal d'autres protocoles IP que si on leur spécifie. Et je pense que
cette notion de VPN pass through est liée à un truc genre : "tiens,
elle a redirigé le port 1723 vers la machine 192.168.0.100, elle doit
vouloir faire du PPTP, je vais lui envoyer du protocole 47 si j'en
croise" :-)
Mais je peux aussi me tromper...
--
Nina
On Wed, 06 Sep 2006 20:07:37 +0200, Pascal Hambourg wrote:
Qu'entends-tu exactement par "gérer le GRE en passthtru" stp ? Ce que savent faire l'immense majorité des routeurs SOHO depuis... de
nombreuses années. Je vais prendre le cas de PPTP que j'ai longtemps pratiqué : en redirigeant le port 1723 vers une machine interne, ça fonctionne. J'ai appris l'existence et l'utilité de GRE le jour où ça n'a pas fonctionné : c'était un des premiers routeurs à intégrer ses propres fonctions de VPN, et il laissait visiblement GRE à la porte. A cette même (lointaine) époque le "VPN pass through" était même spécifié dans les docs des routeurs. Je soupconne donc les routeurs NAT de se préoccuper en priorité de TCP et d'UDP (ce qui semble logique...) et de ne faire des choses avec pas mal d'autres protocoles IP que si on leur spécifie. Et je pense que cette notion de VPN pass through est liée à un truc genre : "tiens, elle a redirigé le port 1723 vers la machine 192.168.0.100, elle doit vouloir faire du PPTP, je vais lui envoyer du protocole 47 si j'en croise" :-) Mais je peux aussi me tromper... -- Nina
Alain
Il faut simplement utiliser une encapsulation UDP, désormais standardisée sous le protocole NAT-T UDP/4500.
"GG" wrote in message news:44ff1654$0$12821$
Bonjour,
Du GRE pur ou faisant partie d'un VPN PPTP ?
Le GRE est toujours pur. :) PPTP utilise le GRE pour transporter les packets PPP, mais même quand le protocole PPTP s'en sert il est encore et toujours pur.
Par conséquent tu ne pourras *jamais* utiliser *pleinement* ta connexion internet derrière un routeur NAT.
Oui peut-être, mais il existe des routeurs qui supportent du GRE en mode passthru ce qui me semble la moindre des choses pour un routeur digne de ce nom et d'autre non.
-- Cordialement. GG.
Il faut simplement utiliser une encapsulation UDP, désormais standardisée
sous le protocole NAT-T UDP/4500.
"GG" <news@nospam.assysm.com> wrote in message
news:44ff1654$0$12821$626a54ce@news.free.fr...
Bonjour,
Du GRE pur ou faisant partie d'un VPN PPTP ?
Le GRE est toujours pur. :)
PPTP utilise le GRE pour transporter les packets PPP, mais
même quand le protocole PPTP s'en sert il est encore et toujours
pur.
Par conséquent tu ne pourras *jamais* utiliser *pleinement* ta
connexion internet derrière un routeur NAT.
Oui peut-être, mais il existe des routeurs qui supportent du GRE
en mode passthru ce qui me semble la moindre des choses pour
un routeur digne de ce nom et d'autre non.
Il faut simplement utiliser une encapsulation UDP, désormais standardisée sous le protocole NAT-T UDP/4500.
"GG" wrote in message news:44ff1654$0$12821$
Bonjour,
Du GRE pur ou faisant partie d'un VPN PPTP ?
Le GRE est toujours pur. :) PPTP utilise le GRE pour transporter les packets PPP, mais même quand le protocole PPTP s'en sert il est encore et toujours pur.
Par conséquent tu ne pourras *jamais* utiliser *pleinement* ta connexion internet derrière un routeur NAT.
Oui peut-être, mais il existe des routeurs qui supportent du GRE en mode passthru ce qui me semble la moindre des choses pour un routeur digne de ce nom et d'autre non.
-- Cordialement. GG.
Nina Popravka
On Wed, 6 Sep 2006 20:02:31 +0200, "GG" wrote:
Il y a quelques soucis, sur les news proxad Gilles Vollant a soulevé un lievre mais il n'y a eu beaucoup d'échos, surtout de la part de Free. :( Oui je sais, j'ai quand même passé un peu de temps à me faire chier
dessus... Toutefois je comprend que le truc ne soit pas implémenté dans la FB, donc le jour où je veux faire du VPN, je met un Zywall par exemple en aval de la FB en bridge, affaire réglée. :-) -- Nina
On Wed, 6 Sep 2006 20:02:31 +0200, "GG" <news@nospam.assysm.com>
wrote:
Il y a quelques soucis, sur les news proxad Gilles Vollant a soulevé
un lievre mais il n'y a eu beaucoup d'échos, surtout de la part de Free. :(
Oui je sais, j'ai quand même passé un peu de temps à me faire chier
dessus...
Toutefois je comprend que le truc ne soit pas implémenté dans la FB,
donc le jour où je veux faire du VPN, je met un Zywall par exemple en
aval de la FB en bridge, affaire réglée. :-)
--
Nina
Il y a quelques soucis, sur les news proxad Gilles Vollant a soulevé un lievre mais il n'y a eu beaucoup d'échos, surtout de la part de Free. :( Oui je sais, j'ai quand même passé un peu de temps à me faire chier
dessus... Toutefois je comprend que le truc ne soit pas implémenté dans la FB, donc le jour où je veux faire du VPN, je met un Zywall par exemple en aval de la FB en bridge, affaire réglée. :-) -- Nina
Pascal Hambourg
Qu'entends-tu exactement par "gérer le GRE en passthtru" stp ? [...]
Je soupconne donc les routeurs NAT de se préoccuper en priorité de TCP et d'UDP (ce qui semble logique...) et de ne faire des choses avec pas mal d'autres protocoles IP que si on leur spécifie. Et je pense que cette notion de VPN pass through est liée à un truc genre : "tiens, elle a redirigé le port 1723 vers la machine 192.168.0.100, elle doit vouloir faire du PPTP, je vais lui envoyer du protocole 47 si j'en croise" :-)
C'est bien ce que je pensais, c'est plus du "PPTP pass through" que du "GRE pass through". Sans la connexion TCP associée à PPTP, le routeur aurait un peu de mal à savoir comment gérer un flux GRE, qui peut exister en dehors de PPTP. Me trompé-je ?
Qu'entends-tu exactement par "gérer le GRE en passthtru" stp ?
[...]
Je soupconne donc les routeurs NAT de se préoccuper en priorité de TCP
et d'UDP (ce qui semble logique...) et de ne faire des choses avec pas
mal d'autres protocoles IP que si on leur spécifie. Et je pense que
cette notion de VPN pass through est liée à un truc genre : "tiens,
elle a redirigé le port 1723 vers la machine 192.168.0.100, elle doit
vouloir faire du PPTP, je vais lui envoyer du protocole 47 si j'en
croise" :-)
C'est bien ce que je pensais, c'est plus du "PPTP pass through" que du
"GRE pass through". Sans la connexion TCP associée à PPTP, le routeur
aurait un peu de mal à savoir comment gérer un flux GRE, qui peut
exister en dehors de PPTP. Me trompé-je ?
Qu'entends-tu exactement par "gérer le GRE en passthtru" stp ? [...]
Je soupconne donc les routeurs NAT de se préoccuper en priorité de TCP et d'UDP (ce qui semble logique...) et de ne faire des choses avec pas mal d'autres protocoles IP que si on leur spécifie. Et je pense que cette notion de VPN pass through est liée à un truc genre : "tiens, elle a redirigé le port 1723 vers la machine 192.168.0.100, elle doit vouloir faire du PPTP, je vais lui envoyer du protocole 47 si j'en croise" :-)
C'est bien ce que je pensais, c'est plus du "PPTP pass through" que du "GRE pass through". Sans la connexion TCP associée à PPTP, le routeur aurait un peu de mal à savoir comment gérer un flux GRE, qui peut exister en dehors de PPTP. Me trompé-je ?
Pascal Hambourg
Il faut simplement utiliser une encapsulation UDP, désormais standardisée sous le protocole NAT-T UDP/4500.
Tu ne confondrais pas avec un VPN basé sur IPSec et non PPTP ?
Il faut simplement utiliser une encapsulation UDP, désormais standardisée
sous le protocole NAT-T UDP/4500.
Tu ne confondrais pas avec un VPN basé sur IPSec et non PPTP ?
donc le jour où je veux faire du VPN, je met un Zywall par exemple en aval de la FB en bridge, affaire réglée. :-)
Je préfere le Netopia 3386, affaire réglée aussi. :) -- Cordialement. GG.
GG
Bonjour,
Il faut simplement utiliser une encapsulation UDP, désormais standardisée sous le protocole NAT-T UDP/4500.
Tu ne confondrais pas avec un VPN basé sur IPSec et non PPTP ?
Oui je pense. Pour en revenir au problème initial, avec les petits problèmes de Freebox et GRE on sait s'en sortir, il semble qu'avec l'alicebox ce n'est pas possible puisque si on la transforme en modem on perde la fonctionnalité voix sur IP ce qui n'est pas le cas de la Freebox, si on l'utilise en mode modem (avec un routeur) ou en routeur on ne perd pas la fonction voix sur IP. Conclusion si l'Alicebox ne transfert pas le protocole GRE vers l'intérieur du réseau, et que la personne a besoin de VPN et de voix sur IP il faut semble-t-il allez voir ailleurs, chez Free par exemple. :) -- Cordialement. GG.
Bonjour,
Il faut simplement utiliser une encapsulation UDP, désormais
standardisée sous le protocole NAT-T UDP/4500.
Tu ne confondrais pas avec un VPN basé sur IPSec et non PPTP ?
Oui je pense.
Pour en revenir au problème initial, avec les petits problèmes
de Freebox et GRE on sait s'en sortir, il semble qu'avec l'alicebox
ce n'est pas possible puisque si on la transforme en modem
on perde la fonctionnalité voix sur IP ce qui n'est pas le cas de
la Freebox, si on l'utilise en mode modem (avec un routeur) ou
en routeur on ne perd pas la fonction voix sur IP.
Conclusion si l'Alicebox ne transfert pas le protocole GRE vers
l'intérieur du réseau, et que la personne a besoin de VPN et de
voix sur IP il faut semble-t-il allez voir ailleurs, chez Free par
exemple. :)
--
Cordialement.
GG.
Il faut simplement utiliser une encapsulation UDP, désormais standardisée sous le protocole NAT-T UDP/4500.
Tu ne confondrais pas avec un VPN basé sur IPSec et non PPTP ?
Oui je pense. Pour en revenir au problème initial, avec les petits problèmes de Freebox et GRE on sait s'en sortir, il semble qu'avec l'alicebox ce n'est pas possible puisque si on la transforme en modem on perde la fonctionnalité voix sur IP ce qui n'est pas le cas de la Freebox, si on l'utilise en mode modem (avec un routeur) ou en routeur on ne perd pas la fonction voix sur IP. Conclusion si l'Alicebox ne transfert pas le protocole GRE vers l'intérieur du réseau, et que la personne a besoin de VPN et de voix sur IP il faut semble-t-il allez voir ailleurs, chez Free par exemple. :) -- Cordialement. GG.
Pascal Hambourg
Du GRE pur ou faisant partie d'un VPN PPTP ?
Le GRE est toujours pur. :)
Dans PPTP, il est associé à du TCP, il n'est donc pas pur. :-)
PPTP utilise le GRE pour transporter les packets PPP, mais même quand le protocole PPTP s'en sert il est encore et toujours pur.
Ben non puisqu'il faut aussi la connexion TCP sur le port 1723.
Par conséquent tu ne pourras *jamais* utiliser *pleinement* ta connexion internet derrière un routeur NAT.
Oui peut-être, mais il existe des routeurs qui supportent du GRE en mode passthru ce qui me semble la moindre des choses pour un routeur digne de ce nom et d'autre non.
En fait j'avoue que je ne comprends pas trop ces histoires à propos de GRE pour le PPTP. Même sans support particulier, il devrait être possible d'établir une "connexion" GRE sortante, et le NAT devrait se charger de rediriger les paquets entrants vers l'adresse privée qui a généré le flux sortant. C'est encore plus facile que pour TCP et UDP puisqu'il n'y a même pas de ports à gérer.
Or comme tu le dis, le tunnel GRE de PPTP sert à transporter des paquets PPP, et le protocole PPP est totalement symétrique : pas de client, pas de serveur. Dans la mesure où les deux bouts du VPN savent avec qui établir le tunnel GRE grâce à la connexion TCP, il devrait être possible à n'importe lequel des deux côtés de "créer" la connexion GRE à travers le NAT.
J'ai fait un essai entre un serveur PoPToP sous Linux et le client PPTP intégré à Windows. Comme prévu, le serveur n'attend pas d'avoir reçu du trafic GRE du client pour en émettre lui-même. Donc même si le premier paquet émis par le client est bloqué, ça marche quand même. Le premier paquet émis par le serveur crée la connexion et les paquets suivants du client, dont la répétition du premier paquet sans réponse, passent. Donc a priori il n'y a même pas besoin de faire une redirection explicite du protocole GRE vers l'adresse du serveur, la redirection du port TCP 1723 devrair suffire.
Du GRE pur ou faisant partie d'un VPN PPTP ?
Le GRE est toujours pur. :)
Dans PPTP, il est associé à du TCP, il n'est donc pas pur. :-)
PPTP utilise le GRE pour transporter les packets PPP, mais
même quand le protocole PPTP s'en sert il est encore et toujours
pur.
Ben non puisqu'il faut aussi la connexion TCP sur le port 1723.
Par conséquent tu ne pourras *jamais* utiliser *pleinement* ta
connexion internet derrière un routeur NAT.
Oui peut-être, mais il existe des routeurs qui supportent du GRE
en mode passthru ce qui me semble la moindre des choses pour
un routeur digne de ce nom et d'autre non.
En fait j'avoue que je ne comprends pas trop ces histoires à propos de
GRE pour le PPTP. Même sans support particulier, il devrait être
possible d'établir une "connexion" GRE sortante, et le NAT devrait se
charger de rediriger les paquets entrants vers l'adresse privée qui a
généré le flux sortant. C'est encore plus facile que pour TCP et UDP
puisqu'il n'y a même pas de ports à gérer.
Or comme tu le dis, le tunnel GRE de PPTP sert à transporter des paquets
PPP, et le protocole PPP est totalement symétrique : pas de client, pas
de serveur. Dans la mesure où les deux bouts du VPN savent avec qui
établir le tunnel GRE grâce à la connexion TCP, il devrait être possible
à n'importe lequel des deux côtés de "créer" la connexion GRE à travers
le NAT.
J'ai fait un essai entre un serveur PoPToP sous Linux et le client PPTP
intégré à Windows. Comme prévu, le serveur n'attend pas d'avoir reçu du
trafic GRE du client pour en émettre lui-même. Donc même si le premier
paquet émis par le client est bloqué, ça marche quand même. Le premier
paquet émis par le serveur crée la connexion et les paquets suivants du
client, dont la répétition du premier paquet sans réponse, passent. Donc
a priori il n'y a même pas besoin de faire une redirection explicite du
protocole GRE vers l'adresse du serveur, la redirection du port TCP 1723
devrair suffire.
Dans PPTP, il est associé à du TCP, il n'est donc pas pur. :-)
PPTP utilise le GRE pour transporter les packets PPP, mais même quand le protocole PPTP s'en sert il est encore et toujours pur.
Ben non puisqu'il faut aussi la connexion TCP sur le port 1723.
Par conséquent tu ne pourras *jamais* utiliser *pleinement* ta connexion internet derrière un routeur NAT.
Oui peut-être, mais il existe des routeurs qui supportent du GRE en mode passthru ce qui me semble la moindre des choses pour un routeur digne de ce nom et d'autre non.
En fait j'avoue que je ne comprends pas trop ces histoires à propos de GRE pour le PPTP. Même sans support particulier, il devrait être possible d'établir une "connexion" GRE sortante, et le NAT devrait se charger de rediriger les paquets entrants vers l'adresse privée qui a généré le flux sortant. C'est encore plus facile que pour TCP et UDP puisqu'il n'y a même pas de ports à gérer.
Or comme tu le dis, le tunnel GRE de PPTP sert à transporter des paquets PPP, et le protocole PPP est totalement symétrique : pas de client, pas de serveur. Dans la mesure où les deux bouts du VPN savent avec qui établir le tunnel GRE grâce à la connexion TCP, il devrait être possible à n'importe lequel des deux côtés de "créer" la connexion GRE à travers le NAT.
J'ai fait un essai entre un serveur PoPToP sous Linux et le client PPTP intégré à Windows. Comme prévu, le serveur n'attend pas d'avoir reçu du trafic GRE du client pour en émettre lui-même. Donc même si le premier paquet émis par le client est bloqué, ça marche quand même. Le premier paquet émis par le serveur crée la connexion et les paquets suivants du client, dont la répétition du premier paquet sans réponse, passent. Donc a priori il n'y a même pas besoin de faire une redirection explicite du protocole GRE vers l'adresse du serveur, la redirection du port TCP 1723 devrair suffire.
-=lolol=-
Bonjour à tous,
Merci pour vos participations
Pour en revenir au problème initial
oui :-)
il semble qu'avec l'alicebox ce n'est pas possible puisque si on la transforme en modem on perde la fonctionnalité voix sur IP ce qui n'est pas le cas de la Freebox, si on l'utilise en mode modem (avec un routeur) ou en routeur on ne perd pas la fonction voix sur IP. Conclusion si l'Alicebox ne transfert pas le protocole GRE vers l'intérieur du réseau, et que la personne a besoin de VPN et de voix sur IP il faut semble-t-il allez voir ailleurs, chez Free par exemple. :)
Donc la messe semble dite ! Je vais tenté une lettre recommandé chez Alice pour avoir du support qui tient la route (qu'ils me disent si oui ou non on peut le faire et comment). Dans la négative je tacherais de trouver moyen de résilier avant l'heure sans pénalité (faut que je relise le contrat).
Je tâcherais de vous tenir au courant
Encore merci à tous @+lolo
Bonjour à tous,
Merci pour vos participations
Pour en revenir au problème initial
oui :-)
il semble qu'avec l'alicebox
ce n'est pas possible puisque si on la transforme en modem
on perde la fonctionnalité voix sur IP ce qui n'est pas le cas de
la Freebox, si on l'utilise en mode modem (avec un routeur) ou
en routeur on ne perd pas la fonction voix sur IP.
Conclusion si l'Alicebox ne transfert pas le protocole GRE vers
l'intérieur du réseau, et que la personne a besoin de VPN et de
voix sur IP il faut semble-t-il allez voir ailleurs, chez Free par
exemple. :)
Donc la messe semble dite !
Je vais tenté une lettre recommandé chez Alice pour avoir du support qui
tient la route (qu'ils me disent si oui ou non on peut le faire et comment).
Dans la négative je tacherais de trouver moyen de résilier avant l'heure
sans pénalité (faut que je relise le contrat).
il semble qu'avec l'alicebox ce n'est pas possible puisque si on la transforme en modem on perde la fonctionnalité voix sur IP ce qui n'est pas le cas de la Freebox, si on l'utilise en mode modem (avec un routeur) ou en routeur on ne perd pas la fonction voix sur IP. Conclusion si l'Alicebox ne transfert pas le protocole GRE vers l'intérieur du réseau, et que la personne a besoin de VPN et de voix sur IP il faut semble-t-il allez voir ailleurs, chez Free par exemple. :)
Donc la messe semble dite ! Je vais tenté une lettre recommandé chez Alice pour avoir du support qui tient la route (qu'ils me disent si oui ou non on peut le faire et comment). Dans la négative je tacherais de trouver moyen de résilier avant l'heure sans pénalité (faut que je relise le contrat).
Je tâcherais de vous tenir au courant
Encore merci à tous @+lolo
GG
Bonjour,
En fait j'avoue que je ne comprends pas trop ces histoires à propos de GRE pour le PPTP. Même sans support particulier, il devrait être possible d'établir une "connexion" GRE sortante, et le NAT devrait se charger de rediriger les paquets entrants vers l'adresse privée qui a généré le flux sortant. C'est encore plus facile que pour TCP et UDP puisqu'il n'y a même pas de ports à gérer.
Or comme tu le dis, le tunnel GRE de PPTP sert à transporter des paquets PPP, et le protocole PPP est totalement symétrique : pas de client, pas de serveur. Dans la mesure où les deux bouts du VPN savent avec qui établir le tunnel GRE grâce à la connexion TCP, il devrait être possible à n'importe lequel des deux côtés de "créer" la connexion GRE à travers le NAT.
J'ai fait un essai entre un serveur PoPToP sous Linux et le client PPTP intégré à Windows. Comme prévu, le serveur n'attend pas d'avoir reçu du trafic GRE du client pour en émettre lui-même. Donc même si le premier paquet émis par le client est bloqué, ça marche quand même. Le premier paquet émis par le serveur crée la connexion et les paquets suivants du client, dont la répétition du premier paquet sans réponse, passent. Donc a priori il n'y a même pas besoin de faire une redirection explicite du protocole GRE vers l'adresse du serveur, la redirection du port TCP 1723 devrair suffire.
Entierement d'accord avec tes explications, il y a donc un bug dans l'alicebox et aussi d'ailleurs dans la freebox en mode routeur, je suis d'accord le client n'attend pas mais si il n'a pas de réponse, il n'envoie pas l'authentification, avec netmon sur un W2K3 cela se voit, je viens de jouer a mettre ma freebox en routeur, et l'authentification ne me parvient pas, pas de PPP. -- Cordialement. GG.
Bonjour,
En fait j'avoue que je ne comprends pas trop ces histoires à propos de
GRE pour le PPTP. Même sans support particulier, il devrait être
possible d'établir une "connexion" GRE sortante, et le NAT devrait se
charger de rediriger les paquets entrants vers l'adresse privée qui a
généré le flux sortant. C'est encore plus facile que pour TCP et UDP
puisqu'il n'y a même pas de ports à gérer.
Or comme tu le dis, le tunnel GRE de PPTP sert à transporter des
paquets PPP, et le protocole PPP est totalement symétrique : pas de
client, pas de serveur. Dans la mesure où les deux bouts du VPN
savent avec qui établir le tunnel GRE grâce à la connexion TCP, il
devrait être possible à n'importe lequel des deux côtés de "créer" la
connexion GRE à travers le NAT.
J'ai fait un essai entre un serveur PoPToP sous Linux et le client
PPTP intégré à Windows. Comme prévu, le serveur n'attend pas d'avoir
reçu du trafic GRE du client pour en émettre lui-même. Donc même si
le premier paquet émis par le client est bloqué, ça marche quand
même. Le premier paquet émis par le serveur crée la connexion et les
paquets suivants du client, dont la répétition du premier paquet sans
réponse, passent. Donc a priori il n'y a même pas besoin de faire une
redirection explicite du protocole GRE vers l'adresse du serveur, la
redirection du port TCP 1723 devrair suffire.
Entierement d'accord avec tes explications, il y a donc un bug dans
l'alicebox
et aussi d'ailleurs dans la freebox en mode routeur, je suis d'accord le
client
n'attend pas mais si il n'a pas de réponse, il n'envoie pas
l'authentification,
avec netmon sur un W2K3 cela se voit, je viens de jouer a mettre ma freebox
en routeur, et l'authentification ne me parvient pas, pas de PPP.
--
Cordialement.
GG.
En fait j'avoue que je ne comprends pas trop ces histoires à propos de GRE pour le PPTP. Même sans support particulier, il devrait être possible d'établir une "connexion" GRE sortante, et le NAT devrait se charger de rediriger les paquets entrants vers l'adresse privée qui a généré le flux sortant. C'est encore plus facile que pour TCP et UDP puisqu'il n'y a même pas de ports à gérer.
Or comme tu le dis, le tunnel GRE de PPTP sert à transporter des paquets PPP, et le protocole PPP est totalement symétrique : pas de client, pas de serveur. Dans la mesure où les deux bouts du VPN savent avec qui établir le tunnel GRE grâce à la connexion TCP, il devrait être possible à n'importe lequel des deux côtés de "créer" la connexion GRE à travers le NAT.
J'ai fait un essai entre un serveur PoPToP sous Linux et le client PPTP intégré à Windows. Comme prévu, le serveur n'attend pas d'avoir reçu du trafic GRE du client pour en émettre lui-même. Donc même si le premier paquet émis par le client est bloqué, ça marche quand même. Le premier paquet émis par le serveur crée la connexion et les paquets suivants du client, dont la répétition du premier paquet sans réponse, passent. Donc a priori il n'y a même pas besoin de faire une redirection explicite du protocole GRE vers l'adresse du serveur, la redirection du port TCP 1723 devrair suffire.
Entierement d'accord avec tes explications, il y a donc un bug dans l'alicebox et aussi d'ailleurs dans la freebox en mode routeur, je suis d'accord le client n'attend pas mais si il n'a pas de réponse, il n'envoie pas l'authentification, avec netmon sur un W2K3 cela se voit, je viens de jouer a mettre ma freebox en routeur, et l'authentification ne me parvient pas, pas de PPP. -- Cordialement. GG.
