nfqueue vs. tproxy

nfqueue vs. tproxy

[msk]

I've been reading up on tproxy and nfqueue.  Just to confirm my understanding
of the two:

Could one write a layer of code that uses the nfq_*() functions to basically
implement what tproxy can do by simply adjusting the destination information
and checksum, and then returning NF_REPEAT verdicts for each?

Thanks,
-MSK

Re: nfqueue vs. tproxy

[Susan Hinrichs]

You could do that, but the second recipient of the code would lose the
original destination address and port information.

This would be more like the REDIRECT target in iptables.

On Wed, 2011-12-07 at 16:25 -0800, msk@cloudmark.com wrote:
> I've been reading up on tproxy and nfqueue.  Just to confirm my understanding
> of the two:
> 
> Could one write a layer of code that uses the nfq_*() functions to basically
> implement what tproxy can do by simply adjusting the destination information
> and checksum, and then returning NF_REPEAT verdicts for each?
> 
> Thanks,
> -MSK
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nfqueue vs. tproxy

[Jan Engelhardt]

On Thursday 2011-12-08 02:43, Susan Hinrichs wrote:

>You could do that, but the second recipient of the code would lose the
>original destination address and port information.

Um, no.
The second recipient of the packet (code? no.) is either

(a) intentionally the same as the original destination, therefore the 
daddr-dport tuple is already known (obviously)

(b) intentionally not the same as the original destination, i.e. not 
meant to know the original daddr-dport tuple.

And if you need, you can add extra bytes into the stream to tell the new 
peer (in case of (b)) the original address within the stream, provided 
the protocol can carry that information. If the protocol does not allow 
for it, it is not going to be interesting for the recipient anyway.

Oh and don't top-post.

>On Wed, 2011-12-07 at 16:25 -0800, msk@cloudmark.com wrote:
>> I've been reading up on tproxy and nfqueue.  Just to confirm my understanding
>> of the two:
>> 
>> Could one write a layer of code that uses the nfq_*() functions to basically
>> implement what tproxy can do by simply adjusting the destination information
>> and checksum, and then returning NF_REPEAT verdicts for each?
>> 
>> Thanks,
>> -MSK

Re: nfqueue vs. tproxy

[Susan Hinrichs]

On Thu, 2011-12-08 at 05:21 +0100, Jan Engelhardt wrote:
> On Thursday 2011-12-08 02:43, Susan Hinrichs wrote:
> 
> >You could do that, but the second recipient of the code would lose the
> >original destination address and port information.
> 
> Um, no.
> The second recipient of the packet (code? no.) is either
> 
> (a) intentionally the same as the original destination, therefore the 
> daddr-dport tuple is already known (obviously)
> 
> (b) intentionally not the same as the original destination, i.e. not 
> meant to know the original daddr-dport tuple.
> 
> And if you need, you can add extra bytes into the stream to tell the new 
> peer (in case of (b)) the original address within the stream, provided 
> the protocol can carry that information. If the protocol does not allow 
> for it, it is not going to be interesting for the recipient anyway.
> 
> Oh and don't top-post.
> 
> >On Wed, 2011-12-07 at 16:25 -0800, msk@cloudmark.com wrote:
> >> I've been reading up on tproxy and nfqueue.  Just to confirm my understanding
> >> of the two:
> >> 
> >> Could one write a layer of code that uses the nfq_*() functions to basically
> >> implement what tproxy can do by simply adjusting the destination information
> >> and checksum, and then returning NF_REPEAT verdicts for each?
> >> 
> >> Thanks,
> >> -MSK

Thanks for the clarification.  I see now.  And sorry for the breach of
etiquette.

Re: nfqueue vs. tproxy

[Jan Engelhardt]

On Thursday 2011-12-08 01:25, msk@cloudmark.com wrote:

>I've been reading up on tproxy and nfqueue.  Just to confirm my understanding
>of the two:
>
>Could one write a layer of code that uses the nfq_*() functions to basically
>implement what tproxy can do by simply adjusting the destination information
>and checksum, and then returning NF_REPEAT verdicts for each?

That would be really cumbersome, because with nf_queue, you end up 
just having the bare packet. With tproxy, you get the full benefits of 
a socket and TCP handling.