{Complete} Timebased Rules
-
no comment, i will test it
-
I think our language barriers are getting in the way. Is there someone out there that can help translate?
-
Scott,
i think we are finished the project.
Thank you for the the great coding.
heiko -
I am confused, so everything works okay?
-
No, i think it is not working, but you work very well, but i want not a conflict..
-
Nobody is creating a conflict. I just cannot duplicate the problem..
When I permit or deny ICMP traffic on the WAN interface it stops as it should.
-
OK, then it is vmware problem, i think
-
Do you speak german? Please join #pfsenseDE on FreeNODE.
-
I have a feeling that I know what you are testing.
Is this what you did?
ping the wan ip from a client continually (-t on windows)
add icmp allow rule on wan tab
client can now ping the wan
remove the wan icmp rule and apply
client can still ping firewall (pf state exists, you must ctrl-c and ping again or clear states)Where I think the confusion is that I had to do some ipfw mastery to override the pf rules for schedules. And that is the reason why ICMP will be blocked correctly on a schedule. PF rules themselves have not changed so if a state already exists and you remove the rule that session will remain active until it closes or you clear the states on the firewall.
-
Scott,
that´s it. COMPLETELY
-
Good deal. Do you understand now why it works that way? It has always worked that way due to it being a stateful firewall.
In terms of the cosmetic GUI issues, we will look into them.
But at this point is the system working for you? I really need to get 1.2 tagged in CVS and begin the 1.2 beta engineering process.
-
Boh Scott,
yes i do, but we can i test this completley out with schedules on a rule? -
Yes, please test and let me know when you are happy with it.
-
a new snapshot?
-
Sure, that will work. There have been no commits for atleast 9+ hours.
-
Hm? but i will test it
-
Hm? Sorry, I do not understand? What are you trying to tell me?
-
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ß
HeikoHolger, 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?
-
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.
-
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.
-