Vsftpd avec iptables

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
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) :

[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.

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.

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=“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.

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 “ports=21,2121” sur ton serveur, mais tu ne peux pas forcer tous tes clients à le faire aussi.

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

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.

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.

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

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

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=“PascalHambourg”]

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 “actif” en locale, cela fonctionne. Est-ce correcte niveau méthode ?

[quote=“Chucky2401”]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.

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=“PascalHambourg”][quote=“Chucky2401”]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.

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 :confused:
Je sens que je vais de nouveau m’amuser comme un fou :angry: .

Encore merci !
Bonne soirée,
Cordialement.