Red Hat Bugzilla – Bug 1254006
firewalld rich rules: source needed in order to activate direct rules
Last modified: 2016-07-19 16:12:45 EDT
Description of problem:
If you create a zone with rich rules and also have direct rules the direct rules are not used by firewalld as long as there is no general source give in the zone file. I have checked with "ip6tables -L -n -v". There is nothing in the "FWDI" zone as long as I have no source tag.
Version-Release number of selected component (if applicable):
See example as attachment. You can write anything in the source tag (under the description tag). As long as "source" is given the direct rule will be active - otherwise not.
Steps to Reproduce:
Without source tag the direct rule should be active.
The direct rule should be activated regardless whether a "source" is defined in the zone file.
Logging is not working at all. I have checked "journalctl", "journalctl -k" and "/var/log/firewalld". I have even tried to reinstall rsyslog (this was deinstalled since I use journalctl). I cannot see anything in any logs when I do an ssh connection which matches this rule. If you want I can open another ticket for logging.
Created attachment 1063523 [details]
If you use this the direct rule is loaded.
Created attachment 1063524 [details]
If you use this the direct rule is not loaded or not working.
Created attachment 1063525 [details]
the direct file
It would be good to have a more seamless integration of forwarding rules in firewalld. Forwarding is needed for every router scenario. This is nothing exotic.
Without source tag the direct rule is not working (or not even loaded).
The rules of a zone are only created, if the zone is used by a source or interface/connection binding. A zone that is not used does not have any effect. As soon as there is some binding (source or interface/connection) the zone will be created. The rules of a zone are not removed if it is not used any more.
The delayed creation of the rules is done to minimize load times. Just think about a user creating lots of zones, where only a limited number is really used.
It might be possible to add a switch to firewalld.conf to make sure that all zones are created from the start also if they are not used. But this will increase firewalld load times in some scenarios, therefore this switch will be off by default.
My previous config was without any interfaces and is working fine.
If you only use sources and no interfaces everything behaves as expected.
The only reason I was trying to play with "rich rules" was that I thought I might be able to define the interface as additional restriction (e.g. some additional interface like a wireless usb stick should not be allowed to let traffic into the system). With normal zone rules this is impossible because each interface can only be bound to one zone - and then the zone rules with sources takes control over everything.
If on the other hand you build a rule which is bound to an interface the direct rule will takes everything regardless of the source ip. Even if you add a source it has not effect on the forwarding. You might add a --src entry into the direct rule to prevent this - but this is not a very nice solution.
I guess it works like this: if a zone is found for the interface (p4p1 is bound to FedoraWorkstation) then this goes to the FWDI_FedoraWorkstation_Allowed chain. Once it is there the direct rule is applied no matter of the source ip.
Probably you might do all this with chains in iptables. For firewalld I have currently no really good idea.
A simple task would be like this: create rules for firewalld which allows you to let ssh traffic in from certain ip ranges on a certain interface but disallow this from all other interfaces. Alllow the same thing for traffic for kvm hosts (for this the forwarding is necessary).
So I have changed my config a little bit. Now I use chains in direct.xml to take care of the sources. In the FedoraWorkstation zone I added my interface instead of a source.
Created attachment 1064063 [details]
modified default zone
Created attachment 1064064 [details]
direct file which makes use of chains
I have bought now a second NIC in order to test how firewalld will behave in a scneario where I really have two interfaces.
The result is odd (at least to me).
My test scenario is like this:
Amazon EC2 -> Raspi (as IPv6 router with aiccu) -> PC
On my PC I have two interfaces:
- p4p1 with default GW for IPv4
- enp4s0 with default GW for IPv6 (this is my Raspi)
I added an IPv6 address to p4p1 so that I can do tests with both interfaces.
I made a very simple firewalld config with zone "FedoraWorkstation" for both interfaces which allows only ssh access (icmp works by default).
If I now ping or ssh the IPv6 address on enp4s0 it works in all cases. But if I try to reach the IPv6 address on p4p1 it only works from the Raspi but not from the Amazon EC2 instance (stopping firewalld on my Raspi or Amazon EC2 instance makes no difference).
But also this will work as soon as I stop firewalld on my PC. Also I can can make a simple ip6tables config and then it also works fine. But not with firewalld.
Also I have tried to make tcpdumps - but the only thing I could figure out so far is that my PC is not sending any responses to the incoming ping requests.
I know this is not realy my original request - but the idea was to find out how firewalld will behave if you have more than one interface.
It seems to be a routing problem. It works when I add a route with the network for my Amazon EC2 instance as destination via Raspi dev p4p1.
The stange thing is still that it works without this route when I stop firewalld.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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
Thank you for reporting this bug and we are sorry it could not be fixed.