REOUTE target extenstion

REOUTE target extenstion

[Eddi Linder]

Hey,

I am planning to write a "redirection" extension that based on a match
will copy the matched packet to other interfaces.
The extension should work both on input chains and output chains
(ingress and egress traffic), and will be able to copy the packet as
egress or ingress of the selected interface.
I currently have a basic working POC, but I have some concerns.

1. When dealing with egress traffic (OUTPUT/POSTROUTING), the packet
is lacking the Ethernet layer headers. So, as I see it, I can either
fetch those fields by myself which is inefficient, or somehow change
only the output device we are dealing with and call the function
following the NF_HOOK. The latter option requires me to pass the okfn
pointer somehow into the target handling code.
2. An skb received on a bridge needs to be stripped from its nf_bridge
fields, can it cause any problems after the redirect?
3. I'd like to support multiple redirects per-match, currently I use
skb_clone before each redirect (otherwise, the original skb is being
freed), is that the best way to do it?

The current api I'm looking into is: "iptables -A INPUT -i eth2 -j
REROUTE --actions input:eth0,output:veth0,continue".
Upon packet received on eth2 it will redirect the packet into eth0 rx
queue, veth1 tx queue, and will continue the packet handling on eth2
(return XT_CONTINUE).

Any suggestions or comments will be appreciated.
Thanks,
Eddie

Re: REOUTE target extenstion

[Jan Engelhardt]

On Wednesday 2015-05-27 12:11, Eddi Linder wrote:

>Hey,
>
>I am planning to write a "redirection" extension that based on a match
>will copy the matched packet to other interfaces.
>Any suggestions or comments will be appreciated.

We already have the TEE target that does exactly that.

Re: REOUTE target extenstion

[Florian Westphal]

Eddi Linder <eddi@guardicore.com> wrote:
> Hey,
> 
> I am planning to write a "redirection" extension that based on a match
> will copy the matched packet to other interfaces.
> The extension should work both on input chains and output chains
> (ingress and egress traffic), and will be able to copy the packet as
> egress or ingress of the selected interface.

Whats wrong with TEE target?

We also have mirred action in tc to do packet mirroring and redirects.

Re: REOUTE target extenstion

[Eddi Linder]

TEE is for gateway redirections, which means the redirected device has
to have a configured ip, and to be reachable from the original device.
Florian, I didn't find the mirror target in the mainline documentation or code.
REROUTE redirection is more like the openvswitch output action, copy
the packet from one device into another.



On Wed, May 27, 2015 at 2:37 PM, Florian Westphal <fw@strlen.de> wrote:
> Eddi Linder <eddi@guardicore.com> wrote:
>> Hey,
>>
>> I am planning to write a "redirection" extension that based on a match
>> will copy the matched packet to other interfaces.
>> The extension should work both on input chains and output chains
>> (ingress and egress traffic), and will be able to copy the packet as
>> egress or ingress of the selected interface.
>
> Whats wrong with TEE target?
>
> We also have mirred action in tc to do packet mirroring and redirects.

Re: REOUTE target extenstion

[Florian Westphal]

Eddi Linder <eddi@guardicore.com> wrote:
> TEE is for gateway redirections, which means the redirected device has
> to have a configured ip, and to be reachable from the original device.

That makes no sense to me.  The to-redirected device always needs to be
reachable.  And iptables is L3 and upwards, so I don't see how 1:1
copying would fit in here.

> Florian, I didn't find the mirror target in the mainline documentation or code.

I meant the tc action:

tc filter add dev eth0 parent $parent protocol ip [..] action mirred egress redirect dev eth1

> REROUTE redirection is more like the openvswitch output action, copy
> the packet from one device into another.

Sorry, but my feeling is that this is out of scope for iptables.

Re: REOUTE target extenstion

[Pablo Neira Ayuso]

On Wed, May 27, 2015 at 02:11:30PM +0200, Florian Westphal wrote:
> Eddi Linder <eddi@guardicore.com> wrote:
> > TEE is for gateway redirections, which means the redirected device has
> > to have a configured ip, and to be reachable from the original device.
> 
> That makes no sense to me.  The to-redirected device always needs to be
> reachable.  And iptables is L3 and upwards, so I don't see how 1:1
> copying would fit in here.
> 
> > Florian, I didn't find the mirror target in the mainline documentation or code.
> 
> I meant the tc action:
> 
> tc filter add dev eth0 parent $parent protocol ip [..] action mirred egress redirect dev eth1
> 
> > REROUTE redirection is more like the openvswitch output action, copy
> > the packet from one device into another.
> 
> Sorry, but my feeling is that this is out of scope for iptables.

