[RFD] iptables: mangle table obsoletes filter table

[RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

With the existence of the mangle table, how useful is the filter table?

Other than requiring the REJECT target to be ported to the mangle table, is 
the filter table faster than the mangle table?

If not, then shouldn't the filter table be obsoleted to avoid confusion?


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Please send mails discussing netfilter to netfilter-devel.

Al Boldi wrote:
> With the existence of the mangle table, how useful is the filter table?
> 
> Other than requiring the REJECT target to be ported to the mangle table, is 
> the filter table faster than the mangle table?

There are some minor differences in ordering (mangle comes before
DNAT, filter afterwards), but for most rulesets thats completely
irrelevant. The only difference that really matters is that mangle
performs rerouting in LOCAL_OUT for packets that had their routing
key changed, so its really a superset of the filter table. If you
want to use REJECT in the mangle table, you just need to remove the
restriction to filter, it works fine. I would prefer to also remove
the restriction of MARK, CONNMARK etc. to mangle, they're used for
more than just routing today so that restriction also doesn't make
much sense. Patches for this are welcome.

> If not, then shouldn't the filter table be obsoleted to avoid confusion?

That would probably confuse people. Just don't use it if you don't
need to.

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Patrick McHardy wrote:
> Please send mails discussing netfilter to netfilter-devel.

Correct address CCed and unrelated lists removed .. stupid
auto-completion :)

> Al Boldi wrote:
> 
>>With the existence of the mangle table, how useful is the filter table?
>>
>>Other than requiring the REJECT target to be ported to the mangle table, is 
>>the filter table faster than the mangle table?
> 
> 
> There are some minor differences in ordering (mangle comes before
> DNAT, filter afterwards), but for most rulesets thats completely
> irrelevant. The only difference that really matters is that mangle
> performs rerouting in LOCAL_OUT for packets that had their routing
> key changed, so its really a superset of the filter table. If you
> want to use REJECT in the mangle table, you just need to remove the
> restriction to filter, it works fine. I would prefer to also remove
> the restriction of MARK, CONNMARK etc. to mangle, they're used for
> more than just routing today so that restriction also doesn't make
> much sense. Patches for this are welcome.
> 
> 
>>If not, then shouldn't the filter table be obsoleted to avoid confusion?
> 
> 
> That would probably confuse people. Just don't use it if you don't
> need to.

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Patrick McHardy wrote:
> Please send mails discussing netfilter to netfilter-devel.

Ok.  I just found out this changed to vger.  But 
netfilter-devel@vger.kernel.org is bouncing me.

> Al Boldi wrote:
> > With the existence of the mangle table, how useful is the filter table?
> >
> > Other than requiring the REJECT target to be ported to the mangle table,
> > is the filter table faster than the mangle table?
>
> There are some minor differences in ordering (mangle comes before
> DNAT, filter afterwards), but for most rulesets thats completely
> irrelevant. The only difference that really matters is that mangle
> performs rerouting in LOCAL_OUT for packets that had their routing
> key changed, so its really a superset of the filter table. If you
> want to use REJECT in the mangle table, you just need to remove the
> restriction to filter, it works fine. I would prefer to also remove
> the restriction of MARK, CONNMARK etc. to mangle, they're used for
> more than just routing today so that restriction also doesn't make
> much sense. Patches for this are welcome.

Something like this (untested):

--- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
+++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
@@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
 
 static inline void send_unreach(struct sk_buff *skb_in, int code)
 {
+       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
        icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
 }
 
@@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
        .family         = AF_INET,
        .target         = reject,
        .targetsize     = sizeof(struct ipt_reject_info),
-       .table          = "filter",
-       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
-                         (1 << NF_IP_LOCAL_OUT),
        .checkentry     = check,
        .me             = THIS_MODULE,
 };

> > If not, then shouldn't the filter table be obsoleted to avoid confusion?
>
> That would probably confuse people. Just don't use it if you don't
> need to.

