Secure FTP over SSL/TLS

Do you have the FTP Proxy enabled?  Try turning it off.  If you are using the HTTP Proxy, remove the FTP service from the list of allowed services, or define an exception for the secure FTP server in the advanced tab.

Thanks for the quick reply!  No, I do not have the FTP proxy enabled.  I should've been more specific in my original post.  The secure FTP server is at my hosting company (not behind my ASG).  I am simply trying to establish a secure connection from my machine which is behind the ASG.  I seem to remember when we setup the FTPS that we had the initial port (21) and then a range of data ports over which the encrypted data traveled.  I have a request in to my hosting company to find out which ports, then I will try to add a rule to allow traffic from my server on those specific ports.

That's what I was assuming; I meant to make sure you don't have FTP Proxy enabled at on the "client" side... also, are you using HTTP Proxy? If so, make sure you have an exception for the destination site entered in the advanced section.  If this isn't the problem, then you've probably got the ports wrong... Good Luck.

I have the port range that the FTPS server uses for the data connection (in addition to TCP port 21, 9000-9015) to establish a secure FTP over SSL connection.  However, I can't seem to get the ASG to allow the traffic.  When I login to the FTPS server using my FTP client it lets me login, and shows a successful login, but then it tries to establish the encrypted data connection on that range of defined ports and eventually it times out while trying to display the directory contents.

I tried removing FTP from the allowed services in the HTTP Proxy as recommended above, but that didn't work.   I also added the IP of the FTPS server in the exception list of the HTTP Proxy but it didn't work.

I created a DNAT/SNAT rule (I tried both types) with the following settings:

DNAT [FTPS Data]
Traffic selector: IP of FTPS server → FTPS Data 9000-9015 → Any
Destination translation: IP of FTPS server FTPS Data 9000-9015
Automatic packet filter rule: X

I also created a packet filter rule with the following settings:

IP of FTPS server -> Internal (Network)
Service: FTPS Data 9000-9015

But I must be doing something wrong here because it's not working.  It worked fine with my Netgear router before I switched over to the ASG.  Any other suggestions?

Try Active FTP instead of Passive, in the client.

Barry

Barry,

Thanks for the reply.  I did try both active and passive FTP modes in the client, but neither worked.  [:(]

Run the Live log for the packet filter, and attempt the connection, I'll bet you'll see some dropped packets in there.

Another thing; if you are using the HTTP Proxy, make sure you put in exceptions for that site, otherwise your FTP client may try to run these through the proxy.

Run the Live log for the packet filter, and attempt the connection, I'll bet you'll see some dropped packets in there.

Another thing; if you are using the HTTP Proxy, make sure you put in exceptions for that site, otherwise your FTP client may try to run these through the proxy.

I checked the packet filter log and sure enough ASG is blocking outbound requests from the client to the server on the affected ports.  I imagine it would be easy to define a packet filter rule to allow traffic on these ports/IP addresses.

If I were to define an exception in the HTTP Proxy for the FTPS server as you mention, what checks should I skip?  Would it be necessary to define both an HTTP Proxy exception as well as a packet filter rule?

Thanks!

I would define the destination site that you want the HTTP proxy (I'm assuming transparent mode here) to use in the Web Security / HTTP / Advanced Tab, in the Transparent Mode Skiplist... the Exceptions tab will NOT do what we need to do here.  You may also need to define those packet filter rules that match the blocked ports as well.

This one has me very puzzled!  It's as though the ASG is totally ignoring my packet filter rules and dropping packets to the ports I specifically allow in the packet filter rules.  The HTTP proxy is not filtering the FTPS connections (the live log doesn't show anything when attempting a connection).  The Packet Filter live log does indeed continue to show that the secondary set of ports (for the data connection) are being dropped.

My packet filter rules are to allow Source: Internal Network -> Destination: IP of FTPS server, Service FTPS Data - 1:65535 -> 9000-9015.  But upon inspecting the live PF log, it shows the packet drops:

Default DROP  TCP 192.168.1.5:1471 → ip.of.FTP.server:9008 [SYN]  len=48  ttl=127  tos=0x00

It's as though there is some stateful packet inspection that is not occurring properly.  Surely the ASG must know that there is another set of ports associated with the main control connection over port 21.  To that end, I have made sure that the so-called "Connection tracking helper" for FTP is enabled (Network Security -> Packet Filter, Advanced tab).

What else could be causing the ASG to purposely drop these packets?

DUH!  I feel really really embarrassed!  The problem was that I somehow had the wrong IP address in the packet rule for the FTPS server.  [:$]

Bottom line:  In order to get FTPS (secure FTP over SSL) to work, I had to create two packet filter rules (Network Security -> Packet filter)

Internal Network -> Any (Service: FTP, port 21)

and

Internal Network -> Any (or the IP of the FTP server) (Service: FTPS data port range, 9000-9015, or whatever your server uses for its data ports).

Thanks so much to everyone for the replies.

Now, if I could only get my e-mail notifications to work... [:)]

Glad to hear you got it worked out... I can't say something like this hasn't happened to me before, no need to be embarrassed (everybody's human, at least as far as I know)... at least you didn't take the tact that some folks do on the board sometimes that there's some defect in the software that's causing a problem, when it's just a config problem (not that we haven't discovered bugs here before, though).

Glad to hear you got it worked out... I can't say something like this hasn't happened to me before, no need to be embarrassed (everybody's human, at least as far as I know)... at least you didn't take the tact that some folks do on the board sometimes that there's some defect in the software that's causing a problem, when it's just a config problem (not that we haven't discovered bugs here before, though).