Date: Wed, 04 Feb 2015 19:23:23 +0800 From: Julian Elischer <julian@freebsd.org> To: bycn82 <bycn82@gmail.com>, lev@freebsd.org Cc: freebsd-ipfw <freebsd-ipfw@freebsd.org>, "Alexander V. Chernikov" <melifaro@freebsd.org>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) Message-ID: <54D2012B.6040906@freebsd.org> In-Reply-To: <CAC%2BJH2yXMS0sMY0k%2B11krgp7mRh1xEeupdZ024VGrUhPac0=FA@mail.gmail.com> References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> <CAC%2BJH2yXMS0sMY0k%2B11krgp7mRh1xEeupdZ024VGrUhPac0=FA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/4/15 6:08 PM, bycn82 wrote: > /Cool, > But maybe not all people are following this topic, so can you please > simplify it by answering below question in order to allow more > people to know what is going on here. > > / > /What kind of problem you are facing and how does your patch resolve it? > > > / > let me have a go at this: when you write complicated rule sets with state, you start having problems where the state is too broad, or contains things you don't want in the place where you are using it.. sure you want packet/session A to set the state, but you don't want state for session B to trigger there at the same time. this allows you to set a state/action for all future packets in the session without triggering sessions you didn't mean to, or actually doing that action yourself right now. this give you a lot more flexibility in the sets you can create. An example here is combining NAT with session state. You can only have the rule active on one side of the NAT. If you want ot have state on the 'inside' of the NAT then you want outgoing processing to continue on, so that the NAT is then used. However if you try do the check-state on input After the NAT (you need to do NAT on the same 'side' of the NAT for both incoming and outgoing) then you end up having to do various tricks to avoid being diverted into output processing. what you want to do is be able to set a rule that will handle the incoming packets in a way you want but doesn't do the same thing for the outgoing packets. Come to think of it another answer might be the ability to specify different actions for a session for incoming and outgoing, but that would be quite hard to do. at least this way you can specify a rule for input without having to do the same thing on output. there are other drawbackss . like if you have another check-state in the output path, it will still trigger on the packet and do what you didn't expect. but I think this is an improvement. Having said that. I'd REALLY like to have multiple dynamic sets and be able to specify which set I'm looking in. then you could have differnt dynamic rules for NAT'd and unNATed packets, and differnet rules for the same packets as they traverse different interfaces. Lev, I think this is an improvement, but I wonder if we can make it even better. Julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D2012B.6040906>