Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Derrick Lyndon Pallas <derrick@pallas.us>
To: wireguard@lists.zx2c4.com
Subject: Re: Support of multiple endpoints to support IPv6/IPv4 protocol change
Date: Tue, 27 Aug 2019 10:17:41 -0700	[thread overview]
Message-ID: <a5dd2f52-86ba-8bad-4594-af4f821907eb@pallas.us> (raw)
In-Reply-To: <915FDB2D-7452-433C-A3FE-63EF75916417@pallas.us>

Would it make sense to do something like Happy Eyeballs (RFC 8305) 
extended for UDP? If WireGuard were to implement the equivalent of 
section 5 (but keep the list of addresses around after a handshake for 
probing or failover) then userland could easily handle sections 3 and 4. 
~Derrick


On 8/25/19 12:23 PM, Derrick Lyndon Pallas wrote:
> 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
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

      reply	other threads:[~2019-08-27 17:18 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
2019-08-27 17:17   ` Derrick Lyndon Pallas [this message]

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=a5dd2f52-86ba-8bad-4594-af4f821907eb@pallas.us \
    --to=derrick@pallas.us \
    --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).