IBM Support

Windows FTP Passive Mode Not Using Upper-Range Ports

Troubleshooting


Problem

By default, the control connection uses TCP port 21; however, modern FTP setups often avoid port lower range ports, especially in passive mode, where the server selects a dynamic port for data transfers. Passive data connections, rather than the higher default ephemeral range (e.g., 49152–65535 as recommended by IANA for dynamic ports). Use of lower range ports (below 1024 is generally not recommended as they are privileged and require root/admin access) requires careful configuration to avoid conflicts with other services or applications.

Symptom

When the FTP server fails to utilize the configured upper-range ports (e.g., 49152–65535 or a custom high range like 50000–51000) for passive data connections, clients experience connectivity issues. Common symptoms include:

  • Failed Directory Listings or File Transfers: Clients can connect to the FTP control port (21) but fail to list directories or transfer files, resulting in errors like "425 Can't open data connection," "Failed to retrieve directory listing," or "Connection timed out."
  • Intermittent or No Data Connection: Active mode may work (if enabled), but passive mode consistently fails, especially for larger files or directory listings.
  • Client-Side Errors: In FTP clients like FileZilla or WinSCP, logs show the server responding with a PASV command that specifies a low or unexpected port (e.g., ephemeral ports below 49152) instead of the high range.
  • Port Binding Issues: Server logs indicate successful control connections but no data ports opening in the expected range, leading to "port unavailable" or "bind failed" messages.
  • Network Timeouts: External clients behind NAT/firewalls experience hangs during data operations, as the client can't reach the server's announced data port.
  • No Impact on Control Channel: Basic FTP commands (e.g., login, basic navigation) work, but data-intensive operations (LIST, RETR, STOR) fail.

These symptoms often worsen under load, with multiple concurrent users, or when connecting from external networks.

Cause

The issue typically stems from configuration mismatches, security restrictions, or system defaults overriding the intended passive port range. Here's a breakdown:

Misconfigured Passive Port Range:
  • The FTP server (e.g., IIS or FileZilla) has the range set incorrectly (e.g., to 0-0 or a low range) or not applied, causing fallback to Windows' default ephemeral ports (which may not be upper-range).
  • Service not restarted after configuration changes.
Firewall or Security Software Blocking:
  • Windows Firewall, third-party antivirus (e.g., Norton, McAfee), or endpoint protection lacks rules for the high port range, blocking data connections.
  • Group Policy or security policies restrict high-port binding.
NAT/Router Configuration Mismatch:
  • Router/firewall doesn't forward the upper-range ports to the server.
  • Server announces internal IP/port in PASV response instead of public IP, or the port in the response isn't in the configured range.
Port Conflicts or Exhaustion:
  • Other services (e.g., databases, apps) occupy the upper ports, preventing FTP binding.
  • System ephemeral port range overlaps with the FTP passive range, causing Windows to allocate ports outside the upper range.
Windows System Defaults:
  • Default dynamic port range (netsh settings) is not aligned, or IPv6 vs. IPv4 mismatches.
  • Outdated Windows/IIS versions with bugs in passive mode handling.
Client-Side Issues (Less Common):
  • Client not set to passive mode, or incompatible with EPSV (extended passive).
  • Network policies on the client side blocking outbound high ports.

Environment

All versions of Windows server and clients.

Diagnosing The Problem