The problem is that people think they are safe with the filter table, when in 
fact they need the prerouting chain to seal things.  Right now this is only 
possible in the mangle table.



Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Al Boldi wrote:
> Patrick McHardy wrote:
> 
>>Please send mails discussing netfilter to netfilter-devel.
> 
> 
> Ok.  I just found out this changed to vger.  But 
> netfilter-devel@vger.kernel.org is bouncing me.

Seems to work, I got your mail on netfilter-devel.

>>Al Boldi wrote:
>>
>>>With the existence of the mangle table, how useful is the filter table?
>>>
>>>Other than requiring the REJECT target to be ported to the mangle table,
>>>is the filter table faster than the mangle table?
>>
>>There are some minor differences in ordering (mangle comes before
>>DNAT, filter afterwards), but for most rulesets thats completely
>>irrelevant. The only difference that really matters is that mangle
>>performs rerouting in LOCAL_OUT for packets that had their routing
>>key changed, so its really a superset of the filter table. If you
>>want to use REJECT in the mangle table, you just need to remove the
>>restriction to filter, it works fine. I would prefer to also remove
>>the restriction of MARK, CONNMARK etc. to mangle, they're used for
>>more than just routing today so that restriction also doesn't make
>>much sense. Patches for this are welcome.
> 
> 
> Something like this (untested):
> 
> --- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
> +++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
> @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
>  
>  static inline void send_unreach(struct sk_buff *skb_in, int code)
>  {
> +       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
>         icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
>  }
>  
> @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
>         .family         = AF_INET,
>         .target         = reject,
>         .targetsize     = sizeof(struct ipt_reject_info),
> -       .table          = "filter",
> -       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> -                         (1 << NF_IP_LOCAL_OUT),
>         .checkentry     = check,
>         .me             = THIS_MODULE,
>  };


That includes an unrelated change, I meant to simply remove the filter
table restriction.

>>>If not, then shouldn't the filter table be obsoleted to avoid confusion?
>>
>>That would probably confuse people. Just don't use it if you don't
>>need to.
> 
> 
> The problem is that people think they are safe with the filter table, when in 
> fact they need the prerouting chain to seal things.  Right now this is only 
> possible in the mangle table.


Why do they need PREROUTING?

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Patrick McHardy wrote:
> Al Boldi wrote:
> > Patrick McHardy wrote:
> >>Please send mails discussing netfilter to netfilter-devel.
> >
> > Ok.  I just found out this changed to vger.  But
> > netfilter-devel@vger.kernel.org is bouncing me.
>
> Seems to work, I got your mail on netfilter-devel.

Looks like it works sometimes.  Added lkml as a backup...

> >>Al Boldi wrote:
> >>>With the existence of the mangle table, how useful is the filter table?
> >>>
> >>>Other than requiring the REJECT target to be ported to the mangle
> >>> table, is the filter table faster than the mangle table?
> >>
> >>There are some minor differences in ordering (mangle comes before
> >>DNAT, filter afterwards), but for most rulesets thats completely
> >>irrelevant. The only difference that really matters is that mangle
> >>performs rerouting in LOCAL_OUT for packets that had their routing
> >>key changed, so its really a superset of the filter table. If you
> >>want to use REJECT in the mangle table, you just need to remove the
> >>restriction to filter, it works fine. I would prefer to also remove
> >>the restriction of MARK, CONNMARK etc. to mangle, they're used for
> >>more than just routing today so that restriction also doesn't make
> >>much sense. Patches for this are welcome.
> >
> > Something like this (untested):
> >
> > --- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
> > +++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
> > @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
> >
> >  static inline void send_unreach(struct sk_buff *skb_in, int code)
> >  {
> > +       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
> >         icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
> >  }
> >
> > @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
> >         .family         = AF_INET,
> >         .target         = reject,
> >         .targetsize     = sizeof(struct ipt_reject_info),
> > -       .table          = "filter",
> > -       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> > -                         (1 << NF_IP_LOCAL_OUT),
> >         .checkentry     = check,
> >         .me             = THIS_MODULE,
> >  };
>
> That includes an unrelated change, I meant to simply remove the filter
> table restriction.
>
> >>>If not, then shouldn't the filter table be obsoleted to avoid
> >>> confusion?
> >>
> >>That would probably confuse people. Just don't use it if you don't
> >>need to.
> >
> > The problem is that people think they are safe with the filter table,
> > when in fact they need the prerouting chain to seal things.  Right now
> > this is only possible in the mangle table.
>
> Why do they need PREROUTING?

