On 7/29/15 5:26 PM, bycn82 wrote:
/Hi Julian,/
/
/
/So below are the rules in your example/
/
/
/5 skipto 10 from A to B
/
/6 skipto 11 from any to any/
/10{action} from A to B keep-state/
/11{action} from C to D/
/
/
/
/
/If I remove the "skipto" rules they will become/
//
/10 {action} from A to B keep-state/
/11 {action} from C to D /
/
/
/Correct me if I was wrong, but in my opinion, the rule 5 and 10
are almost the same, so I dont see the benefit by introducing the
"skipto" rulees. //IMHO, the "check-state" is to speed-up some
selected packets, it will slow-down all other unexpected packets at
the same time./
/
/
/so because C -D is already in the dynamic table it triggers on 10 and
never reaches 11.
see? you fell for it too.
/
/Regards,/
/bycn82/
On 29 July 2015 at 15:39, Julian Elischer <jul...@freebsd.org
<mailto:jul...@freebsd.org>> wrote:
On 7/29/15 3:43 AM, Lev Serebryakov wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 28.07.2015 08:30, Ian Smith wrote:
I have global lack of any spare time (and all my FreeBSD
activity is
only a hobby) for last ~2 months. I see the end of this
unfortunate
state of affairs in near future and I remember about these
examples.
there are some simple examples of things this patch addresses..
For example in the current code, the following (extemely
simplified) set of
rules will not do what you would think when you are working with
a tcp
session from A to B and another from C to D *which has
previously been**
**accepted with a keep-state at some other point in the ruleset*
10 {any action} from A to B keep-state
20 {any action} tcp from C to D
because despite the fact that you are only triggering on a
'setup' packet for A to B, any rule
that includes "keep-state" does a "check-state" implicitly.
so the packet from C to D never gets past rule 10.
the only way you can do this is to prefix rule 10 by something like
5 skipto 10 from A to B
6 skipto 11 from any to any
to make sure packets that are not A to B do not hit the hidden
'check-state' .
this is a very simple example and yes there are ways to get
around it,
but it complicates the ruleset and increases errors
that reminds me I'd also like to be able to put a "not" at the
front of the rule matching to negate the whole test but it
doesn't seem to like that.
_______________________________________________
freebsd-ipfw@freebsd.org <mailto:freebsd-ipfw@freebsd.org>
mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to
"freebsd-ipfw-unsubscr...@freebsd.org
<mailto:freebsd-ipfw-unsubscr...@freebsd.org>"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
