Date: Thu, 30 Jul 2015 03:47:07 +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: <55B92DBB.5050204@freebsd.org> In-Reply-To: <55B92ACC.6090505@freebsd.org> 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> <55B92ACC.6090505@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/30/15 3:34 AM, Julian Elischer wrote:
> 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
reread the original example description..
>
>
> /
>> /
>> /
>> /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>"
>>>
>>>
>>
>>
>
> _______________________________________________
> 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"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B92DBB.5050204>