Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Pablo Neira Ayuso <pablo@netfilter.org>]

Carl-Daniel Hailfinger wrote:
> Martijn Lievaart wrote:
>> Carl-Daniel Hailfinger wrote:
>>
>>> No, they are not. Let me explain:
>>> The box in question has two pairs of interfaces.
>>> eth0: 10.0.0.254/24   eth1: 10.0.1.254/24
>>> eth2: 10.0.0.254/24   eth3: 10.0.1.254/24
>>> I want to do routing and firewalling between eth0 and eth1. That's
>>> simple. However, I also want to do routing and filtering between
>>> eth2 and eth3. Although eth0 and eth2 have the same subnet, they
>>> are NOT the same network, they just happen to have identical
>>> configurations. Same goes for eth1 and eth3.
>> OK, it's clear to me now. I don't think you can achieve that with
>> current netfilter connection tracking.
> 
> Yes, that's why I wanted to change conntack to optionally consider
> a fwmark/whatever value for matching connections.
> 
> 
>>> /\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
>>> \              /    |      |   \              /
>>> | 10.0.0.0/24 |---eth0  eth1---| 10.0.1.0/24 |
>>> /              \    |      |   /              \
>>> \/\/\/\/\/\/\/\/    +------+   \/\/\/\/\/\/\/\/
>>>
>>>
>>> /\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
>>> \              /    |      |   \              /
>>> | 10.0.0.0/24 |---eth2  eth3---| 10.0.1.0/24 |
>>> /              \    |      |   /              \
>>> \/\/\/\/\/\/\/\/    +------+   \/\/\/\/\/\/\/\/
>> Why not do it exactly like that, but with two real boxes? Makes
>> interconnecting later also a nobrainer (NETMAP).
> 
> The setup is already running with one box. It's just the firewalling
> which has problems sometimes. I've even used NETMAP to make
> connections between the networks of eth0 and eth2 possible on the
> same machine.
> The problems only happen if two connections with the same conntrack
> tuple happen at the same time. A seldom occurence, I agree. But I
> had it happen (IIRC there were two identical pings running in the
> different network pairs). Now my goal is to make it perfect.
> 
> 
> New proposal:
> To handle interfaces in different networks with identical configuration,
> connection tracking may optionally consider an additional "realm/mark"
> value for matching connections. Such a value would be set for each
> packet in the RAW table and have a default value of 0. For existing
> setups, no change will happen. Both directions of a flow must have the
> same "realm/mark" value set on incoming packets. Expectations also will
> have the value set for any new expectation. Since reusing nfmark will
> break some setups, struct sk_buff probably has to be enlarged.
> 
> Would a patch for adding such a feature be accepted into mainline?

IHMO, your numering schema is not convenient. I would not accept such
patch since I can't see any other utility apart from supporting your
setting.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris