Can not open ftp port via firewalld

Question

I'm trying to open ftp port in the public zone and firewall-cmd exits with a very non-descriptive response. Command output is:

firewall-cmd --zone=public --add-service=ftp
Error: COMMAND_FAILED

OS: CentOS Linux release 7.3.1611 (Core)

Updating original question with more details.

journalctl output:

~ firewall-cmd --zone=public --add-service=ftp
Error: COMMAND_FAILED
~ journalctl -xf
Mar 06 00:46:42 hostname firewalld[3496]: ERROR: COMMAND_FAILED

debug output:

~ firewalld --nofork --debug=10
<...>
2017-03-06 00:49:57 DEBUG1: zone.addService('public', 'ftp', 0)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.execute(True)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.prepare(True, ...)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.prepare(True, ...)
2017-03-06 00:49:57 DEBUG4: <class 'firewall.core.fw_transaction.FirewallZoneTransaction'>.pre()
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-restore /run/firewalld/temp.tptEtP: 89
       1: *filter
       2: -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore /run/firewalld/temp.CYsjiA: 89
       1: *filter
       2: -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.modules.modules'>: /sbin/modprobe nf_conntrack_ftp
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-restore /run/firewalld/temp.1dBrUZ: 89
       1: *filter
       2: -D IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 DEBUG2: <class 'firewall.core.ipXtables.ip6tables'>: /usr/sbin/ip6tables-restore /run/firewalld/temp.vbUyZC: 89
       1: *filter
       2: -D IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT
       3: COMMIT
2017-03-06 00:49:57 ERROR: COMMAND_FAILED

One more update: if I do:

~ iptables -A IN_public_allow -p tcp --dport 21 -m conntrack --ctstate NEW -j ACCEPT

ftp service is working. However I'd like to manage everything via firewalld. So I'm wondering if it is a firewalld glitch or error in configuration.

Unfortunately firewalld log and even 'firewalld --nofork --debug=10' provide the same brief error: COMMAND_FAILED — nweb, Mar 05 '17 at 21:23
are you root? is this a virtual server or bare metal? this might be related to limits of the guest. you might want to read https://www.certdepot.net/rhel7-get-started-firewalld/ which seems to describe the process as well — Dennis Nolte, Mar 05 '17 at 21:40
I am root. Server is a virtual machine. I can successfully open any other ports except ftp. — nweb, Mar 05 '17 at 21:44
What is the underlying hypervisor? if it is OpenVZ then you will not be able to control the firewall. if it's not then as Michael suggested, look in the journal. — user9517, Mar 05 '17 at 21:50
KVM. The only thing I see in journal is: "firewalld[3493]: ERROR: COMMAND_FAILED". — nweb, Mar 05 '17 at 22:06
`journalctl -xf` will show more about the error. Since `firewalld` runs `iptables` commands in the background, you most probably are missing the appropriate table where the `ftp` service is going to. — Valentin Bajrami, Mar 05 '17 at 22:56
Hm, now that's interesting. What happened to your kernel? You don't seem to be running the standard CentOS kernel. — Michael Hampton, Mar 06 '17 at 01:27
Not sure how to tell whats happened. Standard yum update. Did nothing extra. And yum updates worked before. — nweb, Mar 06 '17 at 01:36
You completely ignored my question. Please go back, read it and respond. — Michael Hampton, Mar 06 '17 at 02:19
Your question was "What happened to your kernel?", I've written "Standard yum update.". Nothing else. Could you please elaborate what other info you need? — nweb, Mar 06 '17 at 02:22
I am have the same problem on bare metal. Kernel 3.10.0-514.21.1.el7 I noticed that FTP opens ports 20 and 21, and loads module nf_conntrack_ftp. modprobe -v nf_contrack_ftp reveals could not insert, cannot allocate memory. This system has 8 GB of memory with 1 GB and 4 GB swap partitions available. Solution: it was out of memory because the database was started first. I shutdown the database and the kernel module slipped right in. Go figure. — The Dude, Jul 11 '17 at 20:11

score 2 · Answer 1 · answered Mar 29 '17 at 01:17

2

Same issue, but --add-port worked for me:

# firewall-cmd --zone=public --add-port=21/tcp

answered Mar 29 '17 at 01:17

Yevgen Krylov

21
1

That doesn't quite work for me - I am unable to load nf_conntrack_ftp. Is 8 GB of RAM not enough to open FTP ports for firewalld? Also, when I modprobe -v nf_conntrack_ftp I get the error - not enough memory to load, unloading. – The Dude Jul 11 '17 at 15:19

score 0 · Answer 2 · answered Apr 05 '18 at 23:02

This answers the problem of LXC guest with host that supports it. Does your LXC support this?

Host needs to have support modprobe nf_conntrack_ftp lsmod shows nf_conntrack_ftp? if so add nf_conntrack_ftp to /etc/modules Capture the output of modinfo nf_conntrack_ftp for later

Supported in your LXC? /sys/module/nf_conntrack_ftp exists? /proc/sys/net/netfilter/nf_conntrack_helper exists? mkdir -p /lib/modules/4.4.67-1-pve/kernel/net/netfilter/ replace 4.4.67-1-pve with your host, I'm using Proxmox with that kernel. touch all those .ko files from the host put the output of modinfo nf_conntrack_ftp into the nf_conntrack_ftp.ko file backup modinfo replace it with this script

#!/bin/bash
cat /lib/modules/4.4.67-1-pve/kernel/net/netfilter/$1.ko

Replace the path with what you created earlier. Make the file executable. You want modinfo nf_conntrack_ftp to have the same output from your host as in your guest.

Next we need to replace modprobe with the following script.

#!/bin/bash
exit 0

Make it executable as well. Because this is the guest it's not like you even have modules to probe.

Great. You can now fool /usr/lib/python2.7/site-packages/firewall/functions.py that your guest can do things with modinfo.

You are also fooling /usr/lib/python2.7/site-packages/firewall/core/modules.py with the modprobe replacement.

Again, I feel it's ok that modinfo and modprobe is replaced with these fake scripts because the guest in a container doesn't have access to modules anyway. This fact is why it doesn't work.

I also think that the firewalld project should fix this as it seems like an unintended bug.

Can not open ftp port via firewalld

2 Answers2

Linked