Well, for example to stop any transient packets being forwarded.  You could 
probably hack around this using mark's, but you can't stop the implied route 
lookup, unless you stop it in prerouting.


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things.  Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
> 
> 
> Well, for example to stop any transient packets being forwarded.  You could 
> probably hack around this using mark's, but you can't stop the implied route 
> lookup, unless you stop it in prerouting.


This also works fine in FORWARD with a little extra overhead.
If you really have to save resources, you should use PREROUTING/raw
to also avoid the creation of a connection tracking entry.

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Patrick McHardy wrote:
> Al Boldi wrote:
> >>>The problem is that people think they are safe with the filter table,
> >>>when in fact they need the prerouting chain to seal things.  Right now
> >>>this is only possible in the mangle table.
> >>
> >>Why do they need PREROUTING?
> >
> > Well, for example to stop any transient packets being forwarded.  You
> > could probably hack around this using mark's, but you can't stop the
> > implied route lookup, unless you stop it in prerouting.
>
> This also works fine in FORWARD with a little extra overhead.
> If you really have to save resources, you should use PREROUTING/raw
> to also avoid the creation of a connection tracking entry.

Yes sure, if you use nat.  But can you see how forcing people into splitting 
their rules across tables adds complexity.  And without ipt_REJECT patch, 
they can't even use REJECT in prerouting, which forces them to do some 
strange hacks.

IMHO, we should make things as easily configurable as possible, and as things 
stand right now, the filter-table is completely useless for 99% of 
use-cases.


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Al Boldi wrote:
> Patrick McHardy wrote:
> 
>>Al Boldi wrote:
>>
>>>Well, for example to stop any transient packets being forwarded.  You
>>>could probably hack around this using mark's, but you can't stop the
>>>implied route lookup, unless you stop it in prerouting.
>>
>>This also works fine in FORWARD with a little extra overhead.
>>If you really have to save resources, you should use PREROUTING/raw
>>to also avoid the creation of a connection tracking entry.
> 
> 
> Yes sure, if you use nat.

Conntrack.

> But can you see how forcing people into splitting 
> their rules across tables adds complexity.  And without ipt_REJECT patch, 
> they can't even use REJECT in prerouting, which forces them to do some 
> strange hacks.
> 
> IMHO, we should make things as easily configurable as possible, and as things 
> stand right now, the filter-table is completely useless for 99% of 
> use-cases.


Sure, as I said, patches to remove the arbitary restrictions to
tables are welcome, but please do this for all targets and
matches which allow this, not only REJECT. And if you include a
seperate (tested) patch for the IPv4 and IPv6 REJECT targets
I'll consider it as well.

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Patrick McHardy wrote:
> Al Boldi wrote:
> > But can you see how forcing people into splitting
> > their rules across tables adds complexity.  And without ipt_REJECT
> > patch, they can't even use REJECT in prerouting, which forces them to do
> > some strange hacks.
> >
> > IMHO, we should make things as easily configurable as possible, and as
> > things stand right now, the filter-table is completely useless for 99%
> > of use-cases.
>
> Sure, as I said, patches to remove the arbitary restrictions to
> tables are welcome, but please do this for all targets and
> matches which allow this, not only REJECT. And if you include a
> seperate (tested) patch for the IPv4 and IPv6 REJECT targets
> I'll consider it as well.

