Summary: | Time constraints in outgoing firewall | ||
---|---|---|---|
Product: | IPFire | Reporter: | Bernhard Bitsch <bbitsch> |
Component: | firewall | Assignee: | Michael Tremer <michael.tremer> |
Status: | CLOSED CANTFIX | QA Contact: | |
Severity: | Minor Usability | ||
Priority: | - Unknown - | CC: | bbitsch |
Version: | 2 | ||
Hardware: | all | ||
OS: | Unspecified |
Description
Bernhard Bitsch
2013-02-16 11:49:32 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. 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" 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? 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). 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! 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 Okay, then we must do the conversion in outgoingfw.pl Despite of the caveats, it functions for me! 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! Fixed in new firewall. Will be tested there. 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? Done. See my former post. Therefore state is "fixed"! Discussion about this has ended. The state is CLOSED CANTFIX. Period. (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 ;) |