[Linux] vsftpd -- troubling connecting from the internet ...
Steven Benmosh
linux@flux.org
Wed, 30 Jan 2008 13:19:01 -0500
------=_Part_21224_20466444.1201717141134
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
If I got it right, both ftp servers suffer from the same problem, which
suggests it is a routing issue, not a server or client issue. It can't be a
configuration issue (such as allow local users, etc.), since it accepts fro=
m
the intranet.
Z.
On Jan 30, 2008 12:33 PM, Andr=E9s Ledesma <aledes@euskalnet.net> wrote:
> THanks, very enlightening post. I'll give it a try a comment later.
>
> REgards,
>
> Andy
>
> On Jan 30, 2008 7:47 AM, Andr=E9s Ledesma - aledes@euskalnet.net<+flux+s=
imicich+d3204ec66a.aledes#euskalnet.net@spamgourmet.com> <+flux+simicich+d3=
204ec66a.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 diagno=
sis.
>
> Anyway, that is where I'd start looking for problems. Good luck.
>
>
>
>
>
--=20
Check out my web site - www.words2u.net
------=_Part_21224_20466444.1201717141134
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
If I got it right, both ftp servers suffer from the same problem, which sug=
gests it is a routing issue, not a server or client issue. It can't be =
a configuration issue (such as allow local users, etc.), since it accepts f=
rom the intranet.<br>
<br>Z.<br><br><div class=3D"gmail_quote">On Jan 30, 2008 12:33 PM, Andr=E9s=
Ledesma <<a href=3D"mailto:aledes@euskalnet.net">aledes@euskalnet.net</=
a>> wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
=20
<div bgcolor=3D"#ffffff" text=3D"#000000">
THanks, very enlightening post. I'll give it a try a comment later.<br>
<br>
REgards, <br>
<br>
Andy<div><div></div><div class=3D"Wj3C7c"><br>
<blockquote cite=3D"http://mida5a3926e0801300917y6cf06cc7p6251442cbfd7f6c2@=
mail.gmail.com" type=3D"cite">
<pre>On Jan 30, 2008 7:47 AM, Andr=E9s Ledesma - <a href=3D"mailto:aledes=
@euskalnet.net" target=3D"_blank">aledes@euskalnet.net</a>
<a href=3D"mailto:+flux+simicich+d3204ec66a.aledes#euskalnet.net@spamgourme=
t.com" target=3D"_blank"><+flux+simicich+d3204ec66a.aledes#euskalnet.net=
@spamgourmet.com></a>
wrote:
</pre>
<blockquote type=3D"cite">
<pre>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>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 co=
ntrol
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 diagnosi=
s.
Anyway, that is where I'd start looking for problems. Good luck.
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Check out my web site -=
<a href=3D"http://www.words2u.net">www.words2u.net</a>
------=_Part_21224_20466444.1201717141134--