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

2015-06-30 Thread Georgios Amanakis via freebsd-ipfw 
On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I can
fish (tcpdump)packets on em0 which have escaped the in-kernel NAT and
have as source address an IP on the LAN.

This should not happen and I can confirm that with pf this is not the
case. I have the following ipfw rules:

nat:  ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset

00100 reass ip from any to any in
00200 allow ip from any to any via lo0
00300 allow ip from any to any via em1
00400 nat 123 ip from any to any in recv em0
00500 check-state
00600 skipto 24000 ip from any to me dst-port 80,443,22,500,4500,1194,993,8112 
in recv em0 keep-state
00700 skipto 24000 ip from any to any out xmit em0 keep-state
00800 deny log ip from any to any
24000 nat 123 ip from any to any out xmit em0
24100 allow ip from any to any

Contrary to many online tutorials, including the example of the
handbook regarding NAT (
https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when one
places the NAT rules with the opposite order (i.e. outbound rule first
and then the inbound rule) the problem disappears.

i.e.
...
00400 nat 123 ip from any to any out xmit em0
...
24000 nat 123 ip from any to any in recv em0
...

Why is this happening? Any objections to reversing the order of the NAT
rules? 
___
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"

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

2015-07-01 Thread Lev Serebryakov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote:

  It is good example for my changes :) All this "skipto / keep-state"
magic is not understandable.

> On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I
> can fish (tcpdump)packets on em0 which have escaped the in-kernel
> NAT and have as source address an IP on the LAN.
> 
> This should not happen and I can confirm that with pf this is not
> the case. I have the following ipfw rules:
> 
> nat:  ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset
> 
> 00100 reass ip from any to any in 00200 allow ip from any to any
> via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip
> from any to any in recv em0 00500 check-state 00600 skipto 24000 ip
> from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv
> em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0
> keep-state 00800 deny log ip from any to any 24000 nat 123 ip from
> any to any out xmit em0 24100 allow ip from any to any
> 
> Contrary to many online tutorials, including the example of the 
> handbook regarding NAT ( 
> https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when
> one places the NAT rules with the opposite order (i.e. outbound
> rule first and then the inbound rule) the problem disappears.
> 
> i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000
> nat 123 ip from any to any in recv em0 ...
> 
> Why is this happening? Any objections to reversing the order of the
> NAT rules? ___ 
> 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"
> 


- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJVlDldXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkigQAMhJSo5UaDxrAz5RmMt1KjJX
5kXKXe35NLzI6J3bt/ZBBwmJSl1Z/17BEhTAMQmietAi5zVV8QD8DB+lq/jjvY3F
TmADQ4O/b2Dml/Vgcg8fzv4Oai/fPENfNLZNItc/Hv9fxKtDUoxW3SehlTcti/DM
5VpIb0Td7o3WWEmtYMUHSvYIXpUQSr8IeE48Svd4dKJ7x7oJP11qpECa2vsDRJFc
8BM5jWWfJqfWcB//+G/9C9nT4DbTHhwrP4UkvZDwM2mc8xz5gzEtwXUDPle8Bgtb
StHrMkrgZvGfGWd95dPVm3oTdhIVvv3KSNW47PCo/xRVz8ZQKog2N4QYrNIUzhbL
Igmxus3VD4uwqr+3z+lB5lgUYMeB0pqnEihWGAQ15cwxNRlEEFOg/hGZTiNx9u88
2/UcK6up2jtxBTXy2Tf/CWL12PqnkDxsC2drZULDOR9P/XT3YcB++ie6Xz9iv7rt
3C8hOQ3B8LqAKfTP4LG2vh1uv4X6Vw7sfx3vpGXr3bQFaZt/odesI3/SiWaSmkNi
bu6JKU2QnepLRrKObeggIap4SSRq7AKZiVa+O5R3HJFAhsFLutgHIYP1G7+BzHAX
OCHRXgHiWDNNKa9tzUQgdS372kM+kP10vbY74TJ2dEL3Nwc9XehiasToEVfYhLin
FG8VdsZZSi+wA8Pg3YbQ
=kzTV
-END PGP SIGNATURE-
___
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"

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

2015-07-27 Thread Ian Smith 
Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote:
 > On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote:
 > 
 >   It is good example for my changes :) All this "skipto / keep-state"
 > magic is not understandable.

Indeed.  So all we're waiting for, Lev, is some simple usage examples of 
how things should be done with your new stateful operators, especially 
when combining stateful rules with NAT.  Please see what you can do ..

I know it's clear to you, but I for one cannot get my head around these
without a couple of examples, roughly suitable for inclusion in ipfw(8) 
EXAMPLES section.  Rough illustrations would do fine at first.

