0

From our office LAN, Secure FTP connections fail. But with a VPN client connection, there is no problem. What could be the cause of this problem, what do we have to change on our firewall?

I normally use another client but for comparison, I use FileZilla here. This is the connection log without VPN:

Status: Resolving address of server
Status: Connecting to ip-address:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Command:    PWD
Response:   257 "/" is the current directory
Command:    TYPE I
Response:   200 Type set to I
Command:    PASV
Response:   227 Entering Passive Mode (*).
Command:    MLSD
Error:  Transfer connection interrupted: ECONNABORTED - Connection aborted

When using a third-party, commercial VPN service using the same connection setup we get this:

Status: Disconnected from server
Status: Resolving address of server
Status: Connecting to ip-adress:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Directory listing of "/" successful

The setting used in FileZilla is "Use explicit FTP over TLS if available". Additionally: After disconnecting the FTP connection and closing the VPN connection but keeping FileZilla open the connection does work. Closing FileZilla and trying again results again in a failed connection.

Was does work, though, is unencrypted FTP, which for obvious reasons, is something we like to avoid.

Improve this question
1
  • If a VPN works, do you want to spend the time and effort to figure out how to make it work without?
    – schroeder ♦
    May 3 at 13:41

1 Answer 1

Reset to default
3

FTP is an old protocol and is not really firewall friendly. It requires one connection from a random port (on client) to port 21 on server for the command channel and a connection between a random port on client and port 20 on server per data exchange (including a directory listing). Those data connection are established by the server in the sendport mode or by the client in passive mode. If there are firewalls on the way, they have to analyze the traffic on the command channel to find which port will be used for the data channels or alternatively to let anything in either side if port 20 on server is used.

Most security teams just assume that it is now too old for them and do not tune their firewall to allow it. Worse, even if it is correctly tuned, as soon as you try to use SSL on the command channel, the firewall can no longer find the port used by the data channels...

Long story made short, contact your firewall admin to know exactly what FTP exchanges are supported. I cannot know that...

BTW, when you use a VPN, your local firewall only sees one (I assume HTTPS) connection to the VPN entry point. All other connections (FTP command and data) are encapsulated in that single channel and are opaque to the VPN. Said differently it is kind of a firewall piercing...

Improve this answer
2
  • Thanks @serge-balleste, I forgot to write that unencrypted FTP works fine from this LAN it is for obvious reasons even worse. We have to work with some hosters that do not offer anything else than FTP to upload content. And yes I know that FTP uses different control and data streams and that can thwart Firewalls.
    – theking2
    May 3 at 12:17
  • 1
    @theking2: if I correctly remember, FTPS allows to choose which channel should be encrypted. For your use case I would try to stop encryption on the command channel immediately after authentication and before any data transfer.
    – Serge Ballesta
    May 4 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.