using untangle firewall and SSL FTP not working

I am using Untagle Firewall 7.2 and I FileZilla client trying to connect to an SSL FTP server.
Others from other networks are connecting ok, but I am not.  I tested my PC bypassing my firewall and it works fine, so that's why I know it's my firewall.  We opened all ports on it, and it's still not working.  We tried port fording, but not exactly sure how to configure that.
Any help would be greatly appreciated.
I know the initial connection connects to the FTP server, because the admin from the remote site says he see's my IP address connect, but when it trys to negotiate using the SSL encryption, that's where it doesn't work.
afactsNetwork EngineerAsked:
Who is Participating?
giltjrConnect With a Mentor Commented:
Are you sure it is on the SSL negotiation?  A firewall should not prevent SSL negotiation, but it could prevent data transfers for FTP SSL.
afactsNetwork EngineerAuthor Commented:
I'm possitive, because here's what happens, it makes the initial connection and actually logs in, but when it tries to display the directory listing, it failes.  I have other users outside of the organization from different parts of the U.S. that connect just fine, so that's why I know it's the untangle firwall.  I had the user put the computer before the firewall, and it worked fine, so that's why I'm 100% positive it is the firewall.

Status:      Connecting to
Status:      Connection established, waiting for welcome message...
Response:      220-FileZilla Server version 0.9.34 beta
Response:      220-written by Tim Kosse (
Response:      220 Please visit
Command:      AUTH TLS
Response:      234 Using authentication type TLS
Status:      Initializing TLS...
Status:      Verifying certificate...
Command:      USER xxx
Status:      TLS/SSL connection established.
Response:      331 Password required for dan
Command:      PASS *******
Response:      230 Logged on
Command:      SYST
Response:      215 UNIX emulated by FileZilla
Command:      FEAT
Response:      211-Features:
Response:       MDTM
Response:       REST STREAM
Response:       SIZE
Response:       MLST type*;size*;modify*;
Response:       MLSD
Response:       AUTH SSL
Response:       AUTH TLS
Response:       UTF8
Response:       CLNT
Response:       MFMT
Response:      211 End
Command:      PBSZ 0
Response:      200 PBSZ=0
Command:      PROT P
Response:      200 Protection level set to P
Status:      Connected
Status:      Retrieving directory listing...
Command:      PWD
Response:      257 "/" is current directory.
Command:      TYPE I
Response:      200 Type set to I
Command:      PASV
Response:      227 Entering Passive Mode (64,55,xxx,xxx,195,121)
Command:      MLSD
Response:      425 Can't open data connection.
Error:      Failed to retrieve directory listing
afactsNetwork EngineerAuthor Commented:
It's been fixed, it looks like the only thing needed is to have a Bypass rule for your destination address.
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

afactsNetwork EngineerAuthor Commented:
I'm giving you the points for your willingness to help.
Here's the solution:
It's been fixed, it looks like the only thing needed is to have a Bypass rule for your destination address.
Thanks for the points and I'm sorry some how I missed your update.

Your problem is not all that abonormal when doing FTP SSL.  Although you solved it with a bypass rule, typically the problem is that the firewall is doing NAT can not see the PORT or PASV command to change the IP address used in the PORT/PASV command nor can it dynamically allow the port that is used in the PORT/PASV command either.

Normally this is resloved by:

1) When using active ftp both firewalls are configured to allow port 20 as a source port and all high ports as the destination.


2) When using passive ftp, the ftp server is configured to use a specific port range and both firewalls are configured to allow all high ports as the source and the specific range as the destination.


3) Using a ftp server and client that support the use if extended mode (EPSV or EPRT) commands which do not have IP addresses, but just the ports.


4) Using a ftp server and client that support the CCC command which will turn off encryption on the command/control connection after authentication to allow the firewall to see the PORT/PASV command, but still have the data connection encrypted.


5) Doing something else that allows the public IP address to be inserted into the PASV/PORT commands.
afactsNetwork EngineerAuthor Commented:
Thanks for those details.

You know, you might be able to help me with this.  

