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(a)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/com…
> <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/com…>)
>
>
> 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(a)lists.balabit.hu <mailto:tproxy@lists.balabit.hu>
> https://lists.balabit.hu/mailman/listinfo/tproxy
> <https://lists.balabit.hu/mailman/listinfo/tproxy>
>
>
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/com…)
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