Re: STATELESS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2003-09-16 at 09:57, Cedric Blancher wrote:
> Le mar 16/09/2003 à 17:50, Ramin Dousti a écrit :
> > > Can I ask you why do you want  to turn off the conntrack?
> > I don't. I just wanted to learn from the people who were saying "just don't
> > load the ip_conntrack..."
> 
> I assume that if someone wants to fallback on stateless filtering is for
> saving load on his box. I can miss something, but I really don't see
> another reason. Once ip_conntrack is loaded, all packets are tracked
> anyway, weither you use state match or not. Yes, one can write a whole
> stateless ruleset with conntrack running, but what's the point : the
> cost implied by a rule with state matching and one without is the same,
> as state flaging is done anyway !
> 
> That's why assuming that stateless is for save load implies ip_conntrack
> module removal. But, as it relies on conntrack, NAT is broken. It is as
> simple as this.
> 
> So, the remaining question is "why does OP wants to fallback to
> stateless filtering". If answer is "to save load", then he will have to
> remove ip_conntrack. If answer is... Well, I don't know, anything else,
> such as "I like writing weak ruleset for fun with powerful tools", then
> not using state matching will be sufficient.

hi,

I do believe that the 2.4 and 2.6 kernels contain an alternative NAT
mechanism associated with the Config variable: CONFIG_IP_ROUTE_NAT

This var is tied to CONFIG_NET_FASTROUTE and "Advanced Router" or
something similar. Internally the source code uses flags like RTCF_NAT
etc.

This mechanism is incomptabile with the whole netfilter infrastructure.
You MUST enable only ONE of the two mechanisms at any given time.
Moreover I have not used this mechanism and dont know if it works and
how well it works and what its limitations are.

-- 

Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
Ranjeet dot Shetye2 at Zultys dot com
http://www.zultys.com/
 
The views, opinions, and judgements expressed in this message are solely
those of the author. The message contents have not been reviewed or
approved by Zultys.




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux