thanks for the quick reply! Ok then i guess i will have to do it this way. The race condition should not be that much of a problem in my case as i run single threaded and pass all packets from main proxy port to the new tproxy port anyway. So i guess the only thing that could happen is that i check the origdst for multiple packets and after the first packed i only forward to my application logic and do not setup a new socket.

The only real problem i might have is how to decide when to close the remote tproxy socket, but thats a application logic problem so i'll figure something out.

Thanks for the help!

regards,

Maximilian Frank

Hi,

udp_accept() was not accepted at that point, and I stopped pushing it. right now the best option is to fetch the first packet, find our the original sender and create a new socket with the matching local/remote endpoints, which would receive further traffic.

there's a race between the reception of the first packet and the creation of the socket though.

--
Bazsi

On Mon, Jun 26, 2017 at 5:54 PM, Maximilian Frank <mail@frank-maximilian.at> wrote:

Hi List,

not sure if I am in the right place as tproxy is part of the kernel now, but i am gonna as here anyway.

I am currently building a python based transparent TCP + UDP proxy. The setup for the proxy would be a basic mitm i.e.

Local Net --> Tproxy Box --> Internet

For TCP i can simply use getsockopt(SO_ORIGINAL_DST) to get original destination address and port. This works for tproxy and normal redirects. With UDP of course i cant do that. At the moment i am using IP_RECVORIGDST to get the original udp destination and port. This works fine apart from the fact that there seems to be a bug in recent kernels disabling this sockopt. (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=d36a1cb1e3285ba7eb1bcff5b231b4786deefc5b)

While researching tproxy i found this mail (https://lists.balabit.hu/pipermail/tproxy/2008-November/000996.html) in the thread archive. My question now is this udp accept part of the kernel version of tproxy or is there a patch for it out there for newer kernels. I ask because i feel this approach is a lot cleaner than me manually creating a new tproxy enabled socket.  So any info/help is much appreciated.

with kind regards,

Maximilian Frank

_______________________________________________
tproxy mailing list
tproxy@lists.balabit.hu
https://lists.balabit.hu/mailman/listinfo/tproxy