Bug 1108651

I see this:

Chain IN_public_allow (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW


On a Leap 15.0 machine, I can see this additional rule:

ACCEPT     udp  --  0.0.0.0/0            224.0.0.251          udp dpt:5353 ctstate NEW

Last note: if I uncheck/check the ssh service in firewall-config for runtime, I can see the ssh rule move out and in again; if I do the same for the mdns service, nothing never happens.

Is this a duplicate of http://bugzilla.opensuse.org/show_bug.cgi?id=1105899 ? Right you your best option would be to ensure that you are using the iptables backend.

(In reply to Markos Chandras from comment #3)
> Is this a duplicate of http://bugzilla.opensuse.org/show_bug.cgi?id=1105899
> ? Right you your best option would be to ensure that you are using the
> iptables backend.

Oh, interesting. I see that in my /var/log/firewalld

2018-09-17 10:02:10 ERROR: Invalid option: 'FirewallBackend=iptables'

(In reply to Vincent Untz from comment #4)
> (In reply to Markos Chandras from comment #3)
> > Is this a duplicate of http://bugzilla.opensuse.org/show_bug.cgi?id=1105899
> > ? Right you your best option would be to ensure that you are using the
> > iptables backend.
> 
> Oh, interesting. I see that in my /var/log/firewalld
> 
> 2018-09-17 10:02:10 ERROR: Invalid option: 'FirewallBackend=iptables'

False positive: was probably before the new rpm got fully installed.

So at least the config points to iptables. Any other way to check which backend is used?

(In reply to Vincent Untz from comment #6)
> So at least the config points to iptables. Any other way to check which
> backend is used?

No, the config option alone should be enough. You can also check the 'nft list ruleset' to ensure that there are no nftables rules out there.

(In reply to Markos Chandras from comment #7)
> (In reply to Vincent Untz from comment #6)
> > So at least the config points to iptables. Any other way to check which
> > backend is used?
> 
> No, the config option alone should be enough. You can also check the 'nft
> list ruleset' to ensure that there are no nftables rules out there.

Ok, "nft list ruleset" is empty.

I edited /usr/lib/firewalld/services/mdns.xml and removed
  <destination ipv4="224.0.0.251" ipv6="ff02::fb"/>

When reloading firewalld, I see it adding a rule for mdns now. So it looks like something is wrong with the handling of that destination tag.

(In reply to Vincent Untz from comment #9)
> I edited /usr/lib/firewalld/services/mdns.xml and removed
>   <destination ipv4="224.0.0.251" ipv6="ff02::fb"/>

Removing ipv6="ff02::fb" is actually enough to trigger the creation of the iptables rule.

I guess we want https://github.com/firewalld/firewalld/commit/d9f46f02dd90bc6630f6e5462e67bc5341bdcade

Ok, applying these 3 patches solves it:

https://github.com/firewalld/firewalld/commit/e9eede7766610d5b632087783761f93334bdd47e
https://github.com/firewalld/firewalld/commit/d9f46f02dd90bc6630f6e5462e67bc5341bdcade
https://github.com/firewalld/firewalld/commit/cc0fadae1eb56ad6aa84e5d15dc2b5a0bad54b39

(In reply to Vincent Untz from comment #10)
> (In reply to Vincent Untz from comment #9)
> > I edited /usr/lib/firewalld/services/mdns.xml and removed
> >   <destination ipv4="224.0.0.251" ipv6="ff02::fb"/>
> 
> Removing ipv6="ff02::fb" is actually enough to trigger the creation of the
> iptables rule.

That makes sense because the upstream fix was about not building the correct rules on both families. So if you had ipv6 configured on the service, it's very likely that it only built the right rule for ipv6. I was hoping that by now there would be a new 0.6.X release which would include the fix but I will just go ahead and commit the backport to OBS for now.

I am closing this as duplicate anyway since the underlying problem is the same. The fix is on its way to Factory. Thank you for the report

*** This bug has been marked as a duplicate of bug 1105899 ***

Thanks for the fast action!