FTP se cuelga: 150 Abrir la conexión de datos en modo ASCII

Estoy configurando un servidor FTP en mi servidor Windows 2008 (R2).

Todo parece estar instalado correctamente, pero tengo problemas para usar un Cliente FTP para iniciar sesión en mi servidor FTP.

Puedo usar el escritorio remoto en el servidor y, a través de comandos de DOS, puedo iniciar sesión con bastante facilidad.

Pero si publico un comando como "DIR", se cuelga con: 150 Abrir la conexión de datos en modo ASCII.

Todo lo que he investigado y leído apunta a puertos de Firewall y / o configuraciones de modo Pasivo / Activo.

Esto es lo que me molesta ... si uso comandos FTP de DOS, puedo iniciar sesión y usar el comando "DIR" solo si uso "localhost" como mi dirección.

Si especifico mi URL FTP completa, aparece el error de bloqueo.

si especifico la URL "localhost", no obtengo el error.

Esto me lleva a creer que es un problema de Firewall (¿o incluso un problema de IIS7?) Pero no estoy seguro de qué puertos necesito abrir.

Tengo los puertos 20, 21 abiertos en mi firewall de Windows. También he abierto esos puertos en mi firewall AWS (Amazon).

Creo que mi cliente FTP está utilizando algunos números de puerto de largo alcance que están potencialmente bloqueados por uno de mis dos firewalls. He usado herramientas de Monitoreo de red para tratar de ver qué puertos está llamando, pero no puedo entenderlo.

¿Alguna idea, consejos, trucos, ayuda?

El servidor FTP y el cliente FTP negocian qué puertos se utilizarán para la transferencia de datos (incluida la lista de directorios cuando se hace un "dir" o "ls") utilizando el "canal de control" de FTP. Entonces, si su "firewall de AWS" no está haciendo una inspección de protocolo en este canal, no hay forma de que sepa qué puertos tiene que abrir dinámicamente para permitir el flujo de tráfico (y cerrar una vez que esos puertos ya no se usen).

En mi humilde opinión, usar la supervisión de la red para descubrir qué puertos se están utilizando no vale la pena porque estos puertos van a cambiar para cada nueva sesión FTP.

A menos que ya lo haya hecho, mi mejor opción para solucionar este problema sería buscar cualquier ajuste en el firewall que protege su servidor FTP (si entiendo su pregunta correctamente, este sería el "firewall de AWS") y ver si hay es cualquier "perilla" para permitir la inspección del protocolo FTP.

Recibí el mismo mensaje cuando intenté usar el lscomando para enumerar los archivos almacenados en un servidor host UNIX FTP desde mi línea de comandos de Ubuntu. Pude iniciar sesión con éxito usando ftp ftp.example.come ingresando mi nombre de usuario y contraseña cuando se me solicitó. Sin embargo, recibiría el 150 Opening ASCII mode data connectionmensaje y nunca sucedió nada. Luego, simplemente ingresé la opción -p(la cambia al modo "pasivo" para manejar los firewalls) con el comando y funcionó.

 ftp -p ftp.example.com

Ingrese el nombre de usuario y la contraseña cuando se le solicite, luego comandos como lsy cdfuncionarán. Creo que también puede ingresar este comando y hará lo mismo, pero no lo he probado.

pftp ftp.example.com

Sé que la pregunta pertenece a Windows; sin embargo, dado que se produjo el mismo error, pensé que valía la pena publicar este consejo.

Para obtener información real sobre por qué la conexión está atascada, tendrá que usar un cliente que registre todos los comandos de protocolo para ver qué está sucediendo realmente. Hay un buen sitio en FTP con ejemplos de registros aquí .

Sin embargo, lo más probable es que

1. su cliente está detrás de un firewall (tonto o bloqueado por SSL) e intenta utilizar FTP en modo activo
2. su servidor está detrás de un cortafuegos (tonto o bloqueado por SSL) e intenta utilizar FTP en modo pasivo

Si está utilizando SSL, la única respuesta es abrir un rango de puertos (por ejemplo, 10000-11000) en el firewall y configurar su servidor FTP para forzar el modo Pasivo y usar ese rango de puertos. Si su servidor está utilizando NAT, también deberá configurar la dirección IP adecuada para que el servidor se anuncie a los clientes, la mayoría obedecerá lo que el servidor proporcione como la cadena de conexión de modo pasivo y si el servidor piensa que es 10.1.1.1, eso es lo que le dirá a los clientes.

