AW: Hyper-V 2019: unable to create wintun device: no interfaces found

[news at lindenberg.one]

Hi Jason,
not the port. My external IP is dynamic. This is really standard for internet services in Germany offered to non-business users, or also business that prefer not the pay extra charges for the assignment of a static ip address. My IP address changes at least once a day (usually between 1 am and 2 am). Usually one uses a dyndns provider, and many routers support updating the ip address automatically. As I am running my external DNS with cloudflar, I am calling their API to update my external address.
Now afaik Wireguard resolves the domain name of the server just once to an IP address and not regularly or whenever the connection breaks down or has been idle for some time.
PersistentKeepAlive cannot address the issue, as the client is also not awake all the time in order to save energy. Looking at wg /? on windows I also don´t see any option that seems applicable..
Thanks, Joachim

-----Ursprüngliche Nachricht-----
Von: Jason A. Donenfeld <Jason at zx2c4.com> 
Gesendet: Sunday, 25 August 2019 20:36
An: Joachim Lindenberg <wireguard at lindenberg.one>
Cc: Simon Rozman <simon at rozman.si>; WireGuard mailing list <wireguard at lists.zx2c4.com>
Betreff: Re: Hyper-V 2019: unable to create wintun device: no interfaces found

On Sun, Aug 25, 2019 at 11:23 AM Joachim Lindenberg <wireguard at lindenberg.one> wrote:
> my experiments were actually roughly three weeks ago with versions .18 and .19, and that mail was somehow stuck..
> Just retried with .22, and the good news is that I was able to set up a tunnel between a Hyper-V as a server and a windows client. The old error on wintun is gone.

Good to hear.

> trick wireguard to work around the dynamic IP issue most Germans face. With the Ubuntu vms I can ping the server from the client, and if it is unreachable I am pulling down the interface and then up again.

Not sure I understand exactly. Is the goal to simply change/re-randomize your listen-port due to some weird quirks of your router's NAT table, in which case `wg set wg0 listen-port 0` will probably work better than down/up? Or is this actually a case where adding PersistentKeepalive=25 could fix things? Both of these options, anyhow, are available in the Windows client. wg.exe is installed into
system32 and works as expected.