The current oNCP (Juniper) protocol support sets "Connection: close" in all
HTTP requests. This is not ideal because it requires many TLS handshakes
and round-trips, making the connection very slow to start when the latency
of the connection to the gateway is high, especially if the number of
authentication forms and redirects is large.
Simply removing the "Connection: close" header causes the oNCP connection
to fail; the server doesn't interpret the first packet sent over the oNCP
tunnel correctly (the vestigial authentication packet).
However, it appears that the "Connection: close" header *only* needs to be
specified for this final HTTP request, and not for any of the prior ones.
The presence of this header seems to signal to the gateway that it should
stop treating this as an HTTP connection, and start treating it as an
oNCP tunnel.
Tested on two different Juniper gateways, one which returns
"NCP-Version: 2" and one which returns "NCP-Version: 3" in response to
the oNCP negotiation requests.
Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
auth-juniper.c | 1 -
oncp.c | 14 ++++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/auth-juniper.c b/auth-juniper.c
index acd9c77..30ceb3a 100644
--- a/auth-juniper.c
+++ b/auth-juniper.c
@@ -47,7 +47,6 @@ void oncp_common_headers(struct openconnect_info *vpninfo, struct oc_text_buf *b
{
http_common_headers(vpninfo, buf);
- buf_append(buf, "Connection: close\r\n");
// buf_append(buf, "Content-Length: 256\r\n");
buf_append(buf, "NCP-Version: 3\r\n");
// buf_append(buf, "Accept-Encoding: gzip\r\n");
diff --git a/oncp.c b/oncp.c
index 6fa3333..a6a5b6b 100644
--- a/oncp.c
+++ b/oncp.c
@@ -560,6 +560,11 @@ int oncp_connect(struct openconnect_info *vpninfo)
reqbuf = buf_alloc();
buf_append(reqbuf, "POST /dana/js?prot=1&svc=1 HTTP/1.1\r\n");
+ /* Seems unnecessary because we always ignore the response body,
+ and close the connection anyway, but retained in case any
+ server depends on it. (See comments on second negotiation
+ request below. */
+ buf_append(reqbuf, "Connection: close\r\n");
oncp_common_headers(vpninfo, reqbuf);
buf_append(reqbuf, "Content-Length: 256\r\n");
buf_append(reqbuf, "\r\n");
@@ -571,6 +576,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
goto out;
}
+ vpn_progress(vpninfo, PRG_TRACE, _("Sending oNCP negotiation request #1\n"));
ret = vpninfo->ssl_write(vpninfo, reqbuf->data, reqbuf->pos);
if (ret < 0)
goto out;
@@ -605,6 +611,13 @@ int oncp_connect(struct openconnect_info *vpninfo)
buf_truncate(reqbuf);
buf_append(reqbuf, "POST /dana/js?prot=1&svc=4 HTTP/1.1\r\n");
+ /* The TLS socket actually remains open for use by the oNCP
+ tunnel, but the "Connection: close" header is nevertheless
+ required here. It appears to signal to the server to stop
+ treating this as an HTTP connection and to start treating
+ it as an oNCP connection.
+ */
+ buf_append(reqbuf, "Connection: close\r\n");
oncp_common_headers(vpninfo, reqbuf);
buf_append(reqbuf, "Content-Length: 256\r\n");
buf_append(reqbuf, "\r\n");
@@ -615,6 +628,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
ret = buf_error(reqbuf);
goto out;
}
+ vpn_progress(vpninfo, PRG_TRACE, _("Sending oNCP negotiation request #2\n"));
ret = vpninfo->ssl_write(vpninfo, reqbuf->data, reqbuf->pos);
if (ret < 0)
goto out;
--
2.7.4