Diagnosis involves verifying configurations, monitoring ports, and testing connectivity. Follow these steps systematically:

  • In IIS Manager, check FTP Firewall Support for the port range and external IP. Review logs at C:\inetpub\logs\LogFiles\FTPSVC* for errors like "data channel failed" or incorrect PASV responses.
  • Use Command Prompt (Admin): netstat -ano | findstr "LISTENING" | findstr ":<start_port>" (e.g., :50000) to see if FTP process (PID from Task Manager) binds to upper ports.
  • Tool: Resource Monitor (resmon.exe) > Network tab > Listening Ports filter for FTP executable.
  • If no bindings in the range during a passive connection attempt, check for conflicts with netstat -ano | findstr LISTENING.
  • Connect via FTP client in passive mode and attempt a directory list. Note exact error.
  • Command-Line Test: ftp <server_ip>, login, then quote PASV to see the announced IP/port. Verify it's in the upper range and reachable via telnet <server_ip> <announced_port>.
  • Wireshark: Capture on server NIC, filter ftp or tcp.port >=50000, look for PASV response and failed SYN packets to data ports.
  • Check router logs/port forwarding for drops on upper ports.
  • If internal tests work but external fail, verify external IP in PASV (use quote EPSV for IPv6).
  • Event Viewer: Windows Logs > Application/System for FTP service errors (Event ID related to MSFTPSVC).
  • ProcMon (Sysinternals): Filter for FTP process to trace port binds/file accesses.
  • If multi-user: Monitor with netstat -an | findstr TIME_WAIT for port exhaustion.

Resolving The Problem

1. Verify FTP Passive Mode Configuration

Passive mode requires the FTP server to specify a range of ports for data connections. Ensure the port range is correctly configured.

For IIS FTP Server:

  • Check Passive Port Range:
    • Open IIS Manager.
    • Navigate to the FTP site > FTP Firewall Support.
    • Under Data Channel Port Range, ensure a range is specified (e.g., 49152-65535).
    • If set to 0-0 or blank, IIS uses the default Windows ephemeral port range, which may conflict with other services.
    • Set a specific range (e.g., 50000-51000) and restart the FTP service.
  • Restart the FTP Service:
    • Open a Command Prompt as Administrator and run:

net stop msftpsvc

net start msftpsvc

  • Verify External IP:
    • In FTP Firewall Support, ensure the External IP Address of Firewall is set to the public IP or NAT address clients use to connect.
  • For FileZilla Server or Other FTP Servers:
    • Open the server’s configuration settings.
    • Locate the passive mode settings and confirm the port range (e.g., 50000-51000).
    • Ensure Use custom port range is enabled and matches the desired high port range.
    • Save changes and restart the server.

2. Check Windows Firewall Settings

The Windows Firewall or other security software may block the specified passive port range.

  • Open Windows Firewall:
    • Go to Control Panel > System and Security > Windows Defender Firewall > Advanced Settings.
  • Create Inbound Rule for Passive Ports:
    • Right-click Inbound Rules > New Rule.
    • Select Port > TCP > Specific local ports (e.g., 50000-51000).
    • Allow the connection and apply the rule to all profiles (Domain, Private, Public).
    • Name the rule (e.g., “FTP Passive Ports”).
  • Verify FTP Service Rules:
    • Ensure rules exist allowing TCP port 21 (FTP control) and the passive port range for the FTP service executable (e.g., ftpsvc.exe for IIS).
  • Test Firewall Configuration:
    • Temporarily disable the firewall to test if it’s the issue:

netsh advfirewall set allprofiles state off

(If it works, re-enable the firewall and adjust rules:)

netsh advfirewall set allprofiles state on

 3. Check Network and NAT Configuration

If the FTP server is behind a NAT router or firewall, the passive port range must be forwarded correctly.

  • Verify Router/Firewall Port Forwarding:
    • Log in to the router or firewall admin interface.
    • Ensure TCP port 21 and the passive port range (e.g., 50000-51000) are forwarded to the FTP server’s internal IP.
  • Check External IP Announcement:
    • Some FTP servers send an incorrect IP in the PASV command response. Ensure the server is configured to announce the public IP (not the internal IP) in passive mode responses.
    • For IIS, this is set in FTP Firewall Support (see step 1).
    • For FileZilla, check Settings > Passive mode settings > Use the following IP.

4. Verify Port Usage with Netstat

Check if the FTP server is actually binding to the configured passive port range.

  • Run Netstat:
    • Open Command Prompt as Administrator and run:

netstat -ano | findstr :50000

Replace 50000 with the start of your passive port range.

  • Check Listening Ports:
    • Look for LISTENING entries associated with the FTP server process ID (PID).
    • Find the PID in Task Manager or use:

