My Rocky 8.5 system acts as a FTP client that connects to a FTP mediation server. Client connection is accepted by firewalld. But it rejects the response by the server (related to this response File operation failed: 150 Here comes the directory listing).
Is there a means to track the client connection such that the server response is not rejected?
I am using the default Firewalld configuration from first installation. By default outbound connections are permitted. So I am not trying to open port 21 but trying to open the random port used by my client.
Hi,
This sounds like a server side issue to me. Are you able to test an ftp connection, with another device running a different OS on the client side?
Regards Tom.
Hi Thanks for your reply.
Yes, I have tested the ftp connection from a CentOS 6 server (FTP client) that connects to the FTP mediation server. Connection works.
Just to give context, of the 2 CentOS 6 servers, I had the other CentOS 6 Server connecting to the FTP mediation server successfully as well. Recently I upgraded (fresh install) the CentOS 6 server to Rocky Linux 8.5 server. When I check the firewall logs I see return packets are being dropped. When I switch off the firewalld then everything works fine.
Also when I run lsmod
nf_conntrack_ftp 20480 0
In firewall logs on my server (FTP client) I see that the FTP mediation server responds on port 20 always. But my server my FTP client creates a random port for communicating.
Hi,
A google has found this:
https://bugzilla.redhat.com/show_bug.cgi?id=1380168
Its an old bug, but if it works with centos 6, then this may equate?
Have you considered using FTPS or SFTP? Not only is encrypted, its easier to setup on both firewalls.
Regards Tom.
Make sure your firewall rule is adding the “ftp” service.
firewall-cmd --add-service=ftp --permanent
firewall-cmd --reload
The ftp service is defined in /usr/lib/firewalld/services/ftp.xml. There is a line near the bottom (helper name=“ftp”) that enables the connection tracking module.
If you just add the port, firewalld only looks for that port.
2 Likes
Thanks Tom. I will have a look.
I might add that on Rocky I don’t use the FTP client. I am using the Apache CAMEL FTP client. But I don’t think this makes a difference. The problem with the FTP mediation server, it is using old technology and we will only see operational upgrades in the next 2 years. So FTPS nor SFTP are options right now. Worse of all FTP mediation server seems to use Active FTP where the server initiates the data connection.
Thanks Joe. I am now testing this option. I will give you feedback shortly.
@joebeasley3 ok the error still persists. Enabling service=ftp on firewalld enables port 21 if I understand correctly from the xml file. But it doesn’t seem like connection tracking is working (if I understand it correctly). Are there extra configs I need to do?
I confirmed that port 21 is enabled via nmap from an external server.
PORT STATE SERVICE
21/tcp closed ftp
The firewall is sitting on my server where the FTP client initiates a connection to the FTP server. The outgoing connection request from my client to the servers control port 21 is not blocked by default. My client uses a random port 42019 (example) and tells the server on control port 21 this src port. This connection initiation seems to work fine until when the server has to respond. When the server responds it must initiate a connection from its data channel on port 20 and respond to my FTP client on port 42019 to send data. But it must go through my firewall. If connection tracking was working, shouldn’t the firewall automatically allow data through port 42019? Currently, as per firewall logs, the packet to 42019 are getting rejected by the firewall.
This is a bit new to me so I am trying to understand the concepts behind it.
Seems like the other alternative for inbound is, though this is not ideal as it opens too many ports:
- sudo firewall-cmd --permanent --add-port=1024-50000/tcp
Hi,
Just to clarify its firewalld on the client server (Rocky), not firewalld on the mediation FTP server blocking the connection?
If so, does the issue persist after issuing:
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
Also:
If you can ssh to server, you can use SFTP:
https://camel.apache.org/components/3.16.x/sftp-component.html
Thanks Tom.
To clarify, yes firewalld is on client server Rocky, not on mediation FTP server.
By the way here is my conntrack_helper output:
cat /proc/sys/net/netfilter/nf_conntrack_helper
0
It seems like the command you provide is the silver bullet I am looking for. Let me test.
PS: I believe SSH is possible but any upgrade to FTPS and SFTP will happen in the next 2 years. Slow processes unfortunately 
1 Like
@tjdoyle hey Tom! The error is now suppressed. Thank you. It looks like it is the silver bullet I required. I just need to make sure it persists between reboots. I will do some tests a bit later.
A security audit will require this FTP connection be Secured or changed to SCP. But I think it will only be in the next 24 months. This would simplify life so I don’t have so support protocols that are no longer recommended.
1 Like
Hi,
To make it persistent between reboot, create this file: /etc/sysctl.d/10-nf_conntrack_helper.conf
Contents:
net.netfilter.nf_conntrack_helper=1
Thanks Tom.
1 Like
Thank you @tjdoyle. Apache CAMEL FTP is now happy and transferring files accordingly. Furthermore, when I inspect the logs, I no longer see the mediation FTP server data packets being rejected for FTP. This is awesome.
Thank you all.
1 Like