ip_conntrack_tuple and marks

ip_conntrack_tuple and marks

[Carl-Daniel Hailfinger]

Hi,

is it possible to add a nfmark field to ip_conntrack_tuple
so that only packets with a certain mark set are matched to
a connection? I'm trying to filter/nat multiple independent
connections with same ip/proto/port tuples on both sides
and the only distinguishing property of the different
connections is their nfmark. Using NOTRACK doesn't help
because it can only exclude packets from tracking, not
match packets to different expectations.

At first sight, it seems possible to only change a few lines
of code (expectation comparison and setup), but I fear there
might be a lot more to consider.

Any pointers to docs/patches/etc. are appreciated.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: ip_conntrack_tuple and marks

[Pablo Neira Ayuso]

Carl-Daniel Hailfinger wrote:
> Hi,
> 
> is it possible to add a nfmark field to ip_conntrack_tuple
> so that only packets with a certain mark set are matched to
> a connection? I'm trying to filter/nat multiple independent
> connections with same ip/proto/port tuples on both sides
> and the only distinguishing property of the different
> connections is their nfmark. Using NOTRACK doesn't help
> because it can only exclude packets from tracking, not
> match packets to different expectations.

Could the connmark match/target be what you need?

-- 
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

Re: ip_conntrack_tuple and marks

[Carl-Daniel Hailfinger]

Pablo Neira Ayuso wrote:
> Carl-Daniel Hailfinger wrote:
>>
>> is it possible to add a nfmark field to ip_conntrack_tuple
>> so that only packets with a certain mark set are matched to
>> a connection? I'm trying to filter/nat multiple independent
>> connections with same ip/proto/port tuples on both sides
>> and the only distinguishing property of the different
>> connections is their nfmark. Using NOTRACK doesn't help
>> because it can only exclude packets from tracking, not
>> match packets to different expectations.
> 
> Could the connmark match/target be what you need?

Unfortunately, connmark does exactly the opposite of what
I'm trying to achieve.

connmark: get/set fwmark based on flow
my problem: handle different flows with identical
  srcip/dstip/sport/dport/proto tuples where the only
  difference is the packet fwmark

Example (what I hope to get working)
SYN packet from 10.0.0.1:1024->10.0.0.2:80 fwmark 1 creates
one connection.
SYN packet from 10.0.0.1:1024->10.0.0.2:80 fwmark 2 creates
another connection independent of the first. Current netfilter
code considers both packets to belong to the same connection.


Regards,
Carl-Daniel

Re: ip_conntrack_tuple and marks

[Martijn Lievaart]

Carl-Daniel Hailfinger wrote:

>Pablo Neira Ayuso wrote:
>  
>
>>Carl-Daniel Hailfinger wrote:
>>    
>>
>>>is it possible to add a nfmark field to ip_conntrack_tuple
>>>so that only packets with a certain mark set are matched to
>>>a connection? I'm trying to filter/nat multiple independent
>>>connections with same ip/proto/port tuples on both sides
>>>and the only distinguishing property of the different
>>>connections is their nfmark. Using NOTRACK doesn't help
>>>because it can only exclude packets from tracking, not
>>>match packets to different expectations.
>>>      
>>>
>>Could the connmark match/target be what you need?
>>    
>>
>
>Unfortunately, connmark does exactly the opposite of what
>I'm trying to achieve.
>
>connmark: get/set fwmark based on flow
>my problem: handle different flows with identical
>  srcip/dstip/sport/dport/proto tuples where the only
>  difference is the packet fwmark
>
>Example (what I hope to get working)
>SYN packet from 10.0.0.1:1024->10.0.0.2:80 fwmark 1 creates
>one connection.
>SYN packet from 10.0.0.1:1024->10.0.0.2:80 fwmark 2 creates
>another connection independent of the first. Current netfilter
>code considers both packets to belong to the same connection.
>
>  
>

Because they are the same connection! What on earth are you trying to 
achieve? What strange setup do you have where these packets do *not* 
belong to the same connection? Mind you, that's not only netfilter, the 
recieving box will also see these packets as belonging to the same 
connection.

HTH,
M4

Re: ip_conntrack_tuple and marks

[Carl-Daniel Hailfinger]

Martijn Lievaart wrote:
> Carl-Daniel Hailfinger wrote:
> 
>> Pablo Neira Ayuso wrote:
>>  
>>
>>> Carl-Daniel Hailfinger wrote:
>>>   
>>>> is it possible to add a nfmark field to ip_conntrack_tuple
>>>> so that only packets with a certain mark set are matched to
>>>> a connection? I'm trying to filter/nat multiple independent
>>>> connections with same ip/proto/port tuples on both sides
>>>> and the only distinguishing property of the different
>>>> connections is their nfmark. Using NOTRACK doesn't help
>>>> because it can only exclude packets from tracking, not
>>>> match packets to different expectations.
>>>>     
>>> Could the connmark match/target be what you need?
>>>   
>>
>> Unfortunately, connmark does exactly the opposite of what
>> I'm trying to achieve.
>>
>> connmark: get/set fwmark based on flow
>> my problem: handle different flows with identical
>>  srcip/dstip/sport/dport/proto tuples where the only
>>  difference is the packet fwmark
>>
>> Example (what I hope to get working)
>> SYN packet from 10.0.0.1:1024->10.0.0.2:80 fwmark 1 creates
>> one connection.
>> SYN packet from 10.0.0.1:1024->10.0.0.2:80 fwmark 2 creates
>> another connection independent of the first. Current netfilter
>> code considers both packets to belong to the same connection.
> 
> Because they are the same connection!

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.

/\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
\              /    |      |   \              /
 | 10.0.0.0/24 |---eth0  eth1---| 10.0.1.0/24 |
/              \    |      |   /              \
\/\/\/\/\/\/\/\/    +------+   \/\/\/\/\/\/\/\/


/\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
\              /    |      |   \              /
 | 10.0.0.0/24 |---eth2  eth3---| 10.0.1.0/24 |
/              \    |      |   /              \
\/\/\/\/\/\/\/\/    +------+   \/\/\/\/\/\/\/\/

> What on earth are you trying to achieve?

See above. The setup I have usually requires two machines. With
iproute2, it is possible to have eth[0123] in one machine.
Works perfectly and is already in service *as a router*. Loading
netfilter makes this setup very unreliable. I want to fix that.

> What strange setup do you have where these packets do
> *not* belong to the same connection?

You are right that the setup is very strange. Historical baggage :-(
Basically, years ago someone tried to be clever and created two
networks with identical configuration "to reduce management overhead".
I have to deal with the fallout now. Thankfully, the networks do
not have to interoperate yet. That will give me another headache.

> Mind you, that's not only netfilter, the
> recieving box will also see these packets as belonging to the same
> connection.

Since the networks are separate, the receiving boxes are also
separate and thus each of them will only see one of the packets
and only one connection.

Regards,
Carl-Daniel

Re: ip_conntrack_tuple and marks

[Martijn Lievaart]

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.

>/\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
>\              /    |      |   \              /
> | 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).

M4

[Proposal] ip_conntrack_tuple extension for advanced matching

[Carl-Daniel Hailfinger]

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?

Regards,
Carl-Daniel

Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Pablo Neira Ayuso]

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

Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Carl-Daniel Hailfinger wrote:
> 
>>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.

Me neither, the network setup is obviously broken. Its also a bit harder
than just extending the conntrack keys, you need also need to take care
of NAT unique tuple generation, expectations and ICMP error tracking.
That still leaves a few corner cases, but nothing terribly important.

Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Martijn Lievaart]

<citaat van="Patrick McHardy">
> Pablo Neira Ayuso wrote:
>> Carl-Daniel Hailfinger wrote:
>>
>>>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.
>
> Me neither, the network setup is obviously broken. Its also a bit harder
> than just extending the conntrack keys, you need also need to take care
> of NAT unique tuple generation, expectations and ICMP error tracking.
> That still leaves a few corner cases, but nothing terribly important.

This would be possible with multiple network stacks (aka virtual routers),
something I've been thinking about but is way beyond my capabilities.

It would be pretty cool to have multiple stacks, f.i. one for management
while the other does the firewalling.

M4

Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Carl-Daniel Hailfinger]

Martijn Lievaart wrote:
> <citaat van="Patrick McHardy">
>> Pablo Neira Ayuso wrote:
>>> Carl-Daniel Hailfinger wrote:
>>>
>>>> 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.
>> Me neither, the network setup is obviously broken. Its also a bit harder
>> than just extending the conntrack keys, you need also need to take care
>> of NAT unique tuple generation, expectations and ICMP error tracking.
>> That still leaves a few corner cases, but nothing terribly important.
> 
> This would be possible with multiple network stacks (aka virtual routers),
> something I've been thinking about but is way beyond my capabilities.

IIRC that has already been implemented by Extreme Networks in their
Linux-based routers. The only problem is that I can't find any source
code from them. Will inquire further.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Patrick McHardy]

Carl-Daniel Hailfinger wrote:
> Martijn Lievaart wrote:
> 
>><citaat van="Patrick McHardy">
>>
>>>Pablo Neira Ayuso wrote:
>>>
>>>>Carl-Daniel Hailfinger wrote:
>>>>
>>>>
>>>>>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.
>>>
>>>Me neither, the network setup is obviously broken. Its also a bit harder
>>>than just extending the conntrack keys, you need also need to take care
>>>of NAT unique tuple generation, expectations and ICMP error tracking.
>>>That still leaves a few corner cases, but nothing terribly important.
>>
>>This would be possible with multiple network stacks (aka virtual routers),
>>something I've been thinking about but is way beyond my capabilities.
> 
> 
> IIRC that has already been implemented by Extreme Networks in their
> Linux-based routers. The only problem is that I can't find any source
> code from them. Will inquire further.

