Juniper SRX and Active and Passive FTP port forwarding

As you probably know, FTP comes in two flavours:
-Active FTP where data port 20 is used on the Server and the client offers a random port > 1023 to the Server via a “Port” command.

Hosting this behind a Juniper firewall is faily basic and works. The only thing is that you have to forward traffic to TCP control port 21 on the FTP server, and the “Application Layer Gateway” (ALG) will sniff your control packet and sense the “Port” command. From then on the SRX should allow traffic from the Client port to the server port without needing any additional configuration. This kind of works out of the box, once you get the port-forwarding setup for port 20 and allow ftp to be forwarded in a security policy.

-Passive FTP where the FTP Server chooses a Random port and the client should connect to this.
A “ftp -d” session clearly shows how to Server is now in control of the Port that the client should connect to in order to perform data transfers:

—> EPSV
229 Entering Extended Passive Mode (|||10097|)

Officially, if I understand the confusing documentation properly, the ALG should intercept this EPSV (Passive) command, open-up a pinhole to the Server allowing the client to connect to eg TCP.10,097 as described above, and Bob’s you uncle.

But.. it doesn’t. Not just for me, but not for loads of people on the net. For some reason the ALG will not open – up the pinhole in the direction from client to server, following the command mentioned above.

Juniper describes how to configure FTP with ALG for passive FTP in this document : “https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-ftp-alg.html“
For me the document makes no sense whatsoever where source NAT is configured from untrust to trust zone?! And then they seem to make an unexplained mix between IPv4 and 6.. whatever, I don’t get it.

Where it comes doen to is : ALG should take care of the pin-hole, and it doesn’t.

So here is my workaround ; I am not proud of it, but at least I got a working situation:

Make sure you RECONFIGURE your FTP SERVER (?!) to limit the ports it’s going to use for it’s Data connections. So for vsftpd that’s in /etc/vsftpd.conf:
pasv_enable=Yes
pasv_max_port=10100
pasv_min_port=10090

Of course you have to restart your vsftp daemon afterwards and take care of iptables. The range chosen above is just arbitrary really. Take a larger range for larger installations as the number of ports limit the number of concurrent sessions.

2. Configure the SRX to forward normal Client FTP traffic to TCP.21 on the server, AND ADD another destination nat rule for THE NEW RANGE from client to server (here 10,090-10,100) :

pool spamfighter-ftp {
address 192.168.3.2/32 port 21; } // regular FTP:

pool pasv-ftp-pool {
address 192.168.3.2/32; };

rule spamfighter-ftp {
match {
destination-address 0.0.0.0/0;
destination-port { 21; }
protocol tcp;
then {
destination-nat {
pool { spamfighter-ftp;

Now for the Extra Data Ports that you manually open up from Client (untrust) to Server (trust) :

rule pasv-ftp {
match {
destination-address 0.0.0.0/0;
destination-port { 10090 to 10100; }
protocol tcp; }
then {
destination-nat {
pool { pasv-ftp-pool; }

And don’t forget the security policy both for the regular FTP port 21 as well as for the extra port-range :
policy To_DMZ {   
match {
source-address any;
destination-address dmz-network;
        application [ junos-ftp pasv-ftp ];    }
    then {
permit;

Where my application ‘pasv-ftp’ is defined as:
application pasv-ftp {
protocol tcp;
  destination-port 10090-10100;

This should do it.. I hope you won’t have to struggle as much as I did. 🙁
And the downside of this of course is that you…

-have to change the way your FTP server behaves because it becomes impossible to predict which Server TCP ports will be opened without a working ALG.

-your extra port-range will ALWAYS be forwarded on the Firewall, even if there is no FTP session. NOT nice. So Juniper.. please update your documentation in case you DO have a working ALG working and make it easier to understand, or fix the ALG, because this is silly.

-ALG is on by default, but for the setup above you don’t really need it because this is a workaround in case it doesn’t work as it should. 🙁

-Surprisingly I HAVE seen SRX use cases where ALG works perfectly, even with passive FTP. Let’s hope you’ll never need the recipe mentioned above..