My first and best solution for you would be to get away from FTP, it is
an outdated and insecure network protocol. Use sftp (the FTP interface
to SSH -- *not* regular FTP over SSL or ftps)
If you need to stay with FTP, it's important to understand how FTP
works. When you transfer a file or directory listing (directory
listings are transferred over the network the same way a file would be)
the FTP software sends an IP address and port number over the network
connection for the other side to connection to. It uses a random port
from am ephemeral range. So the port number will be different every
time. Also, because of the widespread use of NAT (where you have an
"internal IP" and a different "external IP") sending the IP address
often causes problems.
You've seen people in this thread say "this is an active vs passive
issue". What passive mode changes is which side hosts the file transfer
connection. In the original (active) mode, the CLIENT actually opens a
port, and the server makes a connection to it. This is very troublesome
because network admins usually designate computers as being either
"desktop" (or workstation) computers vs. servers. So the fact that your
client needs to temporarily act as a network server causes all sorts of
problems. The firewall, NAT and routing all need to know about this for
it to work properly.
Passive mode means that the FTP server also acts in a server role for
file transfers. Frustratingly the crappy little FTP client that Windows
provides doesn't support this mode.. but anyway even though this is
usually better aligned with the way networks are set up, it still isn't
foolproof. It helps if the server is not behind a NAT gateway and has
the ephemeral port range open to the public, but in cases where it is
not, you'll still have the same problem.
So you can change the network setup, you can try using passive mode, you
can maybe solve it. Then what will you have? A very insecure way of
sending files that you've had to weaken your network security to enable.
Switch to sftp/scp. Works all on one port, no problems with NAT.
Everything is encrypted and protected.
It's 2024... FTP is a protocol from the 1970s. Time to move on.
On 2/8/2024 7:08 PM, mlazarus wrote:
I am running into a situation where an FTP session to a client's i,
where some commands work and others fail.
- Connection is via a VPN.
- FTP client is the basic Windows FTP.EXE, run in a DOS box.
- I'm able to connect and sign in using a QSECOFR level profile.
- Basic commands like CD, LCD, BIN, PWD work fine.
- Commands that access data like LS, DIR, GET, PUT have up the session
for a while and then times out:
ftp> ls
200 PORT subcommand request successful.
425 Not able to open data connection.
- According to the network admin all ports for my connection are open.
- FTP to other machines from this PC work fine.
Any idea what might be causing this? Or how to debug it? TIA.
-mark
midrange.com
