Problem with iOS WireGuard client

Thu Jan 16 03:44:15 CET 2020

Yes, your problem sounds quite similar to mine.  However, I'm running into
this issue on several different networks -- both wifi and cellular.  To be
clear: I haven't found a pattern of networks where this does / doesn't
happen.

Details of my config:

   - I'm running on an iPhone 8+; I've experienced this problem on both iOS
   12.x and 13.x.
   - I used Algo to setup a VPN endpoint on a new Digital Ocean droplet (
   https://github.com/trailofbits/algo), and installed the Wireguard iOS
   app (v0.0.20191015 (15) / 0.0.20190909) on my iPhone 8+.
   - My Droplet is in the Digital Ocean datacenter in North Bergen, NJ.
   - I have the iOS Wireguard client set for "on-demand activation" on both
   Cellular and Wi-Fi (Any SSID).
   - When this problem occurs, I find that going into iOS Settings --> VPN
   and toggling the VPN off (which then immediately toggles back on, because
   of the Wireguard "on-demand" settings) fixes the problem.  I do not need to
   go to Airplane mode or otherwise disconnect from / reconnect to the current
   network.
   - I have not found a pattern for when this happens / when this does not
   happen:
      - Sometimes it happens when I switch from network A to network B, but
      other times -- when switching from the same network A to B -- it doesn't
      happen.
      - Sometimes when I wake up in the morning (when my phone has been
      charging on wifi all night), when I first pick it up in the
morning, it is
      in this state.
      - It also happens sometimes when it's been sitting idle on my desk
      next to me for a while -- i.e., it's been on the same network for an
      extended period of time.
      - The only common thing that I have noticed is that it does not
      happen in the middle of interactive use.  If it's working, it
stays working
      / traffic keeps flowing for the duration of my interactive use.
      Specifically: I have only ever found it in this state right
after unlocking
      my phone to use it (usually after it has been sitting with the screen
      locked or off for some period of time).
   - If you wait long enough, sometimes the failed handshakes resolve
   themselves (see below).  That usually takes many minutes (about 4 minutes
   in the screencast, below).  I usually don't have that kind of patience, and
   just toggle the VPN on/off, which always seems to fix the problem
   immediately.

 Here's a sorta-long screencast showing when this happened back on 11/27
<https://youtu.be/9188GaszaLw>.  The behavior is the same today / in late
Jan 2020; I just recorded this back when this started.  Here's some notable
points in the video:

   1. The beginning shows that everything appears to be connected.
   2. At 0:22, I go into WG to show the current log, and you see the failed
   handshake messages.
   3. At 0:56, you see me try to load the zx2c4 "what's my IP?" page, and
   it hangs.
   4. At 1:38, you see me go back into WG and you can see all the failed
   handshake messages scroll by.
   5. Suddenly, at 3:53, the handshake succeeds, and now traffic appears to
   be flowing properly.
      - Note that nothing changed in my networking connectivity during that
      time, to my knowledge.  I had 3-4 bars on AT&T.
   6. After that (around 4:39), you can also see the IPv6 / IPv4 flip.  The
   recording keeps going for a while, but you can probably skip the rest.

Right after I finished the screencast, I saved the WG logs -- see
attached.  You can see all the handshake failures towards the end.

Is there any more information that I can provide to help diagnose this
issue?

On Wed, Jan 15, 2020 at 1:47 PM John <graysky at archlinux.us> wrote:

> Your issue sounds similar to mine linked below.  Do you find this
> endless failed handshakes to be when you're connected to any network
> or just a specific one?  I routinely connect to 4 networks in my
> travels and only 1 of them causes the problem.
>
> Link to my post:
> https://lists.zx2c4.com/pipermail/wireguard/2020-January/004858.html
>
> On Wed, Jan 15, 2020 at 1:31 PM Jeff Squyres <jeff at squyres.com> wrote:
> >
> > Over the past ~2 months, I have been experiencing an intermittent
> problem with the iOS WireGuard client: sometimes the WireGuard client gets
> into a loop of endlessly-failing handshakes, which therefore stops all
> traffic.  If I disconnect/reconnect the WireGuard tunnel, the handshakes
> succeed, and traffic starts flowing normally again.
> >
> > This happens multiple times a day.  It has been happening with multiple
> versions of iOS starting with 12.x, and now with 13.x.  WireGuard for iOS
> version 0.0.20191015(15), Go Backend 0.0.2019.0909.
> >
> > I can send more details (logs, screenshots / screencast, etc.), but
> first: is this the right list to ask questions about the iOS client?  If
> not, can someone point me in the right direction?
> >
> > Additionally, another oddity: when my Wireguard tunnel is connected
> properly and I visit whoer.net or zx2c4.com/ip, sometimes I see my
> WireGuard endpoint's IPv6 address, and sometimes I see my WireGuard
> endpoint's IPv4 address.  This happens regardless of what network my iOS
> device (i.e., my phone) is on.  Sometimes when the IPv6 address is shown
> and I refresh the page a few times (over the span of a few seconds), it
> switches to show the endpoint's IPv4 address.
> >
> > Thanks!
> >
> > --
> > {+} Jeff Squyres
> > _______________________________________________
> > WireGuard mailing list
> > WireGuard at lists.zx2c4.com
> > https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>

-- 
{+} Jeff Squyres
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200115/acdae2cf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireguard-log-2019-11-27T200624Z.txt.bz2
Type: application/x-bzip2
Size: 12216 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20200115/acdae2cf/attachment.bz2>