Hi, On Sun, Jul 05, 2009 at 03:16:47PM -0400, John Lauro wrote:

...

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

I have a very simplistic patch for netcat here: http://home.sch.bme.hu/~piglet/netfilter/tproxy/netcat-ip_transparent-suppor... May or may not work, since it was a long time ago I wrote that. In theory, getsockname() for the fd returned by accept() should be the original destination address, while getpeername() should return the client (source) address. For UDP, you should be able to get the original destination address via an ancillary message returned by recvmsg() (You can find the git commit introducing that feature here: http://tinyurl.com/n4yjlt)

...

* 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)?

Reusing the original port is usually a bad idea. A notable example of things breaking is Netfilter connection tracking, which gets confused if you reuse the exact same endpoints for a different connection. -- KOVACS Krisztian