Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Daniel Gröber" <dxld@darkboxed.org>
To: Daniel <tech@tootai.net>
Cc: wireguard <wireguard@lists.zx2c4.com>
Subject: Re: Endpoint failover ip
Date: Tue, 1 Aug 2023 00:27:44 +0200	[thread overview]
Message-ID: <20230731222744.5wej7mv5sef57w46@House.clients.dxld.at> (raw)
In-Reply-To: <e9ddd93a-4517-7411-a5d3-360fa8e1bde6@tootai.net>

Hi Daniel,

On Mon, Jul 31, 2023 at 11:39:35PM +0200, Daniel wrote:
> I create a hostname with few IPs v4 & v6 for my wireguard server. I faced
> today a problem that after a failure with the ip a customer wg was
> registered, it continue to try to register with this ip insteed to fallback
> to another one.

Your message is hard to parse, but I think you're having the same v4/v6
failover problem as me. See my patch "wg: Support restricting address
family of DNS resolved Endpoint":

  https://lists.zx2c4.com/pipermail/wireguard/2023-February/007961.html

which has yet to get any attention from Jason unfortunately.

The headline is this: wireguard doesn't support multiple endpoints so you
have to be careful with how you setup your host records. At the moment you
can't just throw multiple IPs in there and hope for the best. Wg will stick
to whatever IP the system picks when the tunnel comes up.

> Is there a way to avoid this problem and to get failover working properly
> with wireguard ?

There isn't any wg native solution[1] right now, only hacky
workarounds. You basically need one wg tunnel per unique endpoint but once
you do that routing becomes an issue. Plain static routes wont cut it
anymore. On top of that using an endpoint domain with multiple IPs is a
problem. Things are easier if you stick to one IP per domain or just
hardcode one endpoint IP for each of the many tunnels.

[1]: Supporting multiple active endpoints is where we have to head to fix
this properly IMO, see my recent proposal
https://lists.zx2c4.com/pipermail/wireguard/2023-July/008111.html

Anyway with the many wg tunnels one could then write a script to ping
through the tunnels and switch the appropriate route to the one that
responds. This has to happen at both ends of the tunnel. Me personally, I
just use an easy to setup routing daemon (babeld) to do that.

--Daniel

  reply	other threads:[~2023-07-31 22:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-31 21:39 Daniel
2023-07-31 22:27 ` Daniel Gröber [this message]
2023-08-01  8:33   ` Daniel
2023-08-01  9:07     ` Daniel Gröber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230731222744.5wej7mv5sef57w46@House.clients.dxld.at \
    --to=dxld@darkboxed.org \
    --cc=tech@tootai.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).