Sounds fair.  All we need now is for someone to kindly submit these rather 
straight forward patches.


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Bill Davidsen]

Al Boldi wrote:
> Patrick McHardy wrote:
>> Please send mails discussing netfilter to netfilter-devel.
> 
> Ok.  I just found out this changed to vger.  But 
> netfilter-devel@vger.kernel.org is bouncing me.
> 
>> Al Boldi wrote:
>>> With the existence of the mangle table, how useful is the filter table?
>>>
>>> Other than requiring the REJECT target to be ported to the mangle table,
>>> is the filter table faster than the mangle table?
>> There are some minor differences in ordering (mangle comes before
>> DNAT, filter afterwards), but for most rulesets thats completely
>> irrelevant. The only difference that really matters is that mangle
>> performs rerouting in LOCAL_OUT for packets that had their routing
>> key changed, so its really a superset of the filter table. If you
>> want to use REJECT in the mangle table, you just need to remove the
>> restriction to filter, it works fine. I would prefer to also remove
>> the restriction of MARK, CONNMARK etc. to mangle, they're used for
>> more than just routing today so that restriction also doesn't make
>> much sense. Patches for this are welcome.
> 
> Something like this (untested):
> 
> --- ipt_REJECT.bak.c    2007-10-12 08:25:17.000000000 +0300
> +++ ipt_REJECT.c        2007-10-12 08:31:44.000000000 +0300
> @@ -165,6 +165,7 @@ static void send_reset(struct sk_buff *o
>  
>  static inline void send_unreach(struct sk_buff *skb_in, int code)
>  {
> +       if (!skb_in->dst) ip_route_me_harder(&skb_in, RTN_UNSPEC);
>         icmp_send(skb_in, ICMP_DEST_UNREACH, code, 0);
>  }
>  
> @@ -245,9 +246,6 @@ static struct xt_target ipt_reject_reg =
>         .family         = AF_INET,
>         .target         = reject,
>         .targetsize     = sizeof(struct ipt_reject_info),
> -       .table          = "filter",
> -       .hooks          = (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_FORWARD) |
> -                         (1 << NF_IP_LOCAL_OUT),
>         .checkentry     = check,
>         .me             = THIS_MODULE,
>  };
> 
>>> If not, then shouldn't the filter table be obsoleted to avoid confusion?
>> That would probably confuse people. Just don't use it if you don't
>> need to.
> 
That is a most practical suggestion.

> The problem is that people think they are safe with the filter table, when in 
> fact they need the prerouting chain to seal things.  Right now this is only 
> possible in the mangle table.
> 
I'm not sure what you think is unsafe about using the filter table, and 
the order of evaluation issues certainly seem to suggest that some 
actions would take a major rethink at least. Perhaps you could avoid 
breaking all of the setups which currently work, rather than force 
everyone to do things differently because you feel that your way is better.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: [RFD] iptables: mangle table obsoletes filter table

[Bill Davidsen]

Bill Davidsen wrote:

