VSFTPD+SSL problème uniquement avec client ftp sous windows

Bonsoir,

Je rencontre un problème assez étrange pour moi… J’ai installé vsftpd sur une Debian 4.0 de base. J’utilise ce serveur aussi bien en local que vers internet. Ce serveur est situé derrière un routeur grand public netgear avec les port 21 et 40000 à 40100 d’ouvert (expliquation plus loin pour ce range) redirigé vers l’adresse ip du serveur.

J’utilise Filezilla sous linux et sous windows en version 2.

Si je n’active pas le SSL, j’arrive a me connecter

-> sous Windows en local et par le web (via une connexion adsl externe pas en loopback)
->Linux (ubuntu 7.04) en local et par le web

SI j’active le ssl et que je règle filezilla sur

  • FTP SSL explicite et force le mode passif dans les paramètres, la donne change:

-> sous linux: connexion possible en local et par le web
-> sous windows impossible dans tous les cas. Il ne me propose meme pas d’accepter le certificat ssl.

Avec coreftp meme probleme sous windows

Voici mon fichier de conf:

Mode “standalone”:

listen=YES

Accès pour utilisateurs locaux en écritures et “chrooter”:

local_enable=YES
write_enable=YES
chroot_local_user=YES

Connexions anonymes désactivées:

anonymous_enable=NO
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO

On défini le nombre maximum de sessions à 5(les nouveaux clients recevront

un message du genre: “erreur: serveur occupé”).

On défini le nombre maximum de sessions par IP à 2

max_clients=25
max_per_ip=5

#Log FTP protocol
log_ftp_protocol=YES
ftpd_banner=Bienvenue à la maison :slightly_smiling:

####################################

Debian customization

(ou adoptons la debian attitude)

####################################

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

default. These settings are more Debian-friendly.

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

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/certs/vsftpd.pem

#Activation du SSL et des versions prises en compte
ssl_enable=YES
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES

#Interdit l’utilisation de ssl aux anonymes
allow_anon_ssl=NO

#Force les comptes locaux à s’authentifier et utiliser SSL lors des des transferts:
force_local_data_ssl=NO
force_local_logins_ssl=YES

#Accès depuis internet:
pasv_promiscuous=YES
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
pasv_address=XXXXXXXXX
port_promiscuous=YES

Merci de votre aide car je ne vois pas ce qui cloche vu que ça marche nickel sous linux en mode ftp-ssl ou avec filezilla et pas moyen sous windows sauf si je désactive ssl .
Cdlt

Pourquoi as tu activé ces options ? Cela ne me semble pas logique dans un optique de sécurité.

Pour ton problème, il faudrait centrer un peu pour savoir si cela vient du control channel (ensemble des commandes sur le port 21) ou si c’est l’établissement du data channel (ports passifs) qui coince.

as-tu essayé de ne pas forcer les ports et de charger le module ip_conntrack_ftp ?

Bonjoru merci pour vos réponses:

j’ai commenté ces deux lignes pasv_promiscuous=YES
port_promiscuous=YES mais ça ne donne rien de plus avec les clients windows.

ip_conntrack_ftp est un module iptables mais je ne l’ai pas installé donc je reste sur mon problème de connexion de client ftp WINDOWS, les linux fonctionnent.

Cdlt

Pourquoi ? J’ai jamais dit que cela allait changer quelque chose. J’ai simplement mentionné que cela allait à l’encontre de la sécurité.

man vsftp

On en déduira donc, que toutes les requêtes entrantes et sortantes de ton serveur ne subissent aucun filtrage !

On ne sait toujours pas où cela coince ? Un petit indice ? Cela ne fait même pas l’authentification, cela ne liste pas les répertoires ? Tu as sûrement un message d’erreur côté client, voir peut-être des logs côté serveur ?