From abaire at irisa.fr  Thu Jun  7 05:15:27 2012
From: abaire at irisa.fr (Anthony Baire)
Date: Thu, 07 Jun 2012 11:15:27 +0200
Subject: [PATCH] accept multiple server fingerprints with --servercert
Message-ID: <4FD0712F.4090203@irisa.fr>

Hi,

I am sending a small patch to allow accepting multiple server 
fingerprints with the --servercert option. This is useful for 
configurations with redundant servers.

Signed-off-by: Anthony Baire <abaire at irisa.fr>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: servercert.patch
Type: text/x-patch
Size: 2533 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120607/54dfcce1/attachment.bin>

From dwmw2 at infradead.org  Thu Jun  7 09:15:29 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 07 Jun 2012 14:15:29 +0100
Subject: [PATCH] accept multiple server fingerprints with --servercert
In-Reply-To: <4FD0712F.4090203@irisa.fr>
References: <4FD0712F.4090203@irisa.fr>
Message-ID: <1339074929.26785.202.camel@shinybook.infradead.org>

On Thu, 2012-06-07 at 11:15 +0200, Anthony Baire wrote:
> 
> I am sending a small patch to allow accepting multiple server 
> fingerprints with the --servercert option. This is useful for 
> configurations with redundant servers.
> 
> Signed-off-by: Anthony Baire <abaire at irisa.fr>

Thanks... but I'm not sure this is the right approach.

The --servercert option is supposed to be used only for the final
connection, after you have already authentication in a GUI through
libopenconnect. Then we pass the cookie, the address of the final server
you ended up at *after* load balancing, and the cert fingerprint of
*that* server to openconnect.

If you want this for the general case of logging in from the command
line, and your servers' certificates aren't trusted by your normal CAs,
then surely you'd do better putting the appropriate CAs (or just the
servers' certs) into a --cafile?

If we really do end up needing something like this, maybe it could be a
new option '--accept-cert' which takes a hostname too, and you could put
them directly into the 'accepted_certs' list in main.c?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120607/33a5c17e/attachment.bin>

From dwmw2 at infradead.org  Thu Jun  7 10:40:18 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 07 Jun 2012 15:40:18 +0100
Subject: GnuTLS support in OpenConnect
In-Reply-To: <1338511899.11518.521.camel@shinybook.infradead.org>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
Message-ID: <1339080018.26785.213.camel@shinybook.infradead.org>

On Fri, 2012-06-01 at 01:51 +0100, David Woodhouse wrote:
> I've just pushed GnuTLS support for OpenConnect to the git repository.
> 
> This isn't entirely feature-complete yet. It doesn't support DTLS, and
> in fact it the openconnect executable doesn't build at all right now
> because it still uses the OpenSSL "UI" abstraction for user
> interaction. 

Both of those are now fixed. There's an experimental patch against the
GnuTLS 3.0 branch to provide Cisco-compatible DTLS support, at
http://david.woodhou.se/gnutls-cisco-dtls-working-2.patch

Thanks Nikos for your assistance and your patience.

I would appreciate some more widespread testing, and then I think we're
getting close to the point where we can release OpenConnect v4.00 with
GnuTLS support.

The main thing I have left to do is finish cleaning up the OpenSSL side
so that we *never* use the OpenSSL 'UI' abstraction to interact with the
user. That's already fixed for everything but the TPM PIN request.

I would also like to do some basic testing of PKCS#11 modules with
GnuTLS, and I'll need to set up the PIN request handling for that too.
Are there any simple PKCS#11 modules that we can use for testing? If I
could just have a trivial PKCS#11 module which is hard-coded with a
single certificate, and requests the PIN when I try to use it, that
would do nicely.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120607/63fbdbbf/attachment.bin>

From nmav at gnutls.org  Thu Jun  7 10:53:03 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 7 Jun 2012 16:53:03 +0200
Subject: GnuTLS support in OpenConnect
In-Reply-To: <1339080018.26785.213.camel@shinybook.infradead.org>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
Message-ID: <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>

On Thu, Jun 7, 2012 at 4:40 PM, David Woodhouse <dwmw2 at infradead.org> wrote:

>> I've just pushed GnuTLS support for OpenConnect to the git repository.
>> This isn't entirely feature-complete yet. It doesn't support DTLS, and
>> in fact it the openconnect executable doesn't build at all right now
>> because it still uses the OpenSSL "UI" abstraction for user
>> interaction.
> Both of those are now fixed. There's an experimental patch against the
> GnuTLS 3.0 branch to provide Cisco-compatible DTLS support, at
> http://david.woodhou.se/gnutls-cisco-dtls-working-2.patch

I'll include it in gnutls master.

> I would also like to do some basic testing of PKCS#11 modules with
> GnuTLS, and I'll need to set up the PIN request handling for that too.
> Are there any simple PKCS#11 modules that we can use for testing?

