Feature suggestion: option to listen on remote server

[afontenot]

From the documentation:

onetun opens a TCP or UDP port on your local system, from which traffic is forwarded to a port on a peer in your WireGuard network. It requires no changes to your operating system's network interfaces: you don't need to have root access, or install any WireGuard tool on your local system for it to work.

The only prerequisite is to register a peer IP and public key on the remote WireGuard endpoint; those are necessary for the WireGuard endpoint to trust the onetun peer and for packets to be routed.

Maybe the documentation just leaves this out, but it's not obvious to me why onetun itself can't function as the remote WG endpoint. Couldn't it just listen on an unprivileged port and forward packets as requested to a destination port?

This might not be a common use case, but it seems like it might be nice to use onetun in cases where neither end of the connection has root.

[aramperes]

Hey! Thanks for the suggestion. This sounds the same as #6.

The first use-case I had for onetun was for an unprivileged client. Having an unprivileged server that listens for TCP handshakes from the tunnel is possible, just not implemented.

[afontenot]

Thanks for the response! I think this is close enough to the same issue that maybe it would have the same solution. I'm okay with closing this if that turns out to be the case.

I think the end goal is a little different though. Usually the goal of a reverse mode has to do with firewalls. E.g. there are ssh servers are both ends, A wants to open a shell on B, but B is behind a firewall that doesn't allow incoming connections. Solution: B connects to A in reverse mode.

I don't care about this feature at all. What I'm after is something that can act like a boring, vanilla Wireguard server on the remote end, just without root. I think onetun could do this without having to implement a control protocol to activate reverse tunneling.

Having an unprivileged server that listens for TCP handshakes from the tunnel is possible

If I understand correctly, this wouldn't involve TCP, it would just be UDP as before. This would not involve any changes to the Wireguard protocol. As I imagine it working, onetun would have two new CLI flags:

--listen 192.168.4.1:51820
--peer BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB:192.168.4.3/32

Or maybe just a --listen-conf if parsing the Wireguard config files is not too hard.

[aramperes]

What I meant is that onetun would behave like a regular WireGuard peer over UDP, just that instead of initiating TCP/UDP connections through the tunnel, it would be receiving TCP/IP handshakes (processed by smoltcp)

In other words, onetun has to create virtual server sockets instead of clients in this mode.

[afontenot]

Okay, I'll close this. Thanks for responding!