Bug 929426

Created attachment 718252 [details]
ip6tables -L -n > ip6tables.conf

Reassigning to the Security Guide component, firewalld will be covered there.

So far it is still unclear to me how to configure the forward chain. I tried again to find some documentation about it but could not find any.

Everything in the documentations seems to be about how to accept or block incoming traffic. What about how to configure outgoing or forwarding traffic?

Only solution so far is to add an iptables rule doing something like this:

ip6tables -I FORWARD 7 -p tcp --dport  22 -j ACCEPT;

Is thre no way doing this with firewall-cmd?

(In reply to Frank Ansari from comment #4)
> Only solution so far is to add an iptables rule doing something like this:
> 
> ip6tables -I FORWARD 7 -p tcp --dport  22 -j ACCEPT;
> 
> Is thre no way doing this with firewall-cmd?

Why you don't use this command?

firewall-cmd --direct --add-rule ipv6 filter FORWARD 1 -p tcp --dport  22 -j ACCEPT

Also, under Fedora 20 the "--permanent" key works fine for me.

Because I did not know this. 

Today I again tried to figure it out and found it.

Also I found I could make it permanent with /etc/firewalld/direct.xml.

<?xml version="1.0" encoding="utf-8"?>
<direct>
   [ <rule ipv="ipv6" table="filter" chain="FORWARD_direct" priority="0"> -p tcp --dport 22 -j ACCEPT </rule> ]
</direct>

This is working.

In this documentation

https://fedoraproject.org/wiki/FirewallD

the "direct" method is mentioned but not the direct.xml file.

The main problem is: how shall one know that you have to check for the keyword "direct" when you want want to do forwarding?

In the documentation you only find "port forwarding" when you search for the keyword "forward". 

Here where I found it:

http://superuser.com/questions/654687/how-to-allow-forwarding-with-firewalld-on-a-fedora-19-router

This was the right clue. Something like this should be added to the documentation.

this is stupid. having to add direct rules is stupid. why does not firewalld offer a native way to add rules to chain FORWARD in table filter?

this is even more stupid. direct rules do not work with interface 'any', you must explicitly set both physical interface name for input and output.

so "-i interface1 -o any" does not work! (tested on RHEL 7.5)

and another stupid thing is that you must specify the physical interface name like in traditional iptables, but I expected it to integrate nicely with networkmanager and I expected to be able to write connection names, not interface names, and then I expected it to automatically translate to physical interface names!
but I guess I have too high expectations of firewalld...

Ha, I was wondering the exactly the same thing and found this bug entry. :)

The whole point firewalld was (I assume) of having a 'daemon' and a user inteface, which would together provide a safe way to make modifications to traffic filtering rules without sawing your own branch off where you were sitting on. Every network specialist knows this risk.

Well, it turns out that firewalld is what I suspected from the start: a workstation firewall solution, not a network firewall solution.

Which is funny as the term firewall is historically just about the network device (a wall), not about host filtering.

Which also funny, that it comes with predefined 'zones' like 'dmz'. Well, where the hell you're supposed to have that DMZ-zone else than in your backbone network which is protected by network firewall? Maybe with VPN you could connect it to your workstation and it would make sense. Or not.

Looks like modifying the dmz service rules go into IN_dmz_allow chain, that is called by hopping chain to antoher:

INPUT 
  INPUT_ZONES
    IN_dmz
      IN_dmz_allow


and in case of network firewall, that would be traffic directed to firewall itself. If it would be traffic that firewall would be routing through itself, it should be in FORWARD.

Using --direct removes the whole point of having that daemon+userinterface and removes the benefits they provide. Only thing left are the other limitations, missing documenation, weird "concepts" and broken XML (and who knows what else crap).

(In reply to Mai Ling from comment #7)
> this is stupid. having to add direct rules is stupid. why does not firewalld
> offer a native way to add rules to chain FORWARD in table filter?

Because no one has implemented the feature.

(In reply to Mai Ling from comment #8)
> this is even more stupid. direct rules do not work with interface 'any', you
> must explicitly set both physical interface name for input and output.
> 
> so "-i interface1 -o any" does not work! (tested on RHEL 7.5)

"-o any" attempts to match an output interface with name "any". If you want to match _any_ output interface, then omit the option. You can also use wildcarding with "+". This is covered pretty thoroughly in the iptables man page.

(In reply to Mai Ling from comment #9)
> and another stupid thing is that you must specify the physical interface
> name like in traditional iptables, but I expected it to integrate nicely
> with networkmanager and I expected to be able to write connection names, not
> interface names, and then I expected it to automatically translate to
> physical interface names!
> but I guess I have too high expectations of firewalld...

What you describe already occurs. firewalld integrates with NetworkManager. You can set the "zone" in the NM connection settings.

(In reply to Juha Tuomala from comment #10)
[..]
> Using --direct removes the whole point of having that daemon+userinterface
> and removes the benefits they provide. Only thing left are the other
> limitations, missing documenation, weird "concepts" and broken XML (and who
> knows what else crap).

If you have documentation topics that you'd like to see, then file an issue upstream.. or better yet add them and submit a PR.

(In reply to Eric Garver from comment #14)
> If you have documentation topics that you'd like to see, then file an issue
> upstream.. or better yet add them and submit a PR.

This is the 15th comment on this topic. Are you sure you're the right person writing the documentation if you need to ask this - when someone already filed a report that there is a problem?

(In reply to Juha Tuomala from comment #15)
> (In reply to Eric Garver from comment #14)
> > If you have documentation topics that you'd like to see, then file an issue
> > upstream.. or better yet add them and submit a PR.
> 
> This is the 15th comment on this topic. Are you sure you're the right person
> writing the documentation if you need to ask this - when someone already
> filed a report that there is a problem?

I was referring to the upstream firewalld documentation as many of the items you mentioned are relevant to upstream. This bug is for fedora downstream documentation. Both accept contributions.

I'm closing this bug as part of a Bugzilla cleanup effort. The most likely reason is that the bug has been opened either against a component we no longer publish, or against Release Notes for an EOL release.