Support TPROXY for TCP connections

[omribahumi]

Did you consider having TPROXY support for TCP connections?
This makes sense in environments that have conntrack disabled for performance reasons. You can't have NAT (and hence -j REDIRECT) without conntrack.
The TPROXY target works without nat and conntrack.

I've explored the code a bit and seen the commit that added the UDP implementation of TPROXY, it's seems pretty big.
If I'm reading the code right and not missing anything, wouldn't a getdestaddr_ip_transparent make more sense here, to cover both TCP and UDP use cases?

I'm assuming that someone who has the knowledge to implement UDP with TPROXY, can migrate his TCP to use TPROXY as well. Of course backwards compatibility (or incompatibility) has to also be considered here.

[darkk]

for performance reasons

Running local TCP/IP stack (accepting connection, managing data buffers & retransmissions in the kernel — current redsocks implementation has all this overhead) is usually way more expensive than conntrack. Also, if you pick only subset of packets to pass to local redsocks daemon, then you can apply NOTRACK as well. Am I missing something?

Adding support for TPROXY for TCP is technically possible, but it will unlikely solve performance issues, if you observe any.

IMHO, the way to get significant performance boost is to do "handshake" with the proxy at packet level and route further packets as-is, but it still requires some tracking to distinguish "handshake" packets from "data" packets.

[semigodking]

You can copy imp. for tproxy from this commit: semigodking@151f09c

[omribahumi]

Didn't know about NOTRACK. This makes sense.

Thanks. I'm closing this for now.