In the problems shown lately, including the one below (harder to read 
with the quoting wrapped like that!) it seems the problem of keepalives 
being issued using the internal address would not occur if keep-state 
was only applied _after_ NAT, only on the already-translated source 
address, but like you and apparently many others, I find these rulesets 
very difficult to follow in terms of different possible flows.

cheers, Ian

 > > On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I
 > > can fish (tcpdump)packets on em0 which have escaped the in-kernel
 > > NAT and have as source address an IP on the LAN.
 > > 
 > > This should not happen and I can confirm that with pf this is not
 > > the case. I have the following ipfw rules:
 > > 
 > > nat:  ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset
 > > 
 > > 00100 reass ip from any to any in 00200 allow ip from any to any
 > > via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip
 > > from any to any in recv em0 00500 check-state 00600 skipto 24000 ip
 > > from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv
 > > em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0
 > > keep-state 00800 deny log ip from any to any 24000 nat 123 ip from
 > > any to any out xmit em0 24100 allow ip from any to any
 > > 
 > > Contrary to many online tutorials, including the example of the 
 > > handbook regarding NAT ( 
 > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when
 > > one places the NAT rules with the opposite order (i.e. outbound
 > > rule first and then the inbound rule) the problem disappears.
 > > 
 > > i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000
 > > nat 123 ip from any to any in recv em0 ...
 > > 
 > > Why is this happening? Any objections to reversing the order of the
 > > NAT rules?

 > - -- 
 > // Lev Serebryakov
___
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"

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

2015-07-27 Thread bycn82 
for me.  i am totally dont understand all these.   waiting dor example as
well

On Tuesday, July 28, 2015, Ian Smith  wrote:

> Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote:
>  > On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote:
>  >
>  >   It is good example for my changes :) All this "skipto / keep-state"
>  > magic is not understandable.
>
> Indeed.  So all we're waiting for, Lev, is some simple usage examples of
> how things should be done with your new stateful operators, especially
> when combining stateful rules with NAT.  Please see what you can do ..
>
> I know it's clear to you, but I for one cannot get my head around these
> without a couple of examples, roughly suitable for inclusion in ipfw(8)
> EXAMPLES section.  Rough illustrations would do fine at first.
>
> In the problems shown lately, including the one below (harder to read
> with the quoting wrapped like that!) it seems the problem of keepalives
> being issued using the internal address would not occur if keep-state
> was only applied _after_ NAT, only on the already-translated source
> address, but like you and apparently many others, I find these rulesets
> very difficult to follow in terms of different possible flows.
>
> cheers, Ian
>
>  > > On FreeBSD 10.1p13 with two interfaces em0(internet) and em1(lan) I
>  > > can fish (tcpdump)packets on em0 which have escaped the in-kernel
>  > > NAT and have as source address an IP on the LAN.
>  > >
>  > > This should not happen and I can confirm that with pf this is not
>  > > the case. I have the following ipfw rules:
>  > >
>  > > nat:  ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset
>  > >
>  > > 00100 reass ip from any to any in 00200 allow ip from any to any
>  > > via lo0 00300 allow ip from any to any via em1 00400 nat 123 ip
>  > > from any to any in recv em0 00500 check-state 00600 skipto 24000 ip
>  > > from any to me dst-port 80,443,22,500,4500,1194,993,8112 in recv
>  > > em0 keep-state 00700 skipto 24000 ip from any to any out xmit em0
>  > > keep-state 00800 deny log ip from any to any 24000 nat 123 ip from
>  > > any to any out xmit em0 24100 allow ip from any to any
>  > >
>  > > Contrary to many online tutorials, including the example of the
>  > > handbook regarding NAT (
>  > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html), when
>  > > one places the NAT rules with the opposite order (i.e. outbound
>  > > rule first and then the inbound rule) the problem disappears.
>  > >
>  > > i.e. ... 00400 nat 123 ip from any to any out xmit em0 ... 24000
>  > > nat 123 ip from any to any in recv em0 ...
>  > >
>  > > Why is this happening? Any objections to reversing the order of the
>  > > NAT rules?
>
>  > - --
>  > // Lev Serebryakov
> ___
> 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
> "
>
___
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"

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

2015-07-28 Thread Lev Serebryakov 
-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.