OpenVZ might help. I think it virtualizes the conntrack table etc., so
you could use one virtual instance for each interface and NETMAP them
to seperate networks.

Re: [Proposal] ip_conntrack_tuple extension for advanced matching

[Carl-Daniel Hailfinger]

Patrick McHardy wrote:
> Carl-Daniel Hailfinger wrote:
>> Martijn Lievaart wrote:
>>
>>> <citaat van="Patrick McHardy">
>>>
>>>> Pablo Neira Ayuso wrote:
>>>>
>>>>> Carl-Daniel Hailfinger wrote:
>>>>>
>>>>>
>>>>>> 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.
>>>> Me neither, the network setup is obviously broken. Its also a bit harder
>>>> than just extending the conntrack keys, you need also need to take care
>>>> of NAT unique tuple generation, expectations and ICMP error tracking.
>>>> That still leaves a few corner cases, but nothing terribly important.
>>> This would be possible with multiple network stacks (aka virtual routers),
>>> something I've been thinking about but is way beyond my capabilities.
>>
>> IIRC that has already been implemented by Extreme Networks in their
>> Linux-based routers. The only problem is that I can't find any source
>> code from them. Will inquire further.
> 
> OpenVZ might help. I think it virtualizes the conntrack table etc., so
> you could use one virtual instance for each interface and NETMAP them
> to seperate networks.

Thanks! I'll look at that code.


Regards,
Carl-Daniel

Re: ip_conntrack_tuple and marks

[Eric Leblond]

Hi,

Le lundi 25 septembre 2006 à 20:42 +0200, Martijn Lievaart a écrit :
> 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.

It is more an on iproute problem.
You could do that by using two dedicated routing tables and by setting
carefully routing table :
 ip rule dev eth1 lookup table eth0eth1
 ip rule dev eth0 lookup table eth0eth1
 ip rule dev eth2 lookup table eth2eth3
 ip rule dev eth3 lookup table eth2eth3

In eth0eth1 table :
ip route add 10.0.1.0/24 iif eth1
ip route add 10.0.0.0/24 iif eth0

Almost same thing for eth2eth2.

Note: syntax given of ip route and ip rule is approximative.

BR,

> >  
> >
> 
> OK, it's clear to me now. I don't think you can achieve that with 
> current netfilter connection tracking.
> 
> >/\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
> >\              /    |      |   \              /
> > | 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).
> 
> M4
> 
> 

Re: ip_conntrack_tuple and marks

[Carl-Daniel Hailfinger]

Eric Leblond wrote:
> Hi,
> 
> Le lundi 25 septembre 2006 à 20:42 +0200, Martijn Lievaart a écrit :
>> 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.
> 
> It is more an on iproute problem.
> You could do that by using two dedicated routing tables and by setting
> carefully routing table :
> [...]

Yes, routing has been running here for a while and works perfectly
(with a similar iproute2 setup as you suggested).
Only connection tracking is giving me problems.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: ip_conntrack_tuple and marks

[Eric Leblond]

Humm,

Sorry, I miss a part of the thread... forget about my previous message.

In the setup you describe and in almost all cases. The differences is in
the interfaces.
 
Could it be a a way to differentiate the connection tracking entries ?

BR,

Le lundi 25 septembre 2006 à 23:56 +0200, Eric Leblond a écrit :
> Hi,
> 
> Le lundi 25 septembre 2006 à 20:42 +0200, Martijn Lievaart a écrit :
> > 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.
> 
> It is more an on iproute problem.
> You could do that by using two dedicated routing tables and by setting
> carefully routing table :
>  ip rule dev eth1 lookup table eth0eth1
>  ip rule dev eth0 lookup table eth0eth1
>  ip rule dev eth2 lookup table eth2eth3
>  ip rule dev eth3 lookup table eth2eth3
> 
> In eth0eth1 table :
> ip route add 10.0.1.0/24 iif eth1
> ip route add 10.0.0.0/24 iif eth0
> 
> Almost same thing for eth2eth2.
> 
> Note: syntax given of ip route and ip rule is approximative.
> 
> BR,
> 
> > >  
> > >
> > 
> > OK, it's clear to me now. I don't think you can achieve that with 
> > current netfilter connection tracking.
> > 
> > >/\/\/\/\/\/\/\/\    +------+   /\/\/\/\/\/\/\/\
> > >\              /    |      |   \              /
> > > | 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).
> > 
> > M4
> > 
> > 
> 
> 

Re: ip_conntrack_tuple and marks

[Carl-Daniel Hailfinger]

Eric Leblond wrote:
> 
> In the setup you describe and in almost all cases. The differences is in
> the interfaces.
>  
> Could it be a a way to differentiate the connection tracking entries ?

I first hoped so. Then I thought about expectation setup and how messy
it would get to guess the incoming interface for a packet in the opposite
direction. And it would also break some cases of load balancing where
packets may leave and/or enter through multiple interfaces. That's where
I gave up on the idea to base this on incoming interface.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/