keep-state and in-kernel NAT exposes local ip on external interface

[Julian Elischer]

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