Agreed.

There is an incomplete patch to add TEE support to nf_tables bridge
family. You only have to specify the destination device as Eddi needs.

Another alternative is to add this TEE support to ebtables, which is
where this belongs.

Re: REOUTE target extenstion

[Eddi Linder]

The matching will be L3 based, but the copy can be of all the packet,
I'd like to simply change the dest device of it.
I can match by source device, I don't see why it's not logical to
target a device as an action.
And turning to "tc" is a nice alternative, and many things that can be
done in *tables can be done in "tc", but I'd like to stay focused on
netfilters as it is more flexible with the stage I insert my rules in
the packet's flow.

Pablo, in this case I need it to work not only on bridged devices, so
ebtables is not a solution for me.

On Wed, May 27, 2015 at 3:40 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Wed, May 27, 2015 at 02:11:30PM +0200, Florian Westphal wrote:
>> Eddi Linder <eddi@guardicore.com> wrote:
>> > TEE is for gateway redirections, which means the redirected device has
>> > to have a configured ip, and to be reachable from the original device.
>>
>> That makes no sense to me.  The to-redirected device always needs to be
>> reachable.  And iptables is L3 and upwards, so I don't see how 1:1
>> copying would fit in here.
>>
>> > Florian, I didn't find the mirror target in the mainline documentation or code.
>>
>> I meant the tc action:
>>
>> tc filter add dev eth0 parent $parent protocol ip [..] action mirred egress redirect dev eth1
>>
>> > REROUTE redirection is more like the openvswitch output action, copy
>> > the packet from one device into another.
>>
>> Sorry, but my feeling is that this is out of scope for iptables.
>
> Agreed.
>
> There is an incomplete patch to add TEE support to nf_tables bridge
> family. You only have to specify the destination device as Eddi needs.
>
> Another alternative is to add this TEE support to ebtables, which is
> where this belongs.

Re: REOUTE target extenstion

[Jan Engelhardt]

On Friday 2015-05-29 14:02, Eddi Linder wrote:

>The matching will be L3 based, but the copy can be of all the packet,
>I'd like to simply change the dest device of it.
>I can match by source device, I don't see why it's not logical to
>target a device as an action.

(Given "sending to a device" comes up again from time to time, let me provide
this linkable reasoning.)

An analogy to sending to a device is commanding a ship to harbor exit #34.

And then? Is it supposed to moor, or sink itself?


A destination is required. _Any_ will do, in whatever way it is derived, but
one is needed. One could for example (re)use the Ethernet address, in case of
copying from and to Ethernet. Or let one be neighbor-discovered by specifying
the L3 address with TEE's --gw. Or other magic, depending on what the link
type's needs are, and what your packet already provides in terms of fields
(which may be fewer or more in case of tunnels and such).
A destination is required, a device is only a waypoint.

Re: REOUTE target extenstion

[Eddi Linder]

I don't see how TEE will help me (in it's current state), I'd like to
redirect ingress packets to a device without an IP address (for IDS).
More specifically, I have a machine with a lot of interfaces
(Openstack hypervisor), each connected to a bridge.
I'd like to match the traffic on each interface using Iptables and to
mirror some of it into my own interface that is connected to an ovs.
There is no direct connection between the my interface and the others.
The reason I'd like to use Iptables is to do all the matches and the
redirects as fast as possible, instead of doing it in user space.

On Fri, May 29, 2015 at 3:50 PM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Friday 2015-05-29 14:02, Eddi Linder wrote:
>
>>The matching will be L3 based, but the copy can be of all the packet,
>>I'd like to simply change the dest device of it.
>>I can match by source device, I don't see why it's not logical to
>>target a device as an action.
>
> (Given "sending to a device" comes up again from time to time, let me provide
> this linkable reasoning.)
>
> An analogy to sending to a device is commanding a ship to harbor exit #34.
>
> And then? Is it supposed to moor, or sink itself?
>
>
> A destination is required. _Any_ will do, in whatever way it is derived, but
> one is needed. One could for example (re)use the Ethernet address, in case of
> copying from and to Ethernet. Or let one be neighbor-discovered by specifying
> the L3 address with TEE's --gw. Or other magic, depending on what the link
> type's needs are, and what your packet already provides in terms of fields
> (which may be fewer or more in case of tunnels and such).
> A destination is required, a device is only a waypoint.