Hey everyone, I wrote this tool because I wanted to be able to access ports running on peers in my WireGuard network from any computer/server; without having to install WireGuard locally and without having root access (no iptables configs).
So as long as you have a private key & peer IP dedicated for your roaming needs, you'll be able to forward a local port to a port on a secured peer.
This can be useful for a few other use-cases, like exposing services to the Internet from a separate server that doesn't have root access (like a non-privileged container).
I've also gotten feedback to enable reverse-tunneling (making a port accessible on a peer that forwards to a port running locally), which enables a few more use-cases. I'm looking for any more ideas or feedback that would fit in this tool!
I've described how the internals work in the README. It's still a proof-of-concept right now but I listed my little roadmap in the issues: reverse-tunneling, UDP support, multi-port-forwarding, etc. Happy to answer any questions.
A note: wireguard-go (the official userspace impl in golang) can do this since several months back. It uses gVisor's netstack as a tcp/udp provider to forward connections to its peer (compared to whitequark's smoltcp in case of onetun).
Can I just put another word in for how bananas this is? WireGuard and Netstack allows you to run an entire TCP/IP stack in your userland program with no cooperation from your kernel. You can an interface to write raw packets (as an unprivileged user) and the whole TCP, integrated into the standard Go networking code. It is very, very cool to play with.
This reminds me a lot of lwIP[0] and uIP[1]. I did some projects 15 years ago with lwIP where we were able to work around a very lossy wireless network link when controlling PTZ cameras by building what was essentially a proxy with lwIP that allowed us to do some hack-ish things like transmitting 2 copies of all TCP packets immediately to increase resiliency. As I recall it exposed the BSD socket API so it was shockingly easy to relink a project to use lwIP instead of the host OS. All that was needed then on the other end was hooking up lwIP to a raw network interface.
Yeah! In Orchid, we have a similar setup to these, letting me layer lwIP on top of Wireguard, OpenVPN, or our WebRTC-based VPN protocol, even in multi-hop configurations.
Hi Saurik: Since LwIP only provides handlers for TCP and UDP, doesn't that reduce Orchid's VPN to a TCP/UDP proxy? For ex, can Orchid handle (or intends to handle) SCTP, say?
Or, is LwIP more capable than what I it give credit for?
(by the way, thank you for building orchid in the open! looking forward to the eventual team-up between orchid and helium :)
The name cries out for an icon derived from a 'won ton' (americans usually pronounce it wahn tawn but the canto pronunciation is exactly like 'one tun').
- SSH doesn't support tunneling UDP out of the box (you need to either wrap UDP with TCP, or use SSH's -w option for creating a TUN interface, which requires root access).
WireGuard being a very simple UDP protocol has its advantages for things like this. The downside is you can't use onetun with the same private-key/assigned IP on multiple devices, since WG only supports 1 UDP endpoint per peer at a time.
Note: my tool doesn't support UDP in it's current state, but there's no technical reason it shouldn't be feasible (unlike SSH). I have a draft PR for it right now.
So as long as you have a private key & peer IP dedicated for your roaming needs, you'll be able to forward a local port to a port on a secured peer.
This can be useful for a few other use-cases, like exposing services to the Internet from a separate server that doesn't have root access (like a non-privileged container).
I've also gotten feedback to enable reverse-tunneling (making a port accessible on a peer that forwards to a port running locally), which enables a few more use-cases. I'm looking for any more ideas or feedback that would fit in this tool!
I've described how the internals work in the README. It's still a proof-of-concept right now but I listed my little roadmap in the issues: reverse-tunneling, UDP support, multi-port-forwarding, etc. Happy to answer any questions.