Using goldy on both ends to create an end-to-end UDP tunnel about goldy

[dubek]

Currently I don't think this is possible. goldy listens to incoming traffic on its listen port (which can be :X or 0.0.0.0:X) and expects that traffic to be DTLS. Goldy cannot proxy traffic in front of a UDP client (that is, accepting plaintext UDP traffic and encrypting it when sending to a DTLS server).

A client mode would be an interesting addition to goldy - allowing it to become an end-to-end secure UDP tunnel (similar to stunnel for TCP traffic).

[jerel]

Yes, I think this would be a very useful feature as there is lots of UDP hardware out there that will never get updated to support DTLS. Unfortunately I don't feel like I have the C chops to add it myself.

I am a little confused about this diagram:

At the very bottom it shows unencrypted traffic coming from the backend and being forwarded as DTLS to the client. In my code when I send a UDP packet back I specify the remote IP and port that it needs to go to... how does goldy end up in the middle or if I send it to goldy instead then how does goldy know who to forward the packet to?

[dubek]

Usually when writing UDP servers you'd receive packets and get the sender's address/port (where the packet came from). When you want to send a reply, you send it to the exact same address. You can see an example for such code in our UDP test server ( https://github.com/ibm-security-innovation/goldy/blob/master/test/udp_test_server.c#L67 ) - when we call recvfrom we get the peer address, which is what we use later in sendto to send the server's response.

If the original UDP server ("backend" in the diagram) is written this way, it'll always receive packets from a local address and port (goldy's), and respond to that same peer, which will be received by goldy and then encrypted and send to the DTLS client.

I hope this clears things up.

[jerel]

That does clear things up, thanks!

[jerel]

@dubek would you be interested in implementing a client mode? I'm willing to put some $ toward the feature since it's out of my realm of contribution skills

[dubek]

I can't promise anything, and I can't accept money too. Sorry. I want to add the client mode, but not sure I can get to it in the next few weeks.

[fortitudepub]

I can across this fantastic project and realized I can use this project to break GF*W in China, so I wrote a client based on the original code, Hope this can help to answer this issue.

https://github.com/fortitudezhang/goldy-client

Note this project is still experimental, issues report are welcome.

[jerel]

@fortitudezhang so awesome, collaboration like this is why I love open source :)

I'm having a small difficulty with a test setup that uses goldy on one end and goldy-client on the other so I'll open an issue on the other repo for that shortly.

[dubek]

Thank you @fortitudezhang for that "fork" and improvements. @jerel - If I understand correctly from scanning the code, note that @fortitudezhang 's current goldy-client assumes only one concurrent connection from the UDP client to goldy-client; when a new connection is received on the listening port it "disconnects" the current active session and opens a new one. I assume this works OK for @fortitudezhang 's needs, but make sure it also fits your scenario.