>>>> If not, then shouldn't the filter table be obsoleted to avoid 
>>>> confusion?
>>> That would probably confuse people. Just don't use it if you don't
>>> need to.
>>
> That is a most practical suggestion.
> 
>> The problem is that people think they are safe with the filter table, 
>> when in fact they need the prerouting chain to seal things.  Right now 
>> this is only possible in the mangle table.
>>
> I'm not sure what you think is unsafe about using the filter table, and 
> the order of evaluation issues certainly seem to suggest that some 
> actions would take a major rethink at least. Perhaps you could avoid 
> breaking all of the setups which currently work, rather than force 
> everyone to do things differently because you feel that your way is better.
> 
It was my intention to suggest that unintentional breakage of existing 
setups should be avoided, not that removing the filter table was some 
evil plot. ;-)
On rereading my original post I failed to make that clear, please take 
it as intended.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Bill Davidsen wrote:
> Bill Davidsen wrote:
> >>>> If not, then shouldn't the filter table be obsoleted to avoid
> >>>> confusion?
> >>>
> >>> That would probably confuse people. Just don't use it if you don't
> >>> need to.
> >
> > That is a most practical suggestion.
> >
> >> The problem is that people think they are safe with the filter table,
> >> when in fact they need the prerouting chain to seal things.  Right now
> >> this is only possible in the mangle table.
> >
> > I'm not sure what you think is unsafe about using the filter table, and
> > the order of evaluation issues certainly seem to suggest that some
> > actions would take a major rethink at least. Perhaps you could avoid
> > breaking all of the setups which currently work, rather than force
> > everyone to do things differently because you feel that your way is
> > better.
>
> It was my intention to suggest that unintentional breakage of existing
> setups should be avoided, not that removing the filter table was some
> evil plot. ;-)
> On rereading my original post I failed to make that clear, please take
> it as intended.

Sure, the idea was to mark the filter table obsolete as to make people start 
using the mangle table to do their filtering for new setups.  The filter 
table would then still be available for legacy/special setups.  But this 
would only be possible if we at least ported the REJECT target to mangle.


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:

> Sure, the idea was to mark the filter table obsolete as to make people start 
> using the mangle table to do their filtering for new setups.  The filter 
> table would then still be available for legacy/special setups.  But this 
> would only be possible if we at least ported the REJECT target to mangle.

That's *half* the battle.  The other half is explaining why I should move
from a perfectly functional setup that uses the filter table.  What gains
do I get from doing so?  What isn't working that I don't know about? etc?

In other words - why do I want to move from filter to mangle?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 20 2007 00:47, Valdis.Kletnieks@vt.edu wrote:
>> Sure, the idea was to mark the filter table obsolete as to make people start 
>> using the mangle table to do their filtering for new setups.  The filter 
>> table would then still be available for legacy/special setups.  But this 
>> would only be possible if we at least ported the REJECT target to mangle.
>
>That's *half* the battle.  The other half is explaining why I should move
>from a perfectly functional setup that uses the filter table.  What gains
>do I get from doing so?  What isn't working that I don't know about? etc?
>
>In other words - why do I want to move from filter to mangle?

Packet processing time.
Compare previous:
	packet goes through mangle, then is dropped in filter
Compare afterwards:
	packet is already dropped in mangle

=> less code to run through

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Valdis.Kletnieks@vt.edu wrote:
> On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
> > Sure, the idea was to mark the filter table obsolete as to make people
> > start using the mangle table to do their filtering for new setups.  The
> > filter table would then still be available for legacy/special setups. 
> > But this would only be possible if we at least ported the REJECT target
> > to mangle.
>
> That's *half* the battle.  The other half is explaining why I should move
> from a perfectly functional setup that uses the filter table.  What gains
> do I get from doing so?  What isn't working that I don't know about? etc?
>
> In other words - why do I want to move from filter to mangle?

This has already been explained in this thread; here it is again:

Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things.  Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
> 
> Well, for example to stop any transient packets being forwarded.  You could 
> probably hack around this using mark's, but you can't stop the implied
> route lookup, unless you stop it in prerouting.

Basically, you have one big unintended gaping whole in your firewall, that 
could easily be exploited for DoS attacks at the least, unless you put in 
specific rules to limit this.

Plus, it's outrageously incorrect to accept invalid packets, just because 
your filtering infrastructure can only reject packets after they have been 
prerouted.


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

On Sun, 21 Oct 2007 07:31:58 +0300, Al Boldi said:
> > Well, for example to stop any transient packets being forwarded.  You could 
> > probably hack around this using mark's, but you can't stop the implied
> > route lookup, unless you stop it in prerouting.
> 
> Basically, you have one big unintended gaping whole in your firewall, that 
> could easily be exploited for DoS attacks at the least, unless you put in 
> specific rules to limit this.

