remove peer endpoint

em12345 em12345 at
Mon Dec 30 12:50:44 CET 2019

Sorry, may be I was not clear enough. I didn't intend to ask for the
removal of the ability to set an endpoint, but for the ability to
configure a peer without knowing the endpoint at configuration time.
Because the endpoint is only known at a later point.

On 2019-12-30 11:58, Jason A. Donenfeld wrote:
> On Mon, Dec 30, 2019 at 11:13 AM em12345 <em12345 at> wrote:
>> Hi,
>> in my case the reason is not exactly being able to remove the endpoint,
>> but rather being able to setup a peer without endpoint, so that only the
>> endpoint needs to be setup later.
>> Scenario:
>> All keys for interface and peer are configured via "wg" standard config
>> file, so that the interface can be brought up at boot time.
>> But when having to use a to be resolved host name as endpoint, then the
>> boot process blocks for around a minute in case no network (incl. DNS)
>> is available. At least when running systemd reading
>> /etc/network/interfaces. I'm not using systemd builtin wg support.
>> There is of course the possibility to bring up the wg-* interfaces later
>> altogether. But the easiest way for me was to use a local endpoint IP
>> ( address, and then use up/down scripts triggered on LAN/WLAN
>> up/down, which then only resolve the endpoint host name and set via wg
>> the resolved IP of that.
>> This way I'm also able to use several hostnames from different DynDNS
>> providers, in case one service provider is down, which wg as far as I
>> know doesn't currently support.
>> I.e:
>>         1.) resolve first host name
>>         2.) set endpoint IP on peer
>>         3.) ping into tunnel to see if it is working
>>         4.) if not working, then try next host name
>> Thanks,
>> Emmanuel
> You've misunderstood the discussion. Nobody is discussing removing the
> ability to set an endpoint after the interface has been configured.
> This exists and works today and isn't going anywhere. Rather, this is
> a discussion about being able to unset an endpoint.

More information about the WireGuard mailing list