John-D-Chapman
asked on
Cannot upload to FTP server from particular computer
I have a strange problem.
I have an FTP server setup at work, on a LAN using zFTPServer. The server is configured to listen on standard port 21, and accept passive connections through ports 40000 to 40100.
The server is behind a D-Link DI-704 Router. The router is set to forward ports 21, and 40000 to 40100 to the internal IP of the computer hosting the server.
zFTPServer has numerous users setup with all of their various permissions and mount points.
All computers, both internally on the LAN, and external to the LAN can logo on and do everything within the constraints of their user permissions. All computers accept ONE.
When I log on as a user that has Read/Write/Upload/Download
The host computer is running Windows XP Pro, with Symantec Antivirus Corporate 9.0...that's it. Aside from the Server software itself, no other uneccessary software is installed. Windows Firewall is DISABLED.
What could possibly be stopping this one particular computer from being able to add data to the FTP server (that is the only thing not working...i.e., if i upload a zero kilobyte file, it works..it is only when attempting to add physical bytes of data that this problem occurs)? It's almost as if the host computer is blocking my home IP address specifically from adding data, but I cannot find any evidence of this at the host computer itself. Could it be my specific Internet Connection from home (High Speed Cable)? I have no idea.
If anyone has any suspicions or suggestions, please let me know and it would be greatly appreciated.
I have an FTP server setup at work, on a LAN using zFTPServer. The server is configured to listen on standard port 21, and accept passive connections through ports 40000 to 40100.
The server is behind a D-Link DI-704 Router. The router is set to forward ports 21, and 40000 to 40100 to the internal IP of the computer hosting the server.
zFTPServer has numerous users setup with all of their various permissions and mount points.
All computers, both internally on the LAN, and external to the LAN can logo on and do everything within the constraints of their user permissions. All computers accept ONE.
When I log on as a user that has Read/Write/Upload/Download
The host computer is running Windows XP Pro, with Symantec Antivirus Corporate 9.0...that's it. Aside from the Server software itself, no other uneccessary software is installed. Windows Firewall is DISABLED.
What could possibly be stopping this one particular computer from being able to add data to the FTP server (that is the only thing not working...i.e., if i upload a zero kilobyte file, it works..it is only when attempting to add physical bytes of data that this problem occurs)? It's almost as if the host computer is blocking my home IP address specifically from adding data, but I cannot find any evidence of this at the host computer itself. Could it be my specific Internet Connection from home (High Speed Cable)? I have no idea.
If anyone has any suspicions or suggestions, please let me know and it would be greatly appreciated.
ASKER
Anyone with a proper username and password both inside and outside of our intranet can carry out actions governed by the privilieges setup in the configuration of the FTP server.
It is just this one particular computer that I am unable to upload from, no matter what user I log in as.
Secure FTP and SSH is definitely the next step, and will hopefully occur sooner than later.
The computer hosting the server, although "plugged" in to our LAN, is not a member of our domain. So, even if a hacker got into to that computer, they would still then need to attain another username and password to gain access to any other resources on our network. Even if this compuer were compromised in the interim, losing the contents of the FTP site would not be catastrophic. I hoped this would provide enough "security" until software that provides Secure connections through SSL/TLS could be decided upon (or the software we are using releases a version supporting it, which is in the works).
So, the problem still stands, I cannot upload from one, and only one, particular computer outside our LAN. I cannot figure out what about this one computer is causing the access denial.
It is just this one particular computer that I am unable to upload from, no matter what user I log in as.
Secure FTP and SSH is definitely the next step, and will hopefully occur sooner than later.
The computer hosting the server, although "plugged" in to our LAN, is not a member of our domain. So, even if a hacker got into to that computer, they would still then need to attain another username and password to gain access to any other resources on our network. Even if this compuer were compromised in the interim, losing the contents of the FTP site would not be catastrophic. I hoped this would provide enough "security" until software that provides Secure connections through SSL/TLS could be decided upon (or the software we are using releases a version supporting it, which is in the works).
So, the problem still stands, I cannot upload from one, and only one, particular computer outside our LAN. I cannot figure out what about this one computer is causing the access denial.
is the local account you use to log on to the ONE computer different to the account used for FTP ?
If so then it may be a credential issue.
If so then it may be a credential issue.
Are there any interesting events in the error logs on that machine?
ASKER
Yes, the local account on the computer in question is different than the account used to log on to the FTP server. But such is the case with everyone that logs on the to FTP server. In no situation does the account of the computer being used to log on the the FTP server have the same credentials as the FTP user itself.
User logs on to his/her computer as user "A", then logs onto the FTP site as user "B". The two sets of credentials have nothing to do with one another.
I have checked the error log, and there is nothing out of the ordinary in any section. There is also nothing extraordinary in the event viewer of the computer hosting the FTP server.
My home computer (the offending machine) is also hosting it's own FTP server using the same software (zFTPServer), and there are no problems the other way around..i.e. uploading/downloading/dele
I apologize, as this may be something that is just impossible to pin down without the bility top sit down in front of the offending machine and assess. But, if anyone has any suspicions that lead to a solution, I will be super happy and ever appreciative.
Can you verify that when you are trying a connection from home that you are actually opening the data port in the range 40000 - 40100.
Are you behind a firewall at home ?
If yes - Does the firewall allow you to open this port ?
Are all the working users connecting from external networks ?
Are you behind a firewall at home ?
If yes - Does the firewall allow you to open this port ?
Are all the working users connecting from external networks ?
ASKER
I have not verified what ports are actually being opened when trying to send data. i will check on this.
Yes, all users, with the exception of myself from within our LAN at wotk, are connecting from external networks.
I doubt, however, that any of them are behind a software firewall (as most would be connecting from workplace machines behind a firewalled router of some sort). At home I am running ZoneAlarm Professional. It may very well be that this is what is stopping me and I did no even think about it. Apologies for that. I will test this as soon as I get home tonight and report back.
Thanks very much for the nudge. I will get back to you to see if this is a resolution.
Yes, all users, with the exception of myself from within our LAN at wotk, are connecting from external networks.
I doubt, however, that any of them are behind a software firewall (as most would be connecting from workplace machines behind a firewalled router of some sort). At home I am running ZoneAlarm Professional. It may very well be that this is what is stopping me and I did no even think about it. Apologies for that. I will test this as soon as I get home tonight and report back.
Thanks very much for the nudge. I will get back to you to see if this is a resolution.
ASKER
I have tested to see whether or not my software firewall (ZoneAlarm Pro) was stopping me from uoploading to my work's FTP site.
After shutting down the firewall completely (and checking that doing so did not turn the Windows Firewall ON), I was still unable to upload.
Next is to verify what ports are being opened to send the data. But I am not sure how to do that, so if someone has a suggestion, that would be great.
After shutting down the firewall completely (and checking that doing so did not turn the Windows Firewall ON), I was still unable to upload.
Next is to verify what ports are being opened to send the data. But I am not sure how to do that, so if someone has a suggestion, that would be great.
To see what ports are being opened, do these three steps:
1. Open a command prompt and enter
netstat -n
You will see all the network connections your computer has open, usually there are several.
2. Open your FTP session and try to transfer a file
3. Return to the command prompt and enter
netstat -n
Compare it to the earlier list -- the new items are the ones the FTP session created.
However, if your FTP connection is failing, you may not see the ports there. Here are two other tests to try-- PORTQRY and ETHEREAL:
Download and install PORTQRY from this site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=89811747-C74B-4638-A2D5-AC828BDC6983&displaylang=en
Then test your FTP connection with these two commands:
portqry -n yourcompany.com -e 21
portqry -n yourcompany.com -e 22
They should both be LISTENING. If they are NOT LISTENING or FILTERED, something is blocking them.
ETHEREAL is a very powerful sniffer. It is a bit complex to use at first, but it shows every packet your machine sends out and every packet it receives. With Ethereal you can see exactly which request is not being responded to correctly. You can download it here:
http://ethereal.com/
1. Open a command prompt and enter
netstat -n
You will see all the network connections your computer has open, usually there are several.
2. Open your FTP session and try to transfer a file
3. Return to the command prompt and enter
netstat -n
Compare it to the earlier list -- the new items are the ones the FTP session created.
However, if your FTP connection is failing, you may not see the ports there. Here are two other tests to try-- PORTQRY and ETHEREAL:
Download and install PORTQRY from this site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=89811747-C74B-4638-A2D5-AC828BDC6983&displaylang=en
Then test your FTP connection with these two commands:
portqry -n yourcompany.com -e 21
portqry -n yourcompany.com -e 22
They should both be LISTENING. If they are NOT LISTENING or FILTERED, something is blocking them.
ETHEREAL is a very powerful sniffer. It is a bit complex to use at first, but it shows every packet your machine sends out and every packet it receives. With Ethereal you can see exactly which request is not being responded to correctly. You can download it here:
http://ethereal.com/
ASKER
Thank you for the nudge on checking port status.
The 'portqry' command returned the following:
TCP port 21 (ftp service): LISTENING
TCP port 22 (unknown service): FILTERED
The 'netstat -n' command returned the following prior to logging onto the FTP site:
Active Connections
Proto Local Address Foreign Address State
TCP MyHomeIP:1075 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1079 ForeignIP:80 CLOSE_WAIT
After logon the command eturned the following:
Active Connections
Proto Local Address Foreign Address State
TCP MyHomeIP:1075 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1079 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1089 FTPServerIP:21 TIME_WAIT
TCP MyHomeIP:1091 FTPServerIP:21 TIME_WAIT
TCP MyHomeIP:1092 FTPServerIP:21 ESTABLISHED
TCP MyHomeIP:1093 FTPServerIP:21 ESTABLISHED
And finally, during an attempted upload:
Active Connections
Proto Local Address Foreign Address State
TCP MyHomeIP:1075 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1079 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1092 FTPServerIP:21 ESTABLISHED
TCP MyHomeIP:1093 FTPServerIP:21 ESTABLISHED
TCP MyHomeIP:1125 ForeignIP:80 TIME_WAIT
TCP MyHomeIP:1126 ForeignIP:80 TIME_WAIT
TCP MyHomeIP:1144 FTPServerIP:40000 ESTABLISHED
TCP 127.0.0.1:1099 127.0.0.1:1068 TIME_WAIT
TCP 127.0.0.1:1116 127.0.0.1:1068 TIME_WAIT
TCP 127.0.0.1:1127 127.0.0.1:1068 TIME_WAIT
TCP 127.0.0.1:1135 127.0.0.1:1068 TIME_WAIT
Is there anything glaring about what these commands have returned that I am missing?
Ethereal is a little over my head, but if it is suggested that I require it's use, I will try to figure it out.
The 'portqry' command returned the following:
TCP port 21 (ftp service): LISTENING
TCP port 22 (unknown service): FILTERED
The 'netstat -n' command returned the following prior to logging onto the FTP site:
Active Connections
Proto Local Address Foreign Address State
TCP MyHomeIP:1075 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1079 ForeignIP:80 CLOSE_WAIT
After logon the command eturned the following:
Active Connections
Proto Local Address Foreign Address State
TCP MyHomeIP:1075 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1079 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1089 FTPServerIP:21 TIME_WAIT
TCP MyHomeIP:1091 FTPServerIP:21 TIME_WAIT
TCP MyHomeIP:1092 FTPServerIP:21 ESTABLISHED
TCP MyHomeIP:1093 FTPServerIP:21 ESTABLISHED
And finally, during an attempted upload:
Active Connections
Proto Local Address Foreign Address State
TCP MyHomeIP:1075 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1079 ForeignIP:80 CLOSE_WAIT
TCP MyHomeIP:1092 FTPServerIP:21 ESTABLISHED
TCP MyHomeIP:1093 FTPServerIP:21 ESTABLISHED
TCP MyHomeIP:1125 ForeignIP:80 TIME_WAIT
TCP MyHomeIP:1126 ForeignIP:80 TIME_WAIT
TCP MyHomeIP:1144 FTPServerIP:40000 ESTABLISHED
TCP 127.0.0.1:1099 127.0.0.1:1068 TIME_WAIT
TCP 127.0.0.1:1116 127.0.0.1:1068 TIME_WAIT
TCP 127.0.0.1:1127 127.0.0.1:1068 TIME_WAIT
TCP 127.0.0.1:1135 127.0.0.1:1068 TIME_WAIT
Is there anything glaring about what these commands have returned that I am missing?
Ethereal is a little over my head, but if it is suggested that I require it's use, I will try to figure it out.
Oops! The ports for FTP are ports 20 and 21, not 21 and 22. But even when FTP is working, it's port 21 that shows LISTENING.
Here is an article explaining how FTP works -- port 21 is used for control, and port 20 to send the data.
http://www.troubleshootingnetworks.com/ftpinfo.html
So although you can connect on port 21, something is blocking port 20, it seems.
Let's try this test. I set up an FTP account on my server and uploaded something successfully -- let's see if you can do the same thing.
The server is s93147768.onlinehome.us
The username is u35755425-testftp
The password is testftp
I recommend that you use the Windows XP command-line FTP program just so you are doing exactly what I did. Here is exactly what I did to connect and upload a file named 'kiooris.jpg' -- just a convenient file that was big enough to take a few seconds to transfer.
--------------------------
E:\Documents and Settings\Sam>ftp s93147768.onlinehome.us
Connected to s93147768.onlinehome.us.
220 FTP Server ready.
User (s93147768.onlinehome.us:(
331 Password required for u35755425-testftp.
Password:
230 User u35755425-testftp logged in.
ftp> send kiooris.jpg
200 PORT command successful
150 Opening ASCII mode data connection for kiooris.jpg
226 Transfer complete.
ftp: 472530 bytes sent in 4.97Seconds 95.10Kbytes/sec.
--------------------------
After logging in, I saw these items in netstat -n, and they remained the same during and after transfer:
TCP 192.168.2.203:1789 82.165.130.247:21 ESTABLISHED
TCP 192.168.2.203:1791 82.165.130.247:21 ESTABLISHED
During transfer, I saw this:
TCP 192.168.2.203:1795 82.165.130.247:20 ESTABLISHED
After transfer was complete, I saw this:
TCP 192.168.2.203:1795 82.165.130.247:20 TIME_WAIT
What happens when you try it?
Here is an article explaining how FTP works -- port 21 is used for control, and port 20 to send the data.
http://www.troubleshootingnetworks.com/ftpinfo.html
So although you can connect on port 21, something is blocking port 20, it seems.
Let's try this test. I set up an FTP account on my server and uploaded something successfully -- let's see if you can do the same thing.
The server is s93147768.onlinehome.us
The username is u35755425-testftp
The password is testftp
I recommend that you use the Windows XP command-line FTP program just so you are doing exactly what I did. Here is exactly what I did to connect and upload a file named 'kiooris.jpg' -- just a convenient file that was big enough to take a few seconds to transfer.
--------------------------
E:\Documents and Settings\Sam>ftp s93147768.onlinehome.us
Connected to s93147768.onlinehome.us.
220 FTP Server ready.
User (s93147768.onlinehome.us:(
331 Password required for u35755425-testftp.
Password:
230 User u35755425-testftp logged in.
ftp> send kiooris.jpg
200 PORT command successful
150 Opening ASCII mode data connection for kiooris.jpg
226 Transfer complete.
ftp: 472530 bytes sent in 4.97Seconds 95.10Kbytes/sec.
--------------------------
After logging in, I saw these items in netstat -n, and they remained the same during and after transfer:
TCP 192.168.2.203:1789 82.165.130.247:21 ESTABLISHED
TCP 192.168.2.203:1791 82.165.130.247:21 ESTABLISHED
During transfer, I saw this:
TCP 192.168.2.203:1795 82.165.130.247:20 ESTABLISHED
After transfer was complete, I saw this:
TCP 192.168.2.203:1795 82.165.130.247:20 TIME_WAIT
What happens when you try it?
Very puzzling! I see that you do have a connection established with port 40000, which should be the data connection with your settings. I don't see any reason for the data transfer to fail.
But anyway, please try my server. If you cannot upload there, that might show us something.
But anyway, please try my server. If you cannot upload there, that might show us something.
It seems that your FTP is working correctly.
Your connections opened up are port 21 and 40000 as the data port which you specified is correct.
"The server is configured to listen on standard port 21, and accept passive connections through ports 40000 to 40100."
If you have access to the FTP server at work, then when you are in the office try and connect with the same account as you do remotely. Then try and copy/delete in the upload directory itself.
More than likely your account does not have rights or there is some problem with "inheritance" permissions which flow downwards from parent to child objects.
I have had this issue in the past and it was a crential/permissions problem on the account.
Not sure if it is your problem but give it a go.
Your connections opened up are port 21 and 40000 as the data port which you specified is correct.
"The server is configured to listen on standard port 21, and accept passive connections through ports 40000 to 40100."
If you have access to the FTP server at work, then when you are in the office try and connect with the same account as you do remotely. Then try and copy/delete in the upload directory itself.
More than likely your account does not have rights or there is some problem with "inheritance" permissions which flow downwards from parent to child objects.
I have had this issue in the past and it was a crential/permissions problem on the account.
Not sure if it is your problem but give it a go.
By the way, can you try an account which does work from your machine at home.
ASKER
samb39 and mianni,
Thanks very much for your help so far.
samb39, I will test an upload to your FTP server when I have a chance. I was puzzled as well because the netstat command told me that port 40000 had been opened for transfer. My router at work has 40000 to 40100 forwarding to the host computer. Port 20, however is NOT being forwarded. I did not think this necessary because I am specifying 40000 to 40100 in the FTP server's config for passive connections. Am I wrong? I will try this anyways (forward port 20) to see if this makes any difference.
mianni, connecting from the office, using the exact same account used to log on from home works without incident. In fact, anywhere I've tried, in or out of my office, and using the identical account, has worked without incident, except from home. So, I don't think credentials are a problem at all. This problem occurs no matter what user I log in as. There are multiple users setup with full Write/Upload privileges, including all subdirectories under their mount points (directories listed upon login).
Previously I had stated that ALL computers I had tested on except my home computer were trouble free. A new development: I have confirmed from another user that the problem is occurring for them as well. I initially thought it was an Active/Passive issue, because my FTP server activity log showed the PORT command, rather than a PASV command prior to a STOR attempt by them. However, I confirmed with the user that they were properly attempting to upload in passive mode. If an upload in passive mode fails, am I correct in assuming it will revert to Active mode (PORT) to try and execute the STOR, and only then if a failure occurs is it returned to the user?
Thanks very much for your help so far.
samb39, I will test an upload to your FTP server when I have a chance. I was puzzled as well because the netstat command told me that port 40000 had been opened for transfer. My router at work has 40000 to 40100 forwarding to the host computer. Port 20, however is NOT being forwarded. I did not think this necessary because I am specifying 40000 to 40100 in the FTP server's config for passive connections. Am I wrong? I will try this anyways (forward port 20) to see if this makes any difference.
mianni, connecting from the office, using the exact same account used to log on from home works without incident. In fact, anywhere I've tried, in or out of my office, and using the identical account, has worked without incident, except from home. So, I don't think credentials are a problem at all. This problem occurs no matter what user I log in as. There are multiple users setup with full Write/Upload privileges, including all subdirectories under their mount points (directories listed upon login).
Previously I had stated that ALL computers I had tested on except my home computer were trouble free. A new development: I have confirmed from another user that the problem is occurring for them as well. I initially thought it was an Active/Passive issue, because my FTP server activity log showed the PORT command, rather than a PASV command prior to a STOR attempt by them. However, I confirmed with the user that they were properly attempting to upload in passive mode. If an upload in passive mode fails, am I correct in assuming it will revert to Active mode (PORT) to try and execute the STOR, and only then if a failure occurs is it returned to the user?
ASKER
samb39,
I tested an upload from the command line to your FTP server with success. This made me decide to try an upload to my FTP server at work from the command line. I was successful. When I saw that the "send" command used PORT instead of PASV, I started to realize that the problem appears to be a PORT/PASV (Passive vs. Active) problem.
So, then I turned OFF Passive FTP in Internet Explorer and tried an upload, and again I was successful. This confirmed that I can upload using Active FTP, but cannot using Passive FTP. This is strange, since I am behind a software firewall at home, and the FTP server is behind a firewalled Router (from wat I've read, Active FTP should not work in this situation, hence the need for Passive mode).
I was successfull at uploading in Passive mode to your FTP Server, so based on that we can narrow my problem to either trouble wth the FTP Server itself (zFTPServer), or a problem with the way the Router is handling the Data Connection.
This would explain why I noticed that successful uploads in my activity log appeared to be after the PORT command, and those that were failing appeared to be after the PASV command.
Does it make any sense at all that I can upload using Active FTP and cannot using Passive FTP?
I tested an upload from the command line to your FTP server with success. This made me decide to try an upload to my FTP server at work from the command line. I was successful. When I saw that the "send" command used PORT instead of PASV, I started to realize that the problem appears to be a PORT/PASV (Passive vs. Active) problem.
So, then I turned OFF Passive FTP in Internet Explorer and tried an upload, and again I was successful. This confirmed that I can upload using Active FTP, but cannot using Passive FTP. This is strange, since I am behind a software firewall at home, and the FTP server is behind a firewalled Router (from wat I've read, Active FTP should not work in this situation, hence the need for Passive mode).
I was successfull at uploading in Passive mode to your FTP Server, so based on that we can narrow my problem to either trouble wth the FTP Server itself (zFTPServer), or a problem with the way the Router is handling the Data Connection.
This would explain why I noticed that successful uploads in my activity log appeared to be after the PORT command, and those that were failing appeared to be after the PASV command.
Does it make any sense at all that I can upload using Active FTP and cannot using Passive FTP?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
samb39,
Thanks very much for all your help.
While I have yet to discern why some users cannot send data in Passive mode, those users seem to have no trouble in Active mode. So, at least data can now be sent, which was my main concern.
If I find the time to make a concerted effort at figuring out and translating Ethereal, I will do so. Until then, the main concern of reinstating the ability to send data to the FTP server has been rectified.
Thanks very much!
Thanks very much for all your help.
While I have yet to discern why some users cannot send data in Passive mode, those users seem to have no trouble in Active mode. So, at least data can now be sent, which was my main concern.
If I find the time to make a concerted effort at figuring out and translating Ethereal, I will do so. Until then, the main concern of reinstating the ability to send data to the FTP server has been rectified.
Thanks very much!
It would make sense for a company to block FTP uploads from the Internet. FTP is an intrinsically insecure protocol because passwords are sent unencryoted, and an intruder often uses FTP to add hacking tools, root kits, trojans, backdoors, etc. So even if you find a way to do this, your company SHOULD disallow it. A far better procedure is to use secure FTP and SSH, so that you really know who is uploading stuff onto your server.