Please check the firewalld log (/var/log/firewalld) after the --add-rule invocation. "-sport 5259" is invalid. It should use two dashes, e.g. "--sport 5259".


# firewall-cmd --direct --add-rule ipv6 security INPUT 2 -p udp -s fd00:b::123 -d fd00:b::111 -sport 5259 -j SECMARK --selctx system_u:object_r:asterisk_iax2_client_t:s0
Error: COMMAND_FAILED: '/usr/sbin/ip6tables -w10 -t security -I INPUT_direct 1 -p udp -s fd00:b::123 -d fd00:b::111 -sport 5259 -j SECMARK --selctx system_u:object_r:asterisk_iax2_client_t:s0' failed: ip6tables v1.4.21: multiple -s flags not allowed
Try `ip6tables -h' or 'ip6tables --help' for more information.

# yum info firewalld
Installed Packages
Name        : firewalld
Arch        : noarch
Version     : 0.6.3
Release     : 9.el7

typo in the bug report. Couldn't copy the text directly out of the vm.. --sport has two dashes in the replicated bug. The direct rule is created fine but what ive done to replicate is run the add run hit the up arrow and directly modify the previous line to change --add-rule --remove-rule and it fails.  If its a non secmark it seems to work fine.

Can you check the firewalld log file for errors or warnings? Please also check "dmesg".

Created attachment 1679414 [details]
Commands Executed

Created attachment 1679415 [details]
/var/log/firewalld output

Created attachment 1679417 [details]
dmesg finding

I attached a screenshot of the commands run slightly different as i tried other ports other contexts and this was the last saved, the outputof /var/log/firewalld (cleared before running either command) and an interesting find I saw in dmesg that possibly related?  Nothing else in the output looked relevant to me.

This is actually an iptables bug. It's trivially reproduced outside of firewalld.

# ip6tables -t security -I INPUT_direct 1 -p udp -s fd00:b::123 -d fd00:b::111 --sport 5259 -j SECMARK --selctx system_u:object_r:firewalld_exec_t:s0

# ip6tables -t security -D INPUT_direct -p udp -s fd00:b::123 -d fd00:b::111 --sport 5259 -j SECMARK --selctx system_u:object_r:firewalld_exec_t:s0
ip6tables: No chain/target/match by that name.

As a workaround, it is possible to delete the rule using an index.
e.g.

   # ip6tables -t security -D INPUT_direct 1

Fix sent upstream: https://lore.kernel.org/netfilter-devel/20200512171018.16871-1-phil@nwl.cc/

Sadly this required quite a bit of code, probably not RHEL7 material anymore. I would prefer to make this a known issue in RHEL7 and fix the bug in RHEL8 instead.

Zach,

(In reply to Zach Tomkoski from comment #0)
> Steps to Reproduce:
> 1. firewall-cmd --direct --add-rule ipv6 security INPUT 2 -p udp -s
> fd00:b::123 -d fd00:b::111 -sport 5259 -j SECMARK --selctx
> system_u:object_r:asterisk_iax2_client_t:s0
> 2. returns success
> 3. firewall-cmd --direct --remove-rule ipv6 security INPUT 2 -p udp -s
> fd00:b::123 -d fd00:b::111 -sport 5259 -j SECMARK --selctx
> system_u:object_r:asterisk_iax2_client_t:s0
> 4. Throws an error

As far as I can tell, this is not a regression in iptables and hence none in firewalld either, right?

Are you OK with treating this as knonw issue in RHEL7 and fixing in RHEL8 instead?

Thanks, Phil

I'd prefer the fix was backported to RHEL7 but understand if its at the netfilter level that's not exactly reasonable. 

 At the end of the day I need to write a program to add and remove these rules and I can work with Eric's suggestion of find the rules index and delete by rule. I appreciate the feedback

Hi Zach,

(In reply to Zach Tomkoski from comment #13)
> I'd prefer the fix was backported to RHEL7 but understand if its at the
> netfilter level that's not exactly reasonable. 
> 
>  At the end of the day I need to write a program to add and remove these
> rules and I can work with Eric's suggestion of find the rules index and
> delete by rule. I appreciate the feedback

At this point, there is no accepted solution upstream yet and the discussion
tends towards bumping revision of xt_SECMARK in kernel. This means a combined
change of kernel and user space is required to fix the problem, so even more
effort than my original solution.

That said, I don't think it is impossible to do still within RHEL7, but we'll
need a strong business case for it. If you consider this crucial functionality,
you may want to go via support and make sure a customer case is opened with
reference to this ticket.

Cheers, Phil

At somepoint we'll be looking at moving to rhel 8 so I'll work with the workaround for rhel 7 and I'd be fine changing the target milestone to rhel 8

(In reply to Zach Tomkoski from comment #15)
> At somepoint we'll be looking at moving to rhel 8 so I'll work with the
> workaround for rhel 7 and I'd be fine changing the target milestone to rhel 8

Thanks for clarifying. I'll move the ticket to RHEL8 then.

Upstream commit to backport:

commit 616800af0da86d151cb695f1376d5ec6ede6fa72
Author: Phil Sutter <phil>
Date:   Thu Apr 29 15:28:59 2021 +0200

    extensions: SECMARK: Implement revision 1
    
    The changed data structure for communication with kernel allows to
    exclude the field 'secid' which is populated on kernel side. Thus
    this fixes the formerly always failing extension comparison breaking
    rule check and rule delete by content.
    
    Signed-off-by: Phil Sutter <phil>

https://src.osci.redhat.com/rpms/iptables/pull-request/14

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (iptables bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4468