-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Use pion/ice for STUN/TURN NAT-traversal #189
Comments
This would be really amazing to see for cross-compatibility across wireguard clients. If the control servers have simple API surfaces and they exchange peer candidates similarly, it wouldn't be hard to imagine one client supporting more than just one control server. |
Hi @colemickens, I started to work on an independent project which implements this: cunicu (formerly WICE). cunicu runs as a zero-configuration userspace daemon alongside the Wireguard kernel (or userspace) driver. cunicu detects available Wireguard interfaces and changes in their peer configs and searches for valid endpoint addresses via the usual ICE procedure. This means that cunicu can also be easily used without kilo in any other Wireguard setups. cunicu also tries to stay out of datapath by using either NF/IPtables, or BPF to alter source/destination addresses and ports of the Wireguard UDP packets. cunicu has pluggable backends. Which we use for exchanging signalling information (like SIP in VOIP). Once a first release is ready, I am planning to submit a PR to kilo which adds cunicu as a new daemonset to the Kubernetes resources. Ideally this does not require any other change in the Kilo code. |
Hi @stv0g this sounds like an amazing project and in particular like something that would be really valuable for the Kilo ecosystem. Like you know, ever since closing #109, Kilo supports discovering WireGuard endpoints and as a result traversing certain NAT cones/configurations, but any additional capabilities in discovery and traversal would be extremely helpful. What would you all think about holding a community video call to talk about Kilo and WICE and discuss future roadmap for the project? Take care! |
Hi @squat, I am working on cunicu as part of my job as a researcher. Thats why there is a funding acknowledgement in the readme. In the last days, progress on cunicu has slowed down a bit because I've been struggeling a bit to properly the code.
I already had the same idea. :) In principle you could go even a step further. In the current state cunicu only focuses on endpoint discovery. |
@stv0g I'm looking forward to use kilo in environments where I don't have the ability to have public IP. I do not have Wireguard-specific knowledge as much as you folks do but I've been coding in Go for the last couple of years. So, I can contribute to help you out finish the design objectives if you can give me some pointers 🙂 |
Hi @muvaf, Sure, I've got a bit stuck over the last weeks with other projects. But I plan to pick up the work pretty soon. Most of the code is now written but lacks proper testing and validation. I could need some help with testing here. Any feedback is highly appreciated. Currently, I plan to support three backends to exchange peer information:
My testing has mostly been done with the HTTP backend. However, this one is still using a simple REST API. Help here is also highly appreciated :) |
@stv0g My high level goal is to be able to create a Kubernetes cluster that any node in the public network can join, something like tailscale with proper CNI. And |
Hi @muvaf, My current plan is to make cunicu and Kilo interoperable. Meaning that Kilo will handle peer discovery and cunicu will handle the endpoint discovery. But adding Peer discovery also to WICE is a future goal. But its still far away. And I do not plan on replacing Kilo with cunicu. |
@stv0g Yes, that's exactly what I'm interested. So, any pointers that I can start with to start contributing to make that happen would be appreciated. |
Hey @stv0g any update on cunicu? How can we get Kilo to interoperate with it and enable better automatic discovery? ❤️ |
Hi @squat, yes work on cunicu is progressing constantly but slowly, as I am doing this in my spare time. cunicu has gained several other features similar to kilo as well:
However, the current code is still to experimental and unstable for giving it a first try. |
Hi @squat,
today I stumbled upon the wiretrustee project which enhances wireguard with some nice NAT-traversal techniques. Its largely based on the pion/ice package to handle endpoint discovery via STUN and even UDP proxying via TURN servers. Its bascially the same stack which is used by their WebRTC implementation. In case of a TURN connection a small proxy forwards packets from ICE to a local socket which gets used by the wirguard kernel module.
wiretrustee adds a signalling server which uses encrypted protobuf packages to exchange candidates.
All in all, I think their solution is the proper way of adding ICE NAT-traversal techniques to wiregard.
I am now considering using their design decisions to implement the same for kilo but replacing their signalling server with the K8S API server.
What do you think about it?
The text was updated successfully, but these errors were encountered: