Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jul 2015 03:34:36 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        bycn82 <bycn82@gmail.com>
Cc:        freebsd-ipfw <freebsd-ipfw@freebsd.org>
Subject:   Re: keep-state and in-kernel NAT exposes local ip on external interface
Message-ID:  <55B92ACC.6090505@freebsd.org>
In-Reply-To: <CAC%2BJH2yYuJ92=zZ8%2BrEMh8ofSyPSyGVa6_VdcZ1eKSkmtHrfzQ@mail.gmail.com>
References:  <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> <CAC%2BJH2ybB_9W-okDbdvERRq=VE_9cAENj=rJDyky3OAAN--19Q@mail.gmail.com> <55B8DD3D.1030900@freebsd.org> <CAC%2BJH2yYuJ92=zZ8%2BrEMh8ofSyPSyGVa6_VdcZ1eKSkmtHrfzQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 7/29/15 10:23 PM, bycn82 wrote:
> /Hi,/
> /But I dont understand why you said C->D is already in the dynamic 
> table?  which line create the dynamic rule for it?/

/it happened on a previous packet at some other rule,  for example
30 allow ip from any to D 80 keep-state


/
> /
> /
> /Regards,/
> /bycn82/
>
> On 29 July 2015 at 22:03, Julian Elischer <julian@freebsd.org 
> <mailto:julian@freebsd.org>> wrote:
>
>     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 <julian@freebsd.org
>>     <mailto:julian@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-unsubscribe@freebsd.org
>>         <mailto:freebsd-ipfw-unsubscribe@freebsd.org>"
>>
>>
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B92ACC.6090505>