If you look at the ridiculous ruleset that firewalld uses by default, you'll see it's much easier to start by amending that rather than trying to coerce your existing rules to match it.
If you don't like firewalld then don't use it. CentOS 7 has iptables-services and ipset-service packages and those together can be used to revert to plain old iptables.
How to migrate from iptables to firewalld
Re: How to migrate from iptables to firewalld
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: How to migrate from iptables to firewalld
I presume that developers say "automatically generated" or "machine readable" (and definitely "not for human eyes") when we say "ridiculous".
Its the same with raw sources generated by Word/Writer, email clients that inject html, webhotel page creators, etc. Atrocious.
The important thing is to separate what from how. The what is more abstract.
For example the "discard clearly bad packets early" is a what. (Btw, does it add security or just improve throughput?)
The exact syntax to achieve the effect with Debian/CentOS iptables/nftables/firewall-cmd is a how.
Firewall front-ends (firewalld, UFW, clickety-clack GUI crap) attempt to present what-like options to the user. However, set of options on a front-end might not cover all that the back-end can do.
Some users claim to write more efficient assembly than the best compilers. They have very specific what to achieve and they know exactly how.
What is a 'reference'?
Netfilter (in kernel) does indeed have 3 built-in chains in the filter table. (nftables has 0 chains by default.)
RHEL 5 did add one custom "reusable" chain. RHEL 6, like Debian, did not.
Firewalld in RHEL 7 and 8 adds many custom chains. As said, one is expected to "speak firewall-cmd" rather than read iptables/nft directly.
Yes, it is a struggle; how to detect the essential and ignore the insignificant from the flood of "data".
Re: How to migrate from iptables to firewalld
Yes, and to be honest this was exactly what I did a day or two after. I was facing some odd behaviour using iptables rules while firewalld was still the actual frontend. And after a couple of wonderings, followed up by a bit of searching and short readings I replaced FirewallD with the iptables-services.
This is a good question. I do not know exactly anymore but I guess what I meant were references in several chains but I would have to look at it again.
EDIT This is what I saw on a stock firewallD ruleset. And it confused me a bit. It is looking complex to me but might be well-suited for specific purposes or environments as in my logic there must (should, ought to..?) be a reason why a Distro like RHEL replaces the easy-to-use and simple IPTables frontend and replaces it with the below...
Anyway, I switched to IPTables and yeah, I have to say I'm happy with that solution. I would say it fits my needs and at least I would say that I do understand (again) what happens with a Packet and how it gets handled. : )
Code: Select all
iptables --list -vn --line-n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 2064 186K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
2 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
3 130 13861 INPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0
4 130 13861 INPUT_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0
5 130 13861 INPUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
6 2 88 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
7 108 12653 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
2 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
3 0 0 FORWARD_direct all -- * * 0.0.0.0/0 0.0.0.0/0
4 0 0 FORWARD_IN_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0
5 0 0 FORWARD_IN_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
6 0 0 FORWARD_OUT_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0
7 0 0 FORWARD_OUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
8 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
9 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 1674 packets, 216K bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
2 1674 216K OUTPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD_IN_ZONES (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 FWDI_public all -- ens3 * 0.0.0.0/0 0.0.0.0/0 [goto]
2 0 0 FWDI_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto]
Chain FORWARD_IN_ZONES_SOURCE (1 references)
num pkts bytes target prot opt in out source destination
Chain FORWARD_OUT_ZONES (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 FWDO_public all -- * ens3 0.0.0.0/0 0.0.0.0/0 [goto]
2 0 0 FWDO_public all -- * + 0.0.0.0/0 0.0.0.0/0 [goto]
Chain FORWARD_OUT_ZONES_SOURCE (1 references)
num pkts bytes target prot opt in out source destination
Chain FORWARD_direct (1 references)
num pkts bytes target prot opt in out source destination
Chain FWDI_public (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 FWDI_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
2 0 0 FWDI_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
3 0 0 FWDI_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0
4 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
Chain FWDI_public_allow (1 references)
num pkts bytes target prot opt in out source destination
Chain FWDI_public_deny (1 references)
num pkts bytes target prot opt in out source destination
Chain FWDI_public_log (1 references)
num pkts bytes target prot opt in out source destination
Chain FWDO_public (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 FWDO_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
2 0 0 FWDO_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
3 0 0 FWDO_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FWDO_public_allow (1 references)
num pkts bytes target prot opt in out source destination
Chain FWDO_public_deny (1 references)
num pkts bytes target prot opt in out source destination
Chain FWDO_public_log (1 references)
num pkts bytes target prot opt in out source destination
Chain INPUT_ZONES (1 references)
num pkts bytes target prot opt in out source destination
1 130 13861 IN_public all -- ens3 * 0.0.0.0/0 0.0.0.0/0 [goto]
2 0 0 IN_public all -- + * 0.0.0.0/0 0.0.0.0/0 [goto]
Chain INPUT_ZONES_SOURCE (1 references)
num pkts bytes target prot opt in out source destination
Chain INPUT_direct (1 references)
num pkts bytes target prot opt in out source destination
Chain IN_public (2 references)
num pkts bytes target prot opt in out source destination
1 130 13861 IN_public_log all -- * * 0.0.0.0/0 0.0.0.0/0
2 130 13861 IN_public_deny all -- * * 0.0.0.0/0 0.0.0.0/0
3 130 13861 IN_public_allow all -- * * 0.0.0.0/0 0.0.0.0/0
4 1 36 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
Chain IN_public_allow (1 references)
num pkts bytes target prot opt in out source destination
1 19 1084 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ctstate NEW,UNTRACKED
Chain IN_public_deny (1 references)
num pkts bytes target prot opt in out source destination
Chain IN_public_log (1 references)
num pkts bytes target prot opt in out source destination
Chain OUTPUT_direct (1 references)
num pkts bytes target prot opt in out source destination
Re: How to migrate from iptables to firewalld
The iptables --list -n (same as iptables -nL) used to be nice, particularly with the "show counters" (for diagnostic) and the "show line numbers" (for making "where to insert" easier), but then iptables did add option --list-rules (-S) that prints rules in same syntax that they are given. The -S shows details that the -L hides.
1. (Presumably) Humans, like us, who see iptables "easy-to-use and simple".
2. Machines, like firewalld or ufw, that simply can't see the way humans see and associate.
3. Humans that need a simplified (G)UI. That UI is a "machine". They never look/understand the actual rules.
RHEL 7 did move from many "static oneshot services" to "dynamic" (e.g. systemd, firewalld, NetworkManager).
Red Hat Enterprise Linux 7.0 was released June 10, 2014.
nftables was merged into the kernel mainline on 19 January 19, 2014. Too late to be in RHEL 7.
One could speculate how far into future did Red Hat see before feature freeze of RHEL 7 ...
Code: Select all
iptables -t mangle -S
iptables -t nat -S
iptables [-t filter] -S
There are three groups of users:
1. (Presumably) Humans, like us, who see iptables "easy-to-use and simple".
2. Machines, like firewalld or ufw, that simply can't see the way humans see and associate.
3. Humans that need a simplified (G)UI. That UI is a "machine". They never look/understand the actual rules.
RHEL 7 did move from many "static oneshot services" to "dynamic" (e.g. systemd, firewalld, NetworkManager).
Red Hat Enterprise Linux 7.0 was released June 10, 2014.
nftables was merged into the kernel mainline on 19 January 19, 2014. Too late to be in RHEL 7.
One could speculate how far into future did Red Hat see before feature freeze of RHEL 7 ...