I use libopensc with some tokens and smart-cards I got from gooze.eu
(they give some for free to free software developers). You can also
try softhsm (though I've never tried it myself).

https://wiki.opendnssec.org/display/SoftHSMDOCS/SoftHSM+Documentation+Home

> If I could just have a trivial PKCS#11 module which is hard-coded with a
> single certificate, and requests the PIN when I try to use it, that
> would do nicely.

If you find something like that let me know, I'm also interested!

regards,
Nikos


From dwmw2 at infradead.org  Thu Jun  7 11:06:44 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 07 Jun 2012 16:06:44 +0100
Subject: GnuTLS support in OpenConnect
In-Reply-To: <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
 <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
Message-ID: <1339081604.26785.223.camel@shinybook.infradead.org>

On Thu, 2012-06-07 at 16:53 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Jun 7, 2012 at 4:40 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > http://david.woodhou.se/gnutls-cisco-dtls-working-2.patch
> 
> I'll include it in gnutls master.

Thanks.

> I use libopensc with some tokens and smart-cards I got from gooze.eu
> (they give some for free to free software developers). You can also
> try softhsm (though I've never tried it myself).
> 
> https://wiki.opendnssec.org/display/SoftHSMDOCS/SoftHSM+Documentation+Home

I do have a Gooze token somewhere; I'm just not sure entirely where :)
And I was trying to avoid getting bogged down in hardware dependencies
right now. SoftHSM looks interesting; I'll give that a try. Thanks.

There's also a TPM emulator, and at some point I'll probably try again
with Trousers and the PKCS#11 support for TPM.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120607/321fe0a8/attachment.bin>

From mtmiller at ieee.org  Thu Jun  7 11:58:30 2012
From: mtmiller at ieee.org (Mike Miller)
Date: Thu, 7 Jun 2012 11:58:30 -0400
Subject: [PATCH] Show correct path to vpnc-script in the man page
Message-ID: <20120607155830.GA1136@ohm.home.local>

Insert the actual path to vpnc-script that is compiled into the
openconnect executable.

Signed-off-by: Mike Miller <mtmiller at ieee.org>
---

The vpnc-script path is different from the default under Debian so I
patched the man page to refer to that path instead.  This is a more
generic version of that patch, hope you can use it.

 Makefile.am      |    2 +-
 configure.ac     |    3 +-
 openconnect.8    |  323 ------------------------------------------------------
 openconnect.8.in |  323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 326 insertions(+), 325 deletions(-)
 delete mode 100644 openconnect.8
 create mode 100644 openconnect.8.in

diff --git a/Makefile.am b/Makefile.am
index 62eaf1e..e9e24e2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -31,7 +31,7 @@ endif
 
 pkgconfig_DATA = openconnect.pc
 
-EXTRA_DIST = version.sh openconnect.8 COPYING.LGPL
+EXTRA_DIST = version.sh COPYING.LGPL
 
 DISTCLEANFILES = $(pkgconfig_DATA)
 
diff --git a/configure.ac b/configure.ac
index 61b21e3..c1bb531 100644
--- a/configure.ac
+++ b/configure.ac
@@ -53,6 +53,7 @@ elif test "$with_vpnc_script" = "no"; then
 fi
 
 AC_DEFINE_UNQUOTED(DEFAULT_VPNCSCRIPT, "${with_vpnc_script}")
+AC_SUBST(DEFAULT_VPNCSCRIPT, "${with_vpnc_script}")
 
 case $host_os in
  *linux* | *gnu*)
@@ -390,4 +391,4 @@ done
 AC_SUBST(GITVERSIONDEPS)
 
 AC_OUTPUT(Makefile openconnect.pc po/Makefile www/Makefile libopenconnect.map \
-	  www/styles/Makefile www/inc/Makefile www/images/Makefile)
+	  openconnect.8 www/styles/Makefile www/inc/Makefile www/images/Makefile)
diff --git a/openconnect.8 b/openconnect.8
deleted file mode 100644
index bb47b38..0000000
--- a/openconnect.8
+++ /dev/null
@@ -1,323 +0,0 @@
-.TH OPENCONNECT 8
-.SH NAME
-openconnect \- Connect to Cisco AnyConnect VPN
-.SH SYNOPSIS
-.SY openconnect
-.OP \-\-config configfile
-.OP \-b,\-\-background
-.OP \-\-pid\-file pidfile
-.OP \-c,\-\-certificate cert
-.OP \-e,\-\-cert\-expire\-warning days
-.OP \-k,\-\-sslkey key
-.OP \-K,\-\-key\-type type
-.OP \-C,\-\-cookie cookie
-.OP \-\-cookie\-on\-stdin
-.OP \-d,\-\-deflate
-.OP \-D,\-\-no\-deflate
-.OP \-\-force\-dpd interval
-.OP \-g,\-\-usergroup group
-.OP \-h,\-\-help
-.OP \-i,\-\-interface ifname
-.OP \-l,\-\-syslog
-.OP \-U,\-\-setuid user
-.OP \-\-csd\-user user
-.OP \-m,\-\-mtu mtu
-.OP \-p,\-\-key\-password pass
-.OP \-P,\-\-proxy proxyurl
-.OP \-\-no\-proxy
-.OP \-\-libproxy
-.OP \-\-key\-password\-from\-fsid
-.OP \-\-key\-type type
-.OP \-q,\-\-quiet
-.OP \-Q,\-\-queue\-len len
-.OP \-s,\-\-script vpnc\-script
-.OP \-S,\-\-script\-tun
-.OP \-u,\-\-user name
-.OP \-V,\-\-version
-.OP \-v,\-\-verbose
-.OP \-x,\-\-xmlconfig config
-.OP \-\-authgroup group
-.OP \-\-cookieonly
-.OP \-\-printcookie
-.OP \-\-cafile file
-.OP \-\-disable\-ipv6
-.OP \-\-dtls\-ciphers list
-.OP \-\-no\-cert\-check
-.OP \-\-no\-dtls
-.OP \-\-no\-http\-keepalive
-.OP \-\-no\-passwd
-.OP \-\-non\-inter
-.OP \-\-passwd\-on\-stdin
-.OP \-\-reconnect\-timeout
-.OP \-\-servercert sha1
-.OP \-\-useragent string
-.B [https://]\fIserver\fB[:\fIport\fB][/\fIgroup\fB]
-.YS
-
-.SH DESCRIPTION
-The program
-.B openconnect
-connects to Cisco "AnyConnect" VPN servers, which use standard TLS
-and DTLS protocols for data transport.
-
-The connection happens in two phases. First there is a simple HTTPS
-connection over which the user authenticates somehow \- by using a
-certificate, or password or SecurID, etc.  Having authenticated, the
-user is rewarded with an HTTP cookie which can be used to make the
-real VPN connection.
-
-The second phase uses that cookie in an HTTPS
-.I CONNECT
-request, and data packets can be passed over the resulting
-connection. In auxiliary headers exchanged with the
-.I CONNECT
-request, a Session\-ID and Master Secret for a DTLS connection are also
-exchanged, which allows data transport over UDP to occur.
-
-
-.SH OPTIONS
-.TP
-.B \-\-config=CONFIGFILE
-Read further options from
-.I CONFIGFILE
-before continuing to process options from the command line. The file
-should contain long-format options as would be accepted on the command line,
-but without the two leading \-\- dashes. Empty lines, or lines where the
-first non-space character is a # character, are ignored.
-
-Any option except the
-.B config
-option may be specified in the file.
-.TP
-.B \-b,\-\-background
-Continue in background after startup
-.TP
-.B \-\-pid\-file=PIDFILE
-Save the pid to
-.I PIDFILE
-when backgrounding
-.TP
-.B \-c,\-\-certificate=CERT
-Use SSL client certificate
-.I CERT
-.TP
-.B \-e,\-\-cert\-expire\-warning=DAYS
-Give a warning when SSL client certificate has
-.I DAYS
-left before expiry
-.TP
-.B \-k,\-\-sslkey=KEY
-Use SSL private key file
-.I KEY
-.TP
-.B \-C,\-\-cookie=COOKIE
-Use WebVPN cookie
-.I COOKIE
-.TP
-.B \-\-cookie\-on\-stdin
-Read cookie from standard input
-.TP
-.B \-d,\-\-deflate
-Enable compression (default)
-.TP
-.B \-D,\-\-no\-deflate
-Disable compression
-.TP
-.B \-\-force\-dpd=INTERVAL
-Use
-.I INTERVAL
-as minimum Dead Peer Detection interval for CSTP and DTLS, forcing use of DPD even when the server doesn't request it.
-.TP
-.B \-g,\-\-usergroup=GROUP
-Use
-.I GROUP
-as login UserGroup
-.TP
-.B \-h,\-\-help
-Display help text
-.TP
-.B \-i,\-\-interface=IFNAME
-Use
-.I IFNAME
-for tunnel interface
-.TP
-.B \-l,\-\-syslog
-Use syslog for progress messages
-.TP
-.B \-U,\-\-setuid=USER
-Drop privileges after connecting, to become user
-.I USER
-.TP
-.B \-\-csd\-user=USER
-Drop privileges during CSD (Cisco Secure Desktop) script execution.
-.TP
-.B \-\-csd\-wrapper=SCRIPT
-Run
-.I SCRIPT
-instead of the CSD (Cisco Secure Desktop) script.
-.TP
-.B \-m,\-\-mtu=MTU
-Request
-.I MTU
-from server
-.TP
-.B \-p,\-\-key\-password=PASS
-Provide passphrase for certificate file, or SRK (System Root Key) PIN for TPM
-.TP
-.B \-P,\-\-proxy=PROXYURL
-Use HTTP or SOCKS proxy for connection
-.TP
-.B \-\-no\-proxy
-Disable use of proxy
-.TP
-.B \-\-libproxy
-Use libproxy to configure proxy automatically (when built with libproxy support)
-.TP
-.B \-\-key\-password\-from\-fsid
-Passphrase for certificate file is automatically generated from the
-.I fsid
-of the file system on which it is stored. The
-.I fsid
-is obtained from the 
-.BR statvfs (2)
-or
-.BR statfs (2)
-system call, depending on the operating system. On a Linux or similar system
-with GNU coreutils, the
-.I fsid
-used by this option should be equal to the output of the command:
-.EX
-stat \-\-file\-system \-\-printf=%i\e\en $CERTIFICATE
-.EE
-It is not the same as the 128\-bit UUID of the file system.
-.TP
-.B \-\-key\-type=TYPE
-Type of private key file (PKCS#12, TPM or PEM)
-.TP
-.B \-q,\-\-quiet
-Less output
-.TP
-.B \-Q,\-\-queue\-len=LEN
-Set packet queue limit to
-.I LEN
-pkts
-.TP
-.B \-s,\-\-script=SCRIPT
-Invoke
-.I SCRIPT
-to configure the network after connection. Without this, routing and name
-service are unlikely to work correctly. The script is expected to be
-compatible with the
-.B vpnc\-script
-which is shipped with the "vpnc" VPN client. See
-.I http://www.infradead.org/openconnect/vpnc-script.html
-for more information. Unless OpenConnect was built in a non-standard way,
-the default is
-.B /etc/vpnc/vpnc-script
-.TP
-.B \-S,\-\-script\-tun
-Pass traffic to 'script' program over a UNIX socket, instead of to a kernel
-tun/tap device. This allows the VPN IP traffic to be handled entirely in
-userspace, for example by a program which uses lwIP to provide SOCKS access
-into the VPN.
-.TP
-.B \-u,\-\-user=NAME
-Set login username to
-.I NAME
-.TP
-.B \-V,\-\-version
-Report version number
-.TP
-.B \-v,\-\-verbose
-More output
-.TP
-.B \-x,\-\-xmlconfig=CONFIG
-XML config file
-.TP
-.B \-\-authgroup=GROUP
-Choose authentication login selection
-.TP
-.B \-\-cookieonly
-Fetch webvpn cookie only; don't connect
-.TP
-.B \-\-printcookie
-Print webvpn cookie before connecting
-.TP
-.B \-\-cafile=FILE
-Cert file for server verification
-.TP
-.B \-\-disable\-ipv6
-Do not advertise IPv6 capability to server
-.TP
-.B \-\-dtls\-ciphers=LIST
-Set OpenSSL ciphers to support for DTLS
-.TP
-.B \-\-no\-cert\-check
-Do not require server SSL certificate to be valid. Checks will still happen
-and failures will cause a warning message, but the connection will continue
-anyway. You should not need to use this option \- if your servers have SSL
-certificates which are not signed by a trusted Certificate Authority, you can
-still add them (or your private CA) to a local file and use that file with the
-.B \-\-cafile
-option.
-
-.TP
-.B \-\-no\-dtls
-Disable DTLS
-.TP
-.B \-\-no\-http\-keepalive
-Version 8.2.2.5 of the Cisco ASA software has a bug where it will forget
-the client's SSL certificate when HTTP connections are being re\-used for
-multiple requests. So far, this has only been seen on the initial connection,
-where the server gives an HTTP/1.0 redirect response with an explicit
-.B Connection: Keep\-Alive
-directive. OpenConnect as of v2.22 has an unconditional workaround for this,
-which is never to obey that directive after an HTTP/1.0 response.
-
-However, Cisco's support team has failed to give any competent
-response to the bug report and we don't know under what other
-circumstances their bug might manifest itself. So this option exists
-to disable ALL re\-use of HTTP sessions and cause a new connection to be
-made for each request. If your server seems not to be recognising your
-certificate, try this option. If it makes a difference, please report
-this information to the
-.B openconnect\-devel at lists.infradead.org
-mailing list.
-.TP
-.B \-\-no\-passwd
-Never attempt password (or SecurID) authentication.
-.TP
-.B \-\-non\-inter
-Do not expect user input; exit if it is required.
-.TP
-.B \-\-passwd\-on\-stdin
-Read password from standard input
-.TP
-.B \-\-reconnect\-timeout
-Keep reconnect attempts until so much seconds are elapsed. The default
-timeout is 300 seconds, which means that openconnect can recover
-VPN connection after a temporary network down time of 300 seconds.
-.TP
-.B \-\-servercert=SHA1
-Accept server's SSL certificate only if its fingerprint matches
-.IR SHA1 .
-.TP
-.B \-\-useragent=STRING
-Use
-.I STRING
-as 'User\-Agent:' field value in HTTP header.
-(e.g. \-\-useragent 'Cisco AnyConnect VPN Agent for Windows 2.2.0133')
-
-.SH LIMITATIONS
-Note that although IPv6 has been tested on all platforms on which
-.B openconnect
-is known to run, it depends on a suitable
-.B vpnc\-script
-to configure the network. The standard
-.B vpnc\-script
-shipped with vpnc 0.5.3 is not capable of setting up IPv6 routes; the one from
-.B git://git.infradead.org/users/dwmw2/vpnc\-scripts.git
-will be required.
-
-.SH AUTHORS
-David Woodhouse <dwmw2 at infradead.org>
diff --git a/openconnect.8.in b/openconnect.8.in
new file mode 100644
index 0000000..97b183e
--- /dev/null
+++ b/openconnect.8.in
@@ -0,0 +1,323 @@
+.TH OPENCONNECT 8
+.SH NAME
+openconnect \- Connect to Cisco AnyConnect VPN
+.SH SYNOPSIS
+.SY openconnect
+.OP \-\-config configfile
+.OP \-b,\-\-background
+.OP \-\-pid\-file pidfile
+.OP \-c,\-\-certificate cert
+.OP \-e,\-\-cert\-expire\-warning days
+.OP \-k,\-\-sslkey key
+.OP \-K,\-\-key\-type type
+.OP \-C,\-\-cookie cookie
+.OP \-\-cookie\-on\-stdin
+.OP \-d,\-\-deflate
+.OP \-D,\-\-no\-deflate
+.OP \-\-force\-dpd interval
+.OP \-g,\-\-usergroup group
+.OP \-h,\-\-help
+.OP \-i,\-\-interface ifname
+.OP \-l,\-\-syslog
+.OP \-U,\-\-setuid user
+.OP \-\-csd\-user user
+.OP \-m,\-\-mtu mtu
+.OP \-p,\-\-key\-password pass
+.OP \-P,\-\-proxy proxyurl
+.OP \-\-no\-proxy
+.OP \-\-libproxy
+.OP \-\-key\-password\-from\-fsid
+.OP \-\-key\-type type
+.OP \-q,\-\-quiet
+.OP \-Q,\-\-queue\-len len
+.OP \-s,\-\-script vpnc\-script
+.OP \-S,\-\-script\-tun
+.OP \-u,\-\-user name
+.OP \-V,\-\-version
+.OP \-v,\-\-verbose
+.OP \-x,\-\-xmlconfig config
+.OP \-\-authgroup group
+.OP \-\-cookieonly
+.OP \-\-printcookie
+.OP \-\-cafile file
+.OP \-\-disable\-ipv6
+.OP \-\-dtls\-ciphers list
+.OP \-\-no\-cert\-check
+.OP \-\-no\-dtls
+.OP \-\-no\-http\-keepalive
+.OP \-\-no\-passwd
+.OP \-\-non\-inter
+.OP \-\-passwd\-on\-stdin
+.OP \-\-reconnect\-timeout
+.OP \-\-servercert sha1
+.OP \-\-useragent string
+.B [https://]\fIserver\fB[:\fIport\fB][/\fIgroup\fB]
+.YS
+
+.SH DESCRIPTION
+The program
+.B openconnect
+connects to Cisco "AnyConnect" VPN servers, which use standard TLS
+and DTLS protocols for data transport.
+
+The connection happens in two phases. First there is a simple HTTPS
+connection over which the user authenticates somehow \- by using a
+certificate, or password or SecurID, etc.  Having authenticated, the
+user is rewarded with an HTTP cookie which can be used to make the
+real VPN connection.
+
+The second phase uses that cookie in an HTTPS
+.I CONNECT
+request, and data packets can be passed over the resulting
+connection. In auxiliary headers exchanged with the
+.I CONNECT
+request, a Session\-ID and Master Secret for a DTLS connection are also
+exchanged, which allows data transport over UDP to occur.
+
+
+.SH OPTIONS
+.TP
+.B \-\-config=CONFIGFILE
+Read further options from
+.I CONFIGFILE
+before continuing to process options from the command line. The file
+should contain long-format options as would be accepted on the command line,
+but without the two leading \-\- dashes. Empty lines, or lines where the
+first non-space character is a # character, are ignored.
+
+Any option except the
+.B config
+option may be specified in the file.
+.TP
+.B \-b,\-\-background
+Continue in background after startup
+.TP
+.B \-\-pid\-file=PIDFILE
+Save the pid to
+.I PIDFILE
+when backgrounding
+.TP
+.B \-c,\-\-certificate=CERT
+Use SSL client certificate
+.I CERT
+.TP
+.B \-e,\-\-cert\-expire\-warning=DAYS
+Give a warning when SSL client certificate has
+.I DAYS
+left before expiry
+.TP
+.B \-k,\-\-sslkey=KEY
+Use SSL private key file
+.I KEY
+.TP
+.B \-C,\-\-cookie=COOKIE
+Use WebVPN cookie
+.I COOKIE
+.TP
+.B \-\-cookie\-on\-stdin
+Read cookie from standard input
+.TP
+.B \-d,\-\-deflate
+Enable compression (default)
+.TP
+.B \-D,\-\-no\-deflate
+Disable compression
+.TP
+.B \-\-force\-dpd=INTERVAL
+Use
+.I INTERVAL
+as minimum Dead Peer Detection interval for CSTP and DTLS, forcing use of DPD even when the server doesn't request it.
+.TP
+.B \-g,\-\-usergroup=GROUP
+Use
+.I GROUP
+as login UserGroup
+.TP
+.B \-h,\-\-help
+Display help text
+.TP
+.B \-i,\-\-interface=IFNAME
+Use
+.I IFNAME
+for tunnel interface
+.TP
+.B \-l,\-\-syslog
+Use syslog for progress messages
+.TP
+.B \-U,\-\-setuid=USER
+Drop privileges after connecting, to become user
+.I USER
+.TP
+.B \-\-csd\-user=USER
+Drop privileges during CSD (Cisco Secure Desktop) script execution.
+.TP
+.B \-\-csd\-wrapper=SCRIPT
+Run
+.I SCRIPT
+instead of the CSD (Cisco Secure Desktop) script.
+.TP
+.B \-m,\-\-mtu=MTU
+Request
+.I MTU
+from server
+.TP
+.B \-p,\-\-key\-password=PASS
+Provide passphrase for certificate file, or SRK (System Root Key) PIN for TPM
+.TP
+.B \-P,\-\-proxy=PROXYURL
+Use HTTP or SOCKS proxy for connection
+.TP
+.B \-\-no\-proxy
+Disable use of proxy
+.TP
+.B \-\-libproxy
+Use libproxy to configure proxy automatically (when built with libproxy support)
+.TP
+.B \-\-key\-password\-from\-fsid
+Passphrase for certificate file is automatically generated from the
+.I fsid
+of the file system on which it is stored. The
+.I fsid
+is obtained from the 
+.BR statvfs (2)
+or
+.BR statfs (2)
+system call, depending on the operating system. On a Linux or similar system
+with GNU coreutils, the
+.I fsid
+used by this option should be equal to the output of the command:
+.EX
+stat \-\-file\-system \-\-printf=%i\e\en $CERTIFICATE
+.EE
+It is not the same as the 128\-bit UUID of the file system.
+.TP
+.B \-\-key\-type=TYPE
+Type of private key file (PKCS#12, TPM or PEM)
+.TP
+.B \-q,\-\-quiet
+Less output
+.TP
+.B \-Q,\-\-queue\-len=LEN
+Set packet queue limit to
+.I LEN
+pkts
+.TP
+.B \-s,\-\-script=SCRIPT
+Invoke
+.I SCRIPT
+to configure the network after connection. Without this, routing and name
+service are unlikely to work correctly. The script is expected to be
+compatible with the
+.B vpnc\-script
+which is shipped with the "vpnc" VPN client. See
+.I http://www.infradead.org/openconnect/vpnc-script.html
+for more information. This version of OpenConnect is configured to use
+.B @DEFAULT_VPNCSCRIPT@
+by default.
+.TP
+.B \-S,\-\-script\-tun
+Pass traffic to 'script' program over a UNIX socket, instead of to a kernel
+tun/tap device. This allows the VPN IP traffic to be handled entirely in
+userspace, for example by a program which uses lwIP to provide SOCKS access
+into the VPN.
+.TP
+.B \-u,\-\-user=NAME
+Set login username to
+.I NAME
+.TP
+.B \-V,\-\-version
+Report version number
+.TP
+.B \-v,\-\-verbose
+More output
+.TP
+.B \-x,\-\-xmlconfig=CONFIG
+XML config file
+.TP
+.B \-\-authgroup=GROUP
+Choose authentication login selection
+.TP
+.B \-\-cookieonly
+Fetch webvpn cookie only; don't connect
+.TP
+.B \-\-printcookie
+Print webvpn cookie before connecting
+.TP
+.B \-\-cafile=FILE
+Cert file for server verification
+.TP
+.B \-\-disable\-ipv6
+Do not advertise IPv6 capability to server
+.TP
+.B \-\-dtls\-ciphers=LIST
+Set OpenSSL ciphers to support for DTLS
+.TP
+.B \-\-no\-cert\-check
+Do not require server SSL certificate to be valid. Checks will still happen
+and failures will cause a warning message, but the connection will continue
+anyway. You should not need to use this option \- if your servers have SSL
+certificates which are not signed by a trusted Certificate Authority, you can
+still add them (or your private CA) to a local file and use that file with the
+.B \-\-cafile
+option.
+
+.TP
+.B \-\-no\-dtls
+Disable DTLS
+.TP
+.B \-\-no\-http\-keepalive
+Version 8.2.2.5 of the Cisco ASA software has a bug where it will forget
+the client's SSL certificate when HTTP connections are being re\-used for
+multiple requests. So far, this has only been seen on the initial connection,
+where the server gives an HTTP/1.0 redirect response with an explicit
+.B Connection: Keep\-Alive
+directive. OpenConnect as of v2.22 has an unconditional workaround for this,
+which is never to obey that directive after an HTTP/1.0 response.
+
+However, Cisco's support team has failed to give any competent
+response to the bug report and we don't know under what other
+circumstances their bug might manifest itself. So this option exists
+to disable ALL re\-use of HTTP sessions and cause a new connection to be
+made for each request. If your server seems not to be recognising your
+certificate, try this option. If it makes a difference, please report
+this information to the
+.B openconnect\-devel at lists.infradead.org
+mailing list.
+.TP
+.B \-\-no\-passwd
+Never attempt password (or SecurID) authentication.
+.TP
+.B \-\-non\-inter
+Do not expect user input; exit if it is required.
+.TP
+.B \-\-passwd\-on\-stdin
+Read password from standard input
+.TP
+.B \-\-reconnect\-timeout
+Keep reconnect attempts until so much seconds are elapsed. The default
+timeout is 300 seconds, which means that openconnect can recover
+VPN connection after a temporary network down time of 300 seconds.
+.TP
+.B \-\-servercert=SHA1
+Accept server's SSL certificate only if its fingerprint matches
+.IR SHA1 .
+.TP
+.B \-\-useragent=STRING
+Use
+.I STRING
+as 'User\-Agent:' field value in HTTP header.
+(e.g. \-\-useragent 'Cisco AnyConnect VPN Agent for Windows 2.2.0133')
+
+.SH LIMITATIONS
+Note that although IPv6 has been tested on all platforms on which
+.B openconnect
+is known to run, it depends on a suitable
+.B vpnc\-script
+to configure the network. The standard
+.B vpnc\-script
+shipped with vpnc 0.5.3 is not capable of setting up IPv6 routes; the one from
+.B git://git.infradead.org/users/dwmw2/vpnc\-scripts.git
+will be required.
+
+.SH AUTHORS
+David Woodhouse <dwmw2 at infradead.org>
-- 
1.7.10


From mtmiller at ieee.org  Thu Jun  7 12:04:52 2012
From: mtmiller at ieee.org (Mike Miller)
Date: Thu, 7 Jun 2012 12:04:52 -0400
Subject: [PATCH] Show correct path to vpnc-script in the man page
Message-ID: <20120607160452.GA1409@ohm.home.local>

Insert the actual path to vpnc-script that is compiled into the
openconnect executable.

Signed-off-by: Mike Miller <mtmiller at ieee.org>
---

Sorry, here's a more readable version of the patch I just sent...

 Makefile.am                       |    2 +-
 configure.ac                      |    3 ++-
 openconnect.8 => openconnect.8.in |    6 +++---
 3 files changed, 6 insertions(+), 5 deletions(-)
 rename openconnect.8 => openconnect.8.in (98%)

diff --git a/Makefile.am b/Makefile.am
index 62eaf1e..e9e24e2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -31,7 +31,7 @@ endif
 
 pkgconfig_DATA = openconnect.pc
 
-EXTRA_DIST = version.sh openconnect.8 COPYING.LGPL
+EXTRA_DIST = version.sh COPYING.LGPL
 
 DISTCLEANFILES = $(pkgconfig_DATA)
 
diff --git a/configure.ac b/configure.ac
index 61b21e3..c1bb531 100644
--- a/configure.ac
+++ b/configure.ac
@@ -53,6 +53,7 @@ elif test "$with_vpnc_script" = "no"; then
 fi
 
 AC_DEFINE_UNQUOTED(DEFAULT_VPNCSCRIPT, "${with_vpnc_script}")
+AC_SUBST(DEFAULT_VPNCSCRIPT, "${with_vpnc_script}")
 
 case $host_os in
  *linux* | *gnu*)
@@ -390,4 +391,4 @@ done
 AC_SUBST(GITVERSIONDEPS)
 
 AC_OUTPUT(Makefile openconnect.pc po/Makefile www/Makefile libopenconnect.map \
-	  www/styles/Makefile www/inc/Makefile www/images/Makefile)
+	  openconnect.8 www/styles/Makefile www/inc/Makefile www/images/Makefile)
diff --git a/openconnect.8 b/openconnect.8.in
similarity index 98%
rename from openconnect.8
rename to openconnect.8.in
index bb47b38..97b183e 100644
--- a/openconnect.8
+++ b/openconnect.8.in
@@ -211,9 +211,9 @@ compatible with the
 .B vpnc\-script
 which is shipped with the "vpnc" VPN client. See
 .I http://www.infradead.org/openconnect/vpnc-script.html
-for more information. Unless OpenConnect was built in a non-standard way,
-the default is
-.B /etc/vpnc/vpnc-script
+for more information. This version of OpenConnect is configured to use
+.B @DEFAULT_VPNCSCRIPT@
+by default.
 .TP
 .B \-S,\-\-script\-tun
 Pass traffic to 'script' program over a UNIX socket, instead of to a kernel
-- 
1.7.10


From dwmw2 at infradead.org  Thu Jun  7 13:33:38 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 07 Jun 2012 18:33:38 +0100
Subject: [PATCH] Show correct path to vpnc-script in the man page
In-Reply-To: <20120607160452.GA1409@ohm.home.local>
References: <20120607160452.GA1409@ohm.home.local>
Message-ID: <1339090418.26785.230.camel@shinybook.infradead.org>

On Thu, 2012-06-07 at 12:04 -0400, Mike Miller wrote:
> Insert the actual path to vpnc-script that is compiled into the
> openconnect executable.
> 
> Signed-off-by: Mike Miller <mtmiller at ieee.org> 

Fixed to not break the out-of-source-tree build (see www/Makefile.am)
and applied. Thanks.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120607/819f87fe/attachment.bin>

From dwmw2 at infradead.org  Fri Jun  8 08:02:19 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jun 2012 13:02:19 +0100
Subject: pMTU discovery
In-Reply-To: <4FC73D74.4080100@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
Message-ID: <1339156939.13998.29.camel@i7.infradead.org>

On Thu, 2012-05-31 at 11:44 +0200, Bernhard Schmidt wrote:
> we're currently testing OpenConnect 3.20 against our new shiny ASA Beta 
> which finally does IPv6 transport. However, when we do use that, we have 
> MTU problems on the link. The official AnyConnect client works fine.

It'd be very interesting to know where the Cisco client gets its numbers
from. How does this compare?

diff --git a/cstp.c b/cstp.c
index dbc24b9..5910940 100644
--- a/cstp.c
+++ b/cstp.c
@@ -32,6 +32,9 @@
 #include <errno.h>
 #include <stdlib.h>
 #include <stdio.h>
+#include <netinet/tcp.h>
+#include <sys/types.h>
+#include <sys/socket.h>
 
 #include <openssl/ssl.h>
 #include <openssl/err.h>
@@ -86,6 +89,48 @@ static int  __attribute__ ((format (printf, 3, 4)))
 	return ret;
 }
 
+static void calculate_mtu(struct openconnect_info *vpninfo, int *base_mtu, int *mtu)
+{
+#ifdef TCP_MAXSEG
+	int mss;
+	socklen_t mss_size = sizeof(mss);
+#endif
+#ifdef TCP_INFO
+	struct tcp_info ti;
+	socklen_t ti_size = sizeof(ti);
+#endif
+	if (vpninfo->mtu) {
+		/* User override */
+		*base_mtu = 0;
+		*mtu = vpninfo->mtu;
+	}
+#ifdef TCP_INFO
+	else if (!getsockopt(vpninfo->ssl_fd, SOL_TCP, TCP_INFO, &ti, &ti_size)) {
+		vpn_progress(vpninfo, PRG_TRACE,
+			     _("TCP_INFO rcv mss %d, snd mss %d, adv mss %d, pmtu %d\n"),
+			     ti.tcpi_rcv_mss, ti.tcpi_snd_mss, ti.tcpi_advmss, ti.tcpi_pmtu);
+		*base_mtu = ti.tcpi_pmtu;
+		if (ti.tcpi_rcv_mss < ti.tcpi_snd_mss)
+			*mtu = ti.tcpi_rcv_mss;
+		else
+			*mtu = ti.tcpi_snd_mss;
+	}
+#endif
+#ifdef TCP_MAXSEG
+	else if (!getsockopt(vpninfo->ssl_fd, SOL_TCP, TCP_MAXSEG, &mss, &mss_size)) {
+		vpn_progress(vpninfo, PRG_TRACE, _("TCP_MAXSEG %d\n"), mss);
+		*mtu = mss;
+		/* Erm, how do we sanely find the base MTU? */
+		*base_mtu = 1500;
+	}
+#endif
+	else {
+		/* Default */
+		*base_mtu = 0;
+		*mtu = 1406;
+	}
+}
+
 static int start_cstp_connection(struct openconnect_info *vpninfo)
 {
 	char buf[65536];
@@ -100,6 +145,7 @@ static int start_cstp_connection(struct openconnect_info *vpninfo)
 	const char *old_addr6 = vpninfo->vpn_addr6;
 	const char *old_netmask6 = vpninfo->vpn_netmask6;
 	struct split_include *inc;
+	int base_mtu, mtu;
 
 	/* Clear old options which will be overwritten */
 	vpninfo->vpn_addr = vpninfo->vpn_netmask = NULL;
@@ -132,6 +178,8 @@ static int start_cstp_connection(struct openconnect_info *vpninfo)
 	}
 
  retry:
+	calculate_mtu(vpninfo, &base_mtu, &mtu);
+
 	buf[0] = 0;
 	buf_append(buf, sizeof(buf), "CONNECT /CSCOSSLC/tunnel HTTP/1.1\r\n");
 	buf_append(buf, sizeof(buf), "Host: %s\r\n", vpninfo->hostname);
@@ -141,7 +189,9 @@ static int start_cstp_connection(struct openconnect_info *vpninfo)
 	buf_append(buf, sizeof(buf), "X-CSTP-Hostname: %s\r\n", vpninfo->localname);
 	if (vpninfo->deflate && i < sizeof(buf))
 		buf_append(buf, sizeof(buf), "X-CSTP-Accept-Encoding: deflate;q=1.0\r\n");
-	buf_append(buf, sizeof(buf), "X-CSTP-MTU: %d\r\n", vpninfo->mtu);
+	if (base_mtu)
+		buf_append(buf, sizeof(buf), "X-CSTP-Base-MTU: %d\r\n", base_mtu);
+	buf_append(buf, sizeof(buf), "X-CSTP-MTU: %d\r\n", mtu);
 	buf_append(buf, sizeof(buf), "X-CSTP-Address-Type: %s\r\n",
 			       vpninfo->disable_ipv6?"IPv4":"IPv6,IPv4");
 	buf_append(buf, sizeof(buf), "X-DTLS-Master-Secret: ");
diff --git a/main.c b/main.c
index 6f7f86c..9f52ed1 100644
--- a/main.c
+++ b/main.c
@@ -412,7 +412,7 @@ int main(int argc, char **argv)
 	/* Set up some defaults */
 	vpninfo->tun_fd = vpninfo->ssl_fd = vpninfo->dtls_fd = vpninfo->new_dtls_fd = -1;
 	vpninfo->useragent = openconnect_create_useragent("Open AnyConnect VPN Agent");
-	vpninfo->mtu = 1406;
+	vpninfo->mtu = 0;
 	vpninfo->deflate = 1;
 	vpninfo->dtls_attempt_period = 60;
 	vpninfo->max_qlen = 10;

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120608/00ab415f/attachment.bin>

From berni at birkenwald.de  Fri Jun  8 12:37:46 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 08 Jun 2012 18:37:46 +0200
Subject: pMTU discovery
In-Reply-To: <1339156939.13998.29.camel@i7.infradead.org>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
Message-ID: <4FD22A5A.3060409@birkenwald.de>

On 08.06.2012 14:02, David Woodhouse wrote:

Hello David,

>> we're currently testing OpenConnect 3.20 against our new shiny ASA Beta
>> which finally does IPv6 transport. However, when we do use that, we have
>> MTU problems on the link. The official AnyConnect client works fine.
>
> It'd be very interesting to know where the Cisco client gets its numbers
> from. How does this compare?

Since that patch doesn't apply to 3.20 I tried HEAD, but it fails to 
compile.

make[2]: Leaving directory `/tmp/buildd/openconnect-3.20+git20120608.1/po'
make[2]: Entering directory `/tmp/buildd/openconnect-3.20+git20120608.1'
   CC     libopenconnect_la-version.lo
   CC     libopenconnect_la-ssl.lo
   CC     libopenconnect_la-http.lo
   CC     libopenconnect_la-auth.lo
   CC     libopenconnect_la-library.lo
   CC     libopenconnect_la-compat.lo
   CC     libopenconnect_la-openssl.lo
   CCLD   libopenconnect.la
   CC     openconnect-xml.o
   CC     openconnect-main.o
main.c: In function 'main':
main.c:400:123: error: 'openconnect_binary_version' undeclared (first 
use in this function)
main.c:400:123: note: each undeclared identifier is reported only once 
for each function it appears in
main.c:400:266: warning: left-hand operand of comma expression has no 
effect [-Wunused-value]
main.c:400:1985: warning: left-hand operand of comma expression has no 
effect [-Wunused-value]
make[2]: *** [openconnect-main.o] Error 1
make[2]: Leaving directory `/tmp/buildd/openconnect-3.20+git20120608.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/buildd/openconnect-3.20+git20120608.1'
dh_auto_build: make -j1 returned exit code 2


Bernhard


From berni at birkenwald.de  Fri Jun  8 12:47:22 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 08 Jun 2012 18:47:22 +0200
Subject: pMTU discovery
In-Reply-To: <4FD22A5A.3060409@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org> <4FD22A5A.3060409@birkenwald.de>
Message-ID: <4FD22C9A.40701@birkenwald.de>

On 08.06.2012 18:37, Bernhard Schmidt wrote:
> On 08.06.2012 14:02, David Woodhouse wrote:
>
> Hello David,
>
>>> we're currently testing OpenConnect 3.20 against our new shiny ASA Beta
>>> which finally does IPv6 transport. However, when we do use that, we have
>>> MTU problems on the link. The official AnyConnect client works fine.
>>
>> It'd be very interesting to know where the Cisco client gets its numbers
>> from. How does this compare?
>
> Since that patch doesn't apply to 3.20 I tried HEAD, but it fails to
> compile.

PEBKAC, I was just being stupid. Compiled fine, will test right away.

Bernhard


From dwmw2 at infradead.org  Fri Jun  8 13:04:13 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jun 2012 18:04:13 +0100
Subject: pMTU discovery
In-Reply-To: <4FD22C9A.40701@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
 <4FD22A5A.3060409@birkenwald.de> <4FD22C9A.40701@birkenwald.de>
Message-ID: <1339175053.16559.15.camel@i7.infradead.org>

On Fri, 2012-06-08 at 18:47 +0200, Bernhard Schmidt wrote:
> PEBKAC, I was just being stupid. Compiled fine, will test right away.

You'll have noticed that I have already committed an updated version...
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/e2c36e363

It may need fine-tuning, but it's probably an improvement on what we
currently have.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120608/cf067353/attachment.bin>

From berni at birkenwald.de  Fri Jun  8 13:05:46 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 08 Jun 2012 19:05:46 +0200
Subject: pMTU discovery
In-Reply-To: <4FD22C9A.40701@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org> <4FD22A5A.3060409@birkenwald.de>
 <4FD22C9A.40701@birkenwald.de>
Message-ID: <4FD230EA.70905@birkenwald.de>

On 08.06.2012 18:47, Bernhard Schmidt wrote:

> PEBKAC, I was just being stupid. Compiled fine, will test right away.

It basically works, but I think you are using the wrong MTU value. I'm 
currently in an IPv4-only non-MTU-challenged location. Cisco Anyconnect 
client connects with 1418 bytes MTU, openconnect with 1315. I'm not 
exactly sure what the difference between X-DTLS-MTU and D-CSTP-MTU is 
supposed to be, but the tunnel should be able to transport the larger value.

TCP_INFO rcv mss 1348, snd mss 1348, adv mss 1448, pmtu 1500
[...]
X-CSTP-MTU: 1315
X-DTLS-MTU: 1418
DTLS option X-DTLS-MTU : 1418

I'll try MTU challenged (DSL) and native IPv6 transport either tonight 
or during the weekend.

Bernhard


From berni at birkenwald.de  Fri Jun  8 13:09:24 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 08 Jun 2012 19:09:24 +0200
Subject: pMTU discovery
In-Reply-To: <1339175053.16559.15.camel@i7.infradead.org>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org> <4FD22A5A.3060409@birkenwald.de>
 <4FD22C9A.40701@birkenwald.de> <1339175053.16559.15.camel@i7.infradead.org>
Message-ID: <4FD231C4.1040604@birkenwald.de>

On 08.06.2012 19:04, David Woodhouse wrote:
> On Fri, 2012-06-08 at 18:47 +0200, Bernhard Schmidt wrote:
>> PEBKAC, I was just being stupid. Compiled fine, will test right away.
>
> You'll have noticed that I have already committed an updated version...
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/e2c36e363

Yes, my latest results have been done with a plain git HEAD (up towards 
a12d91b).

Bernhard


From dwmw2 at infradead.org  Fri Jun  8 13:09:49 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jun 2012 18:09:49 +0100
Subject: pMTU discovery
In-Reply-To: <4FD230EA.70905@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
 <4FD22A5A.3060409@birkenwald.de> <4FD22C9A.40701@birkenwald.de>
 <4FD230EA.70905@birkenwald.de>
Message-ID: <1339175389.16559.17.camel@i7.infradead.org>

On Fri, 2012-06-08 at 19:05 +0200, Bernhard Schmidt wrote:
> It basically works, but I think you are using the wrong MTU value. I'm 
> currently in an IPv4-only non-MTU-challenged location. Cisco Anyconnect 
> client connects with 1418 bytes MTU, openconnect with 1315. I'm not 
> exactly sure what the difference between X-DTLS-MTU and D-CSTP-MTU is 
> supposed to be, but the tunnel should be able to transport the larger value.
> 
> TCP_INFO rcv mss 1348, snd mss 1348, adv mss 1448, pmtu 1500 

Hm, so we should be sending X-CSTP-MTU: 1335, X-CSTP-Base-MTU: 1500.

What is the Cisco client sending? And can you see the debug output from
the server, like you sent in your first message?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120608/17b06873/attachment-0001.bin>

From berni at birkenwald.de  Fri Jun  8 13:13:39 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 08 Jun 2012 19:13:39 +0200
Subject: pMTU discovery
In-Reply-To: <1339175389.16559.17.camel@i7.infradead.org>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org> <4FD22A5A.3060409@birkenwald.de>
 <4FD22C9A.40701@birkenwald.de> <4FD230EA.70905@birkenwald.de>
 <1339175389.16559.17.camel@i7.infradead.org>
Message-ID: <4FD232C3.5070400@birkenwald.de>

On 08.06.2012 19:09, David Woodhouse wrote:
> On Fri, 2012-06-08 at 19:05 +0200, Bernhard Schmidt wrote:
>> It basically works, but I think you are using the wrong MTU value. I'm
>> currently in an IPv4-only non-MTU-challenged location. Cisco Anyconnect
>> client connects with 1418 bytes MTU, openconnect with 1315. I'm not
>> exactly sure what the difference between X-DTLS-MTU and D-CSTP-MTU is
>> supposed to be, but the tunnel should be able to transport the larger value.
>>
>> TCP_INFO rcv mss 1348, snd mss 1348, adv mss 1448, pmtu 1500
>
> Hm, so we should be sending X-CSTP-MTU: 1335, X-CSTP-Base-MTU: 1500.
>
> What is the Cisco client sending? And can you see the debug output from
> the server, like you sent in your first message?

Unfortunately I don't have access to the ASA, so I can't get that debug 
output before Monday. But to me it looks like OpenConnect could just use 
X-DTLS-MTU returned by the ASA and be done with it, no? According to the 
debug output in the first post the ASA is sending

Sending X-CSTP-MTU: 1335
Sending X-DTLS-MTU: 1418

to AnyConnect as well. Apparently AnyConnect is using X-DTLS-MTU and you 
are using X-CSTP-MTU (you did not get a X-DTLS-MTU before as far as I 
can see).

Bernhard


From berni at birkenwald.de  Fri Jun  8 15:54:01 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 08 Jun 2012 21:54:01 +0200
Subject: pMTU discovery
In-Reply-To: <4FD230EA.70905@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org> <4FD22A5A.3060409@birkenwald.de>
 <4FD22C9A.40701@birkenwald.de> <4FD230EA.70905@birkenwald.de>
Message-ID: <4FD25859.1040905@birkenwald.de>

On 08.06.2012 19:05, Bernhard Schmidt wrote:
> On 08.06.2012 18:47, Bernhard Schmidt wrote:
>
>> PEBKAC, I was just being stupid. Compiled fine, will test right away.
>
> It basically works, but I think you are using the wrong MTU value. I'm
> currently in an IPv4-only non-MTU-challenged location. Cisco Anyconnect
> client connects with 1418 bytes MTU, openconnect with 1315. I'm not
> exactly sure what the difference between X-DTLS-MTU and D-CSTP-MTU is
> supposed to be, but the tunnel should be able to transport the larger
> value.
>
> TCP_INFO rcv mss 1348, snd mss 1348, adv mss 1448, pmtu 1500
> [...]
> X-CSTP-MTU: 1315
> X-DTLS-MTU: 1418
> DTLS option X-DTLS-MTU : 1418
>
> I'll try MTU challenged (DSL) and native IPv6 transport either tonight
> or during the weekend.

IPv6 with MTU 1492:

TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1428, pmtu 1500
X-CSTP-MTU: 1335
X-DTLS-MTU: 1386

IPv4 with MTU 1492:

TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1448, pmtu 1500
X-CSTP-MTU: 1335
X-DTLS-MTU: 1418

Can openconnect output the _sent_ HTTP headers somehow?

Best Regards,
Bernhard


From dwmw2 at infradead.org  Fri Jun  8 18:29:06 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jun 2012 23:29:06 +0100
Subject: pMTU discovery
In-Reply-To: <4FD25859.1040905@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
 <4FD22A5A.3060409@birkenwald.de> <4FD22C9A.40701@birkenwald.de>
 <4FD230EA.70905@birkenwald.de> <4FD25859.1040905@birkenwald.de>
Message-ID: <1339194546.16559.26.camel@i7.infradead.org>

On Fri, 2012-06-08 at 21:54 +0200, Bernhard Schmidt wrote:
> 
> IPv6 with MTU 1492:
> 
> TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1428, pmtu 1500
> X-CSTP-MTU: 1335
> X-DTLS-MTU: 1386
> 
> IPv4 with MTU 1492:
> 
> TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1448, pmtu 1500
> X-CSTP-MTU: 1335
> X-DTLS-MTU: 1418
> 
> Can openconnect output the _sent_ HTTP headers somehow? 

It sends X-CSTP-MTU of 13 less than the lower of rcv_mss and snd_mss,
and X-CSTP-Base-MTU equal to the pmtu.

So it's sending 1355 and 1500 respectively in the above cases.

I think I see the problem. I tested this here by setting the outbound
MTU at my border router to 1300. That's *lower* than the TCP MSS set by
the ASA, so my client will have been sending oversized packets and it
will have received an ICMP 'too big' or 'fragmentation needed' response.
So it *knew* the pMTU, reported it correctly in the TCP_INFO response,
and all was good.

In your case, the MTU of 1492 is higher than the MSS that the server
sets on the TCP session. You're never *trying* to send a packet that
exceeds the MTU, so you never receive the ICMP, and you never know what
the path MTU is.

I don't really know how we could *discover* the path MTU except by
sending a packet that exceeds it, and waiting for the ICMP response...
that might never come if some idiot has filtered ICMP.

Does the Cisco client get it "right" in this situation? How? After
running 'ip route flush cache' can you capture the traffic (host $SERVER
or icmp or icmp6) and see precisely what it's doing?

I'm imagining some trick with sending a 1500-byte UDP packet to the
server before making the TCP connection... but that's horrid.


Also, what does the Cisco client do with the MTU of the actual tun0
interface, when the DTLS connection is made/broken? You can test this
firewalling all UDP to/from the server. Does it actually reduce the MTU
of the interface? Or *discard* packets which are too big for the CSTP
MTU, if they arrive while the DTLS is down? Discarding too-big packets
seems silly, since we don't have a good way to generate ICMP responses
(please tell me they aren't faking those!). I think the best option is
just to shove the large packets down the CSTP link even though we know
they'll end up fragmented over the Internet.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120608/c1431ee6/attachment.bin>

From dwmw2 at infradead.org  Fri Jun  8 18:54:02 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 08 Jun 2012 23:54:02 +0100
Subject: pMTU discovery
In-Reply-To: <4FD232C3.5070400@birkenwald.de>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
 <4FD22A5A.3060409@birkenwald.de> <4FD22C9A.40701@birkenwald.de>
 <4FD230EA.70905@birkenwald.de> <1339175389.16559.17.camel@i7.infradead.org>
 <4FD232C3.5070400@birkenwald.de>
Message-ID: <1339196042.16559.30.camel@i7.infradead.org>

On Fri, 2012-06-08 at 19:13 +0200, Bernhard Schmidt wrote:
> Unfortunately I don't have access to the ASA, so I can't get that debug 
> output before Monday. But to me it looks like OpenConnect could just use 
> X-DTLS-MTU returned by the ASA and be done with it, no?

I suppose so, after some handwaving and justification in the commit
message :)

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/21630e7ff2

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120608/bab23537/attachment-0001.bin>

From dwmw2 at infradead.org  Fri Jun  8 20:12:33 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 09 Jun 2012 01:12:33 +0100
Subject: pMTU discovery
In-Reply-To: <1339194546.16559.26.camel@i7.infradead.org>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
 <4FD22A5A.3060409@birkenwald.de> <4FD22C9A.40701@birkenwald.de>
 <4FD230EA.70905@birkenwald.de> <4FD25859.1040905@birkenwald.de>
 <1339194546.16559.26.camel@i7.infradead.org>
Message-ID: <1339200753.16559.31.camel@i7.infradead.org>

On Fri, 2012-06-08 at 23:29 +0100, David Woodhouse wrote:
> Does the Cisco client get it "right" in this situation? How? After
> running 'ip route flush cache' can you capture the traffic (host $SERVER
> or icmp or icmp6) and see precisely what it's doing?
> 
> I'm imagining some trick with sending a 1500-byte UDP packet to the
> server before making the TCP connection... but that's horrid.

I'm relieved to report that it doesn't seem to *work* either :)
--- a/cstp.c
+++ b/cstp.c
@@ -490,6 +490,34 @@ int make_cstp_connection(struct openconnect_info *vpninfo)
        if (ret)
                return ret;
 
+       /* Ick. Try sending a full-sized packet, in the hope that an ICMP
+          response will tell the kernel the path MTU. Except to *really*
+          determine the path MTU we'd need to keep trying with progressively
+          smaller packets because each hop along the way could have a
+          slightly smaller MTU than the one before. That's why they call it
+          a *path* MTU. But the server seems to want *us* to work this out
+          for it, so we can at least try... */
+       if (1) {
+               char buf[1500];
+               int len;
+               int udp;
+
+               memset(buf, 0x5a, sizeof(buf));
+
+               if (vpninfo->peer_addr->sa_family == AF_INET6)
+                       len = 1452;
+               else
+                       len = 1472;
+
+               udp = socket(vpninfo->peer_addr->sa_family, SOCK_DGRAM, IPPROTO_UDP);
+               if (udp >= 0) {
+                       sendto(udp, buf, len, 0, vpninfo->peer_addr, vpninfo->peer_addrlen);
+               }
+               close(udp);
+               sleep(1);
+       }
+                       
+
        if (vpninfo->deflate) {
                vpninfo->deflate_adler32 = 1;
                vpninfo->inflate_adler32 = 1;

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120609/d2fba5b0/attachment.bin>

From mtmiller at ieee.org  Sun Jun 10 20:57:25 2012
From: mtmiller at ieee.org (Mike Miller)
Date: Sun, 10 Jun 2012 20:57:25 -0400
Subject: GnuTLS support in OpenConnect
In-Reply-To: <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
 <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
Message-ID: <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>

On Thu, Jun 7, 2012 at 10:53 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Thu, Jun 7, 2012 at 4:40 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>
>>> I've just pushed GnuTLS support for OpenConnect to the git repository.
>>> This isn't entirely feature-complete yet. It doesn't support DTLS, and
>>> in fact it the openconnect executable doesn't build at all right now
>>> because it still uses the OpenSSL "UI" abstraction for user
>>> interaction.
>> Both of those are now fixed. There's an experimental patch against the
>> GnuTLS 3.0 branch to provide Cisco-compatible DTLS support, at
>> http://david.woodhou.se/gnutls-cisco-dtls-working-2.patch
>
> I'll include it in gnutls master.

Hey guys, trying to build gnutls master tonight in an effort to help
test OpenConnect but I'm failing at:

../../lib/.libs/libgnutls.so: undefined reference to `rsa_pkcs1_sign_tr'
../../lib/.libs/libgnutls.so: undefined reference to `rsa_pkcs1_verify'

I can't find these, my best guess is this is dependent on a nettle
work-in-progress.  Any pointers?  Thanks.

-- 
mike


From dwmw2 at infradead.org  Sun Jun 10 20:58:42 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 11 Jun 2012 01:58:42 +0100
Subject: GnuTLS support in OpenConnect
In-Reply-To: <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
 <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
 <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
Message-ID: <1339376322.16559.56.camel@i7.infradead.org>

On Sun, 2012-06-10 at 20:57 -0400, Mike Miller wrote:
> 
> Hey guys, trying to build gnutls master tonight in an effort to help
> test OpenConnect but I'm failing at:
> 
> ../../lib/.libs/libgnutls.so: undefined reference to
> `rsa_pkcs1_sign_tr'
> ../../lib/.libs/libgnutls.so: undefined reference to
> `rsa_pkcs1_verify'
> 
> I can't find these, my best guess is this is dependent on a nettle
> work-in-progress.  Any pointers?  Thanks. 

The patch should cherry-pick onto the GnuTLS 3.0 branch trivially.
That's what I've been using.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120611/9678c78b/attachment.bin>

From mtmiller at ieee.org  Sun Jun 10 21:34:40 2012
From: mtmiller at ieee.org (Mike Miller)
Date: Sun, 10 Jun 2012 21:34:40 -0400
Subject: GnuTLS support in OpenConnect
In-Reply-To: <1339376322.16559.56.camel@i7.infradead.org>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
 <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
 <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
 <1339376322.16559.56.camel@i7.infradead.org>
Message-ID: <CAD6LDLKZFAERo2U4c_aYODxYdccf9OmWs41s3x4PqoFVYbde1A@mail.gmail.com>

On Sun, Jun 10, 2012 at 8:58 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sun, 2012-06-10 at 20:57 -0400, Mike Miller wrote:
>>
>> Hey guys, trying to build gnutls master tonight in an effort to help
>> test OpenConnect but I'm failing at:
>>
>> ../../lib/.libs/libgnutls.so: undefined reference to
>> `rsa_pkcs1_sign_tr'
>> ../../lib/.libs/libgnutls.so: undefined reference to
>> `rsa_pkcs1_verify'
>>
>> I can't find these, my best guess is this is dependent on a nettle
>> work-in-progress. ?Any pointers? ?Thanks.
>
> The patch should cherry-pick onto the GnuTLS 3.0 branch trivially.
> That's what I've been using.

Perfect, got it built and running that way.  A different error in
certtool-args.c and p11tool-args.c but the library works.

-- 
mike


From nmav at gnutls.org  Sun Jun 10 22:45:29 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 11 Jun 2012 04:45:29 +0200
Subject: GnuTLS support in OpenConnect
In-Reply-To: <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
 <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
 <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
Message-ID: <4FD55BC9.8050500@gnutls.org>

On 06/11/2012 02:57 AM, Mike Miller wrote:

>> I'll include it in gnutls master.
> Hey guys, trying to build gnutls master tonight in an effort to help
> test OpenConnect but I'm failing at:
> ../../lib/.libs/libgnutls.so: undefined reference to `rsa_pkcs1_sign_tr'
> ../../lib/.libs/libgnutls.so: undefined reference to `rsa_pkcs1_verify'
> I can't find these, my best guess is this is dependent on a nettle
> work-in-progress.  Any pointers?  Thanks.


Unfortunately it depends on an uncommitted update in nettle. I hope this
will be fixed soon.

regards,
Nikos


From abaire at irisa.fr  Sun Jun 10 10:11:54 2012
From: abaire at irisa.fr (Anthony Baire)
Date: Sun, 10 Jun 2012 19:41:54 +0530
Subject: [PATCH] accept multiple server fingerprints with --servercert
In-Reply-To: <1339074929.26785.202.camel@shinybook.infradead.org>
References: <4FD0712F.4090203@irisa.fr>
 <1339074929.26785.202.camel@shinybook.infradead.org>
Message-ID: <4FD4AB2A.9040907@irisa.fr>

Le 07/06/2012 18:45, David Woodhouse a ?crit :
> On Thu, 2012-06-07 at 11:15 +0200, Anthony Baire wrote:
>    
>> I am sending a small patch to allow accepting multiple server
>> fingerprints with the --servercert option. This is useful for
>> configurations with redundant servers.
>>
>> Signed-off-by: Anthony Baire<abaire at irisa.fr>
>>      
> Thanks... but I'm not sure this is the right approach.
>
> The --servercert option is supposed to be used only for the final
> connection, after you have already authentication in a GUI through
> libopenconnect. Then we pass the cookie, the address of the final server
> you ended up at *after* load balancing, and the cert fingerprint of
> *that* server to openconnect.
>    
In my case, I have the openclient trying to match the server fingerprint 
for both the load balancer and the final server (I don't know exactly 
how load balancing is implemented in our site), in this context 
--servercert was helpless.

> If you want this for the general case of logging in from the command
> line, and your servers' certificates aren't trusted by your normal CAs,
> then surely you'd do better putting the appropriate CAs (or just the
> servers' certs) into a --cafile?
>    
Yes, this would be a good idea. The point with --servercert was that it 
is easier to use (rather that filling a CA file).

> If we really do end up needing something like this, maybe it could be a
> new option '--accept-cert' which takes a hostname too, and you could put
> them directly into the 'accepted_certs' list in main.c?
>    
That's a good idea too.

Anthony


From dwmw2 at infradead.org  Mon Jun 11 12:00:17 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 11 Jun 2012 17:00:17 +0100
Subject: GnuTLS support in OpenConnect
In-Reply-To: <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
References: <1338511899.11518.521.camel@shinybook.infradead.org>
 <1339080018.26785.213.camel@shinybook.infradead.org>
 <CAJU7zaL8gnTh37zWhgVQDEXi_HjCVjbTdGYNcmKK6t6qYq_c9Q@mail.gmail.com>
 <CAD6LDL+2euhM_0WkV-e1VOQ7=7c1PfcwvBYvPBNGWAO6VYBTEQ@mail.gmail.com>
Message-ID: <1339430417.2851.177.camel@shinybook.infradead.org>

On Sun, 2012-06-10 at 20:57 -0400, Mike Miller wrote:
> >> Both of those are now fixed. There's an experimental patch against the
> >> GnuTLS 3.0 branch to provide Cisco-compatible DTLS support, at
> >> http://david.woodhou.se/gnutls-cisco-dtls-working-2.patch
> >
> > I'll include it in gnutls master.
> 
> Hey guys, trying to build gnutls master tonight in an effort to help
> test OpenConnect but I'm failing at:

I've just pushed support to the repository for building with *both*
GnuTLS and OpenSSL simultaneously.

It'll use GnuTLS for the HTTPS connections, including all the PKCS#11
goodness.. Since that's all that's included in the libopenconnect
library, it's enough to fix the KDE licensing problem. And if your
version of GnuTLS doesn't include the Cisco DTLS support, it'll *also*
link the openconnect executable against OpenSSL and use that for DTLS.

So now you should have everything working? even if your GnuTLS is as old
as 2.12.16. Unfortunately, Fedora *still* isn't shipping GnuTLS 3.0, and
isn't even planning to do so in Fedora 18, citing the libnettle
requirement and alleged patent problems with the unconditional elliptic
curve support as reasons?.

-- 
dwmw2

? The one thing that doesn't work with 2.12.x is warning the user that
  their certificate is about to expire, and working around an OpenSSL
  but on the server, *if* the private key comes from PKCS#11. Not many
  people will care about that... and I could even fix the expiry check.

?  https://bugzilla.redhat.com/show_bug.cgi?id=726886#c24
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120611/6e17dbc6/attachment.bin>

From dwmw2 at infradead.org  Tue Jun 12 20:05:02 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 13 Jun 2012 01:05:02 +0100
Subject: pMTU discovery
In-Reply-To: <1339194546.16559.26.camel@i7.infradead.org>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org>
 <4FD22A5A.3060409@birkenwald.de> <4FD22C9A.40701@birkenwald.de>
 <4FD230EA.70905@birkenwald.de> <4FD25859.1040905@birkenwald.de>
 <1339194546.16559.26.camel@i7.infradead.org>
Message-ID: <1339545902.2131.52.camel@shinybook.infradead.org>

On Fri, 2012-06-08 at 23:29 +0100, David Woodhouse wrote:
> Does the Cisco client get it "right" in this situation? How? After
> running 'ip route flush cache' can you capture the traffic (host $SERVER
> or icmp or icmp6) and see precisely what it's doing?
> 
> I'm imagining some trick with sending a 1500-byte UDP packet to the
> server before making the TCP connection... but that's horrid. 

Any progress on this? I'm almost ready to do a v4.00 release of
OpenConnect with fully functional GnuTLS support (including PKCS#11 and
TPM). I might disable the automatic setting of base-mtu from TCP_INFO
data, since it's not working, and just leave you with the command line
option for it until we work out a better way to detect it.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120613/09e689b5/attachment.bin>

From berni at birkenwald.de  Wed Jun 13 08:13:02 2012
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Wed, 13 Jun 2012 14:13:02 +0200
Subject: pMTU discovery
In-Reply-To: <1339545902.2131.52.camel@shinybook.infradead.org>
References: <4FC73D74.4080100@birkenwald.de>
 <1339156939.13998.29.camel@i7.infradead.org> <4FD22A5A.3060409@birkenwald.de>
 <4FD22C9A.40701@birkenwald.de> <4FD230EA.70905@birkenwald.de>
 <4FD25859.1040905@birkenwald.de> <1339194546.16559.26.camel@i7.infradead.org>
 <1339545902.2131.52.camel@shinybook.infradead.org>
Message-ID: <4FD883CE.1080406@birkenwald.de>

Am 13.06.2012 02:05, schrieb David Woodhouse:
> On Fri, 2012-06-08 at 23:29 +0100, David Woodhouse wrote:
>> Does the Cisco client get it "right" in this situation? How? After
>> running 'ip route flush cache' can you capture the traffic (host $SERVER
>> or icmp or icmp6) and see precisely what it's doing?
>>
>> I'm imagining some trick with sending a 1500-byte UDP packet to the
>> server before making the TCP connection... but that's horrid. 
> 
> Any progress on this? I'm almost ready to do a v4.00 release of
> OpenConnect with fully functional GnuTLS support (including PKCS#11 and
> TPM). I might disable the automatic setting of base-mtu from TCP_INFO
> data, since it's not working, and just leave you with the command line
> option for it until we work out a better way to detect it.

Looking at it at the moment. At first glance the MTU detected by the new
scheme always worked for me, both with IPv4 and IPv6 transport both
within a 1500 byte network and behind a MTU 1492 ADSL line.

So, even if openconnect errorneously always sends X-CSTP-Base-MTU 1500,
the connection works way better than before. Probably because it allows
the ASA to calculate it on its own.

We can give you a test account on our ASA if you'd like to test it, too.

Best Regards,
Bernhard


From dwmw2 at infradead.org  Wed Jun 13 19:24:58 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 14 Jun 2012 00:24:58 +0100
Subject: OpenConnect 3.99 release (4.00 beta)
Message-ID: <1339629898.2141.31.camel@shinybook.infradead.org>

This is a prerelease of v4.00 to get a little more testing.

The main thing it does is add GnuTLS support. It supports PKCS#11 crypto
tokens, and also TPM keys. Thanks to Carolin Latze for the TPM support,
and especially to Nikos Mavrogiannopoulos for a lot of other help in
getting GnuTLS working, including DTLS support.

It still uses OpenSSL by default, unless you pass '--with-gnutls' on the
configure command line. If you aren't using a version of GnuTLS which
supports Cisco-DTLS, it'll still fall back to using OpenSSL for that,
while using GnuTLS for the HTTPS part.

Places where the library used to expose an OpenSSL 'X509' structure now
expose a generic pointer. It *might* be an X509, or it might be a
gnutls_x509_crt_t. There are functions to do various operations on it
(fingerprint, pretty-print as text) that the auth-dialogs were doing,
and a function to export it in DER form if an auth-dialog wants to do
something more advanced. All the callbacks for user interaction are also
cleaned up to use the ->process_auth_form() method, so auth-dialogs no
longer need to capture the OpenSSL UI method calls.

Note that TPM support is only available with GnuTLS 3.x; if you're stuck
on GnuTLS 2.12 then please file a bug with your Linux distribution to
get it updated. GnuTLS 3.0 was released almost a year ago! Other
functionality is subtly substandard when used with GnuTLS 2.12 too.

This release also also adds a $CISCO_SPLIT_DNS variable when invoking
vpnc-script, with a comma-separated list of search domains. (Patches to
vpnc-script welcome; NetworkManager is already updated.)

Finally it improves the MTU configuration to improve connectivity with
new servers by allowing different MTU for CSTP and DTLS connections.
Although it's not clear how Cisco's scheme for this is intended to work;
it looks like it'd work a lot better if their server didn't give an
artificially low MSS when accepting the TCP connection.

Oh, and the --cert-type option is gone from the command line. We've been
automatically detecting that for a *long* time, so the option was
unneeded.

ftp://ftp.infradead.org/pub/openconnect/openconnect-3.99.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-3.99.tar.gz.asc

David Woodhouse (137):
      Add --with-pkgconfigdir to allow different environments like FreeBSD
      Make openconnect_open_https() and openconnect_close_https() more forgiving.
      Fix non-blocking support in fetch_config()
      Use openconnect_open_https() and openconnect_close_https() better.
      Add gnutls support to build system
      Fix API major/minor handling for out-of-source-tree build
      Move peer_cert handling to openconnect_open_https()
      Add openconnect_get_cert_details() function
      Add openconnect_sha1() function and use it instead of using OpenSSL directly
      Move basic process_auth_form() out to main.c
      Be more self-sufficient with header inclusions
      Add openconnect_get_cert_DER() function
      Add openconnect_random() function
      Split out connect_https_socket() function from openconnect_open_https()
      Move OpenSSL-specific functions from ssl.c to openssl.c
      Disable DTLS for GnuTLS build for now
      Remove OpenSSL dependency from http.c
      Add SSL library definition to CFLAGS in openconnect.pc
      Introduce semi-opaque OPENCONNECT_X509 type in library API
      Add barely functional GnuTLS support
      Refuse to build with GnuTLS < 2.12.16
      Make CSTP connection in a single SSL record
      Improve GnuTLS compatibility options
      Add client certificate support for GnuTLS
      Check cert expiry, at least for PEM certs
      Clean up GnuTLS PKCS#12 handling a little
      Add server certificate validation for GnuTLS
      Import pkcs12_parse() function from GnuTLS to fix PKCS#12 handling
      Make GnuTLS parse_pkcs12() return extra certificates from the PKCS#12 too
      GnuTLS: Add supporting certificates from PKCS#12 file
      Remove unused workaround_openssl_certchain_bug() function
      GnuTLS: Load trusted CAs before loading certificate
      GnuTLS: Import more than one certificate from PEM file
      Add GnuTLS to changelog
      Add openssl.c and gnutls.c to POTFILES
      Remove duplicate socket connect code from gnutls.c
      Fix vpninfo->peer_cert handling for GnuTLS
      Move openconnect_SSL_printf() to ssl.c
      Fix build on systems without O_CLOEXEC
      Remove stray debug printf
      Fix GnuTLS select() during handshake
      Bump API version, advertise get_cert_DER() and get_cert_details() functions
      Reduce priority of GnuTLS certificate verify failure message to PRG_INFO
      Fix GnuTLS request_passphrase() if no UI callback function
      openconnect_set_xmlsha1() takes a const char *
      Stop using OpenSSL UI for user interaction
      Add completely untested PIN callback for GnuTLS
      GnuTLS: Split logging of additional certs into a separate loop
      GnuTLS: Don't include root CA in the supporting evidence; only intermediates
      OpenSSL: Don't include root CA in the supporting evidence; only intermediates
      Fix FreeBSD compile
      Allow interface name to be specified on *BSD
      Fix FreeBSD tun handling with net.link.tun.devfs_cloning=0
      Update comment about gnutls_x509_privkey_import_pkcs8() password handling
      Move request_passphrase() to ssl.c
      Use request_passphrase() for OpenSSL PKCS#12
      Fix config_arg handling
      Fix config fetch
      Use request_passphrase() for OpenSSL PEM files
      Check for gnutls_pkcs12_simple_parse() in GnuTLS
      Split out OpenSSL_specific start_dtls_handshake() function
      Add DTLS support for GnuTLS
      Allow '--with-gnutls' in configure
      Add UI handling for OpenSSL TPM keys
      GnuTLS now uses gnutls_session_set_premaster()
      Fix GnuTLS PKCS#11 PIN request function
      Use p11-kit for directing PIN request to process_auth_form()
      Remove last traces of special UI and PIN handling from main.c
      Bump library soname to libopenconnect.so.2
      Kill old openconnect_vpninfo_new()
      Fix cbdata argument to process_auth_form()
      Change Requires: to Requires.private: in openconnect.pc
      Fix generation of version.c for out-of-tree builds
      Fix git-tree deps for version.c in out-of-tree build
      Don't hard-code cipher type in GnuTLS DTLS
      Set X-CSTP-Base-MTU: for new servers
      Make 'make dist' work for out-of-tree build
      Add gnutls_pkcs12 to dist
      Add gnutls.c and openssl.c to EXTRA_DIST too
      Add $CISCO_SPLIT_DNS environment variable for vpnc-script
      Update changelog
      Use X-DTLS-MTU response from server as well as X-CSTP-MTU
      Import updated gnutls_pkcs12_simple_parse() from GnuTLS
      Don't unregister p11-kit PIN callback until vpninfo is finished with
      Fix error handling when GnuTLS can't open key file
      Cope with SSL key being PKCS#11 but cert from file
      Use gnutls_certificate_set_x509_system_trust() where available
      GnuTLS: Fix expiry check and CA chain addition for PKCS#11 certs
      GnuTLS: Fix build with GnuTLS 2.12 and PKCS#11
      Set object-type on PKCS#11 URL for key and cert
      GnuTLS: Cache token PIN
      Remove obsolete GnuTLS FIXME comment
      Portability fixes for Solaris, *BSD
      Fix non-interactive mode
      Update docs for GnuTLS and PKCS#11 support
      GnuTLS: Print name of primary certificate
      OpenSSL: Print name of primary certificate
      Fix update-translations make target for out-of-tree build
      Fix upload-pot make target for out-of-tree build
      Update translations from Transifex
      Remove stray openssl includes
      Allow building against GnuTLS (for TCP) and GnuTLS (for DTLS) simultaneously
      Print SSL build options on --version or usage()
      Remove --cert-type option from command line
      Make --disable-ipv6 really do it
      Translate build option output
      Return error from OpenSSL load_certificate() for PKCS#11 URLs
      Add openconnect_has_pkcs11_support()
      Add --authenticate option
      Fix const char * warnings in GnuTLS pin_helper on FreeBSD
      Add openconnect_has_tss_blob_support()
      GnuTLS: Fix password memory leaks
      Fix useragent leak
      Make authentication valgrind-friendly
      OpenSSL: Fix password memory leaks
      OpenSSL: Clean up leaks in TPM ENGINE handling
      OpenSSL: Free BIO leak in reload_pem_cert()
      OpenSSL: Fix leak of cert_x509
      Explicitly check for gnutls_certificate_set_key(), separate it from p11-kit
      Fix DTLS fallback to OpenSSL for old GnuTLS
      Clean up build options printout
      Add TPM support for GnuTLS
      Remove redundancy in code which 'matches' cert to privkey
      Fix GnuTLS PIN cache leak when only *key* is PKCS#11 and not certificate.
      Implement certificate matching for TPM/PKCS#11 privkeys
      Fix error exits in GnuTLS load_certificate() function
      Try null SRK key (20 bytes of zero) first
      Give proper error reporting from tpm_sign_fn() TPM operations
      Handle TPM keys with their own authentication PIN
      Allow GUI to distinguish between PIN/passphrase callbacks
      Fix build with GnuTLS 2.12
      Update translations from Transifex
      Move dtls1_stop_timer() declaration inside the OPENCONNECT_OPENSSL section
      Link libopenconnect to trousers, not openconnect
      $CISCO_SPLIT_DNS is separated by commas in vpnc, not spaces
      Make 'make tag' work out of source tree
      Tag version 3.99

Mike Miller (2):
      Remove libopenconnect.map from EXTRA_DIST
      Show correct path to vpnc-script in the man page


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120614/aeaec5c9/attachment.bin>

From dwmw2 at infradead.org  Fri Jun 15 10:01:47 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 15 Jun 2012 15:01:47 +0100
Subject: [PATCH] Add Android keystore support
In-Reply-To: <CACsWFyzZX155bMcUCYhuB4UueFs=zF++Fq=p0ArnBiznuZiqTg@mail.gmail.com>
References: <CACsWFyzPWhzS8w=A52jwVmbjSpDkXo0Fz=WddOfhzXNB118ZFw@mail.gmail.com>
 <1325107600.14398.30.camel@shinybook.infradead.org>
 <CACsWFyzZX155bMcUCYhuB4UueFs=zF++Fq=p0ArnBiznuZiqTg@mail.gmail.com>
Message-ID: <1339768907.2141.136.camel@shinybook.infradead.org>

On Thu, 2011-12-29 at 01:22 +0000, Vilmos Nebehaj wrote:
> Good point.  I refactored certificate handling in ssl.c, attaching
> revised patch. 

Six months later, I've finally committed something based on this;
thanks. It works like wpa_supplicant does on Android ? if a "filename"
starts with "keystore:" then it uses the keystore for it, otherwise it
treats it as a filename as usual. I've implemented it for both OpenSSL
and GnuTLS, although we don't use GnuTLS on Android.

This is consistent with our handling of pkcs11: for PKCS#11 tokens, too.

I've also updated Android.mk and included it in the release tarball,
although it doesn't actually build here because my Android build tree is
a little buggered. Should I be able to install an NDK with libxml2 and
the other requirements, and build this simply? Or does it require a full
CyanogenMod/AOSP build?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120615/85fb5726/attachment.bin>

From jon at erezlife.com  Sat Jun 16 19:55:22 2012
From: jon at erezlife.com (Jon Dufresne)
Date: Sat, 16 Jun 2012 16:55:22 -0700
Subject: Best practices for scripting openconnect
In-Reply-To: <1337959671.5820.77.camel@i7.infradead.org>
References: <1337958108.5886.13.camel@bender.futurama>
 <1337959671.5820.77.camel@i7.infradead.org>
Message-ID: <1339890922.4450.7.camel@bender.futurama>

Thank you for the very informative reply!

On Fri, 2012-05-25 at 16:27 +0100, David Woodhouse wrote:
> On Fri, 2012-05-25 at 08:01 -0700, Jon Dufresne wrote:
> > What is the best way to handle a script run by a normal user, but still
> > able to establish the VPN connection. I want to limit the use of sudo
> > and root as much as possible.
> 
> You didn't specify, but I'm assuming you're doing this under Linux.

Yes, correct. Scientific Linux 6 and Fedora 17.

> You can almost certainly eliminate the *teardown* step though, and then
> 'openconnect --setuid' would work. If you don't change the DNS setup to
> use the VPN's DNS servers, and if you don't change your *default* route
> to go via the VPN, then there's nothing to tear down. If there's just
> the tun device with a simple route to one subnet like 172.16.0.0/20,
> then it'll just go away naturally when openconnect exits, and everything
> will be back to normal. So you could use 'openconnect --setuid' with
> your own little script which is a *wrapper* around vpnc-script, and just
> clears the INTERNAL_IP4_DNS variable and sets its own CISCO_SPLIT_INC*
> variables to route just the IP addresses/subnets you need, before
> invoking the real vpnc-script.
> 
> You still need to invoke openconnect as root for that though. And you
> wouldn't get VPN DNS, although your scripts *could* manually look up
> things on the VPN's DNS servers and access services by IP address ? the
> servers would be *reachable*, but just not listed in /etc/resolv.conf.
> 

This approach looks like the easiest given my situation. I gave it a
shot. The wrapper script simply unset the INTERNAL_IP4_DNS environment
variable, then called vpnc-script with all arguments. I was able to
successfully connect to the VPN. My resolv.conf was unchanged. After
connected, openconnect successfully changed ownership to a
non-privileged user.

While connected to VPN my non-VPN network continued to work properly. I
then killed openconnect as the non-privileged user. After successful
shutdown, I was unable to use the non-VPN network interface. Any idea
why this might be and steps I could take to fix this? I'd be happy to
provide any output or diagnostic if you think that would help.

Thanks,
Jon



From dwmw2 at infradead.org  Sat Jun 16 20:10:28 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 17 Jun 2012 01:10:28 +0100
Subject: Best practices for scripting openconnect
In-Reply-To: <1339890922.4450.7.camel@bender.futurama>
References: <1337958108.5886.13.camel@bender.futurama>
 <1337959671.5820.77.camel@i7.infradead.org>
 <1339890922.4450.7.camel@bender.futurama>
Message-ID: <1339891828.3311.44.camel@shinybook.infradead.org>

On Sat, 2012-06-16 at 16:55 -0700, Jon Dufresne wrote:
> While connected to VPN my non-VPN network continued to work properly.

Really? You sure you weren't routing packets for the Internet via the
VPN rather than your local network?

> I then killed openconnect as the non-privileged user. After successful
> shutdown, I was unable to use the non-VPN network interface. Any idea
> why this might be and steps I could take to fix this? I'd be happy to
> provide any output or diagnostic if you think that would help. 

My first guess is that your default route was set to go via the VPN,
which worked OK until you killed openconnect. And since openconnect
dropped root privs, it couldn't put the default route *back* again.

Can you show output of 'ip route list' from
 - Before you connect (when it's working)
 - While connected
 - After disconnect (when it's not working)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120617/82f047e2/attachment.bin>

From lists at fuchsschwanzdomain.de  Sun Jun 17 06:08:22 2012
From: lists at fuchsschwanzdomain.de (Sven Geggus)
Date: Sun, 17 Jun 2012 10:08:22 +0000 (UTC)
Subject: "Target networks" option?
Message-ID: <jrkaam$c3g$1@ultimate100.geggus.net>

Hello,

using vpnc I had a configuration file (/etc/vpnc/sitename.conf) where
I could specify a "Target networks" option overwriting the default to
do anything over VPN.

With openconnect which seems to somehow using the
/etc/vpnc/vpnc-script how can I specify this Option?

Can I just put it into the file given by "--config"?

Sven

-- 
"Dynamische IP-Nummern sind Security-Hom?opathie."
						(Kristian K?hntopp)

/me is giggls at ircnet, http://sven.gegg.us/ on the Web


From dwmw2 at infradead.org  Sun Jun 17 06:26:29 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 17 Jun 2012 11:26:29 +0100
Subject: "Target networks" option?
In-Reply-To: <jrkaam$c3g$1@ultimate100.geggus.net>
References: <jrkaam$c3g$1@ultimate100.geggus.net>
Message-ID: <1339928789.3311.50.camel@shinybook.infradead.org>

On Sun, 2012-06-17 at 10:08 +0000, Sven Geggus wrote:
> using vpnc I had a configuration file (/etc/vpnc/sitename.conf) where
> I could specify a "Target networks" option overwriting the default to
> do anything over VPN.

If you want to override the routes and DNS configuration provided by the
VPN, currently you can do that by putting a wrapper around vpnc-script
which modifies the environment variables before invoking the real
vpnc-script. I've put an example such script below. You put the networks
that you *do* want to route in the 'ROUTES' variables at the top.

It'll also spit out the list in a form you can put into a NetworkManager
configuration file (e.g. in /etc/NetworkManager/system-connections/

This one only handles Legacy IP but it could be extended to handle IPv6
fairly easily.

#!/bin/sh

ROUTES="10.0.0.0/8 172.16.0.0/12 192.168.21.0/24 192.168.65.0/24"

# Helpers to create dotted-quad netmask strings.
MASKS[1]="128.0.0.0"
MASKS[2]="192.0.0.0"
MASKS[3]="224.0.0.0"
MASKS[4]="240.0.0.0"
MASKS[5]="248.0.0.0"
MASKS[6]="252.0.0.0"
MASKS[7]="254.0.0.0"
MASKS[8]="255.0.0.0"
MASKS[9]="255.128.0.0"
MASKS[10]="255.192.0.0"
MASKS[11]="255.224.0.0"
MASKS[12]="255.240.0.0"
MASKS[13]="255.248.0.0"
MASKS[14]="255.252.0.0"
MASKS[15]="255.254.0.0"
MASKS[16]="255.255.0.0"
MASKS[17]="255.255.128.0"
MASKS[18]="255.255.192.0"
MASKS[19]="255.255.224.0"
MASKS[20]="255.255.240.0"
MASKS[21]="255.255.248.0"
MASKS[22]="255.255.252.0"
MASKS[23]="255.255.254.0"
MASKS[24]="255.255.255.0"
MASKS[25]="255.255.255.128"
MASKS[26]="255.255.255.192"
MASKS[27]="255.255.255.224"
MASKS[28]="255.255.255.240"
MASKS[29]="255.255.255.248"
MASKS[30]="255.255.255.252"
MASKS[31]="255.255.255.254"

export CISCO_SPLIT_INC=0

# Create environment variables that vpnc-script uses to configure network
function addroute()
{
    local ROUTE="$1"
    export CISCO_SPLIT_INC_${CISCO_SPLIT_INC}_ADDR=${ROUTE%%/*}
    export CISCO_SPLIT_INC_${CISCO_SPLIT_INC}_MASKLEN=${ROUTE##*/}
    export CISCO_SPLIT_INC_${CISCO_SPLIT_INC}_MASK=${MASKS[${ROUTE##*/}]}
    export CISCO_SPLIT_INC=$((${CISCO_SPLIT_INC}+1))
}

# Old function for generating NetworkManager 0.8 GConf keys 
function translateroute ()
{
    local IPADDR="${1%%/*}"
    local MASKLEN="${1##*/}"
    local OCTET1="$(echo $IPADDR | cut -f1 -d.)"
    local OCTET2="$(echo $IPADDR | cut -f2 -d.)"
    local OCTET3="$(echo $IPADDR | cut -f3 -d.)"
    local OCTET4="$(echo $IPADDR | cut -f4 -d.)"

    local NUMADDR=$(($OCTET1*16581375 + $OCTET2*65536 + $OCTET3*256 + $OCTET4))
    local NUMADDR=$(($OCTET4*16581375 + $OCTET3*65536 + $OCTET2*256 + $OCTET1))
    if [ "$ROUTESKEY" = "" ]; then
	ROUTESKEY="$NUMADDR,$MASKLEN,0,0"
    else
	ROUTESKEY="$ROUTESKEY,$NUMADDR,$MASKLEN,0,0"
    fi
}
  
if [ "$reason" = "make-nm-config" ]; then
    echo "Put the following into the [ipv4] section in your NetworkManager config:"
    echo "method=auto"
    COUNT=1
    for r in $ROUTES; do
	echo "routes${COUNT}=${r%%/*};${r##*/};0.0.0.0;0;"
	COUNT=$(($COUNT+1))
    done
    exit 0
fi

for r in $ROUTES; do
    addroute $r
done

exec /etc/vpnc/vpnc-script

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120617/9cf73668/attachment-0001.bin>

From dwmw2 at infradead.org  Sun Jun 17 20:28:41 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 18 Jun 2012 01:28:41 +0100
Subject: [PATCH] Add Android keystore support
In-Reply-To: <CACsWFyzZX155bMcUCYhuB4UueFs=zF++Fq=p0ArnBiznuZiqTg@mail.gmail.com>
References: <CACsWFyzPWhzS8w=A52jwVmbjSpDkXo0Fz=WddOfhzXNB118ZFw@mail.gmail.com>
 <1325107600.14398.30.camel@shinybook.infradead.org>
 <CACsWFyzZX155bMcUCYhuB4UueFs=zF++Fq=p0ArnBiznuZiqTg@mail.gmail.com>
Message-ID: <1339979321.3311.105.camel@shinybook.infradead.org>

On Thu, 2011-12-29 at 01:22 +0000, Vilmos Nebehaj wrote:
> 
> I have actually implemented Anyconnect support in android 2.3 as a
> system feature using the built-in VPN framework & openconnect.  See the
> repositories  android_external_openconnect, android_frameworks_base,
> android_system_core, android_packages_apps_Settings and
> android_external_openssl at https://github.com/ldx.  This openconnect
> repository contains further commits for further integration.  The gingerbread
> branches from the repos can be used with cyanogenmod7 to build a full
> ROM with openconnect and the GUI bits in the Settings app.  Works
> great for me with both certificate based and 2-factor password based
> authentication against a Cisco ASA 55xx.  I'll write a few lines about
> how to build it step by step.

I've just been taking another look at this. I like the way you handle
the callbacks from openconnect via the control socket. With OpenConenct
4.00 it's not the OpenSSL UI any more; we have the ->process_auth_form()
callback in the vpninfo.

Did you ever get round to revising it for the new VpnService in Android
4.0?

It looks like it should be relatively simple ? you just need to make
openconnect dup() and pass the file descriptors over the control socket
for the Java code to call protect() on them, and also it'll need to get
its file descriptor for the tun device from the establish() call on the
Java side.

That's easy enough in the C code, and it looks simple if you have access
to the LocalSocket object on the Java side. So as long as you don't use
DaemonProxy, which keeps its mControlSocket private and doesn't let you
send/receive file descriptors over it, you should be fine. It's not that
hard to use LocalSocket for the control socket direclty and then you can
use its getAncillaryFileDescriptors() and setFileDescriptorsForSend()
methods, right?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120618/92d6a066/attachment.bin>

From dwmw2 at infradead.org  Wed Jun 20 15:03:28 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 20 Jun 2012 20:03:28 +0100
Subject: OpenConnect 4.00 release
Message-ID: <1340219008.3485.10.camel@shinybook.infradead.org>

A bunch of fixes since the 3.99 beta release. Thanks to everyone who
tested it.

This release has full functionality even with GnuTLS 2.12, although it
uses OpenSSL for DTLS in that case. The GnuTLS support code is cleaned
up a little... and then made messier by adding support for the old
OpenSSL encrypted PEM files.

This release also adds support for keys from the Android keystore.

ftp://ftp.infradead.org/pub/openconnect/openconnect-4.00.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-4.00.tar.gz.asc

David Woodhouse (41):
      Fix GnuTLS 2.12 library still referencing OpenSSL ERR_print_errors_cb()
      Fix Solaris build, again
      Document SHA1 buffer requirements more clearly
      Fix wording of comment about string handling
      Fix memory leak of TPM key password
      Cope with lack of gnutls_certificate_set_key() in GnuTLS 2.12
      Fix BER encoding of hash in sign_dummy_data()
      Clean up handling of gnutls_pkcs12.c
      Move TPM code out into gnutls_tpm.c
      Split assign_privkey_gtls3() to separate function
      Split assign_privkey_gtls2() to separate function
      Move setting of vpninfo->my_p11key to somewhere tidier
      Unify assign_privkey() function for GnuTLS 2 and 3
      Clean up GnuTLS load_certificate() and improve comments
      Don't repack extra_certs[] when matching key; just cope with it being sparse
      Add gnutls_tpm.c to POTFILES
      Remove separate POTFILES list and build potfile from real sources lists
      Clean up feature/index web pages a little
      Fix build for OpenSSL without DTLS
      Fix Android build
      Add Android keystore support
      OpenSSL: Fix recognition of repeated 'wrong passphrase' errors
      Automatically keep Android.mk in sync with source lists from Makefile.am
      Remove POTFILES.in from po/ EXTRA_DIST
      Add gnutls.h to noinst_HEADERS
      Add trousers to list of optional build deps
      Fix Android keystore support for older keystore_get.h
      Fix fake Android keystore_get() to return -1 on failure
      Fix double-free of BIO in loading cert from keystore
      Switch from Android's keystore_get() to our own keystore_fetch()
      Add missing includes and libs to Android.mk
      Add Android keystore support for --cafile
      Fix PKCS#11 cleanup when no SSL certificate is set
      NUL-terminate blobs from Andoird keystore
      Fix memory leaks in text-mode process_form_opts
      Support old-style OpenSSL encrypted PEM keys
      Fix typo in error message
      Add translations that GNOME NetworkManager-openconnect has, that we don't
      Run msgmerge after importing translations from Transifex
      Update translations from Transifex
      Tag version 4.00


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120620/49089636/attachment.bin>

From steve at x2.hamachi.us  Sat Jun 23 15:08:39 2012
From: steve at x2.hamachi.us (Steven Ihde)
Date: Sat, 23 Jun 2012 12:08:39 -0700
Subject: [PATCH] Add source port option for DTLS
Message-ID: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>


The attached patch adds support for a "--dtls-source-port" option to set the source port for DTLS datagrams.  For example, to ease firewall configuration.  Comments welcome.

-Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-source-port.patch
Type: application/octet-stream
Size: 3233 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120623/ab1a9b11/attachment.obj>

From dwmw2 at infradead.org  Sat Jun 23 21:32:05 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 24 Jun 2012 03:32:05 +0200
Subject: [PATCH] Add source port option for DTLS
In-Reply-To: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
References: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
Message-ID: <1340501525.24790.1.camel@shinybook.infradead.org>

On Sat, 2012-06-23 at 12:08 -0700, Steven Ihde wrote:
> The attached patch adds support for a "--dtls-source-port" option to
> set the source port for DTLS datagrams.  For example, to ease firewall
> configuration.  Comments welcome.

Looks sane enough at first glance; thanks. Perhaps 'local' port rather
than 'source' port, since it's bidirectional? And the man page needs
updating to match, and it needs a Signed-off-by: as described at
http://www.infradead.org/openconnect/contribute.html

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120624/18041c03/attachment.bin>

From steve at x2.hamachi.us  Sat Jun 23 21:42:04 2012
From: steve at x2.hamachi.us (Steven Ihde)
Date: Sat, 23 Jun 2012 18:42:04 -0700
Subject: [PATCH] Add source port option for DTLS
In-Reply-To: <1340501525.24790.1.camel@shinybook.infradead.org>
References: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
 <1340501525.24790.1.camel@shinybook.infradead.org>
Message-ID: <EB037D1A-1C9A-4A8C-A2CE-9E896B1BA11C@x2.hamachi.us>


On Jun 23, 2012, at 6:32 PM, David Woodhouse wrote:

> On Sat, 2012-06-23 at 12:08 -0700, Steven Ihde wrote:
>> The attached patch adds support for a "--dtls-source-port" option to
>> set the source port for DTLS datagrams.  For example, to ease firewall
>> configuration.  Comments welcome.
> 
> Looks sane enough at first glance; thanks. Perhaps 'local' port rather
> than 'source' port, since it's bidirectional? And the man page needs
> updating to match, and it needs a Signed-off-by: as described at
> http://www.infradead.org/openconnect/contribute.html
> 

Thanks for the pointers.  I will update and resubmit.  I had also considered "bind" port but on balance I agree "local" port is the best description.

-Steve




From steve at x2.hamachi.us  Sat Jun 23 23:49:32 2012
From: steve at x2.hamachi.us (Steven Ihde)
Date: Sat, 23 Jun 2012 20:49:32 -0700
Subject: [PATCH] Add source port option for DTLS
In-Reply-To: <1340501525.24790.1.camel@shinybook.infradead.org>
References: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
 <1340501525.24790.1.camel@shinybook.infradead.org>
Message-ID: <0C49BC04-2485-4CEA-AA9A-4CF58D0CEA48@x2.hamachi.us>


On Jun 23, 2012, at 6:32 PM, David Woodhouse wrote:

> On Sat, 2012-06-23 at 12:08 -0700, Steven Ihde wrote:
>> The attached patch adds support for a "--dtls-source-port" option to
>> set the source port for DTLS datagrams.  For example, to ease firewall
>> configuration.  Comments welcome.
> 
> Looks sane enough at first glance; thanks. Perhaps 'local' port rather
> than 'source' port, since it's bidirectional? And the man page needs
> updating to match, and it needs a Signed-off-by: as described at
> http://www.infradead.org/openconnect/contribute.html

Updated the patch per comments; attached.  

Signed-off-by: Steven Ihde <sihde at hamachi.us>

Thanks,

Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtls-local-port.patch
Type: application/octet-stream
Size: 3676 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120623/04f3d47b/attachment.obj>

From dwmw2 at infradead.org  Mon Jun 25 16:22:29 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 25 Jun 2012 22:22:29 +0200
Subject: [PATCH] Add source port option for DTLS
In-Reply-To: <0C49BC04-2485-4CEA-AA9A-4CF58D0CEA48@x2.hamachi.us>
References: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
 <1340501525.24790.1.camel@shinybook.infradead.org>
 <0C49BC04-2485-4CEA-AA9A-4CF58D0CEA48@x2.hamachi.us>
Message-ID: <1340655749.20392.9.camel@shinybook.infradead.org>

On Sat, 2012-06-23 at 20:49 -0700, Steven Ihde wrote:
> Signed-off-by: Steven Ihde <sihde at hamachi.us>

Thanks. Applied with a couple of minor modifications (most notable being
that port zero is disabled).

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120625/3f513460/attachment.bin>

From orinlunder at gmail.com  Tue Jun 26 08:34:26 2012
From: orinlunder at gmail.com (Orin L.)
Date: Tue, 26 Jun 2012 07:34:26 -0500
Subject: Running OC as Root: Security Implications?
Message-ID: <CAGix_5zrssjj2EoAB0kU+755Kwxi+DOio-j2W=pA5127TEe3iA@mail.gmail.com>

Hello All,

I have read that any "internet facing" user application should not be
run with root privileges.  The OpenConnect website seems to reflect
this sentiment by touting the ability of OpenConnect to run without
root privileges.  As a very security-conscious user, I feel a bit
uneasy about executing a networking application (OpenConnect VPN
client) as root.  Could running OpenConnect as root open my desktop
system to potential security threats?  (I'm aware that the
network-manager plugin allows avoidance of root-privileged execution,
but I do not wish to install network-manager on my system.)

Thanks,

OL


From dwmw2 at infradead.org  Tue Jun 26 09:04:41 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 26 Jun 2012 14:04:41 +0100
Subject: Running OC as Root: Security Implications?
In-Reply-To: <CAGix_5zrssjj2EoAB0kU+755Kwxi+DOio-j2W=pA5127TEe3iA@mail.gmail.com>
References: <CAGix_5zrssjj2EoAB0kU+755Kwxi+DOio-j2W=pA5127TEe3iA@mail.gmail.com>
Message-ID: <1340715881.23729.18.camel@shinybook.infradead.org>

On Tue, 2012-06-26 at 07:34 -0500, Orin L. wrote:
>  Could running OpenConnect as root open my desktop
> system to potential security threats?

Theoretically, yes. It's vaguely possible that if there were a bug in
OpenConnect, a malicious server *might* be able to exploit it.

You're better off with OpenConnect than with Cisco's own client, which
also ran as root ? we *know* that Cisco's client had stupid bugs, such
as opening fixed filenames in /tmp ? thus allowing any unprivileged user
on the system to trick it into overwriting *any* file on the system, as
root, just by making a symlink to the victim file from /tmp!

And that's just the one we happened to notice; we haven't been able to
do a full security audit of the Cisco code, or ensure that it's built
with PIE or any of the other protection measures which are normal these
days for Linux distributions.

Note that you don't necessarily need NetworkManager if you want to run
OpenConnect as non-root. One option doesn't need root at all; you could
even do it on a machine that someone else owns. Just use the
'--script-tun' option and it'll pass all its packets to stdin/stdout of
a separate program, instead of to a tun device. That program can listen
as a SOCKS server on the local machine, and forward all the connections
into the VPN. There's an implementation of such a server at
http://dme.org/ocproxy (Thanks David for sending that).

Or if you want to keep it simple and you *do* actually want to route
packets "properly" from your host to the VPN, you can still run
OpenConnect as an unprivileged user. On Linux you can create the tun
device in advance and assign it to the appropriate user with 'ip
tuntap', and tell OpenConnect the name of the device you want it to use.
Then it's just case of *configuring* the network according to the
information you get from the server, which is all done by vpnc-script
anyway, not OpenConnect itself. It shouldn't be hard to contrive
something which runs instead of vpnc-script, which just passes all the
configuration information back to a small tool that *does* run as root.
Or maybe you could make a setuid wrapper for vpnc-script so that only
*it* runs with root privs. You'd want to vet its input very carefully, I
suspect.

OpenConnect has a --setuid option which makes it drop privileges after
connecting, but then it doesn't have those privs when it runs
vpnc-script a second time to disconnect ? so it can't put your DNS back
to normal, and your default route. It's only really useful if you don't
*use* a default route on the VPN, or VPN DNS.

Perhaps we should patch OpenConnect so that it can fork before
connecting, and do *almost* everything as root except invoking
vpnc-script. The parent can remain root, while the child becomes an
unprivileged user and does the network part. The child can pass the
network information over a UNIX socket back to the parent, which invokes
vpnc-script. And then waits for the child to die before invoking
vpnc-script a second time to disconnect.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120626/4730dde9/attachment.bin>

From orinlunder at gmail.com  Wed Jun 27 02:51:49 2012
From: orinlunder at gmail.com (Orin L.)
Date: Wed, 27 Jun 2012 01:51:49 -0500
Subject: Running OC as Root: Security Implications?
In-Reply-To: <1340715881.23729.18.camel@shinybook.infradead.org>
References: <CAGix_5zrssjj2EoAB0kU+755Kwxi+DOio-j2W=pA5127TEe3iA@mail.gmail.com>
 <1340715881.23729.18.camel@shinybook.infradead.org>
Message-ID: <CAGix_5xEHWbDP3w=jFawJnYRAEXKB+EZ6rkvjwsMu0J3UOTAsg@mail.gmail.com>

David,

Thanks so much for your quick response.  I have inserted a couple more
questions prompted by your answer.

On Tue, Jun 26, 2012 at 8:04 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2012-06-26 at 07:34 -0500, Orin L. wrote:
>> ?Could running OpenConnect as root open my desktop
>> system to potential security threats?
>
> Theoretically, yes. It's vaguely possible that if there were a bug in
> OpenConnect, a malicious server *might* be able to exploit it.

Only the connected VPN server (i.e. no attackers at large on the
internet) would have a chance of exploting such a vulnerability?

> Just use the
> '--script-tun' option and it'll pass all its packets to stdin/stdout of
> a separate program, instead of to a tun device. That program can listen
> as a SOCKS server on the local machine, and forward all the connections
> into the VPN. There's an implementation of such a server at
> http://dme.org/ocproxy (Thanks David for sending that).

For security reasons, I typically only use software supplied through
official repositories.  Has ocproxy from dme.org been carefully
examined and vetted by the OpenConnect team?  What's the method for
running "run-ocvpn.sh"?  That is, should the "ocvpn" directory be
placed inside one of the directories created upon installing lwip from
a repository?

> Or if you want to keep it simple and you *do* actually want to route
> packets "properly" from your host to the VPN, you can still run
> OpenConnect as an unprivileged user. On Linux you can create the tun
> device in advance and assign it to the appropriate user with 'ip
> tuntap', and tell OpenConnect the name of the device you want it to use.
> Then it's just case of *configuring* the network according to the
> information you get from the server, which is all done by vpnc-script
> anyway, not OpenConnect itself. It shouldn't be hard to contrive
> something which runs instead of vpnc-script, which just passes all the
> configuration information back to a small tool that *does* run as root.

This seems to require some expertise.  This is all I'm aware of:
#as root
ip tuntap add dev vpn0 user xxxxxxxx mode tun
#does vpn0 then have to be configured somehow?  If so, how?  Does
having a persistent tun device on my system open it up to potential
threats?

#as normal user
openconnect --interface vpn0 https://vpn.domain.com/
#is this correct?

Thanks,

OL


From dwmw2 at infradead.org  Wed Jun 27 04:51:33 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Jun 2012 09:51:33 +0100
Subject: Running OC as Root: Security Implications?
In-Reply-To: <CAGix_5xEHWbDP3w=jFawJnYRAEXKB+EZ6rkvjwsMu0J3UOTAsg@mail.gmail.com>
References: <CAGix_5zrssjj2EoAB0kU+755Kwxi+DOio-j2W=pA5127TEe3iA@mail.gmail.com>
 <1340715881.23729.18.camel@shinybook.infradead.org>
 <CAGix_5xEHWbDP3w=jFawJnYRAEXKB+EZ6rkvjwsMu0J3UOTAsg@mail.gmail.com>
Message-ID: <1340787093.23729.98.camel@shinybook.infradead.org>

On Wed, 2012-06-27 at 01:51 -0500, Orin L. wrote:
> Only the connected VPN server (i.e. no attackers at large on the
> internet) would have a chance of exploting such a vulnerability?

Fairly much, yes. It's vaguely possible for someone with a packet
sniffer in the path between you and the server to see your TCP or UDP
traffic and maybe inject a packet ? but almost impossible for them to
get the MAC on that packet correct, which will result in the TCP
connection closing, or their UDP packet being silently discarded.

And of course, such a vulnerability shouldn't exist. 

> > Just use the
> > '--script-tun' option and it'll pass all its packets to stdin/stdout of
> > a separate program, instead of to a tun device. That program can listen
> > as a SOCKS server on the local machine, and forward all the connections
> > into the VPN. There's an implementation of such a server at
> > http://dme.org/ocproxy (Thanks David for sending that).
> 
> For security reasons, I typically only use software supplied through
> official repositories.  Has ocproxy from dme.org been carefully
> examined and vetted by the OpenConnect team?

No. David only mentioned it to me on Monday, in fact. I've got as far as
downloading it, browsing briefly through its source code, and running it
once as a test.

>  What's the method for running "run-ocvpn.sh"?  That is, should the
> "ocvpn" directory be placed inside one of the directories created upon
> installing lwip from a repository?

Your guess ought to be as good as mine. I looked for a Makefile and
eventually found one in contrib/ports/unix/proj/ocvpn/ which seemed to
build the lwIP parts too. (To be fair, I used to know it worked like
that, when I was hacking on it a little myself.)

Then the run-ocvpn.sh script seems like it should run directly from the
build directory ? it invokes openconnect with '--script $(PWD)/ocvpn.sh'
and then ocvpn.sh invokes the actual lwIP code with "./ocvpn". I don't
think the niceties of installation have really been addressed yet ;)

> This seems to require some expertise.  This is all I'm aware of:
> #as root
> ip tuntap add dev vpn0 user xxxxxxxx mode tun
> #does vpn0 then have to be configured somehow?  If so, how? 

Yes. It needs to be given the IP address that you obtain from the VPN
server. If that's a *static* address then you can easily do it in
advance ? you don't even need to use vpnc-script to get the information
from openconnect.

And any routing needs to be set up too, of course.

>  Does having a persistent tun device on my system open it up to potential
> threats?

It means that the user 'xxxxxxxx' who owns the tun device can always
open it and send/receive packets.

> #as normal user
> openconnect --interface vpn0 https://vpn.domain.com/
> #is this correct?

Yes. And then you might want to set up some wrapper for vpnc-script
which *configures* the vpn0 device somehow. Or which just gives the
IP/routing/DNS information back to another process which is already
running as root, perhaps. I don't much like the idea of making
vpnc-script setuid so it can be freely invoked :)
 
-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120627/b5076ff2/attachment.bin>

From jack at codezen.org  Wed Jun 27 13:09:34 2012
From: jack at codezen.org (Jack Miller)
Date: Wed, 27 Jun 2012 12:09:34 -0500
Subject: CSTP reconnect segfault on HEAD
Message-ID: <20120627170934.GA18664@sagan.watson.ibm.com>

All -

First of all, I've used openconnect for quite awhile and it's been nothing
but solid, so thanks.

Recently, I noticed that it's been segfaulting about every hour, so I built
from git and fired it up in GDB. I got this backtrace:

---------------------8<---------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
queue_packet (q=<optimized out>, q at entry=0x62fd78, new=0x0) at mainloop.c:40
40              new->next = NULL;
(gdb) bt
#0  queue_packet (q=<optimized out>, q at entry=0x62fd78, new=0x0)
    at mainloop.c:40
#1  0x00000000004081fb in cstp_reconnect (vpninfo=vpninfo at entry=0x62f7c0)
    at cstp.c:535
#2  0x0000000000406a98 in dtls_mainloop (vpninfo=vpninfo at entry=0x62f7c0, 
    timeout=timeout at entry=0x7fffffffe07c) at dtls.c:725
#3  0x0000000000409003 in vpn_mainloop (vpninfo=vpninfo at entry=0x62f7c0)
    at mainloop.c:90
#4  0x0000000000403fe2 in main (argc=6, argv=0x7fffffffe6b8) at main.c:852
(gdb) 
--------------------------------------------------------------------------

Obviously, on the surface, new is NULL dereferenced which is no good. I made
a shallow patch that bails out of queue_packet() if !new which appears to
work, but considering this has worked for so long before I imagine that an
assumption higher up has been broken.

I'm invoking with:
--script=/etc/vpnc/vpnc-script --user=[myuser] --syslog --no-deflate [vpn
target]

I've reproduced this on 3.18+ and this trace is from HEAD. I'm running Arch
Linux with kernels 3.3.2 - 3.4.4. I can't vouch for the sanity of or any
changes in company's VPN setup other than the fact that it was working before
and other clients don't seem to object to it. Let me know if I can provide
any more information.

- Jack


From dwmw2 at infradead.org  Wed Jun 27 15:06:19 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Jun 2012 20:06:19 +0100
Subject: CSTP reconnect segfault on HEAD
In-Reply-To: <20120627170934.GA18664@sagan.watson.ibm.com>
References: <20120627170934.GA18664@sagan.watson.ibm.com>
Message-ID: <1340823979.17626.12.camel@shinybook.infradead.org>

On Wed, 2012-06-27 at 12:09 -0500, Jack Miller wrote:
> #0  queue_packet (q=<optimized out>, q at entry=0x62fd78, new=0x0)
>     at mainloop.c:40
> #1  0x00000000004081fb in cstp_reconnect (vpninfo=vpninfo at entry=0x62f7c0)
>     at cstp.c:535 

Thanks for the clear report. It's rare that a bug report leads me
straight to the fix, and it's nice when it happens.

The problem is in cstp_reconnect() in frame #1, and it arises because
you have --no-deflate on the command line. (Why, btw?)

On reconnect, we check if the pending packet to be sent is the special
'deflate_pkt', which contains the compressed version of a packet. If so,
we requeue the *original* packet, since the compression will reset with
the new connection.

However, the check 'vpninfo->current_ssl_pkt == vpninfo->deflate_pkt' is
still true even when both of those pointers are NULL, because there's no
pending packet to be sent and the 'deflate_pkt' was never allocated
because we aren't doing compression today. So we try to requeue the
packet, which is NULL...

Your patch was actually perfectly sufficient, but this is the better fix
which I'll push to the repository if you can confirm that it's working:

From 7d9bf34daa595da0d876bd594f91e2ee947f398b Mon Sep 17 00:00:00 2001
From: David Woodhouse <David.Woodhouse at intel.com>
Date: Wed, 27 Jun 2012 19:58:55 +0100
Subject: [PATCH] Fix SEGV on cstp_reconnect() without deflate

Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
---
 cstp.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cstp.c b/cstp.c
index ab5eba9..4da4698 100644
--- a/cstp.c
+++ b/cstp.c
@@ -529,13 +529,13 @@ int cstp_reconnect(struct openconnect_info *vpninfo)
 
 	openconnect_close_https(vpninfo, 0);
 
-	/* Requeue the original packet that was deflated */
-	if (vpninfo->current_ssl_pkt == vpninfo->deflate_pkt) {
-		vpninfo->current_ssl_pkt = NULL;
-		queue_packet(&vpninfo->outgoing_queue, vpninfo->pending_deflated_pkt);
-		vpninfo->pending_deflated_pkt = NULL;
-	}
 	if (vpninfo->deflate) {
+		/* Requeue the original packet that was deflated */
+		if (vpninfo->current_ssl_pkt == vpninfo->deflate_pkt) {
+			vpninfo->current_ssl_pkt = NULL;
+			queue_packet(&vpninfo->outgoing_queue, vpninfo->pending_deflated_pkt);
+			vpninfo->pending_deflated_pkt = NULL;
+		}
 		inflateEnd(&vpninfo->inflate_strm);
 		deflateEnd(&vpninfo->deflate_strm);
 	}
-- 
1.7.10.2



-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120627/a4a988ac/attachment.bin>

From dwmw2 at infradead.org  Wed Jun 27 16:16:10 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Jun 2012 21:16:10 +0100
Subject: CSTP reconnect segfault on HEAD
In-Reply-To: <20120627170934.GA18664@sagan.watson.ibm.com>
References: <20120627170934.GA18664@sagan.watson.ibm.com>
Message-ID: <1340828170.17626.16.camel@shinybook.infradead.org>

On Wed, 2012-06-27 at 12:09 -0500, Jack Miller wrote:
> Recently, I noticed that it's been segfaulting about every hour, so I
> built from git and fired it up in GDB. I got this backtrace:

Secondary concern: why in hell are you seeing a CSTP reconnect every
hour anyway? Is this happening even while the connection is in use?

Can you show the output of openconnect with the '-v' option as you
connect, and also as the disconnect/reconnect happens?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120627/92366eac/attachment.bin>

From jack at codezen.org  Wed Jun 27 16:39:43 2012
From: jack at codezen.org (Jack Miller)
Date: Wed, 27 Jun 2012 15:39:43 -0500
Subject: CSTP reconnect segfault on HEAD
In-Reply-To: <1340823979.17626.12.camel@shinybook.infradead.org>
References: <20120627170934.GA18664@sagan.watson.ibm.com>
 <1340823979.17626.12.camel@shinybook.infradead.org>
Message-ID: <20120627203943.GA9232@sagan.watson.ibm.com>

On Wed, Jun 27, 2012 at 08:06:19PM +0100, David Woodhouse wrote:
> The problem is in cstp_reconnect() in frame #1, and it arises because
> you have --no-deflate on the command line. (Why, btw?)

I'm embarassed to say I don't know. I added it to my network script that way
because it was listed in an internal wiki on how to migrate from whatever
awful blob they forced on us before =). It worked, so I never touched it
again.

> 
> On reconnect, we check if the pending packet to be sent is the special
> 'deflate_pkt', which contains the compressed version of a packet. If so,
> we requeue the *original* packet, since the compression will reset with
> the new connection.
> 
> However, the check 'vpninfo->current_ssl_pkt == vpninfo->deflate_pkt' is
> still true even when both of those pointers are NULL, because there's no
> pending packet to be sent and the 'deflate_pkt' was never allocated
> because we aren't doing compression today. So we try to requeue the
> packet, which is NULL...

Ah, of course.

> 
> Your patch was actually perfectly sufficient, but this is the better fix
> which I'll push to the repository if you can confirm that it's working:
>

It's been running for over an hour, so I can say that it looks good here.

- Jack


From jack at codezen.org  Wed Jun 27 18:07:16 2012
From: jack at codezen.org (Jack Miller)
Date: Wed, 27 Jun 2012 17:07:16 -0500
Subject: CSTP reconnect segfault on HEAD
In-Reply-To: <1340828170.17626.16.camel@shinybook.infradead.org>
References: <20120627170934.GA18664@sagan.watson.ibm.com>
 <1340828170.17626.16.camel@shinybook.infradead.org>
Message-ID: <20120627220716.GB9232@sagan.watson.ibm.com>

On Wed, Jun 27, 2012 at 09:16:10PM +0100, David Woodhouse wrote:
> On Wed, 2012-06-27 at 12:09 -0500, Jack Miller wrote:
> > Recently, I noticed that it's been segfaulting about every hour, so I
> > built from git and fired it up in GDB. I got this backtrace:
> 
> Secondary concern: why in hell are you seeing a CSTP reconnect every
> hour anyway? Is this happening even while the connection is in use?

Yes, I've had it disconnect me quite a bit while in the middle of long-ish
transfers.

> 
> Can you show the output of openconnect with the '-v' option as you
> connect, and also as the disconnect/reconnect happens?

I've appended the relevant sections of the log and redacted some of the
network topology stuff - better safe than sorry. It appears that it's just
configured that way (DTLS-Rekey-Time = 3600). As I mentioned before, I can't
comment on the validity of the setup =).

- Jack

--------------------------------------------------------------------------
Attempting to connect to []:443
SSL negotiation with []
Matched DNS altname '[]'
Connected to HTTPS on []
GET https://[]/
Got HTTP response: HTTP/1.0 302 Object Moved
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Wed, 27 Jun 2012 20:44:33 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
HTTP body length:  (0)
SSL negotiation with []
Matched DNS altname '[]'
Connected to HTTPS on []
GET https://[]/+webvpn+/index.html
Got HTTP response: HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpn=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpnc=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpnlogin=1; secure
X-Transcend-Version: 1
HTTP body chunked (-2)
Fixed options give 
POST https://[]/+webvpn+/index.html
Got HTTP response: HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Cache-Control: max-age=0
Set-Cookie: webvpnlogin=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
Set-Cookie: webvpn=<elided>; path=/; secure
Set-Cookie: webvpnc=bu:/CACHE/stc/&p:t&iu:1/&sh:CB201E91F1BA1E094A5648B92EF6B7BE121DCF94&lu:/+CSCOT+/translation-table?textdomain%3DAnyConnect%26type%3Dmanifest&fu:profiles%2FWatsonProfile.xml&fh:BC1A54FB5A8DDAF76F18FF9E9D5474CCAB8663B1; path=/; secure
Set-Cookie: webvpnx=
Set-Cookie: webvpnaac=1; path=/; secure
X-Transcend-Version: 1
HTTP body chunked (-2)
TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1448, pmtu 1500
Got CONNECT response: HTTP/1.1 200 OK
...
X-DTLS-Rekey-Time: 3600
X-CSTP-MTU: 1355
X-DTLS-CipherSuite: AES256-SHA
X-CSTP-Routing-Filtering-Ignore: false
X-CSTP-Quarantine: false
X-CSTP-Disable-Always-On-VPN: false
X-CSTP-TCP-Keepalive: true
CSTP connected. DPD 30, Keepalive 20
DTLS option X-DTLS-Session-ID : 245CBA11166427EAB403833741BFF884BC02781F1B4BBE384408843CD1BDD914
DTLS option X-DTLS-Port : 443
DTLS option X-DTLS-Keepalive : 20
DTLS option X-DTLS-DPD : 30
DTLS option X-DTLS-Rekey-Time : 3600
DTLS option X-DTLS-CipherSuite : AES256-SHA
DTLS connected. DPD 30, Keepalive 20
Connected tun0 as [], using SSL
--------------------------------------------------------------------------

Then, it's pretty much identical chatter for the rekey. This is running the
patch from your previous mail, so it didn't crash.

--------------------------------------------------------------------------
DTLS rekey due
SSL negotiation with []
Matched DNS altname '[]'
Connected to HTTPS on []
TCP_INFO rcv mss 1368, snd mss 1368, adv mss 1448, pmtu 1500
Got CONNECT response: HTTP/1.1 200 OK
X-CSTP-Version: 1
...
X-CSTP-Keep: true
X-CSTP-Rekey-Time: 3600
X-CSTP-Rekey-Method: new-tunnel
X-CSTP-DPD: 30
X-CSTP-Keepalive: 20
X-CSTP-MSIE-Proxy-Lockdown: true
X-CSTP-Smartcard-Removal-Disconnect: true
X-DTLS-Session-ID: 25030952259265BACC034C81E78C596268E4C09863D72B9070617F96D5905796
X-DTLS-Port: 443
X-DTLS-Keepalive: 20
X-DTLS-DPD: 30
X-DTLS-Rekey-Time: 3600
X-CSTP-MTU: 1355
X-DTLS-CipherSuite: AES256-SHA
X-CSTP-Routing-Filtering-Ignore: false
X-CSTP-Quarantine: false
X-CSTP-Disable-Always-On-VPN: false
X-CSTP-TCP-Keepalive: true
CSTP connected. DPD 30, Keepalive 20
No work to do; sleeping for 20000 ms...
No work to do; sleeping for 20000 ms...
Established DTLS connection (using OpenSSL)
--------------------------------------------------------------------------


From dwmw2 at infradead.org  Wed Jun 27 18:57:14 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 27 Jun 2012 23:57:14 +0100
Subject: CSTP reconnect segfault on HEAD
In-Reply-To: <20120627220716.GB9232@sagan.watson.ibm.com>
References: <20120627170934.GA18664@sagan.watson.ibm.com>
 <1340828170.17626.16.camel@shinybook.infradead.org>
 <20120627220716.GB9232@sagan.watson.ibm.com>
Message-ID: <1340837834.17626.47.camel@shinybook.infradead.org>

On Wed, 2012-06-27 at 17:07 -0500, Jack Miller wrote:
> I've appended the relevant sections of the log and redacted some of the
> network topology stuff - better safe than sorry. It appears that it's just
> configured that way (DTLS-Rekey-Time = 3600). As I mentioned before, I can't
> comment on the validity of the setup =). 

Hm, we do reconnect the CSTP connection for a DTLS rekey; I'm not sure
we need to. I knocked up a quick patch to "fix" that, but then noticed
that your server is actually asking for a CSTP rekey every 3600 seconds
*too*. So yeah, your server is configured to request that, and I don't
think there's a lot we can do about it. Perhaps we could optimise for
it, and do it asynchronously rather than blocking data traffic while we
reconnect the TCP connection. But mostly I'm inclined to suggest that it
is a silly configuration on the part of your server, and not worry about
it... unless you care enough to submit a patch :)

(CSTP is the TCP/HTTPS control connection, while DTLS is UDP and is what
we use for the actual network traffic wherever possible.)

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120627/2e0d3441/attachment.bin>

From dwmw2 at infradead.org  Thu Jun 28 08:36:36 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jun 2012 13:36:36 +0100
Subject: [PATCH] Add source port option for DTLS
In-Reply-To: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
References: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
Message-ID: <1340886996.26748.19.camel@shinybook.infradead.org>

On Sat, 2012-06-23 at 12:08 -0700, Steven Ihde wrote:
> The attached patch adds support for a "--dtls-source-port" option to
> set the source port for DTLS datagrams.  For example, to ease firewall
> configuration.  Comments welcome.

Have you tested this with DTLS reconnection, or DPD kicking in?

Try *temporarily* firewalling the UDP traffic until OpenConnect detects
that the peer is dead and tries to remake the connection. Does it
*work*, when it tries to use the same local port again for a second
connection? You may want a further patch to close the old DTLS socket
*first*, rather than trying to keep it around until the new one is up
and running.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120628/b074b807/attachment.bin>

From dwmw2 at infradead.org  Thu Jun 28 08:41:01 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jun 2012 13:41:01 +0100
Subject: OpenConnect 4.01 release
Message-ID: <1340887261.26748.23.camel@shinybook.infradead.org>

This fixes a crash which has been present since v3.16 on CSTP reconnect
with compression disabled. It also deals with the fact that GnuTLS DTLS
support would silently truncate outbound packets above 1185 bytes due to
an overly pessimistic default MTU setting. And a build fix for FreeBSD 8
and earlier, and other systems without O_CLOEXEC.

A patch from Steven Ihde adds a --dtls-local-port option to make it
easier to poke holes in overzealous firewalls.

Finally some translation updates, now that the strings from OpenConnect
have been artificially imported into the NetworkManager-openconnect
repository where the GNOME translation teams can see them.

ftp://ftp.infradead.org/pub/openconnect/openconnect-4.01.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-4.01.tar.gz.asc

David Woodhouse (11):
      Don't require zlib in pkgconfig if it was found without it
      Print correct error when /dev/net/tun open fails
      Rebuild openconnect.8 if necessary before openconnect.8.inc
      Import translations from GNOME
      Transifex import: Reduce churn, and don't forget to add new translations
      Update translations from Transifex
      Fix build on systems without O_CLOEXEC
      Clean up Transifex import some more
      Fix SEGV on cstp_reconnect() without deflate
      Fix DTLS MTU for GnuTLS
      Tag version 4.01

Steven Ihde (1):
      Add source port option for DTLS

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120628/faed9024/attachment-0001.bin>

From dwmw2 at infradead.org  Thu Jun 28 09:13:01 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jun 2012 14:13:01 +0100
Subject: OpenConnect 4.01 release
In-Reply-To: <1340887261.26748.23.camel@shinybook.infradead.org>
References: <1340887261.26748.23.camel@shinybook.infradead.org>
Message-ID: <1340889181.26748.27.camel@shinybook.infradead.org>

Oops, that didn't build for anyone who didn't have GnuTLS v3; it
unconditionally includes <gnutls/dtls.h> even when building with OpenSSL
or with older versions of GnuTLS which don't have that header.

There will be an OpenConnect 4.02 release shortly, once I've got over
the embarrassment...

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/e70e06e4

Thanks to Stuart Henderson for pointing it out... just an hour or so too
late ?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120628/f73d818d/attachment.bin>

From dwmw2 at infradead.org  Thu Jun 28 10:59:45 2012
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 28 Jun 2012 15:59:45 +0100
Subject: OpenConnect 4.02 release
Message-ID: <1340895585.26748.30.camel@shinybook.infradead.org>

OK, I *was* planning to start pushing the idea that GnuTLS is the
preferred crypto library. But not this hard, this soon. The 4.01 release
would unconditionally include <gnutls/dtls.h>, which is only available
from GnuTLS v3. Not so clever.

ftp://ftp.infradead.org/pub/openconnect/openconnect-4.02.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-4.02.tar.gz.asc

David Woodhouse (2):
      Fix build failure on systems without GnuTLS v3
      Tag version 4.02

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120628/d6ab2fb9/attachment.bin>

From steve at x2.hamachi.us  Thu Jun 28 14:44:41 2012
From: steve at x2.hamachi.us (Steven Ihde)
Date: Thu, 28 Jun 2012 11:44:41 -0700
Subject: [PATCH] Add source port option for DTLS
In-Reply-To: <1340886996.26748.19.camel@shinybook.infradead.org>
References: <FDAB80DE-7826-497A-9BCD-617A5B7EFD83@x2.hamachi.us>
 <1340886996.26748.19.camel@shinybook.infradead.org>
Message-ID: <0F83B045-43A5-4771-8361-681309C5A43E@x2.hamachi.us>


On Jun 28, 2012, at 5:36 AM, David Woodhouse wrote:

> On Sat, 2012-06-23 at 12:08 -0700, Steven Ihde wrote:
>> The attached patch adds support for a "--dtls-source-port" option to
>> set the source port for DTLS datagrams.  For example, to ease firewall
>> configuration.  Comments welcome.
> 
> Have you tested this with DTLS reconnection, or DPD kicking in?

No, I haven't.  

> 
> Try *temporarily* firewalling the UDP traffic until OpenConnect detects
> that the peer is dead and tries to remake the connection. Does it
> *work*, when it tries to use the same local port again for a second
> connection? You may want a further patch to close the old DTLS socket
> *first*, rather than trying to keep it around until the new one is up
> and running.

Good suggestions.  I will give it a try this evening and submit a followup patch if needed.

-Steve