OK, the light bulb just went on... ;)

We actually *do* have an issue with the flip side of that - it's a frikking
pain to make packets that show up on eth0 with a destination of 127.0.0.1
go away un-noticed - or at least I'm assuming it's the flip side of the same
issue.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RFD] iptables: mangle table obsoletes filter table

[Bill Davidsen]

Al Boldi wrote:
> Valdis.Kletnieks@vt.edu wrote:
>> On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
>>> Sure, the idea was to mark the filter table obsolete as to make people
>>> start using the mangle table to do their filtering for new setups.  The
>>> filter table would then still be available for legacy/special setups. 
>>> But this would only be possible if we at least ported the REJECT target
>>> to mangle.
>> That's *half* the battle.  The other half is explaining why I should move
>> from a perfectly functional setup that uses the filter table.  What gains
>> do I get from doing so?  What isn't working that I don't know about? etc?
>>
>> In other words - why do I want to move from filter to mangle?
> 
> This has already been explained in this thread; here it is again:
> 
> Al Boldi wrote:
>>>> The problem is that people think they are safe with the filter table,
>>>> when in fact they need the prerouting chain to seal things.  Right now
>>>> this is only possible in the mangle table.
>>> Why do they need PREROUTING?
>> Well, for example to stop any transient packets being forwarded.  You could 
>> probably hack around this using mark's, but you can't stop the implied
>> route lookup, unless you stop it in prerouting.
> 
> Basically, you have one big unintended gaping whole in your firewall, that 
> could easily be exploited for DoS attacks at the least, unless you put in 
> specific rules to limit this.
> 
Well... true enough on a small firewall machine with a really fast link, 
maybe. I like your point about efficiency better, it's more logical, 
like putting an ACCEPT of established connections before a lot of low 
probability rules. The only time I have seen rules actually bog a 
machine was when a major ISP sent out a customer "upgrade" with a bug 
which caused certain connections to be SYN-SYN/ACK-RST leaving half open 
sockets. They sent out 160k of them and the blocking list became very 
long as blocking rules were added.

> Plus, it's outrageously incorrect to accept invalid packets, just because 
> your filtering infrastructure can only reject packets after they have been 
> prerouted.
> 
As long as the filter table doesn't go away, sometimes things change 
after PREROUTING, like NAT, and additional rules must be used.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

Re: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 12 2007 00:31, Al Boldi wrote:
>
>With the existence of the mangle table, how useful is the filter table?

A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
http://marc.info/?l=netfilter-devel&m=117400063907706&w=2

in the end, my proposal was something like
http://jengelh.hopto.org/GFX0/nf_proposal2.svg

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Jan Engelhardt wrote:
> On Oct 12 2007 00:31, Al Boldi wrote:
> >With the existence of the mangle table, how useful is the filter table?
>
> A similar discussion was back in March 2007.
> http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
> http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>
> in the end, my proposal was something like
> http://jengelh.hopto.org/GFX0/nf_proposal2.svg

Any chance you could publish this as something readable like text/html?


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 12 2007 16:30, Al Boldi wrote:
>Jan Engelhardt wrote:
>> On Oct 12 2007 00:31, Al Boldi wrote:
>> >With the existence of the mangle table, how useful is the filter table?
>>
>> A similar discussion was back in March 2007.
>> http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
>> http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>>
>> in the end, my proposal was something like
>> http://jengelh.hopto.org/GFX0/nf_proposal2.svg
>
>Any chance you could publish this as something readable like text/html?

Like, image/png?
http://jengelh.hopto.org/GFX0/nf_proposal2.png

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Jan Engelhardt wrote:
> On Oct 12 2007 16:30, Al Boldi wrote:
>>>>
>>>>With the existence of the mangle table, how useful is the filter table?
>>>
>>>A similar discussion was back in March 2007.
>>>http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
>>>http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
>>>
>>>in the end, my proposal was something like
>>>http://jengelh.hopto.org/GFX0/nf_proposal2.svg
>>
>>Any chance you could publish this as something readable like text/html?
> 
> 
> Like, image/png?
> http://jengelh.hopto.org/GFX0/nf_proposal2.png


