On Thu, 2014-02-13 at 22:53 -0800, Kevin Cernekee wrote: > If I set method "ssl" or "new-tunnel", the result is the same: > X-CSTP-Rekey-Method: new-tunnel > X-DTLS-Rekey-Time: 240 > > This could be a bug, or maybe it means the "ssl" method isn't > implemented on this firmware version. Perhaps the SSL renegotiation method got deprecated around the time of CVE-2009-3555. > FWIW, I still need this patch to prevent DTLS from going out to lunch > after CSTP reconnections: > > https://github.com/cernekee/openconnect/commit/a53877ea22a546b12a9e2c30561fbd38c695532e I broke that in (and around) commit e35b71cb1. Any chance of an updated version, please? It'll take me at least a day to test here... > Every time I reconnect CSTP, I receive a new DTLS session ID from the ASA. Hm, that used *not* to be the case as long as we didn't generate a new master-secret. We have logic in start_cstp_connection() to regenerate vpninfo->dtls_secret only if a DTLS rekey is imminent. Can you add a log message when it's regenerating the secret, and/or just comment it out to make sure it *never* does, and confirm the behaviour? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140214/b1880058/attachment.bin>
