Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Derrick Lyndon Pallas <derrick@pallas.us>
To: Nico Schottelius <nico.schottelius@ungleich.ch>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Support of multiple endpoints to support IPv6/IPv4 protocol change
Date: Sun, 25 Aug 2019 12:23:35 -0700	[thread overview]
Message-ID: <915FDB2D-7452-433C-A3FE-63EF75916417@pallas.us> (raw)
In-Reply-To: <87h86fq4ss.fsf@line.ungleich.ch>

I recently ran into this issue. My solution was to sort a list of endpoint addresses (not domains) by priority and first check whether the client had a route to an address before picking it. It would be nice if Wireguard kept a list of fallback addresses in case the currently active address stopped working, but this can be achieved by tooling today.

~Derrick • iPhone

> On Aug 17, 2019, at 6:50 AM, Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
> 
> 
> Hello,
> 
> TL;DR
> How difficult is it to add support for multiple endpoints in wireguard?
> 
> My problem is that sometimes we need to connect to the VPN server
> via IPv4, sometimes via IPv6 and the other protocol won't work anymore.
> 
> 
> Long story:
> We are a cloud provider offering free IPv6 VPNs with VMs, to enable
> customers to have IPv6 anywhere. In some situations customers are
> confused, because their network doesn't work anymore while wireguard is
> active or the tunnel doesn't work in some networks. I will describe some
> situations that we experienced and how we work around it at the moment.
> 
> 
> Story 1: using VPN in VPN
> Some of our customers have an IPv6 tunnel to provide a /48 to their
> network. They usually use a couple of /64s to separate their internal
> networks. Some of these customers also have a VPN to their end device
> (like a notebook) with another /48 routed to it. In this situation, they
> are unable to reach the VPN server or local clients if they don't
> explicitly change their configuration to reach the VPN server via IPv4
> instead of IPv6:
> 
> With a standard config, the DNS name of the tunnel endpoint in
> in wg0.conf, not fixed to IPv4/IPv6, we had the following report:
> 
> In this case if the notebook connects via IPv6 to the VPN server,
> it effectively connects to the VPN server through the VPN. We had
> reports that in this situation the notebook can either not establish the
> VPN tunnel or is unable to reach local devices
> 
> Workaround from some customers: hard code the IPv4 address as an endpoint
> 
> Story 2: Change from IPv4 only to IPv6 only networks
> 
> We have reports from clients that the VPN is not established again, if
> they switch from an IPv4 only network to an IPv6 only network and vice
> versa. I assume this is due to wireguard resolving the address at
> startup and never re-resolving and/or not storing all DNS results (A and
> AAAA answers).
> 
> Workaround from some customers: restart wireguard when changing
> underlying protocol network
> 
> 
> Story 3: Combination of above
> Some of our clients hard coded the IPv4 address of the tunnel endpoint
> in their wg0.conf to avoid the problem from story 1. However this breaks
> their Internet when switching to IPv6 only networks. In this case the
> endpoint is fixed to IPv4, but they don't have any IPv4 connectivity.
> 
> Workaround from some customers: reconfigure wireguard to use hardcoded
> IPv6 or IPv4 only endpoint.
> 
> 
> --
> Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  reply	other threads:[~2019-08-25 19:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-17 13:50 Nico Schottelius
2019-08-25 19:23 ` Derrick Lyndon Pallas [this message]
2019-08-27 17:17   ` Derrick Lyndon Pallas

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=915FDB2D-7452-433C-A3FE-63EF75916417@pallas.us \
    --to=derrick@pallas.us \
    --cc=nico.schottelius@ungleich.ch \
    --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).