On Sat, 2014-11-15 at 13:39 +0000, David Woodhouse wrote: > On Sat, 2014-11-15 at 12:26 +0100, Nikos Mavrogiannopoulos wrote: > > > > clients behind these nat types will have no issue as long as the nat > > keeps the UDP association. If it is lost there is nothing in the > > received packets that could allow ocserv to reassociate the session > > with the correct server. > > Er, don't they have the session-id in the ClientHello? And the server > *provides* the session-id, so it could make it something which helps > with finding the correct server. That only works if the client detects the lost packets and restarts the DTLS session. > On Sat, 2014-11-15 at 12:45 +0100, Nikos Mavrogiannopoulos wrote: > > David could openconnect reconnect the TLS channel only but continue > > sending on the old DTLS channel? That is what is seems to be happening > > here. > > Yes. See your own commit > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/14d807f5 > > It'll automatically reconnect DTLS after any CSTP reconnect, but *only* > if DTLS doesn't have its own rehandshake timer/mechanism set up. Correct. That seems to be an issue of semantic difference in ocserv and anyconnect servers. ocserv gives a new DTLS session ID on every reconnection and requires DTLS to reconnect too. That can detected by openconnect by checking the session ID for match. An untested patch for openconnect follows. Would that Ismail fix the issue you notice? > And that's probably the right thing to do. If there's been packet loss > and the TCP connection is stalled, DTLS could be running just fine and > the user might not even have *noticed*. We can reconnect the CSTP > without even a momentary blip in actual *traffic* over DTLS. > If the CSTP gives us a new session-id, though, we probably *should* > reconnect DTLS. I think we're careful not to change our > DTLS-Master-Secret on reconnect, aren't we? Indeed. However, the keys being the same wouldn't help ocserv, as a DTLS handshake has to be performed anyway. As it is the DTLS packets move to a black hole with ocserv (on every TLS connection you get a different DTLS session). As I understand that case can be triggered by a random failure in the TLS channel (e.g., cstp_write failed because the TCP session was reset), or by setting "rekey-method = new-tunnel" in ocserv. (in an unrelated issue for some reason DPD detection here didn't work for DTLS which didn't try to reconnect - I don't know if Ismail has the output of openconnect) regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-force-DTLS-reconnect-if-the-session-ID-we-get-from-T.patch Type: text/x-patch Size: 2175 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141115/f5eaa27e/attachment.bin>
