In article ,
Raphael Bouaziz wrote:
Il faut faire attention à la MTU.
Si le tunnel et la session montent mais que le trafic ne passe pas
c'est probablement un souci de MTU, qu'il faut gérer en réduisant
celle des interfaces derrière le VPN.
ah mince, il y a le même pb avec le L2TP ? :-(
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
In article <slrnfg9oit.14a.bouaziz@sonia.noc.nerim.net>,
Raphael Bouaziz <bouaziz@nerim.net> wrote:
Il faut faire attention à la MTU.
Si le tunnel et la session montent mais que le trafic ne passe pas
c'est probablement un souci de MTU, qu'il faut gérer en réduisant
celle des interfaces derrière le VPN.
ah mince, il y a le même pb avec le L2TP ? :-(
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
In article ,
Raphael Bouaziz wrote:
Il faut faire attention à la MTU.
Si le tunnel et la session montent mais que le trafic ne passe pas
c'est probablement un souci de MTU, qu'il faut gérer en réduisant
celle des interfaces derrière le VPN.
ah mince, il y a le même pb avec le L2TP ? :-(
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
In article ,
Raphael Bouaziz wrote:
Il faut faire attention à la MTU.
Si le tunnel et la session montent mais que le trafic ne passe pas
c'est probablement un souci de MTU, qu'il faut gérer en réduisant
celle des interfaces derrière le VPN.
ah mince, il y a le même pb avec le L2TP ? :-(
Dès qu'il y a tunnel et donc encapsulation avec augmentation de la
charge protocolaire, il y a potentiellement des problèmes de MTU et de
fragmentation. Si on veut envoyer des datagrammes d'une certaine taille,
il faut fragmenter. Soit on fragmente avant encapsulation en ajustant
les MTU des extrémités du tunnel, soit on fragmente après encapsulation.
L'inconvénient de la fragmentation après encapsulation, c'est qu'elle
peut se produire n'importe où en chemin hors de ton contrôle, et que ça
peut mal se passer.
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
Alors ça marche dans une certaine mesure ?
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free. Hors si ce tunnel L2TP
passe sur une lien ethernet de MTU 1500, ça implique qu'un paquet IP de
taille supérieure à 1460 (environ), une fois encapsulé, doit être
fragmenté pour passer sur ce lien. Mais il arrive que des paquets soient
perdus dans l'opération.
Des tests de ping de taille croissante devraient permettre de
différencier entre un problème de MTU et un problème de perte de paquets.
In article <slrnfg9oit.14a.bouaziz@sonia.noc.nerim.net>,
Raphael Bouaziz <bouaziz@nerim.net> wrote:
Il faut faire attention à la MTU.
Si le tunnel et la session montent mais que le trafic ne passe pas
c'est probablement un souci de MTU, qu'il faut gérer en réduisant
celle des interfaces derrière le VPN.
ah mince, il y a le même pb avec le L2TP ? :-(
Dès qu'il y a tunnel et donc encapsulation avec augmentation de la
charge protocolaire, il y a potentiellement des problèmes de MTU et de
fragmentation. Si on veut envoyer des datagrammes d'une certaine taille,
il faut fragmenter. Soit on fragmente avant encapsulation en ajustant
les MTU des extrémités du tunnel, soit on fragmente après encapsulation.
L'inconvénient de la fragmentation après encapsulation, c'est qu'elle
peut se produire n'importe où en chemin hors de ton contrôle, et que ça
peut mal se passer.
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
Alors ça marche dans une certaine mesure ?
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free. Hors si ce tunnel L2TP
passe sur une lien ethernet de MTU 1500, ça implique qu'un paquet IP de
taille supérieure à 1460 (environ), une fois encapsulé, doit être
fragmenté pour passer sur ce lien. Mais il arrive que des paquets soient
perdus dans l'opération.
Des tests de ping de taille croissante devraient permettre de
différencier entre un problème de MTU et un problème de perte de paquets.
In article ,
Raphael Bouaziz wrote:
Il faut faire attention à la MTU.
Si le tunnel et la session montent mais que le trafic ne passe pas
c'est probablement un souci de MTU, qu'il faut gérer en réduisant
celle des interfaces derrière le VPN.
ah mince, il y a le même pb avec le L2TP ? :-(
Dès qu'il y a tunnel et donc encapsulation avec augmentation de la
charge protocolaire, il y a potentiellement des problèmes de MTU et de
fragmentation. Si on veut envoyer des datagrammes d'une certaine taille,
il faut fragmenter. Soit on fragmente avant encapsulation en ajustant
les MTU des extrémités du tunnel, soit on fragmente après encapsulation.
L'inconvénient de la fragmentation après encapsulation, c'est qu'elle
peut se produire n'importe où en chemin hors de ton contrôle, et que ça
peut mal se passer.
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
Alors ça marche dans une certaine mesure ?
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free. Hors si ce tunnel L2TP
passe sur une lien ethernet de MTU 1500, ça implique qu'un paquet IP de
taille supérieure à 1460 (environ), une fois encapsulé, doit être
fragmenté pour passer sur ce lien. Mais il arrive que des paquets soient
perdus dans l'opération.
Des tests de ping de taille croissante devraient permettre de
différencier entre un problème de MTU et un problème de perte de paquets.
Albert ARIBAUD wrote:
Si OpenVPN te convient, il fonctionne, au choix en UDP ou TCP,
ah bon :-)
c'est quoi les avantages de l'un et de l'autre ?
TCP et UDP ont tous deux l'avantage d'être beaucoup plus simples à faire
passer à travers les firewalls/NAT qu'IPSec ou les tunnels GRE de PPTP.
TCP a l'avantage de la fiabilité, mais je me suis laissé dire que
l'encapsulation de TCP dans TCP pouvait causer des problèmes en cas de
perte de paquets.et il permet même de faire du pontage.
OpenVPN laisse le choix que le VPN soit vu soit comme une liaison point
à point routée (mode TUN), comme avec PPTP, soit comme une liaison
ethernet (mode TAP). En mode TAP, il est possible de ponter le VPN avec
le réseau local comme à travers un switch afin qu'ils ne fassent plus
qu'un même domaine de broadcast. Cela permet de faire passer très
simplement les protocoles non routables comme Netbios et même les
protocoles non IP comme IPX.
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Si OpenVPN te convient, il fonctionne, au choix en UDP ou TCP,
ah bon :-)
c'est quoi les avantages de l'un et de l'autre ?
TCP et UDP ont tous deux l'avantage d'être beaucoup plus simples à faire
passer à travers les firewalls/NAT qu'IPSec ou les tunnels GRE de PPTP.
TCP a l'avantage de la fiabilité, mais je me suis laissé dire que
l'encapsulation de TCP dans TCP pouvait causer des problèmes en cas de
perte de paquets.
et il permet même de faire du pontage.
OpenVPN laisse le choix que le VPN soit vu soit comme une liaison point
à point routée (mode TUN), comme avec PPTP, soit comme une liaison
ethernet (mode TAP). En mode TAP, il est possible de ponter le VPN avec
le réseau local comme à travers un switch afin qu'ils ne fassent plus
qu'un même domaine de broadcast. Cela permet de faire passer très
simplement les protocoles non routables comme Netbios et même les
protocoles non IP comme IPX.
Albert ARIBAUD wrote:
Si OpenVPN te convient, il fonctionne, au choix en UDP ou TCP,
ah bon :-)
c'est quoi les avantages de l'un et de l'autre ?
TCP et UDP ont tous deux l'avantage d'être beaucoup plus simples à faire
passer à travers les firewalls/NAT qu'IPSec ou les tunnels GRE de PPTP.
TCP a l'avantage de la fiabilité, mais je me suis laissé dire que
l'encapsulation de TCP dans TCP pouvait causer des problèmes en cas de
perte de paquets.et il permet même de faire du pontage.
OpenVPN laisse le choix que le VPN soit vu soit comme une liaison point
à point routée (mode TUN), comme avec PPTP, soit comme une liaison
ethernet (mode TAP). En mode TAP, il est possible de ponter le VPN avec
le réseau local comme à travers un switch afin qu'ils ne fassent plus
qu'un même domaine de broadcast. Cela permet de faire passer très
simplement les protocoles non routables comme Netbios et même les
protocoles non IP comme IPX.
In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
Alors ça marche dans une certaine mesure ?
oui !
(je ne vois pas tellement ce que je peux rajouter)
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free. Hors si ce tunnel L2TP
passe sur une lien ethernet de MTU 1500, ça implique qu'un paquet IP de
taille supérieure à 1460 (environ), une fois encapsulé, doit être
fragmenté pour passer sur ce lien. Mais il arrive que des paquets soient
perdus dans l'opération.
Des tests de ping de taille croissante devraient permettre de
différencier entre un problème de MTU et un problème de perte de paquets.
alors en fait,
comme ifconfig donne
ppp0: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
je croyais qu'il fallait mettre le mtu à 1444 sur l'ordi à l'autre bout
(et ça ne marchais pas mieux)
mais je viens de faire le test du ping (avec "ping -c 4 -s"), et
quand je suis sur le client et que je ping l'ordi derrière le serveur,
ça va jusqu'à 1400
et quand je suis derrière le serveur et que je ping le client, ça va
jusqu'à 1396
peux tu m'expliquer pourquoi c'est comme ça, stp ?
je dois bien laisser le mtu de l'ordi client à 1500 ?
je dois mettre le mtu de l'ordi derrière le serveur à combien ?
In article <fe5k6v$2tb6$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
Alors ça marche dans une certaine mesure ?
oui !
(je ne vois pas tellement ce que je peux rajouter)
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free. Hors si ce tunnel L2TP
passe sur une lien ethernet de MTU 1500, ça implique qu'un paquet IP de
taille supérieure à 1460 (environ), une fois encapsulé, doit être
fragmenté pour passer sur ce lien. Mais il arrive que des paquets soient
perdus dans l'opération.
Des tests de ping de taille croissante devraient permettre de
différencier entre un problème de MTU et un problème de perte de paquets.
alors en fait,
comme ifconfig donne
ppp0: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
je croyais qu'il fallait mettre le mtu à 1444 sur l'ordi à l'autre bout
(et ça ne marchais pas mieux)
mais je viens de faire le test du ping (avec "ping -c 4 -s"), et
quand je suis sur le client et que je ping l'ordi derrière le serveur,
ça va jusqu'à 1400
et quand je suis derrière le serveur et que je ping le client, ça va
jusqu'à 1396
peux tu m'expliquer pourquoi c'est comme ça, stp ?
je dois bien laisser le mtu de l'ordi client à 1500 ?
je dois mettre le mtu de l'ordi derrière le serveur à combien ?
In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
Alors ça marche dans une certaine mesure ?
oui !
(je ne vois pas tellement ce que je peux rajouter)
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free. Hors si ce tunnel L2TP
passe sur une lien ethernet de MTU 1500, ça implique qu'un paquet IP de
taille supérieure à 1460 (environ), une fois encapsulé, doit être
fragmenté pour passer sur ce lien. Mais il arrive que des paquets soient
perdus dans l'opération.
Des tests de ping de taille croissante devraient permettre de
différencier entre un problème de MTU et un problème de perte de paquets.
alors en fait,
comme ifconfig donne
ppp0: flags51<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1444
inet 192.168.1.203 --> 192.168.1.1 netmask 0xffffff00
je croyais qu'il fallait mettre le mtu à 1444 sur l'ordi à l'autre bout
(et ça ne marchais pas mieux)
mais je viens de faire le test du ping (avec "ping -c 4 -s"), et
quand je suis sur le client et que je ping l'ordi derrière le serveur,
ça va jusqu'à 1400
et quand je suis derrière le serveur et que je ping le client, ça va
jusqu'à 1396
peux tu m'expliquer pourquoi c'est comme ça, stp ?
je dois bien laisser le mtu de l'ordi client à 1500 ?
je dois mettre le mtu de l'ordi derrière le serveur à combien ?
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free.
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free.
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une freebox
non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé et
non dégroupé, c'est qu'en non dégroupé la connexion transite dans un
tunnel L2TP entre le BAS de FT et le LNS de Free.
In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé
et non dégroupé, c'est qu'en non dégroupé la connexion transite dans
un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel L2TP
sans pb, mais pas par 2 tunnels L2TP de suite ??
In article <fe5k6v$2tb6$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé
et non dégroupé, c'est qu'en non dégroupé la connexion transite dans
un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel L2TP
sans pb, mais pas par 2 tunnels L2TP de suite ??
In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé
et non dégroupé, c'est qu'en non dégroupé la connexion transite dans
un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel L2TP
sans pb, mais pas par 2 tunnels L2TP de suite ??
Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé
et non dégroupé, c'est qu'en non dégroupé la connexion transite dans
un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel L2TP
sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:
In article <fe5k6v$2tb6$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé
et non dégroupé, c'est qu'en non dégroupé la connexion transite dans
un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel L2TP
sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre dégroupé
et non dégroupé, c'est qu'en non dégroupé la connexion transite dans
un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel L2TP
sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel
L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
In article <pan.2007.10.09.14.19.53@free.fr>,
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:
In article <fe5k6v$2tb6$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel
L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel
L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Le Tue, 09 Oct 2007 16:30:30 +0200, Thomas a écrit:In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel
L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Elles ont alors un même point de départ du tunnel, mais pas forcément un
même point d'arrivée, qui est au choix du FAI.
Le Tue, 09 Oct 2007 16:30:30 +0200, Thomas a écrit:
In article <pan.2007.10.09.14.19.53@free.fr>,
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:
In article <fe5k6v$2tb6$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel
L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Elles ont alors un même point de départ du tunnel, mais pas forcément un
même point d'arrivée, qui est au choix du FAI.
Le Tue, 09 Oct 2007 16:30:30 +0200, Thomas a écrit:In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière une
freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière une
freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1 tunnel
L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Elles ont alors un même point de départ du tunnel, mais pas forcément un
même point d'arrivée, qui est au choix du FAI.
In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 16:30:30 +0200, Thomas a écrit:In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière
une freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière
une freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de
Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1
tunnel L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Elles ont alors un même point de départ du tunnel, mais pas forcément
un même point d'arrivée, qui est au choix du FAI.
le serveur PPTP est derriere celle là :
lns-bzn-51f-81-56-128-208.adsl.proxad.net
on a des pb quand on se connecte au serveur en étant derrière celles là
: lns-bzn-50f-81-56-196-203.adsl.proxad.net
lns-bzn-51f-81-56-143-238.adsl.proxad.net
81-56-128-208 et 81-56-128-208 sont sur le même DSLAM d'ailleurs les 2
ont "51f"
avec ça, c'est encore possible que les tunnels L2TP soient différents ?
et ça dépendrait de qui ? de free ou de FT ?
In article <pan.2007.10.09.14.40.28@free.fr>,
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Le Tue, 09 Oct 2007 16:30:30 +0200, Thomas a écrit:
In article <pan.2007.10.09.14.19.53@free.fr>,
Albert ARIBAUD <albert.aribaud@free.fr> wrote:
Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:
In article <fe5k6v$2tb6$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière
une freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière
une freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de
Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1
tunnel L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Elles ont alors un même point de départ du tunnel, mais pas forcément
un même point d'arrivée, qui est au choix du FAI.
le serveur PPTP est derriere celle là :
lns-bzn-51f-81-56-128-208.adsl.proxad.net
on a des pb quand on se connecte au serveur en étant derrière celles là
: lns-bzn-50f-81-56-196-203.adsl.proxad.net
lns-bzn-51f-81-56-143-238.adsl.proxad.net
81-56-128-208 et 81-56-128-208 sont sur le même DSLAM d'ailleurs les 2
ont "51f"
avec ça, c'est encore possible que les tunnels L2TP soient différents ?
et ça dépendrait de qui ? de free ou de FT ?
In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 16:30:30 +0200, Thomas a écrit:In article ,
Albert ARIBAUD wrote:Le Tue, 09 Oct 2007 15:42:14 +0200, Thomas a écrit:In article <fe5k6v$2tb6$,
Pascal Hambourg wrote:mais c'est quand même bizarre,
il semble y avoir ce pb de mtu si le client vpn est derrière
une freebox non dégroupée,
mais il n'y a pas du tout ce pb si le client vpn est derrière
une freebox dégroupée !
est ce que ça peut quand même être un pb de mtu, du coup ??
Ce n'est pas exclu. Comme on te l'a dit une différence entre
dégroupé et non dégroupé, c'est qu'en non dégroupé la connexion
transite dans un tunnel L2TP entre le BAS de FT et le LNS de
Free.
mais, pourquoi ce tunnel PPTP serait capable de passer par 1
tunnel L2TP sans pb, mais pas par 2 tunnels L2TP de suite ??
Parce que les deux tunnels sont différents,
même quand les 2 freebox sont sur le même dslam ??
Elles ont alors un même point de départ du tunnel, mais pas forcément
un même point d'arrivée, qui est au choix du FAI.
le serveur PPTP est derriere celle là :
lns-bzn-51f-81-56-128-208.adsl.proxad.net
on a des pb quand on se connecte au serveur en étant derrière celles là
: lns-bzn-50f-81-56-196-203.adsl.proxad.net
lns-bzn-51f-81-56-143-238.adsl.proxad.net
81-56-128-208 et 81-56-128-208 sont sur le même DSLAM d'ailleurs les 2
ont "51f"
avec ça, c'est encore possible que les tunnels L2TP soient différents ?
et ça dépendrait de qui ? de free ou de FT ?