engarde - small issue with wireguard-windows

[Alessandro Rinaldi]

Hello,

I just subscribed to the mailing list so I'll introduce myself: I'm
Alessandro, I'm from Italy and I LOVE WireGuard :)

Last year I was looking for a way to create a reliable network tunnel
over multiple unstable connections. I'm a volunteer in a radio station
and it happens sometimes to broadcast from remote locations where
Internet connections are not good.
What I was looking for was not a failover mechanism, since when
transmitting nearly real-time audio we couldn't afford even the time
for it to detect a problem in the connection and switch to another
one. Audio transmission requires low bandwidth, so we didn't care
about wasting it to have a stable connection.

So I came up with a solution that I called engarde [0]: it basically
takes packets emitted from WireGuard and sends them to the other peer
over all the available network interfaces (like for example, an ADSL
modem over Ethernet, one or two 4G USB dongles, and maybe a WiFi
network). On the other peer, engarde takes all the packets it receives
and sends them to the local UDP port WireGuard is listening on. When
it receives a packet back from WireGuard, it sends them back to all
the destinations it received packets from recently (by default, 30
seconds). Since WireGuard disards duplicated packets by looking at
their timestamps [1], this totally works as a redundant bonding
solution, for both upload and download: as long as at least one
connection is up at any given moment, the tunnel is stable, without
even a minimal interruption.
The behaviour is better described in the project README, along with
some example use cases and configurations.

With the spreading of Covid-19 here in North of Italy, many radio
speakers started transmitting from home, and I know of various radio
stations that used engarde to have a stable audio signal by using, for
example, the speaker's home connection and its smartphone one via USB
tethering.

First of all, I'd love to know what you think about it, or if you have
a better approach than this one: I searched a lot for possible
solutions before coming up with my own one and, even if I'm really
satisfied with it, I'd like to know if there are more "mainstream"
approaches for that.

Also, by testing this, I found a strange issue with the WireGuard
Windows client. For the solution to work, the WireGuard client must
send its packets not directly to the other peer, but to engarde
itself, that will dispatch them through all the interfaces. So, I need
to set "127.0.0.1:54321" as the peer address, where 54321 is the port
engarde is listening on. This works on Linux and Mac, but not on
Windows. When I bring the tunnel up with 127.0.0.1:12345 as peer
address, this is the error I get in logs:
```
2020-04-18 00:45:33.537: [TUN] [Radio] peer(gucn…uwWE) - Failed to
send handshake initiation write udp4 0.0.0.0:59301->127.0.0.1:12345:
wsasendto: Indirizzo richiesto non valido nel proprio contesto.
```
This seems to be returned directly by the OS, since it's translated:
I'm using Italian Windows, in the English version it's "The requested
address is not valid in its context".
The exact same configuration works like a charm in TunSafe.
Is this an issue that could be solved on the WireGuard side?

Thank you so much for any feedback you'll provide me, both for engarde
itself and for the issue I'm having on Windows.

[0] https://github.com/porech/engarde
[1] https://www.wireguard.com/protocol/ , "DoS Mitigation" section