The way ISA handled it was you have to restart the service, just like killing all states achieves in pfsense, but you couldnt do schedules in ISA and I dont know about the latest ones either as I've not looked at those.
Today I've been testing pfsense 2.1/freebsd 8 and pfsense2.2/freebsd 10, its more difficult testing with FF on windows because even when you dont use Google as the search provider in the FF toolbar, your web activity is still sent back to Google and the cloud servers they hire like from Amazon, which then further "compliments" their search business a trick MS seems to have missed but the way FF & Google works makes it harder to keep track of the states as its opens up so many to do a distributed download from youtube amongst other things. I'll be hooking into FF & Windows at some point to examine the memory and thus just what exactly is being sent back to Google as we have a concept called privacy over here in Europe.
So I will have to repeat the tests again with some other webbrowsers tomorrow but there is at least one minor change in behaviour in PF/pfctl between freebsd 8 & 10, but until I can come up with a test which can be repeated by others with more detailed steps its hard to prove the states killing isnt working properly using Windows or Linux with the technology most people have access to.
@cmb:
@Derelict:
If I have a pass rule that passes, say, source 192.168.1.0/24 to an ssh server. Then I change the rule to pass 192.168.1.0/25 and Apply Changes. Should the firewall kill all states for source addresses 192.168.1.128-255 but not sources 192.168.1.0-127? Are YOU going to write that code?
That's just one example of many. It's impossible to do in a bug-free way. It's a hell of a lot of work to do in a way that would ultimately be buggy for a range of edge cases.
Nothing ventured nothing gained, but a problem shared is a problem halved, I'm sure there's plenty of people who would like to chip in with their views as to what would be ideal or the best way to handle the different situations to kill off states.
Even taking votes and having a discussion on what should happen and why is at least a democratic way to resolve & expedite some of the thought processes that will be involved in deciding how to handle some situations, which leaves the job of coding it an easier one as no one person can come up with all the ideas.
Can the forum do votes?
@Supermule:
:D Its just because we are questioning basic design in pfsense.
s/pfsense/basically every firewall in the world/
Feature suggestions are always welcome. This wouldn't be an unreasonable feature request. But acting like it's the end of the world and everything is shit because things work the way basically every firewall works isn't going to get you far.
When its your business that keeps getting hacked, anyone who runs their own business knows its their baby and thus it can be for some the end of the world when you baby goes bust for reasons that are in other peoples or industry's hands.
Whether the industry is right or wrong about allowing or even accepting dangling states and dangling sockets in Linux is a debate for another day, but finding a solution to dangling states will certainly elevate ESF above the rest if the problem is to be tackled and users want it to be tackled.
