Passive FTP

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Passive FTP

Not applicable


Is there any trick to allow passive FTP inbound?

I have set a security rule to allow APPLICATION-FTP inbound, and a NAT rule to let Port 21 inbound. Works fine for ACTIVE, but PASSIVE fails at the LIST command.

Help would be appreciated.




Accepted Solutions

Reverting to the 243 content release will fix the issue.

The 244 content has been pulled and the content team is currently working on a fix.


View solution in original post


L3 Networker

Application FTP covers both activ and passive ftp, unless you have it set for application default on the policy there should be no reason for us to drop this traffic.

We may need to take a closer look at your policy.

I am confused - so we should *not* set our FTP policy for application-default?

We are having the same issues - our outbound FTP (using the ftp application and application-default service) will only allow active mode FTP. Yet oddly, out inbound FTP rule using the same configuration is working for both PASV and active mode.


It is possible you are running into an issue we recently uncovered with NAT when a client and server both support FTP extensions and use EPSV/EPRT instead of the normal PASV/PORT commands for active connections. This is being addressed and should be fixed in an upcoming content release. If either the client or the server do not advertise support for those extensions, everything will work fine through NAT.


Thanks - so what would be the work-around in the meantime?

Specifically, we have users who use IE/Windows Explorer as their FTP client to transfer files to and from our internal server in the DMZ. They have always had the "Use Passive" options checked which worked until we moved to the PA firewalls. Now it does not work.

The same FTP server (using an identical security rule) performs fine externally using PASV mode.

The only difference, as you mentioned, is the NAT rule: from the trust zone it uses a dynamic ip-and-port source translation, and from untrust it uses destination translation on TCP 21.

Is there anything we can do on the firewall to work around this issue?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!