Re: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
On Oct 20 2007 00:47, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
[EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. pgpqsKaExhIYs.pgp Description: PGP signature
Re: [RFD] iptables: mangle table obsoletes filter table
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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? pgp2kRiWNrSxQ.pgp Description: PGP signature
Re: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] 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.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +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 [EMAIL PROTECTED]
We have more to fear from the bungling of the incompetent than from
the machinations of the wicked. - from Slashdot
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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 [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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
[EMAIL PROTECTED] 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.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
Al Boldi wrote:
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] 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.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +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?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=2 in the end, my proposal was something like http://jengelh.hopto.org/GFX0/nf_proposal2.svg - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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-develm=117394977210823w=2 http://marc.info/?l=netfilter-develm=117400063907706w=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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFD] iptables: mangle table obsoletes filter table
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
Patrick McHardy wrote:
Please send mails discussing netfilter to netfilter-devel.
Ok. I just found out this changed to vger. But
[EMAIL PROTECTED] 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.c2007-10-12 08:25:17.0 +0300
+++ ipt_REJECT.c2007-10-12 08:31:44.0 +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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
