- This topic is empty.
August 9, 2010 at 2:39 pm #30050
Been troubleshooting a passive connection issue for a while. Connections would work under FTPS (explicit) but not under FTP passive. I was not getting different passive IP’s and ports on the client and server so did not think to change the “Specify PASV IP” option under interfaces for the machine IP to itself as suggested in the FAQ for this issue. I finally changed this to itself and passive is now working. The issue I am seeing now is that when connecting over FTPS the server is advertising the internal IP during the passive phase. My client (FileZilla) is smart enough to fallback to the server public IP to complete the connection but I cannot rely that all clients will do this. Under the “Default FTP and FTPS” interfaces I do have the external IP of the server entered in the Specify PASV IP field. Any thoughts on how to get Cerberus to advertise my external IP for FTPS but still have the internal PASV IP for Passive FTP so it will work with my Sonicwall firewall (which is obviously modifying the unencrypted FTP packets)?
Steve T.August 9, 2010 at 4:17 pm #35858
I’ve had more than one user experience this problem with Sonicwall firewalls and there really aren’t any great solutions. One idea is to dedicate a listener for normal FTP traffic and another for FTPES traffic. You can configure the FTPES interface to “Require Secure Control and Data” connections to try to force people to only connect using explicit FTPES.
I know that this is far from ideal.
I haven’t considered it before but another option would be for us to add an additional configuration option to use the external IP for FTPES only for an interface. I’m very much against adding another work-around for what is already a complicated setup. This really is a firewall issue and I’m curious if Sonicwall firewall has addressed it yet or has a work-around. Have you contacted Sonicwall yet? I will investigate adding a configuration-file only option (not exposed through the UI) for special FTPES passive handling.
BTW, I’ve updated the FAQ entry to try to cover these types of issues.August 9, 2010 at 5:22 pm #35859
I initially tried two listeners, one defined for FTP and the second for FTPES. Though the FTPES definition had the external IP entered for PASV it was still passing the internal IP setup under the FTP definition. To me, this would be an ideal solution (having a second listener defined for FTPES) if it would work. As I’m working in an virtual environment, I may try adding a second IP to the server (with the FTPES listener on it) and try port forwarding on the Sonicwall in lieu of the NAT setup currently in use. Not sure this would be worth the effort if you can get a fix out.
SteveAugust 9, 2010 at 5:32 pm #35860
If I read your last post correctly, it sounds like the second, dedicated FTPES was giving out the internal IP address even though you configured it to give out the external address. That should not have happened. Can you try again and verify that it wasn’t working as expected? What about if you restart the FTP Server (shouldn’t be necessary)?August 9, 2010 at 5:46 pm #35861
That is correct. I just verified and also restarted the server service, no change. To verify it was reading the PASV from the FTP listener I changed this PASV to my external IP. After this it started passing my external IP to the FileZilla client. Of course the passive connections fail under this setup.
Not sure if this matters but both listeners are defined on the same machine IP.August 9, 2010 at 5:54 pm #35862
I can’t seem to duplicate this behavior and there should really be no link between two separate listeners on different ports. Their configurations are maintained entirely separately.
Would it possible for you to send me your interfaces.xml file and maybe a recent log file? If there is a bug I can reproduce I can get it corrected before tonight’s release.
- You must be logged in to reply to this topic.