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.
