nfmark unusable with netfilter/iptables?

[Paul Rusty Russell]

In message <199910060501.BAA17864@opium.mbsi.ca> you write:
> 1) completely decoupling conntrack/NAT internal info from user-defined
> nfmarks; i.e. conntrack/NAT gets a new field of its own in struct sk_buff

This is always the problem.

"I want to use the mark field for XXX, and you're already using it.
You should have a permenant field in the skb."

Why not skip the middle man, and eliminate the mark field altogether?
Everyone can hardcode into the skb.

> 2) possibly eliminating nfreason. the user can freely decide on the
> number, and semantics of nfmark values.

Back to where we were in 2.2, with the qos, routing, and
portforwarding code all fighting for the mark field.  The nf_reason
field doesn't make it fairer, it just makes it defined.

> 3) adding a new PREROUTING chain in iptables to allow setting of nfmark/
> tos values before routing (that unfortunately breaks the "a packet
> traverses only a single chain" concept, but is there a better
> approach?). The PREROUTING chain could also possibly be useful for other
> purposes, such as for selective NAT (see below). 

iptables is packet filtering.  This is why it is where it is.  By
putting a PRE_ROUTING hook (an easy solution, I admit), you're
kludging it into packet mangling.  The lack of separation of these two
lead to many misconfigured boxes, much code complication, and general
hell for users.

The solution is to have field-allocation in the skb, where a module
can say `I need this much space in the skb' and get it
zero-initialized.  The `cb' space already offers this (not the
zero-filled bit), except it is uncontrolled.

> Also, since interface matching is about to be re-implemented in
> ipnatctl, I would propose that nfmark be added as a rule selection
> criteria too. This would also be a very powerful extension. (which I
> needed and had to hardcode in ip_nat_standalone.c:init_conntrack() in a
> relatively complex multi-homed firewall setup).

This is using nfmark in its original sense, but (despite being the
person who put fwmark in in the first place in 2.1) we need a generic
mechanism which can be used by more than one player at once.

Rusty.
--
Hacking time.