Ive been looking to put some better documentation together for what Lusca does for TPROXY4 (I'm guessing you're talking about that and not TPROXY2.)

I think so... It's whatever is now standard in the kernel without extra patches.

In any case, the process is somewhat like this:

* iptables/routing table setup - http://wiki.squid- cache.org/Features/Tproxy4

Ok, I was mostly there. I was missing one critical rule. I think I understand it better now, as that wiki article does a little bit of explaining as to why the rules.

* create listen socket * setsockopt to make it transparent * bind() to 0.0.0.0, relevant port that you've redirected traffic to * listen() as usual

Then, you accept() as usual, use getsockname() to determine the original destination. Then for the outbound socket:

Getsockname is returning back the source/client IP & port instead of the original destination. I will need that, but that's only half... I'm possibly just not passing the correct structure(?) Switching a couple of things around, instead it returns back the generic 0.0.0.0 address I bound as, which is not any better. It might not help that I am tested it from a slightly modified netcat instead of a more simple test and I am probably overlooking something simple. Perhaps next I'll try a more simple code test from scratch instead of patching netcat. At least now I am confident I have the rules in place so that can intercept a stream. I just have to be able to figure out where they were going... (and then the other half which should be easier, recreating them as you indicate...)

* create socket * setsockopt to make it transparent * bind() to relevant IP (and port, or leave it 0 to let the stack choose a port IIRC)

Should I be able to reuse the original source port, or will that fail/cause problems as it would already be in the connection table (except with local/foreign reversed)?

* connect() as usual

I haven't yet really looked into the TPROXY4 kernel implementation to know precisely what is going on. I can't find some clear, concise documentation either explaining the "how" or "why" behind the iptables rules and why packets need to be punted via the loopback interface.