Donc en résumant (sans savoir si c'est du DS-Lite) en ZMD chez Free :

• IPv6 native
• IPv4 portée à travers IPv6 avec un mtu de 1472 octets

Du coup le mécanisme qui fait le partage des "ports" entre 4 freebox, ainsi que le tunnel, est déporté sur le NRO?, ou cela se situe directement dans l'infra de Free? (un peu à la manière d'un LNS)

Ca n'était pas tranché en fait. si tu relis quelques pages à  partir d'ici https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/msg283323/#msg283323.

On n'avait pas eu de confirmation du MTU en IPv4 car personne n'a fait de mesure (ou l'info m'a échappé). On en était resté a un A+P sans tunnel (curieux j'admet).

Cet nouvelle info de MTU semble indiqué des tunnels donc un NAT64, en fait un DS-Lite plutot (le NAT64 n'implique pas d'IPv4 coté client).

Donc Free ferait du DS-Lite avec NAT stateless pré-partagé une IP pour 4, les gateway DS-Lite étant en IDF (pour le moment).
C'est effectivement plus facile de proposer des IP full en option sur ce genre d'archi et ca permet le Pass-thru du VPN.

Ca clarifie nettement les choses. Ca veut dire aussi qu'en mode bridge la Freebox fait toujours le tunnel 4in6 donc on doit pouvoir mettre son propre routeur sans souci si on rêgle bien le MTU.

Alors je vous confirme après avoir écarté le doute sur le driver ethernet de mon contrôleur ethernet Nvidia MCP79 (Nvidia ION)... que sur un routeur ERLite le soucis de la MTU se confirme.

A partir du ERLite 3 :


MTU 1472
root@ubnt# ifconfig eth0 mtu 1472
root@ubnt# tracepath www.free.fr
 1:  192.168.2.254                                         0.918ms pmtu 1472
 1:  192.168.2.1                                           0.620ms
 1:  192.168.2.1                                           0.652ms
 2:  194.149.164.0                                        14.179ms
 3:  p11-crs16-1-be1003.intf.routers.proxad.net           17.461ms
 4:  p11-9k-1-be1000.intf.routers.proxad.net              15.077ms
 5:  bzn-9k-2-sys-be2001.intf.routers.proxad.net          14.872ms
 6:  no reply
 7:  no reply
 8:  no reply

MTU 1500
root@ubnt# ifconfig eth0 mtu 1500
root@ubnt# tracepath www.free.fr
 1:  192.168.2.254                                         0.835ms pmtu 1500
 1:  192.168.2.1                                           0.571ms
 1:  192.168.2.1                                           0.544ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply

Serveur debian 8 :

MTU 1500
root@vpnbox:~# tracepath www.free.fr
 1?: [LOCALHOST]                                         pmtu 1500
 1:  192.168.2.1                                           0.330ms
 1:  192.168.2.1                                           0.269ms
 2:  no reply
 3:  no reply

MTU 1472
root@vpnbox:~# ifconfig eth0 mtu 1472
root@vpnbox:~# tracepath www.free.fr
 1?: [LOCALHOST]                                         pmtu 1472
 1:  192.168.2.1                                           0.322ms
 1:  192.168.2.1                                           0.260ms
 2:  194.149.164.0                                        13.980ms
 3:  p11-crs16-1-be1003.intf.routers.proxad.net           18.045ms
 4:  p11-9k-1-be1000.intf.routers.proxad.net              15.521ms
 5:  bzn-9k-2-sys-be2001.intf.routers.proxad.net          14.505ms
 6:  no reply

Merci Rani


P.S :
J'ai également revérifier la configuration de mon serveur OpenVPN sur ma dédibox, en établissant un tunnel vers un serveur Amazon EC2 en zone Europe, je cartonne bien à plus de 600 Mbit/s en DL / UP sur mon dédié.

Je vais refaire des tests de débits avec iperf3 avec le tunnel OpenVPN de chez moi mais c'est clairement pas cool du tout...

P.S2 : test rejoué avec iperf3 dans les 2 sens, en encapsulant dans un stunnel (ou sans) l'OpenVPN, uniquement en TCP du coup : débit max 180 Mbit/s UP / DL via OpenVPN


Didier

1/ Un serveur Linux (Ubuntu 14.04 LTS ou Debian 8.3) au cul de la Freebox Mini 4K, impossible d'uploader (speedtest-cli) sans modifier la MTU de l'interface eth0 à 1472.

MTU max à 1472 en IPv4 ou en IPv6 ? Les deux sont indépendants.

Comment cela se passe sous Windows avec une MTU par défaut à 1500 octets ? Il serait intéressant de prendre une capture Wireshark pour comprendre.

fragmentation des paquets par la box ? Pourquoi sous Windows et pas sous Linux ?

MTU max à 1472 en IPv4 ou en IPv6 ? Les deux sont indépendants.

Comment cela se passe sous Windows avec une MTU par défaut à 1500 octets ? Il serait intéressant de prendre une capture Wireshark pour comprendre.

fragmentation des paquets par la box ? Pourquoi sous Windows et pas sous Linux ?

La stack IPv6 est désactivé sur mon serveur Debian 8 lors de mes tests (et de façon générale en fait).

Et l'option IPv6 n'est pas activée sur la Freebox.

Didier

Et pourquoi désactives-tu l'IPv6 ? Dans ton cas elle pourrait bien t'aider. Si c'est une question de sécurité, perso, je n'ai aps encore vu de problème en IPv6. Il faudrait d'ailleurs s'il y a un pare-feu par défaut en IPv6 sur la freebox, mais sous windows, il y a au moins celui du PC. Sous linux, c'est possible aussi.

Disons que je n'en vois pas vraiment l'utilité, ni le bénéfice pour mon utilisation actuelle. Maintenant, si pour une obscure raison propre au SI Free, le fait de l'activer permet de nativement bypasser les restrictions que je constate... je vais peut être m'intéresser à basculer mon tunnel VPN sur de l'IPv6.

Pour info, je viens de regarder sous Windows je suis en MTU 1500 par default.

P.S : underground, tu pourrais suggérer à toriyvaca d'activer l'IPv6, pour voir si cela résout ses problèmes de connexion https et d'authentification Freewifi.

Je ne vois pas comment : wifi.free.fr = 212.27.40.236

(et les sites EDF ne semblent pas dispo en IPv6 non plus)