# Vsftpd avec iptables

**URL:** <https://www.debian-fr.org/t/vsftpd-avec-iptables/59068>\
**Category:** Support Debian\
**Created:** [Février 21, 2016, 6:08 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068 "2016-02-21T18:08:50Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chucky2401](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/ecd19e/32.png) [@Chucky2401](https://www.debian-fr.org/u/Chucky2401)\
**Post date:** [Février 21, 2016, 6:08 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/1 "2016-02-21T18:08:50Z")

</div>

Bonjour à tous !

J’ai utilisé mon vieux PC portable pour réaliser un serveur Debian, d’une part pour pratiquer et pour une utilisation perso avec mes amis, etc.  
Au départ, j’avais cette machine sous un Virtualbox, mais j’ai tout refais sur cette machine physique, avec des améliorations.

L’une de ces “améliorations” est l’ajout des règles IPTables. J’ai suivis le tuto suivant : [lafermeduweb.net/billet/tuto … .html#secu](http://www.lafermeduweb.net/billet/tutorial-creer-un-serveur-web-complet-sous-debian-5-backup-securite-197.html#secu)  
Certes un peu vieillot, mais je trouve intéressant la manière de faire.

Mais voilà, après de longues heures de recherches, de modification de mon script dans tous les sens, en essayant de comprendre pourquoi, comment, je n’arrives toujours pas à faire fonctionner IPTables pour autoriser le FTP.  
Je n’arrive plus du tout à accéder en FTP, mais tout le reste fonctionne.

Tout d’abord voici ma config de VSFTPD :

[code]# Example config file /etc/vsftpd.conf

# 

# The default compiled in settings are fairly paranoid. This sample file

# loosens things up a bit, to make the ftp daemon more usable.

# Please see vsftpd.conf.5 for all compiled in defaults.

# 

# READ THIS: This example file is NOT an exhaustive list of vsftpd options.

# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd’s

# capabilities.

# 

# 

# Run standalone? vsftpd can run either from an inetd or as a standalone

# daemon started from an initscript.

listen=YES

# 

# Run standalone with IPv6?

# Like the listen parameter, except vsftpd will listen on an IPv6 socket

# instead of an IPv4 one. This parameter and the listen parameter are mutually

# exclusive.

#listen\_ipv6=YES

# 

# Allow anonymous FTP? (Beware - allowed by default if you comment this out).

anonymous\_enable=NO

# 

# Uncomment this to allow local users to log in.

local\_enable=YES

# 

# Uncomment this to enable any form of FTP write command.

write\_enable=YES

# 

# Default umask for local users is 077. You may wish to change this to 022,

# if your users expect that (022 is used by most other ftpd’s)

local\_umask=022

# 

# Uncomment this to allow the anonymous FTP user to upload files. This only

# has an effect if the above global write enable is activated. Also, you will

# obviously need to create a directory writable by the FTP user.

#anon\_upload\_enable=YES

# 

# Uncomment this if you want the anonymous FTP user to be able to create

# new directories.

#anon\_mkdir\_write\_enable=YES

# 

# Activate directory messages - messages given to remote users when they

# go into a certain directory.

dirmessage\_enable=YES

# 

# If enabled, vsftpd will display directory listings with the time

# in your local time zone. The default is to display GMT. The

# times returned by the MDTM FTP command are also affected by this

# option.

use\_localtime=YES

# 

# Activate logging of uploads/downloads.

xferlog\_enable=YES

# 

# Make sure PORT transfer connections originate from port 20 (ftp-data).

connect\_from\_port\_20=YES

# 

# If you want, you can arrange for uploaded anonymous files to be owned by

# a different user. Note! Using “root” for uploaded files is not

# recommended!

#chown\_uploads=YES  
#chown\_username=whoever

# 

# You may override where the log file goes if you like. The default is shown

# below.

#xferlog\_file=/var/log/vsftpd.log

# 

# If you want, you can have your log file in standard ftpd xferlog format.

# Note that the default log file location is /var/log/xferlog in this case.

#xferlog\_std\_format=YES

# 

# You may change the default value for timing out an idle session.

#idle\_session\_timeout=600

# 

# You may change the default value for timing out a data connection.

#data\_connection\_timeout=120

# 

# It is recommended that you define on your system a unique user which the

# ftp server can use as a totally isolated and unprivileged user.

#nopriv\_user=ftpsecure

# 

# Enable this and the server will recognise asynchronous ABOR requests. Not

# recommended for security (the code is non-trivial). Not enabling it,

# however, may confuse older FTP clients.

#async\_abor\_enable=YES

# 

# By default the server will pretend to allow ASCII mode but in fact ignore

# the request. Turn on the below options to have the server actually do ASCII

# mangling on files when in ASCII mode.

# Beware that on some FTP servers, ASCII support allows a denial of service

# attack (DoS) via the command “SIZE /big/file” in ASCII mode. vsftpd

# predicted this attack and has always been safe, reporting the size of the

# raw file.

# ASCII mangling is a horrible feature of the protocol.

#ascii\_upload\_enable=YES  
#ascii\_download\_enable=YES

# 

# You may fully customise the login banner string:

#ftpd\_banner=Welcome to blah FTP service.

# 

# You may specify a file of disallowed anonymous e-mail addresses. Apparently

# useful for combatting certain DoS attacks.

#deny\_email\_enable=YES

# (default follows)

#banned\_email\_file=/etc/vsftpd.banned\_emails

# 

# You may restrict local users to their home directories. See the FAQ for

# the possible risks in this before using chroot\_local\_user or

# chroot\_list\_enable below.

# chroot\_local\_user=YES

# 

# You may specify an explicit list of local users to chroot() to their home

# directory. If chroot\_local\_user is YES, then this list becomes a list of

# users to NOT chroot().

# (Warning! chroot’ing can be very dangerous. If using chroot, make sure that

# the user does not have write access to the top level directory within the

# chroot)

chroot\_local\_user=NO  
chroot\_list\_enable=YES

# (default follows)

chroot\_list\_file=/etc/vsftpd/vsftpd.chroot\_list

# 

# You may activate the “-R” option to the builtin ls. This is disabled by

# default to avoid remote users being able to cause excessive I/O on large

# sites. However, some broken FTP clients such as “ncftp” and “mirror” assume

# the presence of the “-R” option, so there is a strong case for enabling it.

#ls\_recurse\_enable=YES

# 

# Customization

# 

# Some of vsftpd’s settings don’t fit the filesystem layout by

# default.

# 

# This option should be the name of a directory which is empty. Also, the

# directory should not be writable by the ftp user. This directory is used

# as a secure chroot() jail at times vsftpd does not require filesystem

# access.

secure\_chroot\_dir=/var/run/vsftpd/empty

# 

# This string is the name of the PAM service vsftpd will use.

pam\_service\_name=vsftpd

# 

# This option specifies the location of the RSA certificate to use for SSL

# encrypted connections.

rsa\_cert\_file=/etc/ssl/private/vsftpd.pem

## Ajout utilisateur

# Message d’accueil

ftpd\_banner=Bienvenue sur mon serveur FTP

# Port

listen\_port=2121

# Monitoring

setproctitle\_enable=YES

# Users virtuels

guest\_enable=YES  
guest\_username=www-data  
user\_config\_dir=/etc/vsftpd/vsftpd\_user\_conf/  
local\_root=/var/www

# Correction bug write chroot

allow\_writeable\_chroot=YES

# Mode Passif

pasv\_enable=YES  
pasv\_promiscuous=NO  
pasv\_addr\_resolve=YES  
pasv\_address=DOMAINE\_NOIP  
port\_promiscuous=NO  
pasv\_min\_port=40000  
pasv\_max\_port=40100[/code]

Mon fichier pour Iptables ([firewall.sh](http://firewall.sh)) :

[code]#!/bin/bash  
echo Setting firewall rules…

# 

# 

###### Debut Initialisation

# Interdire toute connexion entrante

iptables -t filter -P INPUT DROP  
iptables -t filter -P FORWARD DROP  
echo - Interdire toute connexion entrante : [OK]

# Interdire toute connexion sortante

iptables -t filter -P OUTPUT DROP  
echo - Interdire toute connexion sortante : [OK]

# Vider les tables actuelles

iptables -t filter -F  
iptables -t filter -X  
echo - Vidage : [OK]

#Ne pass casser les connexions etablies  
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  
echo - Ne pas casser les connexions établies : [OK]

# Autoriser la Supervision du serveur (SNMP)

iptables -t filter -A INPUT -p tcp --dport 161 -s 192.168.1.12/32 -j ACCEPT  
iptables -t filter -A INPUT -p udp --dport 161 -s 192.168.1.12/32 -j ACCEPT  
echo - Autoriser Supervision : [OK]

# Autoriser les requetes DNS, FTP, HTTP, NTP

iptables -t filter -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT  
iptables -t filter -A OUTPUT -p tcp --dport 2121 -m state --state ESTABLISHED,NEW -j ACCEPT  
iptables -t filter -A OUTPUT -p tcp --dport 40000:40100 -m state --state ESTABLISHED,NEW -j ACCEPT  
iptables -t filter -A OUTPUT -p tcp --dport 80 -m state --state ESTABLISHED,NEW -j ACCEPT  
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT  
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT  
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT  
echo - Autoriser les requetes DNS, FTP, HTTP : [OK]

# Autoriser loopback

iptables -t filter -A INPUT -i lo -j ACCEPT  
iptables -t filter -A OUTPUT -o lo -j ACCEPT  
echo - Autoriser loopback : [OK]

# Autoriser ping

iptables -t filter -A INPUT -p icmp -j ACCEPT  
iptables -t filter -A OUTPUT -p icmp -j ACCEPT  
echo - Autoriser ping : [OK]

# HTTP

iptables -t filter -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED,NEW -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT  
echo - Autoriser serveur Apache : [OK]

# FTP

modprobe ip\_conntrack\_ftp  
iptables -t filter -A INPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 2121 -m state --state ESTABLISHED,NEW -j ACCEPT  
iptables -t filter -A INPUT -p tcp --dport 40000:40100 -m state --state ESTABLISHED,NEW -j ACCEPT  
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  
echo - Autoriser serveur FTP : [OK]

# Autoriser SSH

iptables -t filter -A INPUT -p tcp --dport 666 -m recent --rcheck --seconds 60 --hitcount 2 --name SSH -j LOG --log-prefix "SSH REJECT"  
iptables -t filter -A INPUT -p tcp --dport 666 -m recent --update --seconds 60 --hitcount 2 --name SSH -j DROP  
iptables -t filter -A INPUT -p tcp --dport 666 -m state --state NEW -m recent --set --name SSH -j ACCEPT  
echo - Autoriser SSH : [OK][/code]

Et l’erreur obtenu avec FTP :

`Statut :	Déconnecté du serveur
Statut :	Résolution de l'adresse de chucky2401.zapto.org
Statut :	Connexion à 192.168.1.15:2121...
Statut :	Connexion établie, attente du message d'accueil...
Réponse :	220 Bienvenue sur mon serveur FTP
Commande :	USER chucky
Réponse :	331 Please specify the password.
Commande :	PASS *************
Réponse :	230 Login successful.
Commande :	OPTS UTF8 ON
Réponse :	200 Always in UTF8 mode.
Statut :	Connecté
Statut :	Récupération du contenu du dossier...
Commande :	CWD /
Réponse :	250 Directory successfully changed.
Commande :	TYPE I
Réponse :	200 Switching to Binary mode.
Commande :	PASV
Réponse :	227 Entering Passive Mode (127,0,0,1,156,148).
Commande :	LIST
Erreur :	La connexion des données ne peut pas être établie : ECONNREFUSED - Connection refused by server
Erreur :	Affichage du contenu du dossier annulée par l'utilisateur
Statut :	Déconnecté du serveur`

En vous remerciant par avance pour votre aide.

---

<div class="post-metadata">

**Author:** ![lol](https://www.debian-fr.org/user_avatar/www.debian-fr.org/lol/32/15629_2.png) [@lol](https://www.debian-fr.org/u/lol)\
**Post date:** [Février 21, 2016, 6:08 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/2 "2016-02-21T18:08:52Z")

</div>

Salut,  
Et sans charger le module modprobe ip\_conntrack\_ftp ?  
Il n’est pas activé sur mon serveur et ça fonctionne très bien.

Tu n’as pas de filtrage non plus car tu as RELATED,ESTABLISHED et NEW dans tes règles.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 6:08 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/3 "2016-02-21T18:08:55Z")

</div>

Ce script iptables n’est pas terrible. Mais on s’en occupera plus tard, pour le moment le problème est ailleurs :

`Statut : Connexion à 192.168.1.15:2121...
(...)
Commande : PASV
Réponse : 227 Entering Passive Mode (127,0,0,1,156,148).`  
En clair, le client s’est connecté à 192.168.1.15 et le serveur lui dit de se connecter à l’adresse passive 127.0.0.1 (son adresse de loopback, mais aussi l’adresse de loopback du client). Ça ne va pas. D’après la config du serveur, l’adresse IP passive est obtenue par la résolution du nom d’hôte DOMAINE\_NOIP. Quelle est l’adresse IP correspondante ? A vérifier dans /etc/hosts et par requête DNS.

Juste une remarque : utiliser un port autre que 21 pour du FTP, c’est chercher les ennuis. Vraiment.

---

<div class="post-metadata">

**Author:** ![Chucky2401](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/ecd19e/32.png) [@Chucky2401](https://www.debian-fr.org/u/Chucky2401)\
**Post date:** [Février 21, 2016, 6:10 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/4 "2016-02-21T18:10:53Z")

</div>

[quote=“lol”]Salut,  
Et sans charger le module modprobe ip\_conntrack\_ftp ?  
Il n’est pas activé sur mon serveur et ça fonctionne très bien.

Tu n’as pas de filtrage non plus car tu as RELATED,ESTABLISHED et NEW dans tes règles.[/quote]

Ça ne change rien au problème.

[quote=“PascalHambourg”]Ce script iptables n’est pas terrible. Mais on s’en occupera plus tard, pour le moment le problème est ailleurs :

`Statut : Connexion à 192.168.1.15:2121...
(...)
Commande : PASV
Réponse : 227 Entering Passive Mode (127,0,0,1,156,148).`  
En clair, le client s’est connecté à 192.168.1.15 et le serveur lui dit de se connecter à l’adresse passive 127.0.0.1 (son adresse de loopback, mais aussi l’adresse de loopback du client). Ça ne va pas. D’après la config du serveur, l’adresse IP passive est obtenue par la résolution du nom d’hôte DOMAINE\_NOIP. Quelle est l’adresse IP correspondante ? A vérifier dans /etc/hosts et par requête DNS.

Juste une remarque : utiliser un port autre que 21 pour du FTP, c’est chercher les ennuis. Vraiment.[/quote]

Je connais pas IPtables, mais je veux bien comprendre.  
L’adresse IP correspondante au DOMAINE\_NOIP c’est l’adresse externe, mais comme je suis en local pour le test, faudrait que le FTP retourne l’adresse IP locale.  
Pourquoi utiliser un autre port que le 21 serait chercher les ennuis ? Je veux bien une explication, je pensais que cela pouvait sécurisé encore mieux, comme pour le ssh.

EDIT : J’ai tenté en commentant les deux lignes sur l’adresse passive, et cela est retourné correctement en locale, j’essaierais de faire un test de chez quelqu’un d’autre pour voir.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 6:11 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/5 "2016-02-21T18:11:00Z")

</div>

> [@lol](#):
>
> Et sans charger le module modprobe ip\_conntrack\_ftp ?

Pour le moment dans cette configuration le module nf\_conntrack\_ftp (ip\_conntrack\_\* sont des alias maintenant) est sans effet car par défaut il ne surveille que le port 21. Une des raisons qui me font déconseiller l’usage d’un autre port : tu peux forcer le module à surveiller aussi un autre port avec l’option «&nbsp;ports=21,2121&nbsp;» sur ton serveur, mais tu ne peux pas forcer tous tes clients à le faire aussi.

> [@Chucky2401](#):
>
> L’adresse IP correspondante au DOMAINE\_NOIP c’est l’adresse externe

Bizarrement, ça retourne 127.0.0.1 et pas une adresse publique. Sur le serveur,

```auto
ping DOMAINE_NOIP
```

affiche l’adresse publique ou 127.0.0.1 ? Dans le deuxième cas, il n’y aurait pas une définition parasite dans /etc/resolv.conf du serveur ? (Dans le premier cas, je ne comprends). Ou bien c’est le client qui modifie l’adresse passive qu’il reçoit, mais ça me semble improbable qu’il la remplace par 127.0.0.1.

> [@Chucky2401](#):
>
> Pourquoi utiliser un autre port que le 21 serait chercher les ennuis ?

Parce que FTP est un protocole compliqué, mettant en oeuvre des connexions temporaires entre des paires de ports dynamiques, et difficile à faire passer à travers les pare-feux et dispositifs NAT. Les pare-feux s’en sortent en surveillant le dialogue sur la connexion de commande entre le serveur et le client pour découvrir les ports et adresses à autoriser à la volée. C’est la fonction du module nf\_conntrack\_ftp. Quand en plus il y a un dispositif NAT entre le serveur et le client, dans certains cas le NAT doit aussi rediriger les connexions dynamiques et modifier l’adresse passive ou active transmise. Dans netfilter c’est la fonction du module nf\_nat\_ftp.  
Mais par défaut les NAT et pare-feux à état ne surveillent que le port 21. Si on utilise un autre port ou du chiffrement pour la connexion de commande, les pare-feux et NAT deviennent aveugles et on doit tout ouvrir/rediriger/modifier à la main.

---

<div class="post-metadata">

**Author:** ![Chucky2401](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/ecd19e/32.png) [@Chucky2401](https://www.debian-fr.org/u/Chucky2401)\
**Post date:** [Février 21, 2016, 6:11 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/6 "2016-02-21T18:11:06Z")

</div>

> [@PascalHambourg](#):
>
> [quote=«&nbsp;Chucky2401&nbsp;»]L’adresse IP correspondante au DOMAINE\_NOIP c’est l’adresse externe

Bizarrement, ça retourne 127.0.0.1 et pas une adresse publique. Sur le serveur,

```auto
ping DOMAINE_NOIP
```

affiche l’adresse publique ou 127.0.0.1 ? Dans le deuxième cas, il n’y aurait pas une définition parasite dans /etc/resolv.conf du serveur ? (Dans le premier cas, je ne comprends). Ou bien c’est le client qui modifie l’adresse passive qu’il reçoit, mais ça me semble improbable qu’il la remplace par 127.0.0.1.[/quote]  
Alors, je retourne bien l’adresse IP Publique.  
J’ai vu que j’avais dans mon /etc/hosts

```auto
127.0.0.1 DOMAINE_NOIP
```

Je l’ai enlevé et maintenant dans les logs j’ai bien l’adresse IP publique pour le mode passif.  
Or, en local cela ne fonctionne pas. Peut-être avec une redirection sur ma box ?

[quote=«&nbsp;PascalHambourg&nbsp;»]

> [@Chucky2401](#):
>
> Pourquoi utiliser un autre port que le 21 serait chercher les ennuis ?

Parce que FTP est un protocole compliqué, mettant en oeuvre des connexions temporaires entre des paires de ports dynamiques, et difficile à faire passer à travers les pare-feux et dispositifs NAT. Les pare-feux s’en sortent en surveillant le dialogue sur la connexion de commande entre le serveur et le client pour découvrir les ports et adresses à autoriser à la volée. C’est la fonction du module nf\_conntrack\_ftp. Quand en plus il y a un dispositif NAT entre le serveur et le client, dans certains cas le NAT doit aussi rediriger les connexions dynamiques et modifier l’adresse passive ou active transmise. Dans netfilter c’est la fonction du module nf\_nat\_ftp.  
Mais par défaut les NAT et pare-feux à état ne surveillent que le port 21. Si on utilise un autre port ou du chiffrement pour la connexion de commande, les pare-feux et NAT deviennent aveugles et on doit tout ouvrir/rediriger/modifier à la main.[/quote]

Je comprends, je vais donc revenir à une config plus général en remettant le port 21.

EDIT : J’ai tenté une connexion de type «&nbsp;actif&nbsp;» en locale, cela fonctionne. Est-ce correcte niveau méthode ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 21, 2016, 6:11 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/7 "2016-02-21T18:11:07Z")

</div>

[quote=«&nbsp;Chucky2401&nbsp;»]Je l’ai enlevé et maintenant dans les logs j’ai bien l’adresse IP publique pour le mode passif.  
Or, en local cela ne fonctionne pas. Peut-être avec une redirection sur ma box ?[/quote]  
Donc mon intuition du fichier hosts parasite était bonne.  
Ça ne fonctionne pas en local parce que le serveur dit au client local de se connecter à l’adresse publique qui appartient à la box et pas au serveur. Une redirection de la plage de ports passifs sur la box ne fonctionnera pas forcément car il est plus compliqué de faire des redirections qui marchent depuis le LAN que depuis l’extérieur (problème de routage asymétrique client-box-serveur-client alors que le NAT a besoin de routage symétrique client-box-serveur-box-client). Ça peut marcher avec certaines box, pas d’autres.

Une façon d’éviter ce problème est que pour le mode passif le client envoie la commande passive étendue EPSV au lieu de la commande passive classique PASV. En effet la première ne transmet pas d’adresse mais seulement le port, le client se connectant à la même adresse que la connexion de commande pour le transfert de données. Mais voilà, on ne peut pas forcer tous les clients à le faire.

> [@Chucky2401](#):
>
> J’ai tenté une connexion de type «&nbsp;actif&nbsp;» en locale, cela fonctionne. Est-ce correcte niveau méthode ?

En mode actif l’adresse passive ne joue aucun rôle car c’est le client qui transmet sa propre adresse à laquelle le serveur doit se connecter pour le transfert de données. La méthode est correcte mais comme elle est symétrique du mode passif elle souffre des mêmes problèmes si c’est le client au lieu du serveur qui est derrière un NAT ou un pare-feu qui ne gère pas le FTP sur un port non standard ou qui n’a pas autorisé/redirigé la plage de ports actifs vers le poste client. Dans ce cas les connexions de données ont de grandes chances d’échouer.

De chaque côté, client et serveur, il y a deux façons de procéder pour que le FTP marche. Le client et le serveur peuvent appliquer des méthodes différentes.

1. On exploite la prise en charge du protocole FTP par le pare-feu et/ou NAT. Pour un système avec un noyau Linux, cela signifie charger le module nf\_conntrack\_ftp et nf\_nat\_ftp en spécifiant le port utilisé par le serveur FTP si différent de 21. On a juste besoin d’autoriser/rediriger le port en question. En mode passif le serveur renvoie son adresse locale, et les modules reconnaissent/redirigent automatiquement les connexions de données et remplacent l’adresse passive à la volée au besoin. Idem en mode actif avec l’adresse du client.

2. On n’exploite pas la prise en charge du protocole FTP par le pare-feu et/ou NAT. Peu importe qu’on utilise le port 21 ou un autre. Pour un serveur en mode actif ou un client en mode passif, c’est simple : il suffit d’autoriser les connexions sortantes. Pour le client, c’est un peu plus facile car c’est lui qui choisit le mode actif ou passif, et pour lui le mode passif est plus simple. C’est pourquoi la majorité des clients FTP modernes utilisent le mode passif par défaut. Le serveur n’a pas ce luxe, et pour lui le mode passif est plus compliqué. Mais dans la mesure où il y a un serveur et plusieurs clients, il est normal de concentrer l’effort sur le serveur plutôt que sur les clients.

Pour un serveur en mode passif, il faut autoriser/rediriger la plage de ports passifs, et en mode passif classique (PASV) le serveur doit transmettre l’adresse IP publique du NAT le cas échéant. Comme tu l’as constaté cela pose un problème quand le serveur a des clients dans son réseau local (sans NAT) et à l’extérieur (avec NAT), car dans le premier cas il doit transmettre son adresse privée propre. Je ne sais plus si certains serveurs peuvent faire cette distinction.

Pour un client en mode actif, la situation est symétrique : il faut autoriser/rediriger la plage de ports actifs, et en mode actif le client doit transmettre l’adresse IP publique du NAT le cas échéant. Là encore cela pose un problème quand le client doit se connecter à des serveurs dans son réseau local (sans NAT) et à l’extérieur (avec NAT).

J’espère avoir été assez clair.

---

<div class="post-metadata">

**Author:** ![Chucky2401](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/ecd19e/32.png) [@Chucky2401](https://www.debian-fr.org/u/Chucky2401)\
**Post date:** [Février 21, 2016, 6:11 UTC](https://www.debian-fr.org/t/vsftpd-avec-iptables/59068/8 "2016-02-21T18:11:07Z")

</div>

[quote=«&nbsp;PascalHambourg&nbsp;»][quote=«&nbsp;Chucky2401&nbsp;»]Je l’ai enlevé et maintenant dans les logs j’ai bien l’adresse IP publique pour le mode passif.  
Or, en local cela ne fonctionne pas. Peut-être avec une redirection sur ma box ?[/quote]  
Donc mon intuition du fichier hosts parasite était bonne.  
Ça ne fonctionne pas en local parce que le serveur dit au client local de se connecter à l’adresse publique qui appartient à la box et pas au serveur. Une redirection de la plage de ports passifs sur la box ne fonctionnera pas forcément car il est plus compliqué de faire des redirections qui marchent depuis le LAN que depuis l’extérieur (problème de routage asymétrique client-box-serveur-client alors que le NAT a besoin de routage symétrique client-box-serveur-box-client). Ça peut marcher avec certaines box, pas d’autres.

Une façon d’éviter ce problème est que pour le mode passif le client envoie la commande passive étendue EPSV au lieu de la commande passive classique PASV. En effet la première ne transmet pas d’adresse mais seulement le port, le client se connectant à la même adresse que la connexion de commande pour le transfert de données. Mais voilà, on ne peut pas forcer tous les clients à le faire.

> [@Chucky2401](#):
>
> J’ai tenté une connexion de type «&nbsp;actif&nbsp;» en locale, cela fonctionne. Est-ce correcte niveau méthode ?

En mode actif l’adresse passive ne joue aucun rôle car c’est le client qui transmet sa propre adresse à laquelle le serveur doit se connecter pour le transfert de données. La méthode est correcte mais comme elle est symétrique du mode passif elle souffre des mêmes problèmes si c’est le client au lieu du serveur qui est derrière un NAT ou un pare-feu qui ne gère pas le FTP sur un port non standard ou qui n’a pas autorisé/redirigé la plage de ports actifs vers le poste client. Dans ce cas les connexions de données ont de grandes chances d’échouer.

De chaque côté, client et serveur, il y a deux façons de procéder pour que le FTP marche. Le client et le serveur peuvent appliquer des méthodes différentes.

1. On exploite la prise en charge du protocole FTP par le pare-feu et/ou NAT. Pour un système avec un noyau Linux, cela signifie charger le module nf\_conntrack\_ftp et nf\_nat\_ftp en spécifiant le port utilisé par le serveur FTP si différent de 21. On a juste besoin d’autoriser/rediriger le port en question. En mode passif le serveur renvoie son adresse locale, et les modules reconnaissent/redirigent automatiquement les connexions de données et remplacent l’adresse passive à la volée au besoin. Idem en mode actif avec l’adresse du client.

2. On n’exploite pas la prise en charge du protocole FTP par le pare-feu et/ou NAT. Peu importe qu’on utilise le port 21 ou un autre. Pour un serveur en mode actif ou un client en mode passif, c’est simple : il suffit d’autoriser les connexions sortantes. Pour le client, c’est un peu plus facile car c’est lui qui choisit le mode actif ou passif, et pour lui le mode passif est plus simple. C’est pourquoi la majorité des clients FTP modernes utilisent le mode passif par défaut. Le serveur n’a pas ce luxe, et pour lui le mode passif est plus compliqué. Mais dans la mesure où il y a un serveur et plusieurs clients, il est normal de concentrer l’effort sur le serveur plutôt que sur les clients.

Pour un serveur en mode passif, il faut autoriser/rediriger la plage de ports passifs, et en mode passif classique (PASV) le serveur doit transmettre l’adresse IP publique du NAT le cas échéant. Comme tu l’as constaté cela pose un problème quand le serveur a des clients dans son réseau local (sans NAT) et à l’extérieur (avec NAT), car dans le premier cas il doit transmettre son adresse privée propre. Je ne sais plus si certains serveurs peuvent faire cette distinction.

Pour un client en mode actif, la situation est symétrique : il faut autoriser/rediriger la plage de ports actifs, et en mode actif le client doit transmettre l’adresse IP publique du NAT le cas échéant. Là encore cela pose un problème quand le client doit se connecter à des serveurs dans son réseau local (sans NAT) et à l’extérieur (avec NAT).

J’espère avoir été assez clair.[/quote]

Je te remercie pour toutes ces bonnes informations !  
Pour le côté clair, aucun problème ! Par contre, mon cerveau à du mal à tout gérer d’un coup (surtout après quelques heures de codes).  
Je vais donc enregistrer ton explication, bien au chaud, et quand je serais reposé je la relirais de manière tranquille au calme.

En tout cas, un grand merci pour ton aide, et va falloir que je revois mon script iptables.  
Mais avant ça, faut que je mette en place postfix pour mes codes pour l’envoie de mail en php 😕  
Je sens que je vais de nouveau m’amuser comme un fou 😠 .

Encore merci !  
Bonne soirée,  
Cordialement.