The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and "built-in"
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should be possible to set up tables
basically any way you desire.

Re: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 12 2007 15:48, Patrick McHardy wrote:
>
>The netlink based iptables successor I'm currently working on allows to
>dynamically create tables with user-specified priorities and "built-in"
>chains. The only built-in tables will be those that need extra
>processing (mangle/nat). So it should be possible to set up tables
>basically any way you desire.

Will ebtables move a bit closer to iptables?

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Jan Engelhardt wrote:
> On Oct 12 2007 15:48, Patrick McHardy wrote:
> 
>>The netlink based iptables successor I'm currently working on allows to
>>dynamically create tables with user-specified priorities and "built-in"
>>chains. The only built-in tables will be those that need extra
>>processing (mangle/nat). So it should be possible to set up tables
>>basically any way you desire.
> 
> 
> Will ebtables move a bit closer to iptables?


I didn't get to that part yet, but yes, thats one of the goals.

Re: [RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

Patrick McHardy wrote:
> Jan Engelhardt wrote:
> > On Oct 12 2007 16:30, Al Boldi wrote:
> >>>>With the existence of the mangle table, how useful is the filter
> >>>> table?
> >>>
> >>>A similar discussion was back in March 2007.
> >>>http://marc.info/?l=netfilter-devel&m=117394977210823&w=2
> >>>http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
> >>>
> >>>in the end, my proposal was something like
> >>>http://jengelh.hopto.org/GFX0/nf_proposal2.svg
> >>
> >>Any chance you could publish this as something readable like text/html?
> >
> > Like, image/png?
> > http://jengelh.hopto.org/GFX0/nf_proposal2.png
>
> The netlink based iptables successor I'm currently working on allows to
> dynamically create tables with user-specified priorities and "built-in"
> chains. The only built-in tables will be those that need extra
> processing (mangle/nat). So it should be possible to set up tables
> basically any way you desire.

Wow!  How soon can we expect this to surface on mainline?


Thanks a lot!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Patrick McHardy]

Al Boldi wrote:
> Patrick McHardy wrote:
>   
>> The netlink based iptables successor I'm currently working on allows to
>> dynamically create tables with user-specified priorities and "built-in"
>> chains. The only built-in tables will be those that need extra
>> processing (mangle/nat). So it should be possible to set up tables
>> basically any way you desire.
>>     
>
> Wow!  How soon can we expect this to surface on mainline?

I can't tell at this point, there's still too much work to do
for a realistic estimate. I'll post patches to netfilter-devel
as soon as its good enough for some real testing.

[RFD] iptables: mangle table obsoletes filter table

[Al Boldi]

With the existence of the mangle table, how useful is the filter table?

Other than requiring the REJECT target to be ported to the mangle table, is
the filter table faster than the mangle table?

If not, then shouldn't the filter table be obsoleted to avoid confusion?


Thanks!

--
Al

Re: [RFD] iptables: mangle table obsoletes filter table

[Matthew Faulkner]

Hey all

I'm using netperf to perform TCP throughput tests via the localhost
interface. This is being done on a SMP machine. I'm forcing the
netperf server and client to run on the same core. However, for any
packet sizes below 523 the throughput is much lower compared to the
throughput when the packet sizes are greater than 524.

Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    MBytes  /s  % S      % S      us/KB   us/KB
 65536  65536    523    30.01        81.49   50.00    50.00    11.984  11.984
 65536  65536    524    30.01       460.61   49.99    49.99    2.120   2.120

The chances are i'm being stupid and there is an obvious reason for
this, but when i put  the server and client on different cores i don't
see this effect.

Any help explaining this will be greatly appreciated.