On Freitag, 2. Februar 2018 01:57:00 CET mabto@t-online.de wrote:
Hi,
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 success # firewall-cmd --direct --add-rule ipv4 filter IN_home_lpt 20 '-j IN_home_lpt' Error: COMMAND_FAILED
debugging output of firewalld is .. DEBUG2:
: /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?.
Regards mab
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.