{Complete} Timebased Rules

yoda715 · Mar 31, 2007, 9:35 AM

All known bugs are knocked out using latest snapshot. Please test latest snapshot. This latest snapshot should complete time based rules if it meets approval.

heiko · Mar 31, 2007, 8:20 PM

Hello Scott´s,

first, i have a "big problem" with testing it completely out. Here the outcomes. Take a look at the Screenshots.

1.) The Filter reload ist not really working here. I created an icmp-rule to ping the wan-interface. OK, so i disabled this without having a schedule and the ping replys and replys and so on….... It is difficult to test the schedule-logic, cron, resettings states and so on if the filter reloading are not completely working without schedules. Even if i delete the rule, the ping replys and replys, i wait after the deletion one hour, the ping replys....New ping-sessions are also established. Hmmm? I don´t know.

Sorry! Please duplicate!

2.) Can you implement the extension to "Console-menu"?? It would be very nice.

3.) a line break also in the configured range would be helpful --> Screenshot
;D - it´s finished

4.) the Description of the "schedule name" is not right, "-;_" kicks me out when i fill this in..
;D -it´s finished

5.) Upps, when i edit a saved schedule and change the name for example from "test123" to "test12345", all rules with the schedule "test123" are not switching to "test12345" but to "none" -- intended Huh
;D -it´s finished , cool solution

6.) The "schedule name" field is very long, so look at the screenshot, maybe a little bit shorter, a field definition would be good.
??? Not complete, take a look at the screenshot -- Sorry

7.) Screenshot ; edit a saved range without saving the changes, edit then the next range, so the first one is down the drain, it would be better, i think, when only one range at a time can be modified.
;D -it´s finished

8.) Another problem i think --> see Screenshot ssh.jpg- I have to created a blocking rule like ssh at the top. Without a rule schedule it works fine. Now i create a time range - today 16:45 - to 17:00 -. The time is 16:20 when i put the schedule to the rule. Saved, but nothing happens... On 16:40 i cannot established a ssh session. The Blocking rule i think is only active betwen the timerange, so the default lan rule is active, but i can´t access. The webgui anti-lockout checkbox is active. The "not" operator are not used in this rule.

I can test it out, when the filter reloading and states resetting are OK, sorry

Please duplicate this behaviour to number 1 and i will retest as soon as possible

The "knock-out" is delayed :)

Greetings
heiko

sullrich · Mar 31, 2007, 8:35 PM

#1 Sorry, I do not understand this at all. You are saying that ICMP is not being blocked even without a schedule?

In terms of the description boxes, enter a space. Its NOT normal for someone to enter sdvjkhsdgkjhsdgkhsdkjdgsh as a description.

We'll look into the other nit-picks.

heiko · Mar 31, 2007, 9:16 PM

Hello Scott,
what is normal? We can finished it, but in my opinion a test is an extreme test.
Change it or leave it! Your decision!!!

Please test blocking rules without schedules. I´am confused of this.

Heiko

Sorry!!

sullrich · Mar 31, 2007, 9:21 PM

I don't understand the problem so it is going to be hard to test. Can you please explain #1 again.

heiko · Mar 31, 2007, 9:31 PM

Scott,
it is a very simple test.

My first test: I create a rule with icmp path to the wan!
2.) i ping- all is OK
3.) i disable the rule, and the ping replys
4.) i delete the rule, and the ping replys
5.) after the delete of the "one" rule, new ping replys and replys

So, before i test a rule with a schedule, at first a i test the normal behaviour….

Please duplicate!

sullrich · Mar 31, 2007, 9:36 PM

I cannot duplicate this. The firewall works as it should without schedules, in fact, we didn't modify the PF rules at all so if an item does not have a schedule then nothing has changed on the backend.

If you are speaking of a rule having an issue with a schedule please run ipfw show from the shell and show what the rules look like.

heiko · Mar 31, 2007, 9:42 PM

I will test it, i´am disappointed

sullrich · Mar 31, 2007, 9:51 PM

Why are you disappointed?

heiko · Mar 31, 2007, 9:53 PM

no comment, i will test it

sullrich · Mar 31, 2007, 9:53 PM

I think our language barriers are getting in the way. Is there someone out there that can help translate?

heiko · Mar 31, 2007, 9:59 PM

Scott,
i think we are finished the project.
Thank you for the the great coding.
heiko

sullrich · Mar 31, 2007, 9:59 PM

I am confused, so everything works okay?

heiko · Mar 31, 2007, 10:05 PM

No, i think it is not working, but you work very well, but i want not a conflict..

sullrich · Mar 31, 2007, 10:07 PM

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.

heiko · Mar 31, 2007, 10:09 PM

OK, then it is vmware problem, i think

sullrich · Mar 31, 2007, 10:10 PM

Do you speak german? Please join #pfsenseDE on FreeNODE.

sullrich · Mar 31, 2007, 10:49 PM

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.

heiko · Mar 31, 2007, 10:57 PM

Scott,

that´s it. COMPLETELY

sullrich · Mar 31, 2007, 11:00 PM

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.