{Complete} Timebased Rules

heiko

a new snapshot?

sullrich

Sure, that will work. There have been no commits for atleast 9+ hours.

heiko

Hm? but i will test it

sullrich

Hm? Sorry, I do not understand? What are you trying to tell me?

heiko

Hallo,
ich schreibs ausnahmsweise auf Deutsch, Entschuldigung dafür. Ich möchte an dieser Stelle ausdrücklich vermeiden, dass es zu Unstimmigkeiten bzgl. des Projektes kommt. Das "Bounty" ist gezahlt und zwar sehr gerne. Sollte es Probleme mit dem löschen von Firewall Sessions kommen, die durch dieses Projekt verursacht wurden, so bin ich gerne bereit, eine entsprechende Summe zu zahlen, um dieses Problem zu lösen. Es liegt mir fern, ein Projekt zu kaufen! Dies möchte ich noch einmal ausdrücklich betonen.

Mein Test hat gezeigt, dass Firewall Regeln nicht korrekt geladen bzw. umgesetzt werden, dass im ersten Test sogar ohne Zeitbasierte-Regeln. Es ist nicht viel falsch zu machen, eine Regel zu erstellen, welche ICMP erlaubt oder blockt. Da dies nicht erfolgreich durchgeführt werden konnte, habe ich den Test abgebrochen,da es für mich keinen Sinn macht, etwas zu testen, was hier nicht sehr wissenschaftlich ist, denn ich kann nicht erkennen ob es Fehler an den Schedules gibt oder durch einen kausalen Zusammenhang anderer Dinge.

Gruß
Heiko

Holger, es wäre sehr nett, wenn Du das übersetzen würdest, damit dieses erfolgreich zum Abschluß kommt und alle Beteiligten davon profitieren können…

P.S..: Ich teste alles unter VMWARE, vielleicht ist das auch ein Problem?

sullrich

There apparently is a bug when creating the first schedule. The rule will not be active correctly until a reboot.

This is a kernel bug and we are looking into it.

hoba

Wir müssen hier prinzipiell 2 Dinge unterscheiden:

Firewallrules, die keinen Zeitplan haben und quasi immer aktiv sind:
Diese sind immer Statefull, d.h. es wird nur beim Initiieren einer Verbindung geschaut, ob die Verbindung zulässig ist. Ist die Verbindung erst mal erlaubt und man löscht manuell die entsprechende Regel später, so bleibt der State erhalten, bis es einen Timeout gibt oder die Verbindung regulär beendet wird. Daher kann man mit manuellem Aktivieren und Deaktivieren bestehende Verbindungen nicht blocken, es sei denn man führt einen Statereset durch unter diagnostics>states, reset states.
Firewallrules, die zeitlich gesteuert geschaltet werden:
Um hier bereits aktive Verbindungen zu blocken wenn eine Regel zeitgestützt geschaltet wird kommt ein zusätzlicher Mechanismus zum Einsatz (ipfw zusätzlich zu pf). Diese Blocks bereits aktiver Verbindungen finden dann auch statt, wenn die Verbindung noch einen erlaubten State hat.

An dem ersten Beispiel hat sich nichts zum bisherigen Verhalten geändert. pfSense funktioniert schon immer so, wie auch andere stateful Firewalls. Da die Regeln ohne Zeitplan ja als statisch anzusehen zu sind sollte das kein Problem darstellen. Bei zeitgestützen Regeln, wie gesagt, funktioniert das ganze.

heiko

Hello,
sorry for the misunderstandings about the fw states. I have tested it with two schedules, because (scotts posting) the first schedules becomes up only after a reboot.

1.) I created two schedules
2.) I created one rule to permit icmp to WAN with one schedule (activ 12:45 to 13:00)
3.) At 12:45, sorry nothing happens, no ping replys, at 12:51 i edited and saved manually the schedule for a second time, and it rock´s , hm
4.) The same behaviour if i edited and saved the icmp rule a second time.
5.) At 13:00 nothing happens, at 13:10 i edited and saved the schedule a second time manually, the ping is killed directly

