Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[powermick]

Hello everyone,

I have long awaited the release of 1.06 mainly for support Unicode in the FTP.

It is now a week since the ftp function normally (port 21).

Only now it's impossible to complete the downloads: the server disconnect before the end of the transfer. (For reference I use filezilla)

Having discovered this post: http://forums.dlink.com/index.php?topic=3462.0

  Under the 1.06 he needed to go in "ServerType: FTPES - FTP over explicit TLS / SSL" , so I did that. I
therefore redirected port 443 to my nas.

The problem is always present: the ftp server disconnects filezilla before the end of the transfer, the error message is: "ECONNABORTED -- Connection aborted "

Status: The server was not properly closed the TLS connection
Error: Disconnected from server: ECONNABORTED - Connection aborted

So if someone encounter the same problem, he should know, and
if there is a solution, it would be even better.

Please help me!


Ps: I'm RAID1 mode

[powermick]

nobody else did this problem?
Yet I restarts several times the nas and try from
multiple computers

[bripab007]

Yeah, the problem is, according to my router logs, I don't think the DNS-323's SFTP server sends outbound packets on port 443.  It seems to be random, which is kinda crazy...

[powermick]

It is extremely bizare, as I restart the nas and router several times.
and in addition it has to walk the first week!
is there a solution?

[bohemian]

I have the same problem. exactly same as yours.
I bought it at the end of last year. When I got it, f/w was 1.05, h/w rev. B1.
upgraded to f/w 1.06, started to install with 2x 1tb hard in raid 1 mode
and backed up may contents of local hdd.
There was nothing special even though network speed was not satisfied.
Until now, I've suffered the ftp problem since then, I've concentrated my effort on trials to solve in vain.
checked all points, tried to change configuration of dns-323 and a router and even the network cable.

finally, connecting dns-323 to a pc directly, I tested ftp function, but the result is same.
so, even if there is a solution, it would not be any other than dns-323 it self.
in my guess, it probably due to hardware problem or characteristics that could be covered by firmware.
I am suggested to change it with another one by a dlink technician.

I'm going to test and compare mine and another one in different environments in a few days.
according to the results, I would change if no other solution.

cheers.

[fordem]

Bohemian/Powermick

Is your problem related to standard ftp or to secure ftp?

One thing I'd like to suggest - purely as a method of simplifying the troubleshooting process - get it working on the local LAN FIRST, local LAN access does not require you to fiddle with the router, so it's one thing less to worry about.

[bripab007]

Yes, I was just going to reply that I knew it was a blocked port problem because I had already tested SFTP/FTPS to the DNS-323 on the local network, and it works just fine.  It prompts you to download the secure certificate at login, then proceeds as normal.

Again, it seems like the secure port it uses is randomized or something, so I'm not sure what to do about that with regard to port forwarding.

[pikegmu]

hey bripab007, what are the steps you performed to get FTPS to work?  I haven't spent much time with it but initially had some problems.  It's been a few days since i've messed around with it so I was hoping DLink would have posted some updated documentation 

just some clarifications on ports and SFTP/FTPS.  SFTP and FTPS are two different things.  SFTP is FTP through SSH while FTPS is FTP through SSL.  They both use different ports as well.  SFTP using port 22 by default and FTPS uses port 990 as control and 989 as data, by default.  I use Filezilla as my FTP client and if you're configuring a new connection you'll notice that there is explict FTPS (FTPES) and implicit FTPS (FTPS).  If you're using implicit FTPS the FTP client assumes you're connecting to port 990 so if you've configured a different port, FTPS will not work.  For any other port than 990 you must choose the FTPES option.

hope this helps.  if you already know this then ignore  

[bripab007]

Yes, I'm sorry, I couldn't remember at the time which was which, but I just remoted into my home LAN and see that I was using FTPS (FTP with an SSL) to test with.

It always seems to get hung up on the LIST command after logging into the FTP from outside the network, going through the firewall.

So, historically, I've forwarded external FTP requests on port 1023 to port 21 internally on my DNS-323.  So, when connecting with explicit FTPS (FTPES) through Filezilla, it shows this:

Command:   AUTH TLS
Response:   234 AUTH TLS OK.
Status:   Initializing TLS...
Status:   Verifying certificate...
Command:   USER *****
Status:   TLS/SSL connection established.
Response:   331 User ***** OK. Password required
Command:   PASS ********
Response:   230 OK. Current restricted directory is /
Command:   PBSZ 0
Response:   200 PBSZ=0
Command:   PROT P
Response:   534 Fallback to [C]
Status:   Connected
Status:   Retrieving directory listing...
Command:   PWD
Response:   257 "/" is your current location
Command:   TYPE I
Response:   200 TYPE is now 8-bit binary
Command:   PASV
Response:   227 Entering Passive Mode (***,***,*,**,**,***)
Status:   Server sent passive reply with unroutable address. Using server address instead.
Command:   LIST
Error:   Connection timed out
Error:   Failed to retrieve directory listing

So, it appears to login, accept the SSL cert., then issues the usual LIST command, but never completes and ends up timing out.  So I never actually get dumped into my home directory on the FTP.  It's hanging on that directory listing.

I've tried opening ports 990 and 989 to the DNS-323 in the firewall, to no avail.  I've also watched for the destination ports to which the DNS-323 is sending packets back to my remote network while I'm trying to connect with Filezilla over this FTPS, and they're seemingly random.  The last three, for example, are 37251, 38269 and 38517.

So, while it may be an FTPS protocol standard to use ports 990 and 989, it does not appear that the DNS-323's FTP server is using those ports.

[pikegmu]

sweet, thanks for the steps!  it's a pain in the butt.  i was hoping with the release of fw 1.06 the FTP server page would have a nice option to just select FTP over SSL/TLS but i guess not 

the random destination port numbers you're getting from the DNS-323 is normal.  when a client initiates a request in TCP/IP it dynamically is assigned a port number > 1024.  so if FTPS was working (which hopefully it will soon) you would initiate a connection to port 990 on the DNS-323 and your client computer would dynamically assign a port number >1024.

[bripab007]

Yeah, I don't know what I was thinking:  I was looking at the outbound connections and ports from the DNS-323, not the inbound connection from the external client.

So, how 'bout that firmware 1.07, eh, guys?!

[fordem]

sweet, thanks for the steps!  it's a pain in the butt.  i was hoping with the release of fw 1.06 the FTP server page would have a nice option to just select FTP over SSL/TLS but i guess not 

the random destination port numbers you're getting from the DNS-323 is normal.  when a client initiates a request in TCP/IP it dynamically is assigned a port number > 1024.  so if FTPS was working (which hopefully it will soon) you would initiate a connection to port 990 on the DNS-323 and your client computer would dynamically assign a port number >1024.

And what happens at the firewall(s)?

[pikegmu]

hey fordem.  can you give me a specific example of what you're asking?  there are a few things that can happen depending on the scenario and the security settings configured but for the most part the client port assigned shouldn't be a factor in establishing a remote connection through a firewall to a service.  Unless for some reason the firewall was blocking outbound connections.  the only thing that would need to be configured on the server end would be to open the correct port on the firewall. 

just an update on the FTPS thing.  i believe i've gotten it to work locally.  haven't been able to test remotely.  i'll let you guys know if I find anything.

[powermick]

already I am not alone in this problem.

it is clear that the problem come from the ftp server itself and
not the bad port configuration whatsoever in
ssl or not, because local network there is no
port forwarding and even via the Internet by putting
nas in dmz, the result is the same!

[fordem]

pikegmu

Bear with me a minute whilst I explain - starting with standard ftp and not ftps or ftpes

The problem area for most people with ftp is that it uses two connections.

Standard (active) ftp defaults to a control (or command) channel on port 21 outbound from the client to the server and a data channel on port 20 outbound from the server to the client.

For standard (active) ftp with the server behind a NAT firewall, port 21 needs to be forwarded to the server.

Standard (active) ftp with the client behind a NAT firewall usually works because most NAT firewalls know to "fix up" the ftp protocol (that by the way is Cisco's terminology ), so when they see an outgoing control channel established on port 21 to a given ip address, they look for an incoming connection request from the same ip address and forward it to the host that established the control channel - all other incoming connection requests that do not have specific forwarding configured are discarded.

This causes a problem when the standard (active) ftp session is established on a non-standard port - for example 210 - assume the server side has been properly configured for the non-standard port, and it is now trying to establish the data channel to the client - the client side firewall does not recognise the outgoing connection on 210 to be an ftp control connection and so does not provide the "fix-up" instead it discards the incoming request.  This is the reason for standard (passive) ftp.

I will be very brief here with standard (passive) ftp - the main difference between active & passive ftp is that with passive ftp both the control and data channels are established by the ftp client and so the NAT firewall at the client end does not create any problems - the problem instead is shifted to the server end, and can be quite challenging if the server is behind a NAT firewall.

Essentially the server tells the client to establish the data connection on a particular randomly selected port and then waits for the connection, and if the server is behind a NAT firewall, that port or a range of ports needs to be forwarded to the server in addition to the control port - the problem here is in knowing which port(s) to forward.

Now to ftps and ftpes - which I don't claim a great deal of knowledge about.

As far as I understand - these secure types of ftp also use two separate control and data channels - so the problems I outlined above still exist - ftps apparently defaults to 990 for the control port and 989 for the data.

So what my question translates to - is will your client side NAT firewall recognise the outgoing connection on 990 as ftps and allow the inbound connection through or will it discard it?