Currently, for some strange reason, externally, from the internet, it sometimes works and sometimes it doesn't.  For example, almost the whole day yesterday, everything worked fine, but at around 7 or 8 pm, I had some users complain that they can't connect to the FTP server.  I tried connecting today as welI externally, and it still does not work.  I have not made any changes to my firewall for weeks.
I tried stopping and starting the FTP service, but still does not help.
Internally, on my LAN, it always works, so this leads me to believe that it's something with my firewall?
Do you have some clues what it might be?
Thanks, Dan.
I have the same exact setup, and am having the same problem.

I tried a bypass rule, and I still get this error

150 Opening data channel for directory list.  
425 Can't open data connection.  
LIST command failed
Error loading directory...

My untangle box has a port forward of 20, 21

then my firewall has bypass of 20,21 in

and all ports out open.

then I have a bypass to the clients IP.
afactsNetwork EngineerAuthor Commented:
I'm not using the untangle firewall anymore, but have you tried creating a test rule, to open up everything and see if it works then?  Then you can start creating different rules that might help you?
ya, I tried shutting off the whole ftp, but it didn't work

this is what I was told to do.

do a port forward on 21 --> server

then, do another port forward of the passive range eg 1024 - 6000 ----> server

but I didn't try it because I got webdav to work, and it uses port 80 only.

feel much better that I don't have to open a huge port range just to get ftp to work :)
afactsNetwork EngineerAuthor Commented:
can you upload your screenshots of your FTP server?

What you were told to do is one option that you could do do in order to get FTP SSL to work.  The other option would be to make sure you server and client support the CCC (clear channel command) option.

Using passive FTP the port number the server listens on for the data connection is passed to the client in the response to the PASV/EPSV (EPSV is normally better for FTP SSL) command.

By using the CCC command, you start sending information on the command channel (port 21) in clear text.  Since you have already been authenticated there is no risk of somebody seeing user-id passwords.  When the PASV command is issued the firewall will see it and (assuming untangle supports it) will do any NAT and dynamically allow the data connection to be established.

If you do not use the CCC command this means the PASV/EPSV command is encrypted and so the firewall can't see it and thus can do any NAT'ing or dynamically allow the data connection.  EPSV is better than PASV because it does not pass the IP address of the server.  The  PASV command passes the IP address of the FTP server and since it is encrypted the firewall can't do any NAT translation on the PASV command.  This means that the client would try and connect to the servers real IP address.  If this is not publicly available, they will never connect.  Now, some ftp clients will ignore the address on the PASV command and automatically connect to the IP address that the command connection is on.
So does that mean CCC uses port 21, up and down?

that would be really cool. I like to keep the firewall as tight as possible

CCC is a command.  It will be transported on port 21, but the actual data will be sent on the data channel.  Using CCC just allows firewalls that sniff port 21 for PORT/PASV/EPRT/EPSV commands when doing FTP SSL.
what are the ports. sorry for my ignorance. is the data channel 20? or is it that huge ip block 1024-6000 or whatever it is
It depends.  FTP has active data transfers and passive data transers.

With active data transfers the server acts like the client and initiates a TCP connect FROM port 20 (that is the source port is 20) to a random high port to the client.

Passive data transfers the client connects from a random high port to a "random" high port on the server.  Now on the server typically you can code a range of ports so its not really "random", but a specific range you specify.
Ya! that's the part that makes me nuts lol! I don't feel right opening up a whole port range for a login. lol

can't someone just redesign ftp :)
No.  Most people are switching to SFTP which is a FTP like function using SSH.  The gotach with that is if you don't secure it correctly you can allow people to ssh into your server.  If you don't mind that, then it easy to setup.  If you don't want the users to ssh into your server, then you have a little work to do so that they can only sftp.

I don't know for a fact, but I would assume that ftp was designed as a two port protocol so you would not have to use special escape sequences for the start and end of the data.  By using a data port, everything on the data port was part of the file.  It actually makes programming a ftp server/client much easier.
All Courses

From novice to tech pro — start learning today.