[GIT PULL V4] JNI bindings for libopenconnect
Kevin Cernekee
cernekee at gmail.com
Tue Jan 21 12:37:54 EST 2014
On Tue, Jan 21, 2014 at 8:34 AM, Woodhouse, David
<david.woodhouse at intel.com> wrote:
> On Tue, 2014-01-21 at 08:02 -0800, Kevin Cernekee wrote:
>> On Tue, Jan 21, 2014 at 2:47 AM, Nikos Mavrogiannopoulos
>> <nmav at gnutls.org> wrote:
>> > I have not tried yet, but a question on that. On the CSTP reconnect is the
>> > DTLS channel kept open or it is also re-opened? If it is kept opened then
>> > the warnings you see are normal as ocserv handles the CSTP channel as
>> > control and once discarded the DTLS channel is discarded as well.
>>
>> The old behavior was to keep it open. The new behavior is to
>> close+reopen DTLS on CSTP reconnect.
>
> Hm, is that necessary?
>
> One of the reasons why a VPN should run over UDP instead of TCP is
> because TCP connections stall when there's packet loss. So on a crappy
> connection you *do* end up with CSTP reconnects due to aggressive DPD,
> while the DTLS is still quite happily running.
>
> I seem to recall that my testing, back when this was first implemented,
> seemed to show that DTLS would happily keep going even while the CSTP
> was reconnecting, with no loss of service.
>
> Hm, wait a minute... doesn't cstp_reconnect() block? In which case I
> *must* have just made up that previous recollection? The DTLS connection
> did continue to work, but perhaps openconnect never actually made *use*
> of that to provide seamless service?
To get to the point where cstp_reconnect() will block, the CSTP
connection would need to be stalled long enough to lose a couple of
DPD requests or replies (typically on the order of minutes), and then
the new TLS connection would need to time out or fail. Up until the
new connection attempt, DTLS can still pass traffic even if CSTP is
stalled, assuming the system's network connection is still up.
I was toying with the idea of just closing the DTLS connection any
time the CSTP connection is closed, under the assumption that the DTLS
parameters are likely to get changed upon CSTP reconnection. Would
that make sense?
diff --git a/gnutls.c b/gnutls.c
index 4bc863d..8d5d24f 100644
--- a/gnutls.c
+++ b/gnutls.c
@@ -1981,6 +1981,8 @@ void openconnect_close_https(struct
openconnect_info *vpninfo, int final)
FD_CLR(vpninfo->ssl_fd, &vpninfo->select_efds);
vpninfo->ssl_fd = -1;
}
+ dtls_close(vpninfo, 1);
+ vpninfo->new_dtls_started = 0;
if (final && vpninfo->https_cred) {
gnutls_certificate_free_credentials(vpninfo->https_cred);
vpninfo->https_cred = NULL;
diff --git a/openssl.c b/openssl.c
index a875466..a9b685f 100644
--- a/openssl.c
+++ b/openssl.c
@@ -1435,6 +1435,8 @@ void openconnect_close_https(struct
openconnect_info *vpninfo, int final)
FD_CLR(vpninfo->ssl_fd, &vpninfo->select_efds);
vpninfo->ssl_fd = -1;
}
+ dtls_close(vpninfo, 1);
+ vpninfo->new_dtls_started = 0;
if (final) {
if (vpninfo->https_ctx) {
SSL_CTX_free(vpninfo->https_ctx);
More information about the openconnect-devel
mailing list