Bug 10305 - Time constraints in outgoing firewall
Summary: Time constraints in outgoing firewall
Status: CLOSED CANTFIX
Alias: None
Product: IPFire
Classification: Unclassified
Component: firewall (show other bugs)
Version: 2
Hardware: all Unspecified
: - Unknown - Minor Usability
Assignee: Michael Tremer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-16 11:49 UTC by Bernhard Bitsch
Modified: 2013-03-06 15:18 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Bitsch 2013-02-16 11:49:32 UTC

    
Comment 1 Bernhard Bitsch 2013-02-16 12:02:51 UTC
When you define rules with time constraints in outgoing firewall, you usually take your local time ( the timezone you live in and think of! ).

This rule is inserted in iptables with timezone UTC ( without converting the user settings ).

Example: 
Living in TZ CET I define "block from 00:00 to 09:00 on Mon,Tue,Wed,Thu,Fri",
iptables holds "TIME from 00:00:00 to 09:00:00 on Mon,Tue,Wed,Thu,Fri UTC".

Adding a "--localtz" to iptables rule genaration in /var/ipfire/outgoing/bin/outgoingfw.pl does not alter the situation.
Comment 2 Bernhard Bitsch 2013-02-17 01:01:51 UTC
Okay, was an old man page of iptables I've consulted.

Now the definition of time module for iptables says:
- default timezone for time specifications is UTC.
- to achive the supposed function we have to add "--kerneltz"

With this, my example yields 
"TIME from 00:00:00 to 09:00:00 on Mon,Tue,Wed,Thu,Fri"
Comment 3 Michael Tremer 2013-03-04 15:10:49 UTC
Applied: http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=21ef1f15f6807277b756f5be4dd6f320c665a74c

Could you please double-check if this works and does not cause any trouble?
Comment 4 Michael Tremer 2013-03-04 15:25:40 UTC
I just reverted the commit, because apparently it does not have any effect.

The kernel usually runs in UTC (or a WRONG time zone). By coincidence, our difference to UTC it not that big that you would notice.

If this issue should be fixed, it has to be done in the user interface which shows the user rules in local time, but writes configuration in UTC.

As there is currently ongoing development for a new firewall interface, it makes no sense to fix this in the currently released code (my opinion).
Comment 5 Bernhard Bitsch 2013-03-04 16:54:07 UTC
That's not true!
There is a difference if you specify option "--kerneltz".
As stated before, without the iptables rule reads 
DROP       udp  --  <sourceIP>  anywhere             TIME from 00:00:00 to 09:00:00 on Mon,Tue,Wed,Thu,Fri UTC /* DROP_OUTGOINGFW  */

With the option the same rule reads
DROP       udp  --  <sourceIP>  anywhere             TIME from 00:00:00 to 09:00:00 on Mon,Tue,Wed,Thu,Fri /* DROP_OUTGOINGFW  */

I just checked it.
I defined a rule with a time constraint for now and my client.
Only with the option access from my client was blocked and logged.

I know about the new firewall development, but it isn't tested enough yet, i suppose.

And the difference to UTC is big enough that I notice it.
If I want to cut internet connections for my kids at 21:00, they should be able to surf and chat till 22:00!
Comment 6 Michael Tremer 2013-03-04 17:10:59 UTC
Have a look at this and pay special attention to the changes of the man page at the end. This makes it clear, why your approach is not going to work.

https://git.netfilter.org/iptables/commit/?id=db50b83bc3cd634beb71f38978ad7d035c88ff11
Comment 7 Bernhard Bitsch 2013-03-04 17:32:44 UTC
Okay, then we must do the conversion in outgoingfw.pl

Despite of the caveats, it functions for me!
Comment 8 Bernhard Bitsch 2013-03-04 18:03:55 UTC
The man page states the caveats in general.
But in IPFire we can assure that the TZ is set ( it is, as the timezone offset also, known by experience traversing DST changes! ).

With this being assured we can use the --kerneltz option!
Comment 9 Bernhard Bitsch 2013-03-05 10:12:50 UTC
Fixed in new firewall.
Will be tested there.
Comment 10 Michael Tremer 2013-03-05 16:48:55 UTC
Please stop resetting this bug's status all the time.

Could you please post a link to the commit or refer to the discussion about this problem in the new firewall gui?
Comment 11 Bernhard Bitsch 2013-03-06 13:39:17 UTC
Done. See my former post.
Therefore state is "fixed"!
Comment 12 Michael Tremer 2013-03-06 14:12:47 UTC
Discussion about this has ended. The state is CLOSED CANTFIX. Period.
Comment 13 Bernhard Bitsch 2013-03-06 14:20:25 UTC
(In reply to comment #12)
> Discussion about this has ended. The state is CLOSED CANTFIX. Period.

This doesn't really bother me. First I know how to correct the behaviour, second I do not have any customers, which will complain about this ;)