Probably not. Most of these proxies send various http progress messages back to the client. Frox is unable to parse these without giving it a more extensive http implementation, and so it will probably fail. Also there will be a delay before the client starts to get the file, and it may well time out during this period. There is interest in being able to do this though, so if anyone wants to try coding it then they are welcome.

Unless compiled with --enable-run-as-root you must specify a non root user and group for frox to run as. It is strongly recommended that you do this rather than recompiling.

You must specify WorkingDir for frox in the config file. By default it will also chroot to this directory. If you do not wish to run chrooted you must explicitly set DontChroot to "yes" in the config file.

Access to frox is controlled by the access control lists in the config file. These take the format ACL ACTION CLIENT - [USER@]SERVER [PORTS] ACTION can be one of Deny or Allow. CLIENT and SERVER are either a domain name, a *, an ip address, or an address/netmask in either x.x.x.x/y or x.x.x.x/y.y.y.y form. PORTS is optional. If present it should contain one or more port numbers or ranges of port numbers, separated by &dquot;,&dquot;. There should be no whitespace within the PORTS string. If no ports are specified then ports are not taken into account in matching that rule.USER is also optional. If present then note that it should be ftp to match any anonymous connections.

Acls are checked after the client has connected to frox, but before frox connects to the server. If non-transparent proxying is enabled then the client will enter the username before the acl is checked. The acls are checked in the order they appear in the config file until one matches. If no acls match the connection is denied.

Frox has optional support for a ftp-proxy like command control program (ccp). Just to confuse things there are two different ways that this can work. The default is still the old version based on ftp-proxy, while the new version is a bit more like the squid redirector interface.

To use either method you should compile with --enable-ccp, and set CCProgram to the program you wish use. This must be within the chroot jail with any libraries and/or shells it needs to run. To use the new version you should also explicitly set UseOldCCP to no in the config file.

There is very experimental (currently only tested with vsftpd) support for having frox use encryption when connecting to the ftp server. You need to give --enable-ssl to ./configure, and define UseSSL yes in the config file. By default data connections will also be encrypted, but you can turn this off by setting DataSSL no. Note you will need to create /dev/urandom and /dev/random at least in the chroot jail, and possibly some other stuff, for the openssl libraries to work. If you are having difficulties try defining DontChroot yes temporarily to see if it fixes things.

Note SSL support currently only covers the connection between frox and the ftp server. Frox does not support clients connecting to it with SSL at the moment.

It is suggested to have a config file subsection which turns off SSL for anonymous connections. There is little point in having the overhead of encryption for this, and ftp servers may deny an anonymous connection once SSL has been negotiated (this is the default configuration of vsftpd). At this stage frox is not able to undo the ssl negotiation.

This is not yet rfc compliant. It should be at some point...

Look at the log file that frox produces and see if it gives you any clues. It should say ``Connect from A to B''. If it doesn't say anything then you aren't getting through to frox at all - check the config file to see frox is listening on the right address/interface. Have you remembered to do the ipchains/iptables command that is in the INSTALL file?

If the log file suggests frox is connecting back to itself then you are probably contacting it directly and non-transparent proxying is switched off. Either switch non-transparent proxying on in the config file, or make sure that your ftp client is not trying to connect directly to frox - either from you specifying the frox machine as the ftp host on the command line, or from the client trying to use it explicitly as a proxy.

If you have a complicated network setup then check the section.

Read the section again

There are two likely causes for this. One is that you are trying to do non-transparent proxying, but the config file is not setup correctly. Ensure that DoNTP is set to yes in the config file, and comment out NTPAddress - it is never necessary and only serves a purpose if you are doing a mixture of transparent and non-transparent proxying.

The other possiblity is that your connection is transparently redirected to frox, but frox is unable to determine the orriginal destination. The most likely cause is if you are using Linux kernel 2.4.x with ipchains compatability. I do not know of a way around this short of changing from ipchains to iptables (or changing back to a 2.2.x kernel!).

Check whether you have NTPAddress set. If this is set then it must be set to the address and port that the ftp clients are using to contact the proxy, otherwise clients will not be offered non transparent proxying. If you unset it then all clients will be offered non transparent proxying.

If you have HTTP caching set up then frox should conduct all anonymous downloads through your proxy. But, frox also needs to make an ftp connection to the remote ftp server for retrieving directory listings etc. Therefore if you do netstat or equivalent you will not see a connection from frox to squid unless a file download is actually in progress.

This also means that you cannot use frox + squid and then firewall off ftp access to the outside world altogether. Your best bet is to keep frox (with or without squid), and set ApConv to yes in the config file. You will still need to allow frox to make outbound tcp connections on port 21, and any ports in the PasvPorts range, but you should not have any of the usual problems associated with firewalling ftp.

With HTTP caching frox makes a connection to the ftp server initially, and then the http proxy/cache makes its own connection when you initiate a download. If the http proxy and frox are both at the same IP address then there will be problems with any ftp server (and there are a few) which only allow one connection per host.

The workaround is not to use http caching! You can either do this globally, or put in a specific config file subsection to turn off caching for any hosts that you have this problem with. A better workaround should appear in a future version.

As of version 0.7.8 frox scans the username from right to left when looking for the dividing @. If your username on the remote server is abc@def.org and you are logging in to ftp.gnu.org you can simply give "abc@def.org@ftp.gnu.org" to frox as your username.

If you are using both transparent and non-transparent proxying then you will need to use the NTPAddress option so that when your direct connection to ftp.gnu.org is intercepted by frox it won't interpret your username "abc@def.org" as a login to def.org with username abc.

Audiogalaxy is a music sharing program. Although audiogalaxy works through port 21 it does not use the ftp protocol, and therefore frox does not allow its connections through. If you are using frox as a transparent proxy and you wish to use audiogalaxy then you need to change your iptables/netfilter rules so that packets addressed to the audiogalaxy servers do not pass through frox. Fortunately audiogalaxy does not use port 21 to contact other machines using the audiogalaxy client so these do not also need to be added.

There is a mailing list at ./configure at compile time, and what point exactly it fails at. The log file should give you some info, especially if you set LogLevel to 25.

If you are running frox on a machine on your default route, and with little or no firewalling between it and either the outside world or your internal network you should not have network problems. Because of the nature of the ftp protocol though, if your setup is more complicated than this then you may run into difficulties.

The easiest way of checking that your network setup isn't what is causing the problems is to (temporarily if you wish) run an ftp server on the machine which runs frox. If you can't ftp from your clients to this server and retrieve files O.K. then your clients won't be able to ftp to frox either. Also try running an ftp client on the frox machine and connecting to a server in the outside world. If this doesn't work then frox obviously won't be able to do this either.

With a control connection problem your clients will not be able to connect to ftp servers through frox at all. If transparently proxying then check that outgoing tcp traffic is being redirected to frox without changing the destination address (ie. you must route it there, not use DNAT), and that the machine running frox can make a tcp connection to the outside world successfully

If the problem is with the data connection then your clients will be able to connect to the ftp server, login, and do things like print the current working directory. File retrievals and directory listings will fail, though you may find that passive mode ftp works and active doesn't, or visa versa.

If you are having these problems I strongly reccomend that you set TransparentData to no, and ApConv to yes in the config file. The frox machine must be able to make tcp connections on any port to the outside world. It should also be possible to establish tcp connections in either direction between the frox machine and the client machines, and with no NAT being performed on these connections. With this setup you shouldn't have any problems.

The above suggestions aren't strictly necessary, but things get more complicated without them. ApConv = no: Either incoming tcp connections must be allowed from the outside world to the machine running frox, or they must be prevented only by a NATed (IP masquerading) firewall which is configured to allow ftp connections (eg. linux + ipt_nat_ftp.o module) If frox cannot make tcp connections to the client then clients are limited to passive mode ftp. If clients cannot make arbitrary tcp connections to frox then they are limited to active mode ftp. NAT between client and frox: If DNAT occurs when the client connects to frox (ie. the client makes the connection to a different IP to that which the packets frox eventually receives are addressed to then you should set PASVAddress to the IP which the clients should use. NB. This option doesn't actually exist yet, but let me know if you need it and I'll consider adding it. TransparentData = yes: This can make things really unpleasant. Are you sure you need it? These are the problems which spring to mind... Frox should be in your default route for outgoing tcp traffic. If you are using policy based routing to route only port 21 tcp traffic to frox then TransparentData will not work. Beware that frox will make connections to your clients that purport to be from arbitrary hosts outside your network. If there is a firewall/router between your frox and your clients with IP spoofing protection it must let these packets through. Have another read of SECURITY to remind yourself of the extra risks you are taking.

The following is a description from Travis Richardson on how to use frox to tunnel all your ftp connections through an ssh link:

Object:

Tunnel ftp connections from my laptop to my server, and from there out into the world (I'm assuming here (for my own reasons) that my server's connection / routing is more secure than my laptop's). I want to tunnel both control AND data connections, so I can't just use a single tunnel with Frox.

Solution:

Install Zebedee (an open source tunnel - see http://www.winton.org.uk/zebedee/) on your server and client Configure the zebedee server to allow tunnels to 127.0.0.1:3121 (Frox's default port) and for your data connections (eg: 127.0.0.1:41000-41049) Configure your local zebedee client to forward the local versions of these ports to 127.0.0.1 on your server (eg: 3121:127.0.0.1:3121 and 41000-41049:127.0.0.1:41000:41049). You must use 127.0.0.1 instead of my.server.com because Frox will be listening for a data connection on 127.0.0.1 (what you will set PASVAddress to) and won't accept connections on other IPs. It looks weird, but it works. Configure Frox to listen on 127.0.0.1:3121 Configure Frox with PASVAddress to 127.0.0.1 (which will cause your FTP client to connect to localhost, which will be forwarded / tunneled by zebedee to the localhost on your server) and PassivePorts to your port range above (eg: 41000-41049)

Done! Restart / start your zebedee server / client and Frox and set your FTP client to use the new proxy at 127.0.0.1:3121. Should work like a charm.

If you are using the grsecurity kernel patch and also local caching in frox then note that frox does a chown within a chroot jail. If you have disabled this then you will need to manually change the ownership of the frox-cache socket file in the working dir the first time you run frox.