[tproxy] Fwd: Re: TProxy with UDP

Maximilian Frank mail at frank-maximilian.at
Tue Jun 27 12:08:03 UTC 2017


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!


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 at frank-maximilian.at <mailto:mail at 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
>     <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 at lists.balabit.hu <mailto:tproxy at lists.balabit.hu>
>     https://lists.balabit.hu/mailman/listinfo/tproxy
>     <https://lists.balabit.hu/mailman/listinfo/tproxy>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/tproxy/attachments/20170627/dd674e4e/attachment.html>

More information about the tproxy mailing list