Re: more questions about kernel config options for iptables

[Joel Newkirk <netfilter@newkirk.us>]

On Monday 07 April 2003 05:18 pm, Robert P. J. Day wrote:
>   having poked around even more in the options, i must say
> i'm a little puzzled.  mostly, i'm interested in understanding
> what some of these options do all by themselves, so forgive me
> if i end up repeating myself.
>
>   first, the basic Connection tracking option claims to be
> necessary for masq/NAT.  what value is that option if it is
> the only one selected?  it may be *necesasry* for masq/NAT,
> but it certainly doesn't seem to be *sufficient*.  what is
> the value of selecting that single option to the exclusion
> of all others.  what does it allow you to do?

Conntrack is what supports stateful filtering - without it you won't have 
the "--state" match, and can only filter explicitly on IPs, port 
numbers, etc.

>   next, notice that "IP tables support" also claims to be
> necessary for masq/NAT.  if that's the case, it would seem
> that these two options should somehow be interdependent.

Well, if you're going to use MASQUERADE then you need iptables support, 
even if you're not going to use iptables for any filtering.

>   another way of looking at it might be, why would anyone
> select "Connection tracking in the first place"?  might it
> not be more reasonable to have the user select the
> *functionality* they want, and have something like
> that basic connection tracking option as an invislble
> dependency?

For some users, perhaps, but Linux has grown up in (or has gathered, 
depends on your perspective) a community of people who want to know what 
is going on, and have fine-grain control over it at will.  Perhaps some 
day there will be a "make easyconfig" option that will set whole banks 
of appropriate settings based on high-level spoon-fed questions 
targeting a completely non-technical user.  But ATM I'm not aware of any 
'real' kernel config working this way, as kernel building is still 
targetted largely at the knowledgeable linux-savvy user/admin.

>   to that end, it would make more sense to have a restructured
> menu with more obvious options like
>
>   Basic filtering
>   Simple NAT
>   Masquerading
>
> and so on.  the actual object files associated with these
> *functions* are of no interest to the user.  he/she cares
> only about what can be done afterwards.
>
>   here's another question.  notice the options under
> "Connection tracking".  first, i'm aware that because of
> the way FTP works, you need some connection tracking ability
> to filter it properly.  so this is just straight FTP
> filtering.

Actually you can filter it (presuming you mean 'allow it to pass') 
without conntrack, but your resulting firewall is not nearly as tight as 
it would otherwise be...

>   note, however, that the next three options -- IRC,
> TFTP and Amanda -- refer to using those protocols
> in conjunction with NAT or masquerading.  if this is
> the case, i can see having FTP in one submenu associated
> with filtering, with the others in a submenu associated
> with NAT/masq.  it just seems to make more sense that way.

Actually all four (and others) are conntrack and nat helpers that are 
needed both for stateful filtering AND nat, AFAIK.

>   anyway, comments?

Not to be a smartass, but if you're unsatisfied with the options or their 
groupings, you can always contribute to the kernel effort... :^) 
{kernelsourcetreeroot}/net/ipv4/netfilter/Config.in  is the file that 
controls the construction of the netfilter/iptables-related options 
during make xconfig/menuconfig etc.

> rday

j