Have you tried another ftpd? Sounds like that might be the issue here..
[EMAIL PROTECTED] wrote:
In my configuration there is a problem providing publicly-accessible anonymous FTP service. The config works for a small number of clients, but most cannot access my server and use any command that requires a data connection. Ftpd is running on the same machine as PF. I checked the FAQ on this but the cases that are discussed there are either already represented in my pf.conf or relate to different problems. First, I observe that pf is not blocking the connections. Second, with a packet dump on the interface, it shows that when ftpd goes back to the client to make a data connection, the source IP is different from the publicly known address of the FTP server. This is due to the effect of NAT statement(s) and an attempt to manage a block of addresses. In particular, my public FTP address is advertised to be at .197, and the rules are configured for ftpd to answer requests on that address. General outgoing NAT is mapped to .199 with this command: nat on $ext_if1 from $lan_net to any -> a.b.c.199 Control connections work fine. But when ftpd attempts to make a data connection with the client, the source address is mapped to .199. I believe that the clients are ignoring this since it is not correlated to the known connection on .197. On the wire I see ftpd responses going out a number of times. The client does not respond to these packets and ultimately times out with an error about not being to establish the data connection. If there was a NAT option to qualify by user or service I might be able to make a new NAT rule that would translate to the proper address first. Any suggestions as to how to configure this behaviour in a workable arrangement ?
