Je crois que vous n'avez pas très bien suivi. Freewifi vérifierait le réseau d'où émane la demande de connexion, pour vérifier si c'est un réseau Free.

Le message d'erreur que voit toroyvaca est le suivant :

Donc rien à voir avec l'adresse IP du Freewifi lui-même.

Edit : Abel99 a même retrouvé une tâche ouverte sur le bugtracker :

http://dev.freebox.fr/bugs/task/19681

Oui c'est moi qui est ouvert ce ticket quand j'ai constaté le soucis sur la ligne de mes parents.

Depuis, j'ai migré également ma deuxieme ligne FTTH vers Free, et j'ai d'autres soucis qui vont je pense mériter des tickets chez eux.

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.

2/ Soucis en bypassant la freebox en mode bridge et en mettant à la place l'ERLite 3 (l'interface eth1 prend bien le DHCP et l'IP publique de la box) mais aucune resolution DNS possible (je pense que c'est le soucis de MTU 1472 qu'il faudrait que je reteste avec l'ERLite)

3/ Soucis pour maintenir un tunnel OpenVPN sous Debian / Ubuntu au cul de la Freebox. => Impossible en mode UDP (connexion établie mais 0 flux possible)

=> Possibilité de lancer le tunnel OpenVPN en mode TCP mais avec un débit limité pour le moment sans cryptage / auth à 16 Mo/s avec le serveur dédié (qui est en interface gigabit), le pire étant pour le moment qu'il est du coup impossible de maximiser la MTU du tun0/tap0 pour optimiser les performances.

Bref, pour le moment cette solution IP shared ne me convient pas vraiment... quid de la possibilité d'avoir une IP dédiée (via option payante ou pas) ? Quand ?

Didier

2/ Soucis en bypassant la freebox en mode bridge et en mettant à la place l'ERLite 3 (l'interface eth1 prend bien le DHCP et l'IP publique de la box) mais aucune resolution DNS possible (je pense que c'est le soucis de MTU 1472 qu'il faudrait que je reteste avec l'ERLite)

Moi je crois plutôt que comme l'ERL n'est pas au courant qu'il n'a pas droit à tous les ports, manque de chance le port source choisi pour les requêtes DNS (si tu utilises dnsmasq sur l'ERL) ne fait pas partie du range qui t'es attribué, et du coup la réponse "va chez ton voisin".

Personnellement j'ai du mal à voir comment le mode bridge peut fonctionner sans indiquer explicitement au routeur quelle plage de ports il peut utiliser.

L'IP dédiée, Rani a dit que l'option serait gratuite, et que l'on pourrait même avoir plusieurs IP (option payante). Mais on attend toujours sa réponse sur la date de disponibilité de l'option...

Pour moi, en ZMD, c'est toujours en beta-test. Mais chez Free, on l'a souvent vu (freebox v6, 4K etc...), on peut être en beta-test et en même temps en étape de commercialisation. Il vaut mieux attendre que les soucis soient réglés avant de souscrire...

P.S : au fait, tu as quel range de ports ?

Pour info, sur ma ligne Free FTTH ZMD j'ai gagné à la loterie et j'ai le premier range [0 - 15000] (ou quelque chose comme ça). C'est sur cette ligne que j'ai fais les tests d'OpenVPN.

Je vais refaire joujou avec l'ERLite 3 ports et la freebox en mode bridge jusqu'à trouver le pourquoi du comment.

Et pour le CGNAT, je pense que c'est pour ça que le tunnel OpenVPN UDP ne passe pas aussi. (Il faut que je teste à partir d'un poste sous Windows)

Didier

Il me semble au contraire que c'est ce que l'on disait depuis le début. D'après Vivien, et les tests de traceroute effectués, on ne peut pas tracer l'IP, car cela sort d'un tunnel IPv6 sur un routeur free à Paris (cf cyberjuls). Donc il y a peut-être effectivement un en-tête d'encapsulation à rajouter/déduire ?

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.

Je ne connaissais pas DS-Lite, et donc je me suis un peu renseigné. Cela semble tout à fait cela. Et donc la freebox n'aurait pas d'adresse IPv4 publique, c'est le routeur au bout du tunnel qui ferait la passerelle vers IPv4. L'article wikipedia en anglais me semble assez clair, et surtout le schéma qui l'accompagne :

https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual-Stack_Lite_.28DS-Lite.29

Sauf que la partie

The original IPv4 packet is recovered and NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.

est fausse : pas de CGN, pas de "recording", même pas de NAT.

Un article du blog de Stéphane Bortzmeyer à propos de DS-Lite :

http://www.bortzmeyer.org/6333.html

Voilà :

L'AFTR doit donc faire attention à empêcher les utilisateurs de monter une DoS (volontairement ou par accident) en s'attribuant tous les ports possibles. Par exemple, l'AFTR peut limiter le rythme d'allocation des ports, ou bien mettre une limite absolue au nombre de ports qu'un B4 peut s'allouer.

C'est inapplicable.

Donc Free ne fait pas vraiment du DS-Lite.