Problem with passive FTP on new CloudMan Galaxy instance

Question: Problem with passive FTP on new CloudMan Galaxy instance

4.6 years ago by

United States

Ok, different but non-lethal FTP problem with the latest CloudMan FTP server. I can't seem to be able to get my clients (either command-line FTP from Mac OSX or FileZila running on mac OSX) stably connect to the server. Only if I turn to active transfer that I'm able to get it work. I first thought that this was intentional but I don't think it is as:

From the proFTPd config file (/usr/proftpd/etc/proftpd.conf), the passive ports are set to PassivePorts 30000 30100.

From the CloudMan security groups initialized at start up, the TCP pots 30000-30100 are open to all inbound traffic:

{
"ToPort": 30100,
"IpProtocol": "tcp",
"IpRanges": [
{
"CidrIp": "0.0.0.0/0"
}
],
"UserIdGroupPairs": [],
"FromPort": 30000
},

However, I still can't successfully connect to the server unless I turn the transfer to active mode. Can't seem to figure out what my issue is here.

Any help would be appreciated (unless again this is by design).

Thanks

ftp galaxy cloudman • 1.2k views

ADD COMMENT • link •

modified 4.5 years ago • written 4.6 years ago by Marco Blanchette • 10

This is a distinct issue from the others reported about Cloudman and FTP. We are investigating.

ADD REPLY • link written 4.6 years ago by Jennifer Hillman Jackson ♦ 25k

4.6 years ago by

Dannon Baker ♦ 3.7k

United States

Dannon Baker ♦ 3.7k wrote:

I'm actually having a ton of trouble replicating this. FileZilla and Cyberduck both work in both Active and Passive mode for me on a fresh cloud instance, uploading multi-gigabyte files, without any security group tweaks, etc.

Do you think there's a chance that this could perhaps be an issue with the network you're running on?

ADD COMMENT • link written 4.6 years ago by Dannon Baker ♦ 3.7k

4.5 years ago by

Marco Blanchette • 10

United States

Marco Blanchette • 10 wrote:

The problem was indeed internal... We have an alias in our dns that maps the address galaxy.sgc.loc to an elastic IP from AWS that is used to map the server. Somehow, this causes the server to lose track of the client IP (the galaxy.sgc.loc is only resolvable within our network). The fix that our IT team came with was to add the following line to the proFTPd setting (well, using the real IP):

MasqueradeAddress 54.122.33.155

Not sure if there is a better more deployable solution that could be implemented but at least, this fixes our issue.

Similar posts • Search »