> Way back on Wed, 1 Jul 2015 22:02:53 +0300, Lev Serebryakov wrote:
>> On 30.06.2015 22:20, Georgios Amanakis via freebsd-ipfw wrote:
>> 
>> It is good example for my changes :) All this "skipto /
>> keep-state" magic is not understandable.
> 
> Indeed.  So all we're waiting for, Lev, is some simple usage
> examples of how things should be done with your new stateful
> operators, especially when combining stateful rules with NAT.
> Please see what you can do ..
> 
> I know it's clear to you, but I for one cannot get my head around
> these without a couple of examples, roughly suitable for inclusion
> in ipfw(8) EXAMPLES section.  Rough illustrations would do fine at
> first.
> 
> In the problems shown lately, including the one below (harder to
> read with the quoting wrapped like that!) it seems the problem of
> keepalives being issued using the internal address would not occur
> if keep-state was only applied _after_ NAT, only on the
> already-translated source address, but like you and apparently many
> others, I find these rulesets very difficult to follow in terms of
> different possible flows.
> 
> cheers, Ian
> 
>>> On FreeBSD 10.1p13 with two interfaces em0(internet) and
>>> em1(lan) I can fish (tcpdump)packets on em0 which have escaped
>>> the in-kernel NAT and have as source address an IP on the LAN.
>>> 
>>> This should not happen and I can confirm that with pf this is
>>> not the case. I have the following ipfw rules:
>>> 
>>> nat:  ipfw nat 123 config ip xxx.xxx.xxx.xxx same_ports reset
>>> 
>>> 00100 reass ip from any to any in 00200 allow ip from any to
>>> any via lo0 00300 allow ip from any to any via em1 00400 nat
>>> 123 ip from any to any in recv em0 00500 check-state 00600
>>> skipto 24000 ip from any to me dst-port
>>> 80,443,22,500,4500,1194,993,8112 in recv em0 keep-state 00700
>>> skipto 24000 ip from any to any out xmit em0 keep-state 00800
>>> deny log ip from any to any 24000 nat 123 ip from any to any
>>> out xmit em0 24100 allow ip from any to any
>>> 
>>> Contrary to many online tutorials, including the example of the
>>>  handbook regarding NAT ( 
>>> https://www.freebsd.org/doc/handbook/firewalls-ipfw.html),
>>> when one places the NAT rules with the opposite order (i.e.
>>> outbound rule first and then the inbound rule) the problem
>>> disappears.
>>> 
>>> i.e. ... 00400 nat 123 ip from any to any out xmit em0 ...
>>> 24000 nat 123 ip from any to any in recv em0 ...
>>> 
>>> Why is this happening? Any objections to reversing the order of
>>> the NAT rules?
> 
>> - -- // Lev Serebryakov
> 


- -- 
// Lev Serebryakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVt9tRXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePejUQAMknraIZcEVjcS+rctLZ1RUl
rOgiYBI3R8LWXi8QaiMYnIqHPhI8llsKNPi/3g1eWaZcgFhOEkzZlG6Nv+EvXTYC
3U7ml35WjqOKf6q7o/HLcA3GBkFUoNTnSnwbVnrfiKdlshu2nRN+IEvWUW9Uc8Zc
b2O0PKpOhdw1L8pbh8ZPNh1Sv3JyMFOoi3WWAu4kNWI+i+wYe0anKsNG9eDzI398
bRMOFXFEuM2qsjseDL9wyi2LJYhGk5kaO5fp+3NkBuqI3KFDUxlJ63Xz2E2fMUI6
y0HtHpuB6JUbSUrWIMsK0TUgGkInHwBg71pUa4N/Cv3z68fA8/V3u57JQMisoFzQ
MemareZUd0Af87a9Rk+XwcV1gdVN+neavlcdRK0h58nUwJOWrF2U2bjkglvrUN2v
LCXc2ietFeEkj4CgbebQLwRHLtuB6rPQSY6tknnNkoybzRyA1nZBDM+W2GTfo3ap
iHz2Dtakd45njJLK5AYom/1blbpZHW1Mw0DpdV+2t3c/0UqXGITtds5dyvSGyBQN
iII4K2eqOwf6QHe6i0LDc6ZcWnX64xZJbS2lzyoUlrGrbszXu2hgZLfwgN+pJ1Zd
5i+HCg2cJcZsft9hOusS4SC3LcgUly2IFLwrPZcYI4Y9zLwBfa01smLRzwza/ruT
PBV3/W3B9sLMZA1/8gny
=O0Et
-END PGP SIGNATURE-
___
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"

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

2015-07-29 Thread Julian Elischer 

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

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

2015-07-29 Thread bycn82 
*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.*


*Regards,*
*bycn82*




On 29 July 2015 at 15:39, Julian Elischer  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 mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "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"

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

2015-07-29 Thread Julian Elischer 

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

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

2015-07-29 Thread bycn82 
*Hi,*
*But I dont understand why you said C->D is already in the dynamic table?
 which line create the dynamic rule for it?*

*Regards,*
*bycn82*

On 29 July 2015 at 22:03, Julian Elischer  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  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 mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "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"

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

2015-07-29 Thread Julian Elischer 

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

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

2015-07-29 Thread 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 > 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 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 
mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to
"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"



___
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"