tasklist | findstr <pid>

If no ports in the range are listening, the FTP server isn’t binding correctly, indicating a configuration error.
  • Check for Port Conflicts:
    • If other services are using the passive port range, it may prevent the FTP server from binding. Use:

netstat -ano | findstr LISTENING

to identify conflicting services and reconfigure the port range if needed.

5. Test Passive Mode Connectivity

Use an FTP client to test passive mode and diagnose issues.

  • Configure Client for Passive Mode:
    • In clients like FileZilla, set the transfer mode to Passive (Settings > Connection > FTP > Transfer Mode).
  • Connect and Monitor:
    • Attempt a connection and list a directory.
    • Check the client logs for errors like “425 Can’t open data connection” or “Failed to retrieve directory listing.”
  • Capture Network Traffic (Optional):
  • Use Wireshark to capture traffic on the server:
    • Filter for tcp.port >= 50000 && tcp.port <= 51000 (adjust for your range).
    • Verify the server is sending PASV responses with the correct port and that the client is attempting to connect to those ports.
    • If the client can’t connect, check for dropped packets indicating a firewall or NAT issue.

6. Check Windows System Configuration

Windows may restrict the ephemeral port range or have policies affecting port usage.

  • Check Ephemeral Port Range:
    • Run:

netsh int ipv4 show dynamicport tcp

Ensure the configured passive port range doesn’t overlap with the system’s ephemeral ports (default: 49152-65535).

  • If there’s overlap, set a non-overlapping range in the FTP server config or adjust the system range:

netsh int ipv4 set dynamicport tcp start=10000 num=20000

(This example sets the ephemeral range to 10000-29999.)

  • Check Group Policy or Security Software:
    • Some security software or Group Policy settings may restrict high port usage. Check with your system administrator or review policies in gpedit.msc under Computer Configuration > Windows Settings > Security Settings.

7. Common Issues and Fixes

  • Server Not Using Configured Ports:
    • Cause: Misconfiguration or service not restarted.
    • Fix: Reapply the passive port range and restart the FTP service.
  • Firewall Blocking Ports:
    • Cause: Windows Firewall or third-party security software blocking the port range.
    • Fix: Add firewall rules for the passive port range (see step 2).
  • NAT/Firewall Mismatch:
    • Cause: Router/firewall not forwarding the correct ports or server announcing wrong IP.
    • Fix: Update port forwarding and external IP settings (see step 3).
  • Port Range Too Small:
    • Cause: Too few ports allocated for high traffic, causing port exhaustion.
    • Fix: Increase the port range (e.g., 50000-51000 for 1000 ports) and ensure firewall rules match.

8. Test and Validate

  • Use an External Client:
    • Test from a different network to rule out local issues.
    • Use tools like ftp (command line), FileZilla, or WinSCP.
  • Check Logs:
    • For IIS, check logs at C:\inetpub\logs\LogFiles\FTPSVC*.
    • For FileZilla, check server logs in the application interface.
    • Look for errors related to port binding or connection failures.
  • Verify with Telnet:
    • Test control connection:

telnet <server_ip> 21

  • Test a passive data port (e.g., 50000):

telnet <server_ip> 50000

If it fails, the port isn’t open or reachable.

9. Additional Notes

  • Security Considerations:
    • Use FTPS (FTP over SSL/TLS) to secure data transfers.
    • Limit the passive port range to minimize the attack surface (e.g., 1000 ports instead of 16000).
  • If Issue Persists:
    • Check for third-party software (e.g., antivirus, endpoint protection) restricting ports.
    • Contact your network administrator to verify no network-level policies are blocking high ports.
    • Consider switching to active mode for testing (though passive is preferred for NAT compatibility).

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB66","label":"Technology Lifecycle Services"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SSTIPK","label":"Microsoft Windows"},"ARM Category":[{"code":"a8mKe000000004NIAQ","label":"Windows"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":""}]

Document Information

Modified date:
26 September 2025

UID

ibm17246327

Page Feedback