Support of multiple endpoints to support IPv6/IPv4 protocol change

Derrick Lyndon Pallas derrick at
Tue Aug 27 19:17:41 CEST 2019

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. 

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 at> 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
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard at
> _______________________________________________
> WireGuard mailing list
> WireGuard at

More information about the WireGuard mailing list