I am using WireGuard on my iPhone, and the endpoint is specified by a domain name that has both AAAA and A record. When I turn on WireGuard in a network with dual IPv6 and IPv4, I find out that WireGuard chooses IPv4 by executing "wg" on my server. If I explicitly set the endpoint as IPv6 address, WireGuard works just fine, so it is not a misconfiguration on my server. Most operating systems prioritize IPv6 over IPv4, so it is baffling why WireGuard iOS goes the other way. More importantly, this is not a theoretical discussion for me: in my case, IPv6 has better performance due to less congestion (as fewer people utilize it). I also have an IKEv2/IPSec VPN configured on the same server, and it performs better because it always prioritize IPv6. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
On Thu, Jan 2, 2020 at 09:40:53 CET, Siyuan Ren <netheril96@gmail.com> wrote: > I am using WireGuard on my iPhone, and the endpoint is specified by a > domain name that has both AAAA and A record. When I turn on WireGuard > in a network with dual IPv6 and IPv4, I find out that WireGuard > chooses IPv4 by executing "wg" on my server. If I explicitly set the > endpoint as IPv6 address, WireGuard works just fine, so it is not a > misconfiguration on my server. The Android (v0.0.20200206) and Windows (v0.0.38) clients have the same bug. This might be considered just bad behavior in dual-stack networks, but it causes real issues in IPv6-only networks: On Android, WireGuard uses IPv4 via 464XLAT (if available). This works, but can result in decreased performance. Windows doesn't have a CLAT [1], but WireGuard tries to use IPv4 anyway. This results in the tunnel not working at all. Cheers, Maurice [1] Well, it does, but only on mobile data, not on WiFi or Ethernet. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Hello, On Thu, Jan 2, 2020 at 09:40:53 CET, Siyuan Ren <netheril96@gmail.com> wrote: > I am using WireGuard on my iPhone, and the endpoint is specified by a > domain name that has both AAAA and A record. When I turn on WireGuard > in a network with dual IPv6 and IPv4, I find out that WireGuard > chooses IPv4 by executing "wg" on my server. If I explicitly set the > endpoint as IPv6 address, WireGuard works just fine, so it is not a > misconfiguration on my server. The Android (v0.0.20200206) and Windows (v0.0.38) clients have the same bug. This causes severe issues in IPv6-only networks: On Android, WireGuard uses IPv4 via 464XLAT (if available). This works, but can result in decreased performance. Windows doesn't have a CLAT [1], but WireGuard tries to use IPv4 anyway. This results in the tunnel not working at all. Can someone confirm this? Is there a better place to report it? Cheers, Maurice [1] Well, it does, but only on mobile data, not on WiFi or Ethernet. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
On 17.02.20 16:44, Maurice Walker wrote: > The Android (v0.0.20200206) and Windows (v0.0.38) clients have the same bug. It's not a ("simple") bug, but a general problem with peers with multiple addresses – wireguard only stores one in the kernel, it doesn't do multipath, by design. Thus the frontend needs to remember all addresses, send one to the driver, wait a bit, check whether a link could be established, then try with another peer address. Repeat until success. Bonus points for repeating the host name lookup. -- -- Matthias Urlichs _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Hi Matthias, Thanks for the explanation. I did some more testing on Windows. If the peer FQDN resolves to both AAAA and A, WireGuard seems to check for an interface with an IPv4 address (other than link-local or loopback). If there is one, it uses IPv4, otherwise IPv6. The issue is that it doesn't seem to check whether there actually is an IPv4 route to the peer. So as long as there is any IPv4 address on any interface, WG doesn't use IPv6 - even if there is no IPv4 default gateway (or other IPv4 route to the peer). Since it already seems to perform some rudimentary IPv4 connectivity check, a simple check of the routing table could be a stopgap fix. > Thus the frontend needs to remember all addresses, send one to the > driver, wait a bit, check whether a link could be established, then try > with another peer address. Repeat until success. Right, that would ultimately be what one would wish for. But until this is implemented, WG should at least prefer IPv6 over IPv4. Cheers, Maurice (Sorry for double posting. I mailed again after the first mail had been on hold for moderator approval for three days. I will be more patient this time.) _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard