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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
