Tunnel dying with ping timeout on idle or device locked (Apple bug)

[keeshux]

Reported by several users since iOS 13.

[keeshux]

It looks like, for whatever reason, the client is able to send data to the server, but at some point in time stops reading server responses. This is confirmed by looking at the server logs, the client assumes a ping timeout whereas the server is actually active. It's just that the client is not reading (getting?) the data.

[keeshux]

Pings fail to deliver, because when sleep state is ultimately signalled, all queue code hangs up. As a direct consequence, e.g. packets are not sent and packet handlers are not executed until the device wakes up again.

In fact, the scheduled ping block pending execution in the tunnel queue, resumes immediately on wake-up, also causing a snappy .pingTimeout error (the ping timeout condition is checked against in the ping() function). This all explains why the VPN doesn't actually die during sleep, but as soon as there's a wake-up. Notice the temporary "4G" popping in the status bar when turning on the device screen, indicating a prompt reconnection.

Now the problem is: why does the queue stop running on sleep?

Potential fix: try a specific DispatchQoS, e.g. .utility as suggested on Apple forums.

[keeshux]

Setting an explicit QoS didn't help. Upgrading to iOS 13.3 didn't fix the issue either.

[keeshux]

Reported bug to Apple.

[keeshux]

Apple never responded, but I haven't experienced this with recent iOS releases. Need to re-test properly.

[rogersia]

This seems to be happening again in iOS 14

What information do you need from the log?

[keeshux]

This seems to be happening again in iOS 14

What information do you need from the log?

I wouldn't say "again" as this was never resolved by Apple. If you confirm it's coming from the same test case, there's nothing to add I guess.

[rogersia]

Thanks.

The debug log says: 14:02:37 - DNS: Using servers 14:02:37 - DNS: Using search domains 14:02:37 - Ack successfully written to LINK for packetId 43 14:02:38 - Reasserting flag cleared 14:02:38 - Tunnel interface is now UP 14:03:49 - Send ping 14:04:25 - Data: Received ping, do nothing 14:08:13 - Trigger shutdown (error: pingTimeout) 14:08:13 - Session did stop with error: pingTimeout 14:08:13 - Failed LINK read: Error Domain=NSPOSIXErrorDomain Code=89 "Operation canceled" 14:08:13 - Socket state is cancelled (endpoint: -> ) 14:08:13 - Cleaning up... 14:08:13 - Tunnel did stop (error: pingTimeout) 14:08:13 - Flushing log...

looks like it is doing nothing in that period between the ping and the other errors! Hope this helps.

[sith-on-mars]

For me this problem only happened when I used the IKEv2 protocol. I have tested it when using both the ProtonVPN app (under Settings->VPN->Personal VPN) and the manual configuration (under Settings->VPN->VPN Configurations). The OpenVPN protocol didn't have this issue.

[rogersia]

Definitely have this issue with OpenVPN to my router.