Load-balancing destination address

[aramperes]

Add support for passing multiple destination addresses for one source address. Should round-robbin the destination address to use for each incoming connection on the source address.

As suggested by @danielbodnar

[cipriancraciun]

I'm curios what is the use-case for this feature?

(Shouldn't the load-balancing be handled at the other end? I.e. somewhere between the Wireguard router and the actual remote server? One could easily achieve this in a number of ways.)

[aramperes]

If you have web servers on the peers:

• 192.168.4.2:8080
• 192.168.4.3:8080

The objective is to set up a load balancer (LB) on a third system to round-robbin requests from the 2, and expose that to the internet. If you use something like HAProxy or Nginx Plus, you'd need to have WireGuard installed on the LB so that the LB software is able to connect to those peers by IP.

However you can also run 1 onetun instance that round-robbins between the 2, and opens a single port on 0.0.0.0. Which means:

                             192.168.4.2:8080
                          /
0.0.0.0:8080 -> [onetun] 
                          \
                             192.168.4.3:8080

Of course, you could also run multiple forwards of onetun (#2) and let an LB software do the round-robbin, but that adds an extra step in the chain:

                                0.0.0.0:8081 -> [      ] -> 192.168.4.2:8080
                              /                 |      |
0.0.0.0:8080 -> [LB software]                   |onetun|
                              \                 |      |
                                0.0.0.0:8082 -> [      ] -> 192.168.4.3:8080

[cipriancraciun]

Although technically I see nothing wrong with the proposed use-case, I don't find it practical enough to be worth complicating onetun ever further. (If nothing else ssh doesn't support this.)

Why I'm saynig it's not "practical enough"? When speaking of load-balancing there are two major concerns: distributing load or high availability. So let's address them individually:

• the initial proposal seems to be focused on distributing load in a round-robin fashion; however (and I might be wrong) onetun is perhaps not meant as a "high performance" gateway but perhaps more focused more on "utilitarian" aspects (such as enabling Wireguard even when one doesn't have root credentials); therefore if one actually needs load-balancing for performance reasons then perhaps onetun would actually become a bottleneck;
• high availability -- the initial proposal doesn't speak about what should happen if a target is down or what would it mean to be down; therefore to actually implement this use-case one would need to complicate onetun even further;

Of course, you could also run multiple forwards of onetun (#2) and let an LB software do the round-robbin, but that adds an extra step in the chain:

Therefore I think the second approach would make more sense: let onetun just provide support for bridging over Wireguard (with support for multiple endpoints, and perhaps both the reversed feature I've proposed #6), and leave the advanced features (load balancing, high availability, etc.) to a dedicated tool such HAProxy.

[aramperes]

For what it's worth, I don't envision onetun being purely "utilitarian" like you said. It definitely has its uses for quickly accessing a port from a dev machine, but my own primary use-case is to set up long-running proxies for public services that are hosted from peers inside my WG network. I will keep pushing for stability and performance as much as possible.

You make a good point that letting the LB software handle the round-robin and health checks would help onetun be "leaner". This will only be possible once #2 is implemented though, since separate instances of onetun would need to have separate IPs/keys configured (which is a bit of a chore).

[aramperes]

I've decided not to implement this since it should be covered by #2 and putting a capable LB software in front. I'll reopen if I change my mind.