Pour moi le schéma est le suivant. La connexion data est établie dans un cas par le client (le serveur doit avoir les ports ouvert) dans l'autre cas par le serveur (le client doit avoir le port 20 ouvert) :

En mode passif :

Le client établie une connexion de commandes sur le port 21 sur le serveur (le serveur doit avoir le port 21 d'ouvert)
-- Le serveur va envoyer au client l'IP et le port xxx a  contacter pour transférer les données. --
Le client établie une connexion de data vers le serveur sur le port xxx (port xxx à ouvrir coté serveur).

En mode Actif :

Le client établie une connexion de commandes sur le port 21 sur le serveur (le serveur doit avoir le port 21 d'ouvert)
Le serveur établie une connexion de data vers le client sur le port 20 (port 20 à ouvrir coté client).

Pour moi le schéma est le suivant. La connexion data est établie dans un cas par le client (le serveur doit avoir les ports ouvert) dans l'autre cas par le serveur (le client doit avoir le port 20 ouvert) :

En mode passif :

Le client établie une connexion de commandes sur le port 21 sur le serveur (le serveur doit avoir le port 21 d'ouvert)
-- Le serveur va envoyer au client l'IP et le port xxx a  contacter pour transférer les données. --
Le client établie une connexion de data vers le serveur sur le port xxx (port xxx à ouvrir coté serveur).

En mode Actif :

Le client établie une connexion de commandes sur le port 21 sur le serveur (le serveur doit avoir le port 21 d'ouvert)
Le serveur établie une connexion de data vers le client sur le port 20 (port 20 à ouvrir coté client).

Je ne voudrai surtout pas te froisser, Vivien, mais tu es dans le faux pour le ACTIF :
Pour ceux qui lisent l'anglais, la RFC 959 : http://tools.ietf.org/html/rfc959
Maintenant, dans la langue de Molière, et plus facile d'accès côté 'prose' : https://fr.wikipedia.org/wiki/File_Transfer_Protocol
(j'ai tout de même vérifié et relu les deux, surtout la norme en 'anglais' 'originale')

Je ne voudrai surtout pas te froisser, Vivien, mais tu es dans le faux pour le ACTIF :

Effectivement j'avais faux, mauvais souvenirs de mes cours de réseau... En actif c'est bien le serveur qui établie la connexion mais pas vers le port 20 mais depuis le port 20 vers un port décidé par le client. Donc il n'est pas nécessaire d'ouvrir le port 20 sur le serveur en entrant et encore moins sur le client.

Voici ce que dit wikipedia :

• Mode actif: c'est le client FTP qui détermine le port de connexion à utiliser pour permettre le transfert des données. Ainsi, pour que l'échange des données puisse se faire, le serveur FTP initiera la connexion de son port de données (port 20) vers le port spécifié par le client. Le client devra alors configurer son pare-feu pour autoriser les nouvelles connexions entrantes afin que l'échange des données se fasse. Ce mode est donc moins sécurisé que le FTP passif pour le client. De plus il peut s'avérer problématique pour les utilisateurs essayant d'accéder à des serveurs FTP lorsqu'ils sont derrière une passerelle NAT. Vu la façon dont fonctionne le NAT, le serveur FTP initie la connexion de données en se connectant à l'adresse externe de la passerelle NAT sur le port choisi. La passerelle NAT n'ayant pas de correspondance pour le paquet reçu dans sa table d'état le paquet sera ignoré et ne sera pas délivré au client.
  
• Mode passif, le serveur FTP détermine lui-même le port de connexion à utiliser pour permettre le transfert des données (data connexion) et le communique au client. Dans le cas de l'existence d'un pare-feu devant le serveur FTP celui-ci devra être configuré pour autoriser la connexion de données. L'avantage de ce mode, est que le serveur FTP n'initie aucune connexion. Dans le cas des clients FTP sur un réseau local, ce mode est beaucoup plus sécurisé que le FTP en mode actif, car le pare-feu ne devra laisser passer que les flux sortant vers internet pour permettre aux clients d'échanger des données avec le serveur. Il fonctionne donc sans problèmes avec une passerelle NAT.
  

Un test vers ce serveurs par un abonné Neuf FTTH est un bon moyen effectivement de mieux cerner le problème.

Feyb64, tu ne pense pas qu'en cas d'echec a ce test, il faudrait le refaire en ouvrant de grande plage de ports (par exemple les ports 1024 à 65500 TCP ouverts vers le PC client FTP pour tenter de laisser passer la connexion ?)

Oui, le test ACTIF vers download.nvidia.com par exemple sans toucher la 9box, permettra d'être sûr que c'est elle ou pas le pb.

Certe, en ouvrant un max de ports, il y a plus de chances que ça passe, mais le test ci-dessus SANS AUCUNE REDIRECTION sera le seul à dire 'pb 9box ou pas' même si pas 'Médiafibre' de l'autre côté.
Si ce test ACTIF download.nvidia.com est ok, alors on peut tester vers serveur Médiafibre en ouvrant effectivement un max de port, histoire que la box soit totalement 'blanchie' (mais attention, test uniquement 'temporairement' et court car risques importants, et bien programmer le soft firewall pour n'autoriser ces ports en entrée que POUR le soft client FTP lorqu'il est effectivement lancé)

Donc :
1 : Tester vers download.nvidia.com par les Abos NeufFTTH PBC en FTP ACTIF

2 : si 1 OK, pas la 9box en cause, comme au moins deux abos NeufFTTH n'ont pas réussi vers Mediafibre, BLOCAGE NEUF entre NeufFTTH (au moins PBC) Client FTP ACTIF vers serveur FTP ACTIF sur Mediafibre. FIN des Tests
Toutefois, SI JAMAIS au moins UN abo NeufFTTH est arrivé à faire du FTP ACTIF avec le serveur côté Mediafibre ALORS BUG 9Box sur certaines (version ? ou suivant modif de config par abonné lui même ? ou par différence de réglages envoyés par Neuf ? ... Le test est à refaire alors 9Box ré-initialisée aux valeurs USINE pour confirmer que c'est pas les modifs abo de sa config qui plante la 9box en FTP ACTIF)

3 : si 1 PAS OK, alors refaire même test qu'en 1 en ouvrant préalablement un max de ports TCP (1024 à 65535) sur la 9box côté Client

4 : si 3 OK, alors PB 'proxy FTP' sur la 9box :
 a -  La 9box n'a tout simplement n'a pas de module 'proxy FTP ACTIF' (étonnant pour une box 'récente' ! des vendues actuellement box ou routeurs ce serait bien la première à être restée à l'age de pierre sur cette fonctionnalité) ALORS seule possibilité, faire du FTP PASSIF avec les 9box côté client
 b - La 9box a bien un 'proxy FTP ACTIF', ALORS bug de celui ci (raisons possibles identiques à celles évoquées pour haut en 1)

5 : si 3 PAS OK, alors définitivement un BLOCAGE NEUF entre un Client NeufFTTH (au moins PBC) FTP ACTIF quelque soit la destination. Fin des tests

3 : si 1 PAS OK, alors refaire même test qu'en 1 en ouvrant préalablement un max de ports TCP (1024 à 65535) sur la 9box côté Client

220 NET Disk FTP Server ready.

USER test64000

331 User name okay, need password.

PASS *
230 User logged in, proceed.

PWD

257 "/" is current directory.

TYPE A

200 Type set to A.

PORT 192,168,1,20,177,46

200 Command okay.

LIST -aL

150 File status okay; about to open data connection.

226 Closing data connection.

Je te confirme que c'est toujours NOK 
Si c'était bon je l'aurais marqué mais comme ce n'est pas le cas