Si no está utilizando SSL, la mejor respuesta es ver si puede hacer que su firewall haga una inspección de protocolo para FTP. El firewall leerá el tráfico en el puerto 21 y abrirá cualquier puerto que su servidor quiera abrir. Esto a menudo también puede corregir las direcciones NAT (cuando el firewall también maneja el NAT). Probablemente aún desee forzar el modo pasivo ya que algunas personas no saben cómo configurar su cliente FTP correctamente y casi todos están detrás de un enrutador / firewall de banda ancha en estos días.

Si no puede obtener un cortafuegos más inteligente, tendrá que apegarse a la opción "abrir un montón de puertos" (o cambiar a un protocolo que no necesite abrir un montón de puertos aleatorios como sshp de ssh).

Tuve este problema y se resolvió haciendo lo siguiente.

Estaba usando FireFTP que por defecto se conecta a través del modo pasivo. Al configurar un FTP en IIS, el puerto predeterminado será 21. Tuve que abrir el puerto 21 en el firewall, lo que me llevó a una etapa más avanzada, pero se bloqueó al abrir la conexión de datos en modo ASCII .

Resulta que luego selecciona algunos otros puertos dinámicos. Sabía que era un problema de firewall ya que con el firewall apagado el FTP se conecta bien. También localmente en el servidor, sin problemas.

Para solucionarlo, cargué IIS (usando la versión 8.0, creo que es lo mismo en 7.5), en el nivel del servidor del árbol (que es el nodo superior) solo haga clic y seleccione "Soporte de firewall FTP". Cada sitio FTP que use usará estos rangos de puertos, los sitios FTP individuales tendrán esta opción atenuada ya que se hereda de esta sección.

En Data Channel Port Range, especifique x cantidad de puertos, en mi caso 10000-10125 .

Ahora, en su firewall abra ese rango de puertos TCP como "rango de puertos pasivos FTP".

Entonces pensé que el problema se resolvería, pero no del todo. Asegúrese de reiniciar el servicio del servicio FTP de Microsoft para recoger el nuevo rango de puertos. Cierre FireFTP / client y vuelva a intentarlo y esta vez con suerte estará en. :)

Tengo el mismo problema contigo y lo solucioné ahora.

Lo que hice fue abrir el Firewall de Windows (Win7), hacer clic en 'Permitir un programa o función a través del Firewall de Windows', y luego en la lista 'Programas y características permitidos', encontrar 'Programa de transferencia de archivos' y marcar la casilla.

Una vez hecho esto, abra el símbolo del sistema e ingrese ftp XXXX, inicie sesión y luego ls / dir / get / put, todo funciona ahora.

Pero todavía no pude conectarme desde File Zilla y Web Browser, espero que sea útil para usted.

Verifique la sincronización horaria de su servidor

No ensucies nada en tu configuración

Simplemente agregue la regla de salida en el Firewall de Windows con seguridad avanzada y coloque el puerto no 20.

Disfruta de FTP en CLI

El problema para mí estaba en la PC local, no en el host remoto. Confirmé que la instalación del servicio FTP en el host remoto ya había abierto correctamente todos los puertos en el servidor de seguridad del servidor que necesitaba, por lo que ese no era el problema. Era mi PC cliente local que no estaba jugando. Entonces,

1. Abrí el Firewall de Windows Defender.
2. Luego hice clic en el enlace de la izquierda, "Permitir una aplicación o función a través del Firewall de Windows Defender":

3. Me desplacé hacia abajo al Programa de transferencia de archivos y marqué las casillas de Dominio, Privado y Público:

¡Esto finalmente me arregló esto! Cuando fui a reintentar un comando LS, la respuesta fue instantánea y no hubo más interrupciones.

Resolvimos este problema usando el Asistente de nueva regla de entrada del Firewall de Windows Seleccione Programa, luego C: \ Windows \ System32 \ ftp.exe, Permitir la conexión, Verificar opciones; Dominio, Privado, Público (puede restringirlo más tarde si es necesario), nombre la regla y listo.

Ahora ftp a un sitio ftp y verifique que dir o ls respondan correctamente.

He encontrado el mismo problema que el OP

Comando 200 PORT exitoso.
150 Apertura de la conexión de datos en modo ASCII.
425 No se puede abrir la conexión de datos.

Encontré el problema anterior cuando intenté usar el modo pasivo en la línea de comandos en Windows.
Encontré la información que buscaba buscando en los materiales:

IE generalmente usa el modo pasivo, mientras que la utilidad de línea de comando (comando ftp) siempre usa el modo activo.

Intenté mi operación anterior en IE y funcionó. Problema resuelto

enlace de materiales: https://forums.iis.net/t/1207342.aspx?150+Opening+ASCII+mode+data+connection+for+file+list+425+Can+t+open+data+connection+