On 1/30/19 10:05 PM, Simon Matter via CentOS wrote:> Did you look at Shorewall? IMHO that's what is best used in such > situations and it works since many years now.shorewall doesn't support nftables, which is largely the point of firewalld:? The Linux firewall system is currently undergoing yet another deprecation and migration from iptables to nftables. firewalld should remain stable during the migration process.? As far as I know, there are no plans to support nftables under shorewall, so new users will most likely throw away any investment they make in learning and implementing shorewall.
> On 1/30/19 10:05 PM, Simon Matter via CentOS wrote: >> Did you look at Shorewall? IMHO that's what is best used in such >> situations and it works since many years now. > > > shorewall doesn't support nftables, which is largely the point of > firewalld:? The Linux firewall system is currently undergoing yet > another deprecation and migration from iptables to nftables. firewalld > should remain stable during the migration process.? As far as I know, > there are no plans to support nftables under shorewall, so new users > will most likely throw away any investment they make in learning and > implementing shorewall.IIRC nftables has a compatibility mode with iptables? Anyway, I thought the future on Linux is bpfilter, no? Until then, I'll continue to enjoy Shorewall as I did for more a decade now. Regards, Simon
Gordon Messmer wrote:> On 1/30/19 10:05 PM, Simon Matter via CentOS wrote: > >> Did you look at Shorewall? IMHO that's what is best used in such >> situations and it works since many years now. > > shorewall doesn't support nftables, which is largely the point of > firewalld:? The Linux firewall system is currently undergoing yet > another deprecation and migration from iptables to nftables. firewalld > should remain stable during the migration process.? As far as I know, > there are no plans to support nftables under shorewall, so new users will > most likely throw away any investment they make in learning and > implementing shorewall. >I seem to have missed a few posts in my thread. Let me note that a) I'm at work. I have to do what is required. b) we are moving from iptables to firewalld. No other options. Since the firewall system is moving from iptables to firewalld, WHY IS THERE NOT A PROGRAM INCLUDED with the firewalld package to convert EXISTING rules? Each firewall will have its own set of rules. We have three? four? internal firewalls, *each* with its own rules. Since that's us, I assume there are tens, if not hundreds of thousands just like us, many with more firewalls. Why would *ANYONE* think that everyone should just start from scratch, taking all the time in the world to get it converted? mark, still looking for a script
On Thu, 31 Jan 2019 at 13:13, mark <m.roth at 5-cent.us> wrote:> Gordon Messmer wrote: > > On 1/30/19 10:05 PM, Simon Matter via CentOS wrote: > > > >> Did you look at Shorewall? IMHO that's what is best used in such > >> situations and it works since many years now. > > > > shorewall doesn't support nftables, which is largely the point of > > firewalld: The Linux firewall system is currently undergoing yet > > another deprecation and migration from iptables to nftables. firewalld > > should remain stable during the migration process. As far as I know, > > there are no plans to support nftables under shorewall, so new users will > > most likely throw away any investment they make in learning and > > implementing shorewall. > > > I seem to have missed a few posts in my thread. Let me note that > a) I'm at work. I have to do what is required. > b) we are moving from iptables to firewalld. No other options. > > Since the firewall system is moving from iptables to firewalld, WHY IS > THERE NOT A PROGRAM INCLUDED with the firewalld package to convert > EXISTING rules? > >> Each firewall will have its own set of rules. We have three? four? > internal firewalls, *each* with its own rules. Since that's us, I assume > there are tens, if not hundreds of thousands just like us, many with more > firewalls. > > Why would *ANYONE* think that everyone should just start from scratch, > taking all the time in the world to get it converted? > >You answered your own question. Because a lot of different places set up their firewalls their own way and parsing all the different ones/ways seems to break over and over again? Firewalld is still outputting text in iptables format.. and will output it in nftables later when it is done. It is just a program which tries to make decisions which certain classes of systems need to be done automagically. For most RHEL-7 systems which have custom iptables rules.. I thought the package iptables-services.x86_64 sets up everything to keep that going. If you need to move to firewalld because it should support future formats ( nftables, plughtables, xyzzytables, etc.) you are going to need to learn the tool just like you had to from ipchains to iptables days. [Pretty much every conversion tool from ipchains to iptables worked only on the simplest but anyone with a custom firewall ended up having to learn the syntax.]> mark, still looking for a script > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Stephen J Smoogen.
On Jan 31, 2019, at 11:12 AM, mark <m.roth at 5-cent.us> wrote:> > Why would *ANYONE* think that everyone should just start from scratch, > taking all the time in the world to get it converted?If the conversion were simple enough to be easily automated, the new system is probably no more than just a syntactic difference away from the old, and thus does not provide any interesting new functionality or change in existing functionality. It?s much the same as asking why there aren?t automatic programming language conversion tools: we wouldn?t need more than one programming language if they all mapped 1:1 to each other, short of going down to the machine code level and back up the technology stack. Pretty much all the other major competing OSes have had at least one incompatible shift in their firewall implementations over the years, even that supposed bastion of ultimate stability, FreeBSD. I take that as a sign that those designing firewall schemes in the early 1990s didn?t have magical levels of foresight when doing their work, so that replacements had to be incompatible to provide the functionality we now expect.