User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0 Build Identifier: I needed to add a rule to iptables to update the source address of packets originating on another system and travelling through mine. I tried the following rule: firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 99 "-m mark --mark 0x64 -j SNAT --to-source $SERVER_IP" I received the following error: Error: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: The -t option (seen in line 2) cannot be used in iptables-restore. Reproducible: Always Steps to Reproduce: 1. For testing, add a POSTROUTING_test chain to the nat table: iptables -t nat -N POSTROUTING_test 2. Use "firewall-cmd --direct" to send packets to that chain (fails): firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 99 "-i any -j POSTROUTING_test" 3. Use "iptables" to add the rule (works). Note that I'm adding the rule to the POSTROUTING_direct chain, because I believe that's what firewall-cmd wants to do: iptables -t nat -A POSTROUTING_direct -i any -j POSTROUTING_test Actual Results: firewall-cmd failed with the following error: Error: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.3 (legacy): no command specified Error occurred at line: 3 Try `iptables-restore -h' or 'iptables-restore --help' for more information. Note that the "iptables" command adds the rule to the POSTROUTING_direct table as expected. Expected Results: I expected firewall-cmd to add the rule to either the POSTROUTING or POSTROUTING_direct table in the same manner that the "iptables" command did. This impacts my ability to set up my server as desired, because I can't use "firewall-cmd --permanent --direct" to have this rule appear in my sytsem after a restart. So I need to devise a workaround. This is also an issue on CentOS 7, so I suspect it's present in RHEL 7 as well.
What if you remove the quotes? e.g. firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 99 -i any -j POSTROUTING_test -->8-- [root@rhel7-test1 ~]# iptables -t nat -N POSTROUTING_test [root@rhel7-test1 ~]# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 99 "-i any -j POSTROUTING_test" Error: COMMAND_FAILED: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.4.21: interface name ` any -j POSTROUTING_test' must be shorter than IFNAMSIZ (15) Error occurred at line: 2 Try `iptables-restore -h' or 'iptables-restore --help' for more information. [root@rhel7-test1 ~]# firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 99 -i any -j POSTROUTING_test success
That works -- thank you. This is where an example in the documentation would be useful. As a long time Linux user, whenever I see a situation where some text that can have spaces in it is required as part of a command (such as useradd --comment="Firstname Lastname" or mysql -p"'y pass'), said text is usually a "word," which means it has to be passed inside quote marks. firewall-cmd departs from this pattern: the rule not a word but rather is parsed along with the rest of the command (a la "ssh user@host command arg arg ..."). Passing it as a word results in an unhelpful error message, unlike by the ssh example which happily accepts either format. I note the documentation for firewall-cmd's --direct feature indicates the rule is passed as "args" and not as a word, which means it doesn't need to be within quotes. But simply having an example would remove all doubt. Question: can this bug be used as a request to update the documentation, or should I open a separate bug for that?
Oops: "mysql" example in previous comment was not formatted properly. It should read: mysql -p'my pass'
(In reply to Rowan Bowler from comment #2) > That works -- thank you. > > This is where an example in the documentation would be useful. As a long > time Linux user, whenever I see a situation where some text that can have > spaces in it is required as part of a command (such as useradd > --comment="Firstname Lastname" or mysql -p"'y pass'), said text is usually a > "word," which means it has to be passed inside quote marks. > > firewall-cmd departs from this pattern: the rule not a word but rather is > parsed along with the rest of the command (a la "ssh user@host command arg > arg ..."). Passing it as a word results in an unhelpful error message, > unlike by the ssh example which happily accepts either format. It's true that firewalld parses it as a word. That's because it _is_ a word due to the quotes. firewalld then passes the word to iptables-restore. This is important with string literals. e.g. firewall-cmd --direct --add-rule ipv4 filter INPUT 99 -p tcp --dport -j LOG --log-prefix "PREFIX WITH SPACE: " > I note the documentation for firewall-cmd's --direct feature indicates the > rule is passed as "args" and not as a word, which means it doesn't need to > be within quotes. But simply having an example would remove all doubt. > > Question: can this bug be used as a request to update the documentation, or > should I open a separate bug for that? Sure, I think adding an example to the docs would make it clear.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.