> when adding a rule to a previously defined chain with firewall-cmd --direct
> this fails with Error: COMMAND_FAILED
> # firewall-cmd --direct --add-chain ipv4 filter IN_home_lpt
> # firewall-cmd --direct --add-rule ipv4 filter IN_home_lpt 20 '-j
> IN_home_lpt' Error: COMMAND_FAILED
> debugging output of firewalld is
> DEBUG2: <class 'firewall.core.ipXtables.ip4tables'>: /usr/sbin/iptables-
> restore /run/firewalld/temp.h2n5ztp6: 49
> 1: *filter
> 2: -I IN_home_lpt 1 "-j IN_home_lpt"
> 3: COMMIT
> WARNING: '/usr/sbin/iptables-restore --wait=2 -n' failed:
> /usr/sbin/iptables- restore: unrecognized option '--wait=2'
> iptables-restore v1.6.1: Invalid target name ` IN_home_lpt'
> Error occurred at line: 2
> Try `iptables-restore -h' or 'iptables-restore --help' for more information.
> ERROR: COMMAND_FAILED
> With iptables v1.6.1 (currrent TW), iptables-restore doesn't support option
> -- wait.
> Is this a version-mismatch in TW or a bug of firewall-cmd?.
WARNING: Strong opinions ahead
This isn’t going to answer your question, but unless you need the fancy
desktop stuff and D-Bus interfaces to control your firewall, I *highly*
recommend using FireHOL and FireQOS instead.
firewalld just seems awfully fragile and unnecessarily complex to configure.
Seems useless for servers, given its shoddy frontends and XML-based
configuration. I hate it when software that needs to adapt to complex
scenarios obscures its configuration and forces me to use some misdesigned
garbage utilities because it’s “not supposed to be managed by hand”. This is
pretty much like giving sysadmins the finger. Same reason why I’m not a fan of
wicked. Way too opaque and hard to debug. Heck, I even *preferred*
SuSEfirewall over this nonsense, despite its limitations.
On the plus side, it works well with libvirt and friends. And it *could* be
cleaner than a bunch of mildly insane shell scripts with no API to control it.
But in my opinion, it really isn’t.