Subject: Re: ports for ftp
To: None <Timothy.Musson@zin-tech.com>
From: Daniel R. Killoran,Ph.D. <drkilloran@speakeasy.net>
List: netbsd-help
Date: 08/01/2005 19:15:43
On Aug 1, 2005, at 5:39 PM, Timothy A. Musson wrote:

> Daniel R. Killoran,Ph.D. wrote:
>
>> On Aug 1, 2005, at 11:18 AM, Timothy A. Musson wrote:
>>
>>> I believe the term you want to search for in your firewall   
>>> documentation is "keep state".
>>>
>

My firewall is hardware - an Asante FR3004LC to be exact, and has no  
provision for such stuff. I also use my OS-X software firewall as  
well, as an additional obstacle, but it doesn't interfere with the FTP.



>> Thanks all! A little "sniffing" revealed that ftp had grabbed a  
>> port  in the 5100 range and insisted on using it for data transfer  
>> or  something like that. Odd - I thought it used port 20 for  
>> that.  Anyway, I have to open up that range to get ftp to work.
>> Dan Killoran
>>
>
> No, you really need to enable "keep state", "connection tracking",  
> or "session tracking" in your firewall. Why? The short story is  
> that FTP just doesn't work through a firewall without it. There are  
> caveats, explained in the the long story below. Here's what happens:
> (Approximately; if I'm too far off I'm sure someone will enlighten  
> us both. I'm leaving out source port numbers to keep things simple.)
>
> FTP Client -- Connection request to port 20 --> FTP Server
> FTP Client <-- "Yeah, I'm here. I'll connect back to you on port  
> 12345." -- FTP Server
> Connection on Server port 20 is closed.
> FTP Client opens port 12345.
> FTP Server spawns a child.
> FTP Client <-- Connection request on port 12345 -- FTP Server  
> (child process)
> FTP SESSION over client-side port 12345 (put/get requests, data  
> transfer, et. all)
>
> Now, IIRC, that client-side port (12345 in this example) is random  
> and can be any of the non-privilege ports, meaning you'd have to  
> allow public access to essentially all of the ports on your  
> computer. That's not much of a firewall, obviously. What this means  
> for your current configuration is that the next time you try an  
> FTP, you are likely to have more problems. How often you have  
> problems depends on the percentage of the public ports that you've  
> already opened up.
>
> Most firewalls nowadays have been made smart enough to watch for an  
> outgoing connection request and then dynamically open a single port  
> for a short amount of time in order to allow the back-connection  
> that standard FTP requires. This is what terms like "connection  
> tracking" refer to.
>
> If you're having problems with a dedicated firewall unit (like a D- 
> Link or Linksys, etc.) that you configure through a web page, the  
> option you're looking for might be under a page labeled  
> "Applications" or some such. You don't want one for "allow incoming  
> FTP requests" (unless you want to run an FTP server). You want  
> something that allows Active FTP sessions.
>

Aha! Then that's what I will do! The FR3004LC DOES have provision for  
that, and probably includes FTP.


> The Passive FTP stuff that Theo Borm was talking about is where the  
> FTP Server does not make a back-connection to the client. This mode  
> of FTP works fine with older and/or simpler firewalls, but many  
> large FTP sites do not allow that type of connection due to  
> performance issues (all traffic happens over port 20, as you said  
> earlier; meaning that only one client can connect at a time). Your  
> FTP client likely attempted passive mode by default and got  
> rejected, but you can go ahead and try to force it anyway (with -p ?).
>

I do, in fact. There is a checkbox in the OS-X firewall software for  
this. That's probably why that firewall gives no trouble.

Thanks to all!

Dan Killoran