What's the purpose of the *INPUT_direct* custom-chain in the
filter/INPUT chain? Is this the recommended chain to use when inserting
custom rules via the --direct option? Is it sort of like, to keep
I have some LXC containers running on a server and I want to forward a port
to each of their SSH ports( Fedora 20, firewalld 0.3.9.2). After fiddling
with firewall-cmd for several hours now, I am still nowhere near working
I have my external interface in the public zone.
I enabled the masquerading on public :
$ firewall-cmd --zone=public --add-masquerade
and I am using the following for forwarding the port :
$ firewall-cmd --zone=public
The zone status after that is :
public (default, active)
services: dhcpv6-client http https mdns ssh
But ssh on port 22822 is still not possible. There is a change though.
Without the forward rule nmap shows the port as "filtered", and after
applying it it is shown as "closed" . I thought maybe there is something
wrong with the routing, so I tried a simpler example :
$ firewall-cmd --zone=public
to forward port 8888 to port 22 on loop back interface. SSH is enabled to
listen on the lo interface, but I still get the same result if I try to
connect on port 8888.
And if I don't specify destination address :
$ firewall-cmd --zone=public
Forwarding is working as expected.
Am I missing something, or doing something wrong ? Similar example is shown
in the documentation at
Is there something I need to enable on the target interfaces, for the
forwarding to work ?
I really find firewallD very nice idea, but this is very frustrating ...
I just installed Fedora 20 on my desktop and I'm playing with firewalld
for the first time. I read the docs and with the new rich-rules I think
I'm a happy camper so far. I have some questions & observations:
# firewall-config (GUI app)
I opened a bugzilla because every time you start the app it starts
# Target for a Zone
When using firewall-config and you switch to permanent configuration, in
order to edit one of the zone properties, there's a Target drop-down
list there. When I changed ACCEPT to DROP for the public zone (my
default) I noticed only the FORWARD chain was changed. I did an
"iptables -L -n -v" in order to confirm this. The actual chain
affected is FWDI_public (where the last REJECT rule is replaced by a
DROP). Shouldn't the IN_public (for public zone) have a DROP statement
as well? Since it doesn't have it, a REJECT from the default INPUT chain
is what gets applied. Is this a bug?
Also, when I do this I loose all my connections (can't browse the web,
anything..). I have dissected the resulting iptable rules and I only
see the change in the FWDI_public chain. Nothing else. I can't find the
culprit. I have to change the target back to ALLOW for things to get
In a nutshell, I would like all packets to be dropped for all services
that are not allowed. How can I do this via
firewall-cmd/firewall-config? I know there's a drop zone but still
would like to learn how to change the default target for a given zone.
What does it mean for a zone to be immutable? Is it that, once loaded,
you can't change it? (add/remove rules)? When I change my default zone
to the drop zone, I still can add/remove services from it.
# Best Practices
If I'm going to add/remove services for a given zone, is it better to
just clone one zone and have one of my own? Should I leave all the stock
zones as they are?
Thanks in advance.
I'm running 0.3.9.1 (Fedora 20) with the default "public" zone. I'm not
running any special rules (riched rules). The only customization I did
to the default zone is to remove "mdns" and two or three more services
that come enabled out of the box.
Now, when I use firewall-config to modify the public zone:
- switch to permanent
- change the default target to DROP
- perform a firewalld reload
...I loose all connectivity. When I run "iptables -v -L -n" I see all
counters showing 0 packets/bytes. I do notice the DROP lines in their
respective *public" chains (as it should after the change). That is, if
you take a look at the iptables rules they all make sense (they should
work) but somehow, after changing the default target to DROP, it seems
packet aren't reaching netfilter at all.
As soon as I found out 0.3.9.2 was released I performed:
yum update --enablerepo=updates-testing firewalld
and grabbed 0.3.9.2. Now I realize I have 2 packages for firewalld:
# rpm -qa | grep -i firewalld
If I do "rpm -ql long-package-name" I get the list of files on both
packages. I don't know how RPM/YUM informed me of conflicting files. I
don'tknow..perhaps something is wrong with the way the last update was
I couldn't remove them with yum or rpm (even specifying complete package
name). I had to:
rpm -e --noscripts firewalld-0.3.9-1.fc20.noarch
rpm -e --noscripts firewalld-0.3.9.2-1.fc20.noarch
we've just released firewalld-0.3.9.1
changes since 0.3.8:
- translation updates
- New IPv6_rpfilter setting to enable source address validation
- Do not mix original and customized zones in case of target changes,
apply only used zones
- firewall-cmd: fix --*_lockdown_whitelist_uid to work with uid 0
- Don't show main window maximized. (RHBZ#1046811)
- Use rmmod instead of 'modprobe -r' (RHBZ#1031102)
- Deprecate 'enabled' attribute of 'masquerade' element
- firewall-config: new zone was added twice to the list
- Enable python shebang fix again
- firewall/client: handle_exceptions: Use loop in decorator
- firewall-offline-cmd: Do not mask firewalld service with disabled option
- firewall-config: richRuleDialogActionRejectType Entry -> ComboBox
- Rich_Rule: fix parsing of reject element (RHBZ#1027373)
- Show combined zones in permanent configuration (RHBZ#1002016)
- firewall-cmd(1): document exit code 2 and colored output (RHBZ#1028507)
- firewall-config: fix RHBZ#1028853