Hi, 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 On 27/06/17 11:49, Scheidler, Balázs wrote:
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 <mailto: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/comm... <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 <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 <mailto:tproxy@lists.balabit.hu> https://lists.balabit.hu/mailman/listinfo/tproxy <https://lists.balabit.hu/mailman/listinfo/tproxy>