On Thu, Jul 7, 2011 at 6:51 AM, Tony Sarendal <[email protected]> wrote:
> On Thu, Jul 7, 2011 at 2:03 AM, Ryan McBride <[email protected]> wrote: > >> On Wed, Jul 06, 2011 at 10:45:01PM +0200, Tony Sarendal wrote: >> > >> If there is anyone out there who disables fragment reassembly >> (enabled >> > >> by default), you need to help testing this diff which folds >> > >> pf_test_fragment() into pf_test_rule(). >> > >> >> > > we use this feature in our OpenBSD routers. I'll test and get back to >> you. >> > > >> > Basic testing done. Looks ok. >> >> Thanks for speaking up, and the quick response with test results. >> >> >> > The only thing I noticed was that default wasn't actually default as I >> > thought. If I do "set reassemble no" and reload pf it works as >> > expected, if I now remove or comment it out and reload I still have >> > the "set reassemble no" behaviour. >> >> I'll take a look at this. I think this is the case for some of the other >> 'set foo' options in pfctl... they should all be made consistent one way >> or the other. >> >> >> > Removing the ability to not reassemble seems a little extreme to me, >> > in IP networks there is no guarantee that a router will see all >> fragments. >> >> In such a situation fragments are unlikely to get handled properly >> anyways unless you're filtering completely statelessly, because they >> won't get matched against the states and things will get out of sync. >> > That is correct. We use stateless filtering in these cases. > > I might as well add that we are testing with sloppy flows in some scenarios. We havent gotten as far as checking how things like single fragments are handled but the ability to do pfctl -ss when troubleshooting is making people happy. I was a little hesitant at first but when the openbsd box got to 5.3M states (AMD64/4.9) before the having memory issues I felt we could give it a go. Regards Tony