This is not a April Fool's joke!

I think it will work, but only when i edit and save a schedule or the special schedule-rule for a second time! I suppose so.

Can you duplicate this? I´m blessed if i know.

In german:

Hallo,
entschuldigung für die Missverständnisse bzgl. der firewall states. Ich habe es mit 2 schedules getestet (scotts posting), weil der erste Zeitplan nur nach einem Neustart aktiv wird.

1.) Ich habe zwei Zeitpläne erstellt
2.) Ich habe eine Regel mit einem Zeitplan (aktiv 12:45 bis 13:00) erstellt, die ICMP Traffic zum WAN Interface erlaubt.
3.) Um 12:45, entschuldigung, nichts passiert. Keine Ping Antwort, um 12:51 habe ich manuell den zeitplan ein zweites mal gespeichert, und es läuft..
4.) Das gleiche Verhalten war beim zweitenmal abspeichern der ICMP Regel
5.) Um 13:00, nichts passiert, um 13:10 habe ich den Zeitplan ein zweites Mal manuell abgespeichert. Der Ping ist sofort gekillt.

Das ist kein Aprilscherz

Ich denke es wird funktionieren, aber nur wenn ich ein zweites Mal den Zeitplan oder die entsprechende Zeitplan-Regel editiere und speichere. Ich vermute es!

Könnt Ihr das nachstellen?Ich weiß es wirklich nicht.

sullrich

Please try creating schedules at least 30 minutes apart. If these work then I have a hunch of what is going on.

heiko

i will test it

heiko

It is not working.

The Test:

first i created 2 schedules with 30 min. apart –> Screenshot
i created a blocking rule to block icmp traffic to www.heise.de without a schedule. I saved it and it works, no ping replys, i disabled the rule and reset the states, the ping reply and all was good....!
Then i edited this blocking rule and choose a schedule - the activate time were not reached -, so the ping should be answered, but nothing happens. Here i waited for 20 minutes, but alsio nothing happens.
I edited and saved the schedule and rule a second time, but also nothing happens...
The Test Box is a real box not a virtual machine

I capitulate, in my opinion, anywhere is a "bug".
Please duplicate.
Greetings
Heiko

blocking_icmp_rule.jpg_thumb

2_ranges_with_30min_apart.jpg_thumb

heiko

Morning i am in irc with hoba again.
greetings heiko

Then i post it back or hoba

heiko

Sdale: thanks for the really pretty gui. It looks now fine

sullrich

Please test a new snapshot about 2 hours from now.

Thanks to Hoba for translating.

heiko

i´m tired ;D

i will test it in a few hours, i´m taking with hoba tonight in irc…..

heiko

Hello sdale,
look at the screenshot. I think a "missing text" is in the notification…

I don´t know. Can you duplicate this behaiour?

1.) I have a schedule on the rule.
2.) If i edit and save the rule and change the schedule to "none"
3.) I´m going immediate to the schedules, delete the schedule.
4.) The schedule is away. OK, but the notifaction above comes up...

Thanks

in_use_by_what.jpg_thumb

heiko

Hello Scott,
sorry, sorry, sorry, it runs not for me. I think, we need tonnight another IRC-session and a dry wine. ;) The behaviour is same as yesterday. Before the test, i updated to the newest snapshot.

yoda715

@heiko:

Hello sdale,
look at the screenshot. I think a "missing text" is in the notification…

I don´t know. Can you duplicate this behaiour?

1.) I have a schedule on the rule.
2.) If i edit and save the rule and change the schedule to "none"
3.) I´m going immediate to the schedules, delete the schedule.
4.) The schedule is away. OK, but the notifaction above comes up...

Thanks

Put a description in the firewall rule and it should show.

heiko

Ah yes, superb

heiko

OK, that runs, the rule description says (not parsed). Would it be better with "parsed for schedules" ?