1

I have setup an FTP service in Windows Azure using this guide http://www.itq.nl/blogs/post/Walkthrough-Hosting-FTP-on-IIS-75-in-Windows-Azure-VM.aspx

The FTP Server works well when I connect without SSL when sitting at work behind my office firewall.

BUT when I try to connect with SSL (port 21, AUTH TLS - Explicit , CuteFTP), I get a timeout. When I do exactly the same at home, the connection works (SSL). What am I doing wrong? Is the SSL connection using other ports?

Authentication works fine, it's when the client sends the LIST command the timeout comes

STATUS:>    [11.02.2013 12:56:28] Using UTF-8.
STATUS:>    [11.02.2013 12:56:28] This site can resume broken downloads.
COMMAND:>   [11.02.2013 12:56:28] REST 0
        [11.02.2013 12:56:28] 350 Restarting at 0.
COMMAND:>   [11.02.2013 12:56:28] PBSZ 0
        [11.02.2013 12:56:28] 200 PBSZ command successful.
COMMAND:>   [11.02.2013 12:56:28] PROT P
        [11.02.2013 12:56:28] 200 PROT command successful.
COMMAND:>   [11.02.2013 12:56:28] PASV
        [11.02.2013 12:56:28] 227 Entering Passive Mode (***,**,**,201,27,92).
COMMAND:>   [11.02.2013 12:56:28] LIST
STATUS:>    [11.02.2013 12:56:28] Connecting FTP data socket... ***.**.**.201:7004...
ERROR:>     [11.02.2013 12:56:49] The connection failed due to an error or timeout.

I read something about trouble with FTPS and NAT but didn't quite catch it

Martin
  • 113
  • 1
  • 6
  • You don't say **where** in the process things fail. From the office, are you able to make the control connection (login, give commands) but not the data connection (directory listing, file transfer)? Give us more details, preferably by editing them into your question; we can probably be more help. – MadHatter Feb 11 '13 at 09:22

1 Answers1

5

Ah, that makes more sense. The problem here is the two-channel nature of FTP, plus encryption, plus (most likely) an adaptive firewall en route.

What happens when an FTP control connection requests some data (which includes a directory listing) is that a new connection is built; from server to client in ACTIVE mode (which is uncommon) or from client to server in PASSIVE mode (which is more common).

The details of this connection are agreed over the control channel, the new connection is opened in the direction appropriate to the mode, and data then flows (I'll assume that it's PASSIVE mode for the rest of this answer; things are similar, but even more complicated, if you're trying to use ACTIVE mode).

Unless there's a firewall in place. If the firewall doesn't allow arbitrary TCP connections from inside to outside, then the data channel can't be built.

Unless the firewall is clever, and is watching the control data stream, looking for the FTP PORT command that is the precursor to a data channel being built. Then a clever firewall will open up a temporary permission and/or port-mapping for the duration of that data channel. This is often called adaptive firewalling.

Unless the control channel is end-to-end encrypted, in which case the firewall has no idea that a data channel is being negotiated, and the temporary permissions can't be granted.

Does that make sense? Basically, your use of SSL is very likely preventing your firewall from knowing that it should get clever about this, which is why it works without SSL from the office, and works fine from home where you probably don't have such a sophisticated firewall.

The only way to get this to work from the office without dropping encryption will be to get the firewall admin to allow you to make arbitrary TCP connections outbound from your desktop to the ftp server.

MadHatter
  • 79,770
  • 20
  • 184
  • 232