Bug 1254006 - firewalld rich rules: source needed in order to activate direct rules
Summary: firewalld rich rules: source needed in order to activate direct rules
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 22
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-16 14:42 UTC by Frank Ansari
Modified: 2016-07-19 20:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 20:12:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
If you use this the direct rule is loaded. (358 bytes, application/xml)
2015-08-16 14:44 UTC, Frank Ansari
no flags Details
If you use this the direct rule is not loaded or not working. (322 bytes, application/xml)
2015-08-16 14:44 UTC, Frank Ansari
no flags Details
the direct file (178 bytes, application/xml)
2015-08-16 14:45 UTC, Frank Ansari
no flags Details
modified default zone (349 bytes, application/xml)
2015-08-17 20:06 UTC, Frank Ansari
no flags Details
direct file which makes use of chains (627 bytes, application/xml)
2015-08-17 20:07 UTC, Frank Ansari
no flags Details

Description Frank Ansari 2015-08-16 14:42:59 UTC
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):
0.3.14.2

How reproducible:
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:
1.
2.
3.

Actual results:
Without source tag the direct rule should be active.

Expected results:
The direct rule should be activated regardless whether a "source" is defined in the zone file.


Additional info:
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.

Comment 1 Frank Ansari 2015-08-16 14:44:13 UTC
Created attachment 1063523 [details]
If you use this the direct rule is loaded.

Comment 2 Frank Ansari 2015-08-16 14:44:56 UTC
Created attachment 1063524 [details]
If you use this the direct rule is not loaded or not working.

Comment 3 Frank Ansari 2015-08-16 14:45:48 UTC
Created attachment 1063525 [details]
the direct file

Comment 4 Frank Ansari 2015-08-16 14:46:52 UTC
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.

Comment 5 Frank Ansari 2015-08-16 14:52:35 UTC
Correction:
Actual results:
Without source tag the direct rule is not working (or not even loaded).

Comment 6 Thomas Woerner 2015-08-17 08:06:13 UTC
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.

Comment 7 Frank Ansari 2015-08-17 20:05:25 UTC
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.

Comment 8 Frank Ansari 2015-08-17 20:06:05 UTC
Created attachment 1064063 [details]
modified default zone

Comment 9 Frank Ansari 2015-08-17 20:07:03 UTC
Created attachment 1064064 [details]
direct file which makes use of chains

Comment 10 Frank Ansari 2015-08-30 18:50:31 UTC
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.

Comment 11 Frank Ansari 2015-08-30 19:10:33 UTC
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.

Comment 12 Fedora End Of Life 2016-07-19 20:12:45 UTC
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.