> On Jul 7, 2015, at 4:41 PM, Steve Yates <[email protected]> wrote: > > ED Fochler wrote on Tue, Jul 7 2015 at 1:10 pm: > >> FTP is a nasty beast. There’s active, passive, and extended passive >> connections. You may need a client that does extended passive (epsv?) to >> work >> properly. Standard passive will hand back the server’s IP & data port over >> the >> control connection, so unless PFSense is altering the packets as they leave, >> or >> ProFTPd knows that it needs to respond to that IP range with a masqueraded >> IP, standard passive will get hung up. > > http://www.proftpd.org/docs/directives/linked/config_ref_MasqueradeAddress.html > > Basically that should hand out the public IP for the passive connection, > instead of the server's LAN IP. However (not tested) that may well break > internal FTP, unless perhaps requests to the WAN IP are reflected back > inside. I think I would even expect internal FTP users to have to connect > via the WAN IP also.
Yep - I’m using that. Status: Resolving address of domain.ltd Status: Connecting to public.IP:9000... Status: Connection established, waiting for welcome message... Status: Initializing TLS... Status: Verifying certificate... Status: TLS connection established. Status: Connected Status: Retrieving directory listing... Command: PWD Response: 257 "/" is the current directory Command: TYPE I Response: 200 Type set to I Command: PORT 10,20,1,49,214,167 Response: 200 PORT command successful Command: MLSD Error: Connection timed out after 20 seconds of inactivity Error: Failed to retrieve directory listing But internally it immediately connects. _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
