Firewall Module not allowing FTP or TFTP

Hey everyone,

I’ve struggled with this for weeks and I am reaching out to see if anyone else has the same experience as I.

If I set my public interface to external (this box is on the public internet without NAT) and set FTP and TFTP services to the external zone, I get the following results:

TFTP: Connection refused
FTP: I establish a connection according to the vsftp log BUT I get a timeout trying to retrieve the directory listing.

If I add my PC’s WAN IP to the trusted network in the firewall module, FTP connects and transfers (also get the directory listing) and TFTP works too.

I know some aspects of the firewall work fine because I have also added the chanSIP and secure web management ports to the external zone and I can register a phone and use the web interface just fine (even without adding my network to the trusted zone).

I have tried this with the Responsive feature turned on and off and I get the same result. So why can I connect to SIP and web management but seem to not be able to connect to tftp or ftp?


I’ve done a quick test on ftp and almost confirm what you are seeing. FTP in active mode works, but Passive mode does not:

ftp> passive
Passive mode off.
ftp> get phonebook.xml
local: phonebook.xml remote: phonebook.xml
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for phonebook.xml (362 bytes).
226 Transfer complete.
362 bytes received in 3.9e-05 secs (9282.05 Kbytes/sec)
ftp> passive
Passive mode on.
ftp> get phonebook.xml
local: phonebook.xml remote: phonebook.xml
227 Entering Passive Mode (173,252,35,203,251,195).
ftp: connect: Connection refused

Not sure if this is a bug or by design, paging Dr. @xrobau for comment.

Testing for tftp works just fine. I am testing using Firewall ver. 13.0.31.

The kernel modules ‘nf_conntrack_ftp’ and ‘nf_nat_ftp’ need to be loaded for passive FTP to work properly. I think they should auto-load, so feel free to open an issue about it 8)

I thought for sure that was it after reading your response and sure enough, none of those helper modules were defined in /etc/sysconfig/iptables-config. For grins, I added them, restarted the firewall module, but still got the same result. The strange thing is when I whitelist my IP or turn off the firewall, I can connect through FTP even without the kernel modules loaded. I am still baffled. Let me do some packet capturing before I open an issue. I don’t like creating an issue without having a clear description of what’s going on. I am still not sure how much is a problem and if any of this is an issue with my NAT on my client side…

Thanks lgaetz for helping to confirm the passive FTP issue.



we are seeing the exact same issue even with the helper modules loaded. as long as the ip of the endpoint is whitelisted it works, but as soon as the ip is removed from the whitelist the phone can no longer load its config.

I’ve built another fresh machine and set my external interface to the external zone. I marked the services tftp, https, and tftp to the external zone only. Unless I white-list my WAN IP, TFTP refuses connection according to /var/log/messages and FTP will log-in according to vsftpd.log but not transfer anything. Once white-listing my IP, TFTP works and FTP works too. I appreciate the confirmation from lgaetz and bksales. Does anyone else have anything else to add or see something I am missing. I am ready to create an issue in the bug tracker.


FTP is a peculiar protocol. It opens the management port on one port and the data transfers happen on another port. It sounds like the FTP Control port (21?) is opening correctly, but the data port (22?) isn’t.

There’s a really good explanation of the protocol at FTP Protocol Discussion. It goes into a lot of detail about how to ensure the FTP protocol needs to work in various (passive/active) modes as well as the ports that need to be open and to where.

If I were using plain iptables and opened up port 21, it would work without me opening the data channel specifically (port 20). Using the “related, established” rule. I should probably check to see if related connections are allowed and maybe that’s the missing piece. Thanks for the suggestion!

I finally sorted things out after a lot of testing and it boils down to this.

TFTP is working fine, it was my client machine’s firewall blocking the outbound connection to the server (banging head against the wall).
Passive FTP is indeed the issue and Rob was on the correct path early-on. Here is the bug submission

Thanks everyone.

1 Like

And it’s fixed in the latest version of Firewall, too!