Menu
▾
▴
RE: [Proftpd-user] Configuring FTP behind a firewall
|
From: gwichman <gwi...@at...> - 2002-10-01 15:55:20
|
Thanks for the response. I looked for stateful inspection support and found it on my firewall. But also in searching around google I found another pair of settings that seems to be the trick to get proftpd to work from behind a firewall even when the client is also behind one. By using "PassivePorts" and mapping those ports to your firewall, as well as "MasqueradeIP" and assign your public IP to that, you can get it to work in pasv mode. It's working great now. Anyways just wanted to follow up on my findings. Thakns again. -Gerald -----Original Message----- From: pro...@pr... [mailto:pro...@pr...] On Behalf Of Stefaan A Eeckels Sent: Saturday, September 28, 2002 4:49 PM To: pro...@pr... Subject: Re: [Proftpd-user] Configuring FTP behind a firewall On Sat, 28 Sep 2002 14:27:00 -0700 "gwichman" <gwi...@at...> wrote: > I've been trying to get proftpd to work from behind a firewall. Mapping > ports 20 and 21 seems to work provided the client is not also behind a > firewall. But if both my server and the client are behind one, I can't > seem to get it to work either via non-pasv or pasv. I've put the output > of both attempts below. Your first example is indeed using passive mode, which means that the server informs the client that it is listening on a specific port at a specific address: 227 Entering Passive Mode (10,1,1,2,15,221). The client is supposed to parse this line and connect to IP address 10.1.1.2 on port 4061. The other mode is called "PORT" mode, and basically reverses the roles of client and server: PORT 192,168,123,192,7,222 200 PORT command successful. The client informs the server that it is listening on IP address 192.168.123.192 and port 2014, whereupon the server connects to the port opened by the client. Now it's easy to see why this can cause problems when using a NAT-based firewall - the addresses known to the machines behind such a beast are private, and hence serve no purpose when conveyed to the other party. The NAT firewall has to look inside each packet on the FTP control port and change the contents of the "PORT" command or the 227 reply to reflect the public address, and change the port to one available on the firewall, effectively becoming an FTP proxy. The important part of _both_ PORT and PASV is that a random port is opened for one of the systems to connect to (in other words, under no circumstances is a machine listening on port 20). > Looking at the FAQ and docs, it seems like non-pasv is the way to go but > it only seems to work when the client is not also behind a firewall. The FAQ is wrong. Port 20 is used _by the server_ to connect to the port opened by the client - there's no way to have the client use port 20 implicitely. In other words, there's always and address and a port that is communicated to one of the parties, and if both client and server are behind an NAT-firewall you're hosed _unless_ (on of) the firewalls is (are) FTP proxy(ies). > Someone else told me that yes you need to use passive when both the ftpd > and client are behind firewalls. So in trying to get pasv to work I went > ahead and used the "PassivePorts" directive and mapped those ports to my > server on the firewall as well. Judging by the passive attempt below it > did work and used one of those ports however the ftpd seems to be > telling the client to connect to 10.1.1.2:4061 instead of the > publicip:4061. Is that the problem and how do I change that (maybe by > configuring a virtualhost somehow?)? You can't expect the server to know the outside address, so it has no other option but to enter its local IP address. The firewall needs to interpret FTP packets and replace local addresses by the public one, thus acting as a proxy. Normally, a firewall that is capable of SPI (Stateful Packet Inspection) ought to be able to handle FTP properly. > Bottom line I'd like to know how to get it to work evne if both the > client and ftpd are behind firewalls. As most people are these days.. > Appreciate any assistance. The bottom line is that it's one of the NAT firewalls that needs to be able to do FTP proxying. My NAT router does this without problems: $ ftp ftp.funet.fi Connected to ftp.funet.fi. 220-Hello UNKNOWN at pppoe62-luxdsl-080.pt.lu, 220- 220-Welcome to the FUNET archive, Please login as `anonymous' with ... ftp> debug Debugging on (debug=1). ftp> dir ---> PORT 192,168,1,20,131,99 200 PORT command successful. ---> LIST 150 Opening ASCII mode data connection for . lrwxrwxrwx 1 root guru 32 Oct 28 1999 README -> \ /pub/files/staff-docs/README.FTP lrwxrwxrwx 1 root guru 38 Oct 28 1999 README.FILETYPES -> \ /pub/files/staff-docs/README.FILETYPES lrwxrwxrwx 1 root guru 34 Apr 30 2001 README.IP-REVERSAL -> \ /ftp/staff-docs/README.IP-REVERSAL As you can see, the client uses its private address in the PORT command, but the server has no problems establishing a connection. If you'd look at the packet leaving the router, you'd see that it has modified the addresses _inside_ the packet. A quick look with tethereal at the PPPoE dialogue between my router and the ADSL modem confirms that the PORT commands have been modified: 0.000000 pppoe62-luxdsl-080.pt.lu -> ftp.funet.fi FTP Request: PORT \ 213,166,62,80,69,200 0.086123 ftp.funet.fi -> pppoe62-luxdsl-080.pt.lu FTP Response: 200 PORT \ command successful. 0.119928 pppoe62-luxdsl-080.pt.lu -> ftp.funet.fi FTP Request: LIST 0.207935 ftp.funet.fi -> pppoe62-luxdsl-080.pt.lu TCP ftp-data > 17864 [SYN] \ Seq=2390392916 Ack=0 Win=8760 Len=0 0.209901 pppoe62-luxdsl-080.pt.lu -> ftp.funet.fi TCP 17864 > ftp-data \ [SYN, ACK] Seq=288197592 Ack=2390392917 Win=25118 Len=0 0.289643 ftp.funet.fi -> pppoe62-luxdsl-080.pt.lu TCP ftp-data > 17864 [ACK] \ Seq=2390392917 Ack=288197593 Win=9254 Len=0 In this example, the server could have been behind a NAT firewall itself, and the result would have been the same. Take care, -- Stefaan -- "One man alone can be pretty dumb sometimes, but for real bona fide stupidity there ain't nothing can beat teamwork." -- Mark Twain ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ ProFTPD Users List <pro...@pr...> https://lists.sourceforge.net/lists/listinfo/proftp-user |