dpd has no effect when using iOS anyconnect

[BitInn Admin]

Took me a while to figure out CSTP means SSL/TLS Tunnel (over TCP).
But thanks to your reply I now have some pointers on how I might be
able to improve connectivity on wake.



To answer your questions:

1. I don't see server-initiated DPD in client-side debug log, only
client-initiated DPD for detecting MTU, possibly because my ocserv
mobile DPD setting is the default 1800 (30 minutes), while my test
only lasts for 20 minutes or so.

2. Only via iOS background activity[0], I can see some DPD timeout
after manual lock (sleep), see next answer for details. For the 2nd
part of your question: as noted in cisco and apple doc, iOS does wake
from TCP connection, otherwise push notification or facetime call
won't work[1].

3. This is the part I am not sure. AnyConnectDataAgent manages both
SSL and DTLS connections, I don't see it complain about connection
timeout/drop, except for `Failed to validate the tunnel MTU via DPD
handshake (DTLS/CDTP)`, and this is the last log entry:
`CTunnelProtocolDpdMgr::handleExpiredMtuDPD Return Code: -25952247
(0xFE740009) Description: TUNNELPROTOCOLDPDMGR_ERROR_UNEXPECTED
DTLS/CDTP`[2].


To investigate further:

1. I will try to lower the mobile DPD settings in ocserv to force DPD to happen.

2. I might need to collect appropriate server log, but I am not sure
about what log level is appropriate for this sort of debug.




[0] apple are pretty strict about this sort of background tasks, but
cisco has special NDA deal with apple to add extra vpn feature to ios,
so who knows: https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html

[1] I do have facetime enabled, but AnyConnect on iOS only have
background activity options (which must be enabled for this vpn app to
work), no push notification settings.

[2] The strange part being that, I let my device sleep for 15 minutes
and that last log appear in the first minute, it would appear
AnyConnect didn't do anything for the next 14 minutes, albeit with
background activity enabled.



On Fri, Jan 23, 2015 at 10:55 PM, Kevin Cernekee <cernekee at gmail.com> wrote:
> On Fri, Jan 23, 2015 at 5:19 AM, David Frank <bitinn at gmail.com> wrote:
>> I recently read this fine-print on Cisco’s document for anyconnect:
>>
>> http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect30/user/guide/iphone-ugac-ios.html#pgfId-205596
>>
>>
>> Known Issues in Apple iOS Impacting VPN:
>>
>> - A DTLS packet received while the device is asleep does not awaken it. TLS packets, however, awaken the device if notifications or Facetime is enabled. AnyConnect automatically disconnects the DTLS tunnel when the device goes to sleep to allow packets received over the TLS connection to wake the device. The DTLS tunnel is restored when the device resumes.
>>
>>
>> So Anyconnect closes UDP session when iOS sleeps (lockscreen), it means dpd is not usable, correct?
>
> There are a few different issues to consider:
>
> 1) Can your client reply to gateway-initiated DPD messages?  AFAICT,
> it can still receive DPD messages over CSTP according to this note.
>
> 2) Can your client initiate its own CSTP DPD messages while the iOS
> device is sleeping (and are these necessary for ocserv to keep the
> connection up)?  Not sure on this one.  The other thing to consider is
> whether the client side can wake up and reconnect if the mostly-idle
> CSTP connection drops while sleeping.  On Android I had to add a fair
> amount of logic to ensure that the client woke up and "phoned home" on
> a regular basis to avoid an idle timeout on the VPN session.
>
> 3) Is the CSTP connection really staying up while the device is
> sleeping?  The last time I played with iOS (v5.x on an old 3GS) I
> looked at packet traces and saw it terminating the CSTP connection
> immediately when it went to sleep.  Maybe this behavior changed, or
> maybe my experiment was flawed.