[Linux] vsftpd -- troubling connecting from the internet ...

Wed, 30 Jan 2008 18:33:43 +0100

This is a multi-part message in MIME format.

--Boundary_(ID_km/DxqghoJPUCNBbi4eluA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 8BIT

THanks, very enlightening post. I'll give it a try a comment later.

REgards,

Andy
> On Jan 30, 2008 7:47 AM, Andrés Ledesma - aledes@euskalnet.net
> <+flux+simicich+d3204ec66a.aledes#euskalnet.net@spamgourmet.com>
> wrote:
>   
>> Hi Nicholas,
>>
>> You're absolutely right. Stopped the vsftpd, and instaled PureFtp, out
>> of the box I can connect to it with a 'ftp' user.
>>  From the internet, I can't, again.
>>
>> Gotta discover how to enroute it. Could it be that adsl test pages
>> report tome that port 20 is closed ?
>>     
>
> Um, this is odd. One client works, one client does not. I personally
> would debug this by starting the older client (VSFTPD), connecting
> from the internet while running ethereal - on the server, making sure
> that I have selected the correct interface.
>
> Look at the ports selected and where the traffic is - and then look at
> it when you run PureFtp,
>
> One is probably running in a different mode than the other - or it
> could be a bug or something silly.- I've seen server processes die
> because the packets came up broken up unexpectedly.
>
> You can also try telnetting unto the FTP control port with a telnet
> command.  You can't transfer data that way, but you can see if you can
> connect at all. As long as you do not list a directory or transfer a
> file, you can do a fair amount of diagnosis.
>
> The way a modern NAT enabled router does FTP, either passive or
> active, is to actually parse the control stream, and look for the
> instructions that talk about the secondary port connections.  Then it
> will alter the data passed in the control stream to reflect the ports
> and addresses that it is going to use.
>
> I said that to say this:  Some routers completely reconstruct the
> stream, and others expect the port address to be passed in a single
> TCP packet, an expectation that is totally broken, but easier to deal
> with in the router software. There are other bugs in this process,
> that is only one.
>
> There is also the "port" vs. "passive" issue.  From the client's
> viewpoint, "port" means that the server will open a connection to the
> client when an ftp data transfer is to be done - that is, that is,
> connections go client->server for the control connection, but for
> every data transfer, the connection is server->client.
>
> In "passive" mode, all connections are client->server.  The control
> connection goes that way, of course. When a data connection is called
> for, the server tells the client which port to connect to, and the
> client connects to that port.  Of course, when the server is behind a
> translating device, the device has to alter the message sent by the
> server that indicates which address and port to connect to, and it has
> to then set up a translation so that when the client connects to that
> port it will NAT the packets back to the inside.
>
> So there are a lot of possible failure points.  Good luck with the diagnosis.
>
> Anyway, that is where I'd start looking for problems.  Good luck.
>
>   

--Boundary_(ID_km/DxqghoJPUCNBbi4eluA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
THanks, very enlightening post. I'll give it a try a comment later.<br>
<br>
REgards, <br>
<br>
Andy<br>
<blockquote
 cite="mida5a3926e0801300917y6cf06cc7p6251442cbfd7f6c2@mail.gmail.com"
 type="cite">
  <pre wrap="">On Jan 30, 2008 7:47 AM, Andr&eacute;s Ledesma - <a class="moz-txt-link-abbreviated" href="mailto:aledes@euskalnet.net">aledes@euskalnet.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:+flux+simicich+d3204ec66a.aledes#euskalnet.net@spamgourmet.com">&lt;+flux+simicich+d3204ec66a.aledes#euskalnet.net@spamgourmet.com&gt;</a>
wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi Nicholas,

You're absolutely right. Stopped the vsftpd, and instaled PureFtp, out
of the box I can connect to it with a 'ftp' user.
 From the internet, I can't, again.

Gotta discover how to enroute it. Could it be that adsl test pages
report tome that port 20 is closed ?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Um, this is odd. One client works, one client does not. I personally
would debug this by starting the older client (VSFTPD), connecting
from the internet while running ethereal - on the server, making sure
that I have selected the correct interface.

Look at the ports selected and where the traffic is - and then look at
it when you run PureFtp,

One is probably running in a different mode than the other - or it
could be a bug or something silly.- I've seen server processes die
because the packets came up broken up unexpectedly.

You can also try telnetting unto the FTP control port with a telnet
command.  You can't transfer data that way, but you can see if you can
connect at all. As long as you do not list a directory or transfer a
file, you can do a fair amount of diagnosis.

The way a modern NAT enabled router does FTP, either passive or
active, is to actually parse the control stream, and look for the
instructions that talk about the secondary port connections.  Then it
will alter the data passed in the control stream to reflect the ports
and addresses that it is going to use.

I said that to say this:  Some routers completely reconstruct the
stream, and others expect the port address to be passed in a single
TCP packet, an expectation that is totally broken, but easier to deal
with in the router software. There are other bugs in this process,
that is only one.

There is also the "port" vs. "passive" issue.  From the client's
viewpoint, "port" means that the server will open a connection to the
client when an ftp data transfer is to be done - that is, that is,
connections go client-&gt;server for the control connection, but for
every data transfer, the connection is server-&gt;client.

In "passive" mode, all connections are client-&gt;server.  The control
connection goes that way, of course. When a data connection is called
for, the server tells the client which port to connect to, and the
client connects to that port.  Of course, when the server is behind a
translating device, the device has to alter the message sent by the
server that indicates which address and port to connect to, and it has
to then set up a translation so that when the client connects to that
port it will NAT the packets back to the inside.

So there are a lot of possible failure points.  Good luck with the diagnosis.

Anyway, that is where I'd start looking for problems.  Good luck.

  </pre>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_km/DxqghoJPUCNBbi4eluA)--