From dwmw2 at infradead.org  Mon Mar  3 15:53:40 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 03 Mar 2014 20:53:40 +0000
Subject: IPv6 split tunneling  support for Linux
In-Reply-To: <8A3144A29401DA46A1D1C88FD08AF2AB3FB3652C@CZ-EXC004.alefnula.com>
References: <8A3144A29401DA46A1D1C88FD08AF2AB3FB3652C@CZ-EXC004.alefnula.com>
Message-ID: <1393880020.26619.184.camel@i7.infradead.org>

On Wed, 2014-02-26 at 10:02 +0000, Tomas Moser wrote:
> 
> Does OpenConnect support IPv6 split tunneling feature or not? If not
> when do you expect it will? I do not understand changelog clearly -
> http://www.infradead.org/openconnect/changelog.html.

Yes, it does. The recent commit you see in the changelog? basically just
sends the extra header which *requests* a split tunnel config from the
ASA. Without that, the server wouldn't send the right routing
information.

I'm guessing they did that because Cisco's own client wasn't capable of
doing things properly in the past so it needs an explicit request from a
newer client to enable it.

OpenConnect and vpnc-script have supported split tunnels ever since IPv6
support was added though ? it never made any sense to do a half-arsed
job and *not* make it work the same as Legacy IP. It's just that we
didn't realise that we needed to explicitly *tell* the server we weren't
brain-dead.

> Our customer wants to buy Cisco ASA platform but strictly insists on
> AnyConnect supporting IPv6  on Linux platform. Cisco states there is
> NO IPv6 support at all in the latest AnyConnect release 3.1.x for
> Linux. I am looking for an alternative solution.

Cisco's own client is worse than just not supporting IPv6. It actually
*crashes*, in a *setuid* executable (vpnagentd) if you happen to have an
IPv6 address on a local Ethernet interface when you start it up. I
didn't look to see if it was exploitable like their tmpfile races used
to be when I first started on OpenConnect; when it comes to Cisco's
crappy clients I really am beyond caring these days.

> Is there any document summarizing OpenConnect IPv6 support for
> different platforms?

This is the 21st century. Any platform mentioned at
http://www.infradead.org/openconnect/platforms.html has been tested with
IPv6 and not just Legacy IP. What kind of Luddites do you think we
are? :)

-- 
dwmw2

? http://git.infradead.org/users/dwmw2/openconnect.git/commit/e9b90e7b3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140303/d9abee26/attachment.bin>

From dwmw2 at infradead.org  Wed Mar  5 06:29:59 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 Mar 2014 11:29:59 +0000
Subject: OpenConnect 5.99 release
Message-ID: <1394018999.21141.65.camel@i7.infradead.org>

This is the beta release for 6.0, with lots of shiny changes.

I'm not entirely convinced that the x.99 "releases" actually get that
much worthwhile testing, but they certainly don't hurt. Mostly this is a
call for Kevin and Nikos to bug me about anything they still have
outstanding that they really want in the 6.00 release...


This release adds support for Windows (32-bit and 64-bit builds with
MinGW), and basic support for RFC4226 HOTP tokens (although there's no
way to *store* the HOTP token counter).

It also adds split tunnelling support for IPv6 ? which always would have
worked, in fact, but we need to explicitly *tell* the server that we
support it in order to receive an appropriate configuration.

It moves the VPN mainloop functionality into libopenconnect so that it
can be invoked through the library instead of having to spawn a separate
openconnect process ? and adds Java bindings for libopenconnect.

There are also various crypto-related improvements, such as the ability
to enforce Perfect Forward Secrecy and new cipher suites in DTLS with
lower overhead. 


Antonio Borneo (2):
      fix bug in run_csd_script()
      Fix --os=win

David Woodhouse (97):
      Merge OpenConnect v5.03 bugfix
      Do not use mmap() for reading XML config file
      Fix cert expiry warning for Windows, which lacks gmtime_r()
      Unify $host_os case statement in configure.ac
      Add compatibility for systems lacking setenv() and unsetenv()
      Start to clean up includes for MinGW build.
      Add -no-undefined to libtool invocation
      Add compatibility inet_aton() function for MinGW build
      Use closesocket() and fix errno handling for MinGW
      Set GnuTLS push/pull/errno functions on MinGW build
      Open files in binary mode on MingGW
      Fix setsockopt() warning on MinGW build
      Use send() and recv() for proxy communication (for MinGW's benefit)
      Disable CSD for MingGW build, make http.c build
      Provide pipe() for MinGW build
      Add openconnect_passphrase_from_fsid() implementation for MinGW
      Add set_sock_nonblock() and set_fd_cloexec() compat functions
      Make tun.c build for MinGW
      Disable --script-tun option on MinGW
      Disable --syslog option on MinGW
      Fix read_stdin() for MingGW
      Disable --setuid, --csd-user and --csd-wrapper options on MinGW
      Disable hostname discovery on MinGW
      Disable signal handling on MinGW
      Disable --background and --pid-file options on MinGW
      Hide GnuTLS MinGW push/pull functions when building with OpenSSL
      Add openconnect__win32_sock_init() function to initialise sockets
      Reorder header files to include <winsock2.h> before <windows.h>
      Update changelog to reflect MinGW status
      Add GnuTLS recv_timeout function for MinGW
      Remove FSF address from copyright boilerplate
      Update copyright year
      Add basic support for opening Windows TAP driver
      Import dumb_socketpair() and enable command fd for MinGW
      Fix Windows error translation to make GnuTLS happy
      Fix Windows set_sock_nonblock()
      Fix setenv() with value==NULL on Windows
      Remove Windows-specific pull/push/errno functions for GnuTLS
      Move DTLS reconnect handling into dtls.c
      Introduce dtls_state variable to make reconnect handling cleaner
      Kill new_dtls_* variables
      Fix up comment on GnuTLS dtls_ssl field
      Abstract select() and FD_SET handling
      Add event handling for Windows
      Finally add tun handling for Windows
      Make web pages work in out-of-tree builds
      Remove obsolete VAR_CVSID variable
      Remove references to Symbian
      Use intptr_t for intermediate cast to gnutls_transport_ptr_t
      Fix overflow warning in dumb_socketpair() on Win64
      Fix Windows openconnect_passphrase_from_fsid()
      Avoid building against GnuTLS v3.2.0-v3.2.9 on Windows
      Print a message when ignoring a TAP device due to --interface option
      Fix error printing when registry open fails
      Print error when no TAP interfaces found
      Move vpnc-script handling after platform detection in configure.ac
      Clean up default vpnc-script handling for Windows
      Update vpnc-script documentation for Windows
      Update build documentation
      Move set_script_env() to script.c
      Move script_config_tun() to script.c
      Factor out os_read_tun() from tun_mainloop()
      Factor out os_write_tun() from tun_mainloop()
      Move tun_mainloop() to mainloop.c
      Split out os_shutdown_tun() for Windows vs. sane platforms
      Move Windows openconnect_setup_tun_fd() to tun-win32.c
      Split out os_setup_tun() for Windows vs. sane platforms
      Move set_tun_mtu() into os_setup_tun()
      Move openconnect_setup_tun_device() to library.c
      Remove tun.c from Windows build
      Move Windows interface name matching into search_taps() function
      Clean up search_taps() function
      Make openconnect_setup_tun_fd() work on Windows
      Add openconnect_setup_tun_script() stub for Windows
      Fix OpenBSD build
      Fix crash with -C option
      Update changelog
      Import translations from GNOME
      Clean up GnuTLS openconnect_SSL_{read,write,gets} functions
      Do not abort when GnuTLS reports unclean shutdown
      Include <errno.h> in xml.c to fix non-libstoken build
      Remove Java_* wildcard from libopenconnect.map
      android: Add android/ directory to release tarballs
      Merge branch 'rekey' of git://gitorious.org/openconnect-x/openconnect-x
      Prefer python2 if available
      Add RFC4226 HOTP token support
      Don't lose translations when merging from Transifex
      Add update-po target
      Sort new files imported from Transifex so 'update-po' won't touch them
      Only include non-empty files in LINGUAS
      Resync translations with sources
      Update translations from Transifex
      Update platforms.html information about Windows builds
      Import translations from GNOME
      Fix 'cast from pointer to integer of different size' warning in Win64 build
      Resync translations with sources
      Tag version 5.99

Jeremy Visser (2):
      Support IPv6 split tunnelling
      Assign Address-IP6 field to netmask instead of address

Kevin Cernekee (83):
      library: Use named constants for process_auth_form() return value
      main: Rename process_auth_form() to avoid conflict with library
      Create a common process_auth_form() wrapper function
      auth: Remove outdated comment for parse_auth_choice()
      auth: Introduce free_opt() helper function
      library: Change oc_form_opt_select->choices to a pointer array
      auth: Provide information on which auth choice is currently selected
      process_auth_form: Add code to support NEWGROUP return status from UI
      main: Extend read_stdin() to accept hidden (password) input
      main: Split process_auth_form_cb() into smaller functions
      main: Make the authgroup picker CLI more user-friendly
      auth: Parse second-auth-related properties from the auth form
      auth: Hide unused form fields based on the selected authgroup
      Revert "auth: Temporarily disable XML POST if an authgroup dropdown exists"
      auth: Add OC_FORM_OPT_NUMERIC hint and apply it to token PIN entry
      library: Bump API version to 3.0 and document changes
      main: Update CLI to handle hidden fields and NEWGROUP
      main: Avoid infinite "303 See Other" loops on certificate-only authgroups
      main: Don't free password if it isn't used in the first auth form
      library: Clean up partially completed auth forms on error
      Unconditionally redirect CSD stdout to stderr
      ssl: Set FD_CLOEXEC on all sockets
      gnutls: Remove unused local variable
      Introduce new helper functions for cancel_fd checking
      library: Rename cancel_fd to cmd_fd
      library: Add new openconnect_setup_cmd_pipe() call
      Add new helper functions to support cmd_fd feature
      Temporarily build ssl.c + deps into the main executable
      Move signal handling out of mainloop
      cstp: Propagate error status up to the mainloop
      mainloop: Convert vpn_mainloop() into a library function
      dtls: Add dtls_close() helper function and call it on library cleanup
      mainloop: Add OC_CMD_PAUSE operation
      main: Introduce xstrdup() function
      tun: Export setup_tun() functionality
      Move vpninfo default settings into library
      library: Check for failed allocations in openconnect_vpninfo_new()
      dtls: Export setup_dtls() function
      cstp: Export make_cstp_connection()
      library: Move the mainloop guts into libopenconnect
      library: Update openconnect.pc.in
      cstp: Close socket after failed connection attempt
      tun, cstp: Don't exit() on failure
      library: Free zlib state
      cstp: Clean up split include/exclude/DNS lists when freeing vpninfo
      library: Add get/set functions for servercert, ifname, reqmtu
      library: Move IP information into a public struct
      library: Make vpn_option a public struct
      library: Export VPN configuration info to callers
      library: Tweak openconnect.h comment formatting for consistency
      library: Add protect_socket callback
      library: Add support for mobile headers
      library: Add openconnect_set_xmlpost() to support different CSD modes
      library: Add new callback for obtaining TX/RX statistics
      ssl: Don't let cmd_fd activity break timeouts
      library: Update changelog and bump minor version
      main: Add openconnect_vpninfo_free() on a couple of exit paths
      buildsys: Allow overriding -W flags
      acinclude: Add AX_JNI_INCLUDE_DIR macro
      JNI: Initial commit of C wrapper functions
      JNI: Initial commit of Java library + example program
      android: Enable JNI in build
      android: Add libstoken to build
      android: Add liboath to build
      android: Add "sources" target
      main: Add --timestamp option
      library: Fix incorrect platform ID for Mac
      Update documentation/help with the correct "--os" names
      www: Update changelog
      Fix a few minor memory leaks
      Add liboath version check
      http: Don't retry on user cancellation
      cstp_reconnect: Don't sleep if the user terminated the connection
      android: Explicitly disable symbol versioning
      android: Use make-standalone-toolchain.sh from NDK
      android: Install stripped binaries under $(TRIPLET)/out
      cstp: Make sure outbound packets are sent over CSTP if DTLS is down
      dtls: Set rekey_method correctly if the header is missing
      Sanity-check CSTP and DTLS rekey times
      mainloop: Use consistent logic for rekey timeout check
      dtls: Fix link error on !HAVE_DTLS builds
      Avoid deprecated AC_OUTPUT syntax
      mainloop: Simplify the keepalive functions

Nikos Mavrogiannopoulos (18):
      mention DTLS ciphersuite name
      Added support for GCM ciphersuites (require DTLS 1.2).
      Enable a padding when sending password, to avoid leakage of password length.
      Added --pfs option to force perfect forward secrecy
      When selecting TLS protocol options for GnuTLS set the same defaults as in openssl.
      Added openconnect_set_pfs() and its JNI counterpart
      link to Kevin's android port.
      Updated changelog for previous changes.
      Distinguish between the different rekey methods.
      Increased DTLS timeout value to 12 seconds.
      Do an SSL rehandshake when the server sends "X-CSTP-Rekey-Method: ssl".
      Do rehandshake on the DTLS channel as well.
      When CSTP rehandshake or reconnection succeeds, reconnect DTLS.
      Removed the new-tunnel reconnection option from DTLS.
      Revert "dtls: Set rekey_method correctly if the header is missing"
      Notify on rekey time when we are not in REKEY_NONE state.
      If DTLS rehandshake fails, then reconnect.
      Advertise the hostname we connect using SNI.

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

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140305/bdf0f09e/attachment.bin>

From cernekee at gmail.com  Wed Mar  5 11:26:11 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Wed, 5 Mar 2014 08:26:11 -0800
Subject: OpenConnect 5.99 release
In-Reply-To: <1394018999.21141.65.camel@i7.infradead.org>
References: <1394018999.21141.65.camel@i7.infradead.org>
Message-ID: <CAJiQ=7DD+0sgiKOwSCb-xVDzsckqqAHnquOz_g77m6_TEJBcqQ@mail.gmail.com>

On Wed, Mar 5, 2014 at 3:29 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> This is the beta release for 6.0, with lots of shiny changes.
>
> I'm not entirely convinced that the x.99 "releases" actually get that
> much worthwhile testing, but they certainly don't hurt. Mostly this is a
> call for Kevin and Nikos to bug me about anything they still have
> outstanding that they really want in the 6.00 release...

I've been testing these (well, really just the rekey patch) for the
last week or two:

6e956a7 cstp: Make cstp_reconnect() static again
e5ae6aa dtls: Align new-tunnel rekey behavior with Cisco clients
d52cdd0 www: Don't ignore groff errors
aa28be0 www: Fix missing space on platforms page

https://github.com/cernekee/openconnect/commits/rekey-20140222

I'm working on integrating GnuTLS 3.2.12 into the Android builds to
fix CVE-2014-0092.  This requires updating nettle to 2.7, forcing
ARMv7 mode so that nettle 2.7's ARM assembly code doesn't break the
build, and fixing a Bionic incompatibility in gnulib's stdint header.
Will rebase on the current master and send a pull request in the next
few days.


From dwmw2 at infradead.org  Wed Mar  5 11:36:07 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 Mar 2014 16:36:07 +0000
Subject: OpenConnect 5.99 release
In-Reply-To: <CAJiQ=7DD+0sgiKOwSCb-xVDzsckqqAHnquOz_g77m6_TEJBcqQ@mail.gmail.com>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <CAJiQ=7DD+0sgiKOwSCb-xVDzsckqqAHnquOz_g77m6_TEJBcqQ@mail.gmail.com>
Message-ID: <1394037367.23726.14.camel@i7.infradead.org>

On Wed, 2014-03-05 at 08:26 -0800, Kevin Cernekee wrote:
> d52cdd0 www: Don't ignore groff errors

That one probably wants an autoconf check, and to disable HTML
generation (like we do if python isn't present) if groff doesn't
understand -Txhtml.

And can we use 'sed -i' on the $@.tmp file?

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

From cernekee at gmail.com  Wed Mar  5 11:50:42 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Wed, 5 Mar 2014 08:50:42 -0800
Subject: OpenConnect 5.99 release
In-Reply-To: <1394037367.23726.14.camel@i7.infradead.org>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <CAJiQ=7DD+0sgiKOwSCb-xVDzsckqqAHnquOz_g77m6_TEJBcqQ@mail.gmail.com>
 <1394037367.23726.14.camel@i7.infradead.org>
Message-ID: <CAJiQ=7COFSmU69P=DY2oMCt1VBGbxrCFtseMKZgN3Lg1A7FqMA@mail.gmail.com>

On Wed, Mar 5, 2014 at 8:36 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Wed, 2014-03-05 at 08:26 -0800, Kevin Cernekee wrote:
>> d52cdd0 www: Don't ignore groff errors
>
> That one probably wants an autoconf check, and to disable HTML
> generation (like we do if python isn't present) if groff doesn't
> understand -Txhtml.

Good idea

> And can we use 'sed -i' on the $@.tmp file?

I think this would be a problem on Solaris unless the user has
manually switched to GNU sed.


From mtmiller at ieee.org  Wed Mar  5 21:54:21 2014
From: mtmiller at ieee.org (Mike Miller)
Date: Wed, 5 Mar 2014 21:54:21 -0500
Subject: OpenConnect 5.99 release
In-Reply-To: <1394018999.21141.65.camel@i7.infradead.org>
References: <1394018999.21141.65.camel@i7.infradead.org>
Message-ID: <20140306025421.GA14546@xps14z.home.local>

On Wed, Mar 05, 2014 at 11:29:59 +0000, David Woodhouse wrote:
> I'm not entirely convinced that the x.99 "releases" actually get that
> much worthwhile testing, but they certainly don't hurt. Mostly this is a
> call for Kevin and Nikos to bug me about anything they still have
> outstanding that they really want in the 6.00 release...

Well, fails to build on Debian with gnutls 2.12.23 (I know, I know):

gnutls.c: In function 'openconnect_SSL_read':
gnutls.c:119:22: error: 'GNUTLS_E_PREMATURE_TERMINATION' undeclared (first use in this function)

Does this bump the requirement for minimum gnutls version or can we work
around this?

Also reminds me to send this patch on, removes the W3C icons from the
html doc (but not necessarily because the docs aren't valid HTML :)

From 0fdfd44ac768568ee98eb558449b4659eb25f1b4 Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmiller at ieee.org>
Date: Wed, 5 Mar 2014 19:58:46 -0500
Subject: [PATCH] Remove W3C icons from web pages

Don't embed links to externally hosted icons in local documentation.

Signed-off-by: Mike Miller <mtmiller at ieee.org>
---
 www/inc/footer.tmpl | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/www/inc/footer.tmpl b/www/inc/footer.tmpl
index aaa58a1..5c526e5 100644
--- a/www/inc/footer.tmpl
+++ b/www/inc/footer.tmpl
@@ -1,17 +1,4 @@
       </div>
    </div>
-   <div align="right">
-   	<p>
-      	<a href="http://validator.w3.org/check?uri=referer">
-		<img src="http://www.w3.org/Icons/valid-xhtml10"
-		 alt="Valid XHTML 1.0!" height="31" width="88" />
-	</a>
-	<a href="http://jigsaw.w3.org/css-validator/">
-    		<img style="border:0;width:88px;height:31px"
-		 src="http://jigsaw.w3.org/css-validator/images/vcss" 
-		 alt="Valid CSS!" />
-	</a>
-	</p>
-    </div>
   </body>
 </html>
-- 
1.9.0

-- 
mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140305/88cf6b87/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Thu Mar  6 04:02:30 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 6 Mar 2014 10:02:30 +0100
Subject: OpenConnect 5.99 release
In-Reply-To: <20140306025421.GA14546@xps14z.home.local>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <20140306025421.GA14546@xps14z.home.local>
Message-ID: <CAJU7zaK30ffSwB7=qQtUxgqodTM4+=ZijGr8R4QwPY2oDy2Mhg@mail.gmail.com>

On Thu, Mar 6, 2014 at 3:54 AM, Mike Miller <mtmiller at ieee.org> wrote:
> On Wed, Mar 05, 2014 at 11:29:59 +0000, David Woodhouse wrote:
>> I'm not entirely convinced that the x.99 "releases" actually get that
>> much worthwhile testing, but they certainly don't hurt. Mostly this is a
>> call for Kevin and Nikos to bug me about anything they still have
>> outstanding that they really want in the 6.00 release...
>
> Well, fails to build on Debian with gnutls 2.12.23 (I know, I know):
>
> gnutls.c: In function 'openconnect_SSL_read':
> gnutls.c:119:22: error: 'GNUTLS_E_PREMATURE_TERMINATION' undeclared (first use in this function)
> Does this bump the requirement for minimum gnutls version or can we work
> around this?

I believe you can get away with it by doing a:
#if GNUTLS_VERSION_NUMBER < 0x030000
#define GNUTLS_E_PREMATURE_TERMINATION GNUTLS_E_UNEXPECTED_PACKET_LENGTH
#endif

regards,
Nikos


From dwmw2 at infradead.org  Thu Mar  6 04:08:32 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 06 Mar 2014 09:08:32 +0000
Subject: OpenConnect 5.99 release
In-Reply-To: <20140306025421.GA14546@xps14z.home.local>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <20140306025421.GA14546@xps14z.home.local>
Message-ID: <1394096912.23726.40.camel@i7.infradead.org>

On Wed, 2014-03-05 at 21:54 -0500, Mike Miller wrote:
> On Wed, Mar 05, 2014 at 11:29:59 +0000, David Woodhouse wrote:
> > I'm not entirely convinced that the x.99 "releases" actually get that
> > much worthwhile testing, but they certainly don't hurt. Mostly this is a
> > call for Kevin and Nikos to bug me about anything they still have
> > outstanding that they really want in the 6.00 release...
> 
> Well, fails to build on Debian with gnutls 2.12.23 (I know, I know):
> 
> gnutls.c: In function 'openconnect_SSL_read':
> gnutls.c:119:22: error: 'GNUTLS_E_PREMATURE_TERMINATION' undeclared (first use in this function)
>
> Does this bump the requirement for minimum gnutls version or can we work
> around this?

Thanks for catching that. Yes, we can work around it easily enough:
https://git.gnome.org/browse/network-manager-openconnect/commit/?id=1b2e3e8c

This does raise the question of whether we should consider dropping
GnuTLS 2.x support altogether. There's a bunch of evil in the
certificate handling code ? especially for the TPM ? which could be
dropped. And anyone using GnuTLS 2.x, unless they eschew DTLS
completely, is going to have to link against OpenSSL *anyway*.

The disadvantages are that existing GnuTLS 2.x users would lose PKCS#11
support, and the licensing issue of using OpenSSL from within KDE's
NetworkManager tool.

Any idea how long you're going to need to support GnuTLS 2.x?

> Also reminds me to send this patch on, removes the W3C icons from the
> html doc (but not necessarily because the docs aren't valid HTML :)

Applied; thanks.

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

From dwmw2 at infradead.org  Thu Mar  6 04:34:34 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 06 Mar 2014 09:34:34 +0000
Subject: OpenConnect 5.99 release
In-Reply-To: <CAJU7zaK30ffSwB7=qQtUxgqodTM4+=ZijGr8R4QwPY2oDy2Mhg@mail.gmail.com>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <20140306025421.GA14546@xps14z.home.local>
 <CAJU7zaK30ffSwB7=qQtUxgqodTM4+=ZijGr8R4QwPY2oDy2Mhg@mail.gmail.com>
Message-ID: <1394098474.23726.51.camel@i7.infradead.org>

On Thu, 2014-03-06 at 10:02 +0100, Nikos Mavrogiannopoulos wrote:
> 
> I believe you can get away with it by doing a:
> #if GNUTLS_VERSION_NUMBER < 0x030000
> #define GNUTLS_E_PREMATURE_TERMINATION GNUTLS_E_UNEXPECTED_PACKET_LENGTH
> #endif

I pondered that. However, it would require satisfying myself that in
*all* cases that it occurs, treating GNUTLS_E_UNEXPECTED_PACKET_LENGTH
as a non-error is acceptable and secure.

And given how much I care about GnuTLS 2.x, coupled with the fact that
this behaviour has never actually been seen from an *AnyConnect* server
(it turned out to be a Juniper VPN), I just didn't think it was worth
the effort of even thinking it through :)

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

From mtmiller at ieee.org  Thu Mar  6 08:36:54 2014
From: mtmiller at ieee.org (Mike Miller)
Date: Thu, 6 Mar 2014 08:36:54 -0500
Subject: OpenConnect 5.99 release
In-Reply-To: <1394096912.23726.40.camel@i7.infradead.org>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <20140306025421.GA14546@xps14z.home.local>
 <1394096912.23726.40.camel@i7.infradead.org>
Message-ID: <20140306133654.GA20776@xps14z.home.local>

On Thu, Mar 06, 2014 at 09:08:32 +0000, David Woodhouse wrote:
> This does raise the question of whether we should consider dropping
> GnuTLS 2.x support altogether. There's a bunch of evil in the
> certificate handling code ? especially for the TPM ? which could be
> dropped. And anyone using GnuTLS 2.x, unless they eschew DTLS
> completely, is going to have to link against OpenSSL *anyway*.
> 
> The disadvantages are that existing GnuTLS 2.x users would lose PKCS#11
> support, and the licensing issue of using OpenSSL from within KDE's
> NetworkManager tool.
> 
> Any idea how long you're going to need to support GnuTLS 2.x?

AIUI the remaining blocker is the licensing on GMP. There was a
discussion about this a couple of months ago [1][2], and it sounded like
once we have a GMP 5.2 release that is compatible with GPLv2+, we should
be able to make GnuTLS 3 the default.

[1] https://lists.debian.org/debian-devel/2013/12/msg00329.html
[2] https://lists.debian.org/debian-devel/2014/01/msg00538.html

-- 
mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140306/f71dd38f/attachment.sig>

From nmav at gnutls.org  Fri Mar  7 01:47:03 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 07 Mar 2014 07:47:03 +0100
Subject: OpenConnect 5.99 release
In-Reply-To: <1394098474.23726.51.camel@i7.infradead.org>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <20140306025421.GA14546@xps14z.home.local>
 <CAJU7zaK30ffSwB7=qQtUxgqodTM4+=ZijGr8R4QwPY2oDy2Mhg@mail.gmail.com>
 <1394098474.23726.51.camel@i7.infradead.org>
Message-ID: <1394174823.4157.3.camel@nomad.lan>

On Thu, 2014-03-06 at 09:34 +0000, David Woodhouse wrote:
> On Thu, 2014-03-06 at 10:02 +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > I believe you can get away with it by doing a:
> > #if GNUTLS_VERSION_NUMBER < 0x030000
> > #define GNUTLS_E_PREMATURE_TERMINATION GNUTLS_E_UNEXPECTED_PACKET_LENGTH
> > #endif
> 
> I pondered that. However, it would require satisfying myself that in
> *all* cases that it occurs, treating GNUTLS_E_UNEXPECTED_PACKET_LENGTH
> as a non-error is acceptable and secure.

There is no much difference for an attacker. One requires him to send an
RST, and the other an incomplete message. That's why older versions
didn't distinguish between them. I mostly added the premature
termination because many web servers were not terminating the ssl
sessions properly. So if you keep premature termination, and want to
have gnutls 2.12.x compatibility, there is no point to not have the
unexpected packet length definition.

It is of course better to just drop the premature termination though.

regards,
Nikos




From jonathan.lauvernier at gmail.com  Fri Mar  7 04:00:23 2014
From: jonathan.lauvernier at gmail.com (Jonathan Lauvernier)
Date: Fri, 7 Mar 2014 10:00:23 +0100
Subject: Windows binaries
Message-ID: <9160DEB1-907E-4B23-934C-C897A5F951DF@gmail.com>

Hi,

Will you release OpenConnect binaries or detail how to build it on Windows soon please ?

OpenConnect will be very useful on Windows because Cisco AnyConnect reset routes every X seconds avoiding the usage of VPN over VPN.

Thanks for your work !

Regards,

Jonathan

From dwmw2 at infradead.org  Fri Mar  7 04:52:32 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 07 Mar 2014 09:52:32 +0000
Subject: Windows binaries
In-Reply-To: <9160DEB1-907E-4B23-934C-C897A5F951DF@gmail.com>
References: <9160DEB1-907E-4B23-934C-C897A5F951DF@gmail.com>
Message-ID: <1394185952.9994.46.camel@i7.infradead.org>

On Fri, 2014-03-07 at 10:00 +0100, Jonathan Lauvernier wrote:
> 
> 
> Will you release OpenConnect binaries or detail how to build it on
> Windows soon please ?

Building for Windows is fairly trivial. On a Fedora box, just:

 yum install mingw32-gnutls mingw32-libxml2

Then run 'mingw32-configure' and 'make' in the OpenConnect source tree.

You'll end up with libopenconnect-3.dll and openconnect.exe in a .libs/
directory, and you need to copy those along with the other DLLs you need
from /usr/i686-w64-mingw32/sys-root/mingw/bin/ to the Windows box.

You can also use 'mingw64' instead of 'mingw32' to build a 64-bit
version.

You can test authentication (but obviously not *connections*) under wine
without having to use Windows.

You also need to install the Windows TAP driver. There's a signed
version in the OpenVPN installer, which is probably the easiest option:
http://openvpn.net/index.php/download/community-downloads.html



I'm not stunningly keen on getting into the business of shipping
binaries. Especially this week, when it occurs to me that I'd be
scrambling to ship new versions of the GnuTLS DLL. On a platform which
doesn't have any sane and coherent software update/repository handling.

However, if anyone else wants to have a go at it then I won't dissuade
them.

Firstly, we probably want to put together a simple NSI installer for it,
so that you don't have to copy files piecemeal. I'd happily accept
patches to create a make target for that in the OpenConnect source tree,
along the lines of the one that get_iplayer has:
http://git.infradead.org/get_iplayer.git/tree/HEAD:/windows

(Don't be scared by that; it's quite a lot more complex than the
OpenConnect one would be, since it has to download a lot of other
non-bundled dependencies.)

Once that's done, it should be fairly simple to make packages in
something like the OpenSuSE Build System. We could even do nightly
builds that way. I think subsurface does its Windows builds that way, or
at least used to.


It would also be interesting to see if we can put together a GUI for
OpenConnect under Windows. Since fairly much everything can now be done
through the library API, it might be easy enough just to wrap the API
calls from your favourite scripting language... any language you can use
to do rapid prototyping should be good enough, and all the *interesting*
parts are done for you by the library.

Personally, however, I've already spent *more* than enough time on the
Windows build for now... :)

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

From dwmw2 at infradead.org  Fri Mar  7 05:53:28 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 07 Mar 2014 10:53:28 +0000
Subject: OpenConnect 5.99 release
In-Reply-To: <CAJiQ=7COFSmU69P=DY2oMCt1VBGbxrCFtseMKZgN3Lg1A7FqMA@mail.gmail.com>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <CAJiQ=7DD+0sgiKOwSCb-xVDzsckqqAHnquOz_g77m6_TEJBcqQ@mail.gmail.com>
 <1394037367.23726.14.camel@i7.infradead.org>
 <CAJiQ=7COFSmU69P=DY2oMCt1VBGbxrCFtseMKZgN3Lg1A7FqMA@mail.gmail.com>
Message-ID: <1394189608.9994.55.camel@i7.infradead.org>

On Wed, 2014-03-05 at 08:50 -0800, Kevin Cernekee wrote:
> On Wed, Mar 5, 2014 at 8:36 AM, David Woodhouse <dwmw2 at infradead.org>
> wrote:
> > On Wed, 2014-03-05 at 08:26 -0800, Kevin Cernekee wrote:
> >> d52cdd0 www: Don't ignore groff errors
> >
> > That one probably wants an autoconf check, and to disable HTML
> > generation (like we do if python isn't present) if groff doesn't
> > understand -Txhtml.
> 
> Good idea

I've done that. Which potentially renders it redundant to catch the
failure... although still good practice.

Did you intend the contents of the java/ directory to be included in the
release tarballs, btw? They aren't at the moment.

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

From cernekee at gmail.com  Fri Mar  7 23:34:03 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Fri,  7 Mar 2014 20:34:03 -0800
Subject: [GIT PULL] Android/documentation/misc updates
Message-ID: <1394253243-8323-1-git-send-email-cernekee@gmail.com>

The following changes since commit ff23715635bd5a548e6b146895768f9e0d442a02:

  Add autoconf test for functional groff with UTF-8 xhtml output (2014-03-07 10:51:13 +0000)

are available in the git repository at:

  git://github.com/cernekee/openconnect gnutls-20140307

for you to fetch changes up to 3c9ff23308ef2f4e2f940e98a852e9f99f5f461e:

  Use AC_PATH_PROGS_FEATURE_CHECK to test groff usability (2014-03-07 20:18:30 -0800)

----------------------------------------------------------------
Kevin Cernekee (10):
      www: Don't ignore groff errors
      www: Fix missing space on platforms page
      dtls: Align new-tunnel rekey behavior with Cisco clients
      cstp: Make cstp_reconnect() static again
      android: Build ARM with -march=armv7-a
      android: Upgrade nettle from v2.6 to v2.7
      android: Update GnuTLS to 3.2.12
      java: Add java/ directory to release tarballs
      Require autoconf 2.62+ to build from git
      Use AC_PATH_PROGS_FEATURE_CHECK to test groff usability

 Makefile.am                                        |    2 +-
 ...read-file-fix-missing-SIZE_MAX-on-Android.patch |   48 ++++++++++++++++++++
 android/Makefile                                   |   16 ++++---
 configure.ac                                       |   14 +++---
 cstp.c                                             |   12 +----
 library.c                                          |   17 ++++---
 openconnect-internal.h                             |    1 -
 www/Makefile.am                                    |    5 +-
 www/platforms.xml                                  |    2 +-
 9 files changed, 82 insertions(+), 35 deletions(-)
 create mode 100644 android/0001-gl-stdint-read-file-fix-missing-SIZE_MAX-on-Android.patch

-- 
1.7.9.5



From nmav at gnutls.org  Sun Mar  9 16:19:24 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 09 Mar 2014 21:19:24 +0100
Subject: OpenConnect 5.99 release
In-Reply-To: <1394018999.21141.65.camel@i7.infradead.org>
References: <1394018999.21141.65.camel@i7.infradead.org>
Message-ID: <1394396364.12679.16.camel@nomad.lan>

On Wed, 2014-03-05 at 11:29 +0000, David Woodhouse wrote:
> This is the beta release for 6.0, with lots of shiny changes.
> 
> I'm not entirely convinced that the x.99 "releases" actually get that
> much worthwhile testing, but they certainly don't hurt. Mostly this is a
> call for Kevin and Nikos to bug me about anything they still have
> outstanding that they really want in the 6.00 release...

I've noticed that DTLS rekey occurs immediately after connection. It
needs this patch for that work properly:
https://www.gitorious.org/openconnect-x/openconnect-x/commit/8dc3d115c5547728a13203d149485214beec01f5

(the patch resets the rekey timer on the first handshake)

regards,
Nikos




From dwmw2 at infradead.org  Sun Mar  9 21:01:31 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 09 Mar 2014 18:01:31 -0700
Subject: OpenConnect 5.99 release
In-Reply-To: <1394396364.12679.16.camel@nomad.lan>
References: <1394018999.21141.65.camel@i7.infradead.org>
 <1394396364.12679.16.camel@nomad.lan>
Message-ID: <1394413291.18632.6.camel@shinybook.infradead.org>

On Sun, 2014-03-09 at 21:19 +0100, Nikos Mavrogiannopoulos wrote:
> 
> I've noticed that DTLS rekey occurs immediately after connection. It
> needs this patch for that work properly:
> https://www.gitorious.org/openconnect-x/openconnect-x/commit/8dc3d115c5547728a13203d149485214beec01f5
> 
> (the patch resets the rekey timer on the first handshake)

Pulled; thanks.

-- 
dwmw2

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

From jakob at notraq.com  Wed Mar 12 05:43:36 2014
From: jakob at notraq.com (Jakob)
Date: Wed, 12 Mar 2014 09:43:36 -0000
Subject: ocserv sigsegv
Message-ID: <51B6C952.7010205@notraq.com>

hi list,

i'm having sigsegvs in ocserv's childs after successful tun device creation!

here's my setup: ocserv 0.1.2 with nettle-2.7.1 and gnutls-3.1.10 on 
ubuntu linux, client is cisco anyconnect 3.0.4235 on windows 7. i put 
<BypassDownloader>true</BypassDownloader> in anyconnect's local 
preferences xml.

connect, authentication, tun device creation works fine. then, the 
ocserv child dies with sigsegv. anyconnect reconnects, and everything 
repeats.

here's a log from ocserv -f -d
ocserv[457]: [main] reusing tun device vpns0
ocserv[457]: [main] assigning tun device vpns0
ocserv[457]: [1.2.3.4]:51436 user 'abc' of group 'abc' re-authenticated 
(using cookie)
ocserv[502]: [1.2.3.4]:51436 sending IPv4 192.168.1.2
ocserv[502]: [1.2.3.4]:51436 adding route 192.168.1.0/255.255.255.0
ocserv[502]: [1.2.3.4]:51436 peer CSTP MTU is 1406
ocserv[502]: [1.2.3.4]:51436 TCP MSS is 1407
ocserv[502]: [1.2.3.4]:51436 reducing MTU due to TCP MSS to 1399
ocserv[502]: [1.2.3.4]:51436 selected MTU is 1399
ocserv[457]: [1.2.3.4]:51436 setting vpns0 MTU to 1399
ocserv[502]: [1.2.3.4]:51436 TCP MSS is 1407
ocserv[502]: [1.2.3.4]:51436 reducing MTU due to TCP MSS to 1378
ocserv[457]: [main] Child 502 died with sigsegv

i'm pretty much at a loss here and would be grateful for any advice!

thank you very much,
jakob


From n.mavrogiannopoulos at gmail.com  Wed Mar 12 06:59:17 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 12 Mar 2014 11:59:17 +0100
Subject: ocserv sigsegv
In-Reply-To: <51B6C952.7010205@notraq.com>
References: <51B6C952.7010205@notraq.com>
Message-ID: <CAJU7zaKoV1D3WKFnviv-_nMNR1urdUj1fOBYD_-r0=_YLPd7pw@mail.gmail.com>

On Tue, Jun 11, 2013 at 8:53 AM, Jakob <jakob at notraq.com> wrote:
> hi list,

> i'm having sigsegvs in ocserv's childs after successful tun device creation!
> here's my setup: ocserv 0.1.2 with nettle-2.7.1 and gnutls-3.1.10 on

Hello,
 Why did you decide to install 0.1.2? The latest is 0.3.1.

regards,
Nikos


From kaloyan.dimitrov at aviaso.com  Wed Mar 12 12:07:35 2014
From: kaloyan.dimitrov at aviaso.com (Kaloyan Dimitrov)
Date: Wed, 12 Mar 2014 18:07:35 +0200
Subject: vpn connection hangs with openconnect version >v5.01 after a couple
 of seconds...
Message-ID: <53208647.3060401@aviaso.com>

Hi there. I am using the latest openconnect I have for my system: 
archlinux(3.13.6-1-ARCH), openconnect(v5.03, but tried with latest code 
from git as well with same result) to connect to a company vpn.

Everything works fine until the first few seconds when connections hang 
and the last line bellow is added to the console output.

I noticed the last working version is v5.01

Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 15, Keepalive 20
Connected tun0 as 10.54.10.17, using SSL + deflate
Established DTLS connection (using GnuTLS)

CSTP Dead Peer Detection detected dead peer!

Please advise why is this happening.

Cheers,

-- 
Kaloyan Dimitrov
Software Developer

Aviaso Inc
Huobstrasse 10 CH-8808 Pfaeffikon Switzerland
Phone: +41 55 422 0000
kaloyan.dimitrov at aviaso.com www.aviaso.com



From kaloyan.dimitrov at aviaso.com  Wed Mar 12 12:17:40 2014
From: kaloyan.dimitrov at aviaso.com (Kaloyan Dimitrov)
Date: Wed, 12 Mar 2014 18:17:40 +0200
Subject: vpn connection hangs with openconnect version >v5.01 after a
 couple of seconds...
In-Reply-To: <53208647.3060401@aviaso.com>
References: <53208647.3060401@aviaso.com>
Message-ID: <532088A4.3080805@aviaso.com>

Hi again, sorry, seems like v5.01 doesn't do the job as well. Same issue 
exists there...
> Hi there. I am using the latest openconnect I have for my system: 
> archlinux(3.13.6-1-ARCH), openconnect(v5.03, but tried with latest 
> code from git as well with same result) to connect to a company vpn.
>
> Everything works fine until the first few seconds when connections 
> hang and the last line bellow is added to the console output.
>
> I noticed the last working version is v5.01
>
> Got CONNECT response: HTTP/1.1 200 OK
> CSTP connected. DPD 15, Keepalive 20
> Connected tun0 as 10.54.10.17, using SSL + deflate
> Established DTLS connection (using GnuTLS)
>
> CSTP Dead Peer Detection detected dead peer!
>
> Please advise why is this happening.
>
> Cheers,
>


-- 
Kaloyan Dimitrov
Software Developer

Aviaso Inc
Huobstrasse 10 CH-8808 Pfaeffikon Switzerland
Phone: +41 55 422 0000
kaloyan.dimitrov at aviaso.com www.aviaso.com



From cernekee at gmail.com  Wed Mar 12 13:23:43 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Wed, 12 Mar 2014 10:23:43 -0700
Subject: vpn connection hangs with openconnect version >v5.01 after a
 couple of seconds...
In-Reply-To: <53208647.3060401@aviaso.com>
References: <53208647.3060401@aviaso.com>
Message-ID: <CAJiQ=7Cy4xoLFLCMXYmZC2M4p_wHRr_e7ZxGiAe=n-5z_AjZgA@mail.gmail.com>

On Wed, Mar 12, 2014 at 9:07 AM, Kaloyan Dimitrov
<kaloyan.dimitrov at aviaso.com> wrote:
> Hi there. I am using the latest openconnect I have for my system:
> archlinux(3.13.6-1-ARCH), openconnect(v5.03, but tried with latest code from
> git as well with same result) to connect to a company vpn.
>
> Everything works fine until the first few seconds when connections hang and
> the last line bellow is added to the console output.
>
> I noticed the last working version is v5.01
>
> Got CONNECT response: HTTP/1.1 200 OK
> CSTP connected. DPD 15, Keepalive 20
> Connected tun0 as 10.54.10.17, using SSL + deflate
> Established DTLS connection (using GnuTLS)
>
> CSTP Dead Peer Detection detected dead peer!

Could you please post the full log, running with the "-v" flag?

Thanks.


From dwmw2 at infradead.org  Wed Mar 12 13:49:48 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 12 Mar 2014 10:49:48 -0700
Subject: vpn connection hangs with openconnect version >v5.01 after a
 couple of seconds...
In-Reply-To: <CAJiQ=7Cy4xoLFLCMXYmZC2M4p_wHRr_e7ZxGiAe=n-5z_AjZgA@mail.gmail.com>
References: <53208647.3060401@aviaso.com>
 <CAJiQ=7Cy4xoLFLCMXYmZC2M4p_wHRr_e7ZxGiAe=n-5z_AjZgA@mail.gmail.com>
Message-ID: <1394646588.2270.252.camel@shinybook.infradead.org>

On Wed, 2014-03-12 at 10:23 -0700, Kevin Cernekee wrote:
> 
> Could you please post the full log, running with the "-v" flag?

And output of 'ip route' both before and after connecting.

-- 
dwmw2

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

From dwmw2 at infradead.org  Wed Mar 12 14:22:23 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 12 Mar 2014 11:22:23 -0700
Subject: vpn connection hangs with openconnect version >v5.01 after a
 couple of seconds...
In-Reply-To: <53208647.3060401@aviaso.com>
References: <53208647.3060401@aviaso.com>
Message-ID: <1394648543.2270.262.camel@shinybook.infradead.org>

On Wed, 2014-03-12 at 18:07 +0200, Kaloyan Dimitrov wrote:
> Established DTLS connection (using GnuTLS)
> 
> CSTP Dead Peer Detection detected dead peer!
> 
> Please advise why is this happening.

This could be a routing issue. Obviously if we set up a default route
that points to the VPN, we have to have a route to the *gateway* that
still goes via the physical network.

When we get that wrong, so packets for the VPN server are handed to
openconnect and then send out again as a packet for the VPN server... it
doesn't really work very well.

You said that 5.01 worked and 5.03 did not. Did anything *else* change?
Like your vpnc-script, for example?

If not, it shouldn't be that hard to track it down. We could use 'git
bisect' to narrow in on the offending commit. There weren't many commits
between 5.01 and 5.03 in fact, and my first suspect would be this one:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/1fe3f43f

What is the value of the $VPNGATEWAY environment variable, when you
connect with 5.01 and with 5.03?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140312/ade39179/attachment-0001.bin>

From kaloyan.dimitrov at aviaso.com  Thu Mar 13 03:45:48 2014
From: kaloyan.dimitrov at aviaso.com (Kaloyan Dimitrov)
Date: Thu, 13 Mar 2014 09:45:48 +0200
Subject: vpn connection hangs with openconnect version >v5.01 after a
 couple of seconds...
In-Reply-To: <1394646588.2270.252.camel@shinybook.infradead.org>
References: <53208647.3060401@aviaso.com>	
 <CAJiQ=7Cy4xoLFLCMXYmZC2M4p_wHRr_e7ZxGiAe=n-5z_AjZgA@mail.gmail.com>
 <1394646588.2270.252.camel@shinybook.infradead.org>
Message-ID: <5321622C.7030303@aviaso.com>

Hi there,

Thanks for your time. Please find bellow the respective logs:

ip route before:
default via 10.55.1.1 dev eth0  proto static
10.55.1.0/24 dev eth0  proto kernel  scope link  src 10.55.1.223 metric 1

ip route after:
default via 10.55.1.1 dev eth0  proto static
10.54.3.0/24 dev tun0  scope link
10.54.3.1 dev tun0  scope link
10.54.5.0/24 dev tun0  scope link
10.54.10.17 dev tun0  scope link
10.55.1.0/24 dev tun0  scope link
10.55.1.0/24 dev eth0  proto kernel  scope link  src 10.55.1.223 metric 1
xxx.xxx.xxx.xxx via 10.55.1.1 dev eth0  src 10.55.1.223


[root at kalski-work CP]# openconnect -v xxx.xxxxxx.xxx
POST https://xxx.xxxxxx.xxx/
Attempting to connect to server xxx.xxx.xxx.xxx:443
SSL negotiation with xxx.xxxxxx.xxx
Connected to HTTPS on xxx.xxxxxx.xxx
Got HTTP response: HTTP/1.0 302 Object Moved
Content-Type: text/html
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Thu, 13 Mar 2014 07:32:32 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
HTTP body length: (0)
GET https://xxx.xxxxxx.xxx/
Attempting to connect to server xxx.xxx.xxx.xxx:443
SSL negotiation with xxx.xxxxxx.xxx
Connected to HTTPS on xxx.xxxxxx.xxx
Got HTTP response: HTTP/1.0 302 Object Moved
Content-Type: text/html
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Thu, 13 Mar 2014 07:32:33 GMT
Location: /+webvpn+/index.html
Set-Cookie: tg=; expires=Thu, 01 Jan 1970 22:00:00 GMT; path=/; secure
HTTP body length: (0)
GET https://xxx.xxxxxx.xxx/+webvpn+/index.html
SSL negotiation with xxx.xxxxxx.xxx
Connected to HTTPS on xxx.xxxxxx.xxx
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)
Please enter your username and password.
Username:xxx
Password:
POST https://xxx.xxxxxx.xxx/+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:C5D90A44E405FF253F75E886D20E5D7549666553&lu:/+CSCOT+/translation-table?textdomain%3DAnyConnect%26type%3Dmanifest; 
path=/; secure
X-Transcend-Version: 1
HTTP body chunked (-2)
TCP_INFO rcv mss 1380, snd mss 1380, adv mss 1460, pmtu 1500
Got CONNECT response: HTTP/1.1 200 OK
X-CSTP-Version: 1
X-CSTP-Address: 10.54.10.17
X-CSTP-Netmask: 255.255.255.255
X-CSTP-DNS: 10.54.3.1
X-CSTP-Lease-Duration: 1209600
X-CSTP-Session-Timeout: none
X-CSTP-Idle-Timeout: 10800
X-CSTP-Disconnected-Timeout: 10800
X-CSTP-Default-Domain: xxxx.xxx
X-CSTP-Split-Include: 10.55.1.0/255.255.255.0
X-CSTP-Split-Include: 10.54.3.0/255.255.255.0
X-CSTP-Split-Include: 10.54.5.0/255.255.255.0
X-CSTP-Keep: true
X-CSTP-Tunnel-All-DNS: false
X-CSTP-DPD: 15
X-CSTP-Keepalive: 20
X-CSTP-MSIE-Proxy-Lockdown: true
X-CSTP-Smartcard-Removal-Disconnect: true
X-CSTP-Content-Encoding: deflate
X-DTLS-Session-ID: 
D71728E0D29B56A4BFC8C6769EBB987181A72358FFFD11D56EEB780DE2DA4487
X-DTLS-Port: 443
X-DTLS-Keepalive: 20
X-DTLS-DPD: 15
X-CSTP-MTU: 1367
X-DTLS-CipherSuite: AES256-SHA
X-CSTP-Routing-Filtering-Ignore: false
X-CSTP-TCP-Keepalive: true
CSTP connected. DPD 15, Keepalive 20
DTLS option X-DTLS-Session-ID : 
D71728E0D29B56A4BFC8C6769EBB987181A72358FFFD11D56EEB780DE2DA4487
DTLS option X-DTLS-Port : 443
DTLS option X-DTLS-Keepalive : 20
DTLS option X-DTLS-DPD : 15
DTLS option X-DTLS-CipherSuite : AES256-SHA
DTLS initialised. DPD 15, Keepalive 20
Connected tun0 as 10.54.10.17, using SSL + deflate
No work to do; sleeping for 15000 ms...
No work to do; sleeping for 15000 ms...
Established DTLS connection (using GnuTLS)
No work to do; sleeping for 15000 ms...
Sent DTLS packet of 61 bytes; DTLS send returned 62
No work to do; sleeping for 10000 ms...
Received DTLS packet 0x00 of 78 bytes
No work to do; sleeping for 10000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 10000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 10000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 10000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 10000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 9000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 9000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 9000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 9000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 8000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 8000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 8000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 8000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 7000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 7000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 7000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 7000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 6000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 6000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 6000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 6000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 5000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 5000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 5000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 5000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 4000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 4000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 4000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 4000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 3000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 3000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 2000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 2000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 2000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 2000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 1000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 1000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 1000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 1000 ms...
Send CSTP DPD
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 7000 ms...
Got CSTP DPD response
No work to do; sleeping for 14000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 15000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 15000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 15000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 14000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 14000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 14000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 14000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 13000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 13000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 13000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 13000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 12000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 12000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 12000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 12000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 11000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 11000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 11000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 11000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 10000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 10000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 10000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 10000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 9000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 9000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 9000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 9000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 8000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 8000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 8000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 8000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 7000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 7000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 7000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 7000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 6000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 6000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 6000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 6000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 5000 ms...
Received DTLS packet 0x00 of 85 bytes
No work to do; sleeping for 5000 ms...
Sent DTLS packet of 70 bytes; DTLS send returned 71
No work to do; sleeping for 5000 ms...
Received DTLS packet 0x00 of 100 bytes
No work to do; sleeping for 5000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 4000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 2000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 1000 ms...
Send CSTP DPD
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 7000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 6000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 5000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 4000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 2000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 1000 ms...
Send CSTP DPD
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 2000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 1000 ms...
Send DTLS DPD
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 4000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 2000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 1000 ms...
Send CSTP DPD
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 3000 ms...
Sent DTLS packet of 84 bytes; DTLS send returned 85
No work to do; sleeping for 2000 ms...
CSTP Dead Peer Detection detected dead peer!

On 03/12/2014 07:49 PM, David Woodhouse wrote:
> On Wed, 2014-03-12 at 10:23 -0700, Kevin Cernekee wrote:
>> Could you please post the full log, running with the "-v" flag?
> And output of 'ip route' both before and after connecting.
>


-- 
Kaloyan Dimitrov
Software Developer

Aviaso Inc
Huobstrasse 10 CH-8808 Pfaeffikon Switzerland
Phone: +41 55 422 0000
kaloyan.dimitrov at aviaso.com www.aviaso.com



From kaloyan.dimitrov at aviaso.com  Thu Mar 13 08:19:05 2014
From: kaloyan.dimitrov at aviaso.com (Kaloyan Dimitrov)
Date: Thu, 13 Mar 2014 14:19:05 +0200
Subject: vpn connection hangs with openconnect version >v5.01 after a
 couple of seconds...
In-Reply-To: <1394648543.2270.262.camel@shinybook.infradead.org>
References: <53208647.3060401@aviaso.com>
 <1394648543.2270.262.camel@shinybook.infradead.org>
Message-ID: <5321A239.2010601@aviaso.com>

Thanks for the quick response.

Regarding the routing: Removing the "10.55.1.0/24 dev tun0  scope link" 
fixed my problem, thanks for your hint.

After discussing with out network administrator he told me that windows 
clients just have the route with higher metric.

We also noticed that the issue appears probably because the physical 
network(10.55.1.0/24) is actually part of the networks behind the vpn. 
If vpnc-script is improved(as it handles the routes based on 
CISCO_SPLIT_INC_%d_* variables) to handle such a case(when physical 
network is part of vpn networks) with adding higher metric route(similar 
to how windows  client does it) this should be just fine.

As for the openconnect problematic version indeed I corrected myself in 
a reply from 03/12/2014 18:17 +0200

"Hi again, sorry, seems like v5.01 doesn't do the job as well. Same 
issue exists there... "

Regards,
Kaloyan


On 03/12/2014 08:22 PM, David Woodhouse wrote:
> On Wed, 2014-03-12 at 18:07 +0200, Kaloyan Dimitrov wrote:
>> Established DTLS connection (using GnuTLS)
>>
>> CSTP Dead Peer Detection detected dead peer!
>>
>> Please advise why is this happening.
> This could be a routing issue. Obviously if we set up a default route
> that points to the VPN, we have to have a route to the *gateway* that
> still goes via the physical network.
>
> When we get that wrong, so packets for the VPN server are handed to
> openconnect and then send out again as a packet for the VPN server... it
> doesn't really work very well.
>
> You said that 5.01 worked and 5.03 did not. Did anything *else* change?
> Like your vpnc-script, for example?
>
> If not, it shouldn't be that hard to track it down. We could use 'git
> bisect' to narrow in on the offending commit. There weren't many commits
> between 5.01 and 5.03 in fact, and my first suspect would be this one:
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/1fe3f43f
>
> What is the value of the $VPNGATEWAY environment variable, when you
> connect with 5.01 and with 5.03?
>


-- 
Kaloyan Dimitrov
Software Developer

Aviaso Inc
Huobstrasse 10 CH-8808 Pfaeffikon Switzerland
Phone: +41 55 422 0000
kaloyan.dimitrov at aviaso.com  www.aviaso.com  



From nmav at gnutls.org  Thu Mar 13 16:44:16 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 13 Mar 2014 21:44:16 +0100
Subject: ocserv 0.3.2
Message-ID: <1394743456.8463.2.camel@nomad.lan>

Hello,
 I've just released ocserv 0.3.2. ocserv is a VPN server that implements
the AnyConnect SSL VPN protocol. The list of changes since 0.3.1
follows.

* Version 0.3.2 (released 2014-03-13)
- Allow a number of retries (3) in plain password authentication.
- Added doc/profile.xml to the distribution.
- ocserv's '-d' option accepts a numeric argument (0-9) that gradualy
  increases verbosity.
- Added the 'mobile-dpd' config option. That allows providing a
  longer DPD value to mobile clients to prevent waking them up
  too often.
- Added the 'idle-timeout' and 'mobile-idle-timeout' config
  options. They ensure that an idle session will be disconnected.
- Added the 'rekey-method' config option. With this option the
  advertized rekey method to the client can be overriden.
- occtl will now print the bandwidth limits, routes, iroutes, dns
  and nbns values per user.
- Added configure options to disable checking for certain libraries,
  and disable features on request.
- Corrected issue where a client disconnection was not being detected.
- Updated the included http-parser.


The current release is available at:
ftp://ftp.infradead.org/pub/ocserv/ocserv-0.3.2.tar.xz
ftp://ftp.infradead.org/pub/ocserv/ocserv-0.3.2.tar.xz.sig

The VPN server's web-site is at:
http://www.infradead.org/ocserv

regards,
Nikos




From sistla.roger at gmail.com  Fri Mar 14 14:37:16 2014
From: sistla.roger at gmail.com (Roger Sistla)
Date: Fri, 14 Mar 2014 14:37:16 -0400
Subject: W7 64bit binaries
Message-ID: <CACHPhiwFoQt_jvr3eXV7M2OYqSyPSnvgnW_TDX2yiTxjRcgE9A@mail.gmail.com>

Greetings All,

I am looking to download a W7 64bit binary for OpenConnect. A GUI
would be nice as well but not necessary. I am not a
developer/coder/compiler but I can test the binaries and provide
feedback. I also use a Smartcard with my current W7  laptop. I would
like to replace my CiscoAnyconnect wit OpenConnect.

Any assistance would be greatly appreciated.


Thanks.


From tonytzhou at gmail.com  Fri Mar 14 20:48:40 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Fri, 14 Mar 2014 20:48:40 -0400
Subject: ocserv + iOS problem
Message-ID: <5323A368.7010707@gmail.com>

Hi all,

I have recently migrated an ocserv server from Xen to KVM platform with 
same settings except for IP address and re-generated certificate. After 
the migration all the other clients are fine except for iOS - it always 
prompts "The certificate on the secured gateway is invalid. A VPN 
connection will not be established". Here's the environment:

Server: Debian 7.0.6 + ocserv 3.2
Client: iOS 7.0.6 + Cisco Anyconnect 3.0.09266

I used -d 9 for logging and it's uploaded here: http://pastebin.com/WNQc04DY

Thanks in advance,
TZ


From steve at thupdi.net  Sat Mar 15 04:17:33 2014
From: steve at thupdi.net (Steve)
Date: Sat, 15 Mar 2014 16:17:33 +0800
Subject: ocserv + iOS problem
In-Reply-To: <5323A368.7010707@gmail.com>
References: <5323A368.7010707@gmail.com>
Message-ID: <CAFuxyaHr7+uvfpj=oKnsuSXYtpgro1JMzNWnfjw5+3bz2-duuA@mail.gmail.com>

How did you generate your certs and config file please?

On Sat, Mar 15, 2014 at 8:48 AM, Tony Zhou <tonytzhou at gmail.com> wrote:
> Hi all,
>
> I have recently migrated an ocserv server from Xen to KVM platform with same
> settings except for IP address and re-generated certificate. After the
> migration all the other clients are fine except for iOS - it always prompts
> "The certificate on the secured gateway is invalid. A VPN connection will
> not be established". Here's the environment:
>
> Server: Debian 7.0.6 + ocserv 3.2
> Client: iOS 7.0.6 + Cisco Anyconnect 3.0.09266
>
> I used -d 9 for logging and it's uploaded here: http://pastebin.com/WNQc04DY
>
> Thanks in advance,
> TZ
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From tonytzhou at gmail.com  Sat Mar 15 19:05:26 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Sat, 15 Mar 2014 19:05:26 -0400
Subject: ocserv + iOS problem
In-Reply-To: <CAFuxyaHr7+uvfpj=oKnsuSXYtpgro1JMzNWnfjw5+3bz2-duuA@mail.gmail.com>
References: <5323A368.7010707@gmail.com>
 <CAFuxyaHr7+uvfpj=oKnsuSXYtpgro1JMzNWnfjw5+3bz2-duuA@mail.gmail.com>
Message-ID: <5324DCB6.6090607@gmail.com>

Hi Steve,

I generated the certificate according to the manual on ocserv's webpage: 
http://www.infradead.org/ocserv/manual.html
and the configuration file using the one from source, of course modified 
to accommodate the actual environment.

Thanks,
TZ

On 3/15/2014 4:17 AM, Steve wrote:
> How did you generate your certs and config file please?
>
> On Sat, Mar 15, 2014 at 8:48 AM, Tony Zhou <tonytzhou at gmail.com> wrote:
>> Hi all,
>>
>> I have recently migrated an ocserv server from Xen to KVM platform with same
>> settings except for IP address and re-generated certificate. After the
>> migration all the other clients are fine except for iOS - it always prompts
>> "The certificate on the secured gateway is invalid. A VPN connection will
>> not be established". Here's the environment:
>>
>> Server: Debian 7.0.6 + ocserv 3.2
>> Client: iOS 7.0.6 + Cisco Anyconnect 3.0.09266
>>
>> I used -d 9 for logging and it's uploaded here: http://pastebin.com/WNQc04DY
>>
>> Thanks in advance,
>> TZ
>>
>> _______________________________________________
>> openconnect-devel mailing list
>> openconnect-devel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel



From cernekee at gmail.com  Sun Mar 16 02:03:49 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Sat, 15 Mar 2014 23:03:49 -0700
Subject: [PATCH] android: Update libstoken to 0.5
Message-ID: <1394949829-17306-1-git-send-email-cernekee@gmail.com>

This fixes 6-digit tokencodes, PIN-less tokens, and the mlockall()
dependency.

It also adds native sdtid support, but that wouldn't be terribly helpful
unless openconnect allowed users to pass in an XML file seed.  Maybe at
some point we should let users specify --token-secret=@/path/to/file
like "curl --data".

Signed-off-by: Kevin Cernekee <cernekee at gmail.com>
---
 android/0001-Remove-call-to-mlockall.patch |   33 ----------------------------
 android/Makefile                           |    3 +--
 2 files changed, 1 insertion(+), 35 deletions(-)
 delete mode 100644 android/0001-Remove-call-to-mlockall.patch

diff --git a/android/0001-Remove-call-to-mlockall.patch b/android/0001-Remove-call-to-mlockall.patch
deleted file mode 100644
index c09afb6..0000000
diff --git a/android/Makefile b/android/Makefile
index 1e52992..ac67605 100644
--- a/android/Makefile
+++ b/android/Makefile
@@ -295,7 +295,7 @@ tomcrypt: $(TOMCRYPT_DEPS)
 #
 # Build libstoken
 #
-STOKEN_VER := 0.2
+STOKEN_VER := 0.5
 STOKEN_SRC := sources/stoken-$(STOKEN_VER)
 STOKEN_BUILD := $(TRIPLET)/stoken
 
@@ -305,7 +305,6 @@ stoken-$(STOKEN_VER).tar.gz:
 $(STOKEN_SRC)/configure: stoken-$(STOKEN_VER).tar.gz
 	mkdir -p sources
 	tar xfz $< -C sources
-	cd $(STOKEN_SRC) && patch -p1 < ../../0001-Remove-call-to-mlockall.patch
 	touch $@
 
 $(STOKEN_BUILD)/Makefile: $(TOOLCHAIN_BUILT) $(STOKEN_SRC)/configure $(TOMCRYPT_DEPS)
-- 
1.7.9.5



From cernekee at gmail.com  Wed Mar 19 00:36:19 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Tue, 18 Mar 2014 21:36:19 -0700
Subject: [GIT PULL] Fix resource leaks and other minor issues
Message-ID: <1395203779-8644-1-git-send-email-cernekee@gmail.com>

Most of these changes (particularly the ones on error paths) are
compile-tested only.

Other outstanding items from the Coverity scan:

openconnect_obtain_cookie() still has a few potential leaks on error
paths, e.g. involving orig_*.  It might be best to split steps 1-3 (?)
into their own function which can free its own resources.  But this is
not something I want to touch before 6.00 is out.

start_cstp_connection() has a couple of possible strcmp(foo, NULL)
comparisons if various IP-related headers are missing.  Also, the
behavior gets a little weird for cases like "Reconnect gave different
Legacy IP address" because it already overwrote the good address with
the bad address.  Maybe what we really want to do is leverage the new
ip_info struct to maintain parallel copies of the new and old info, then
overwrite vpninfo->ip_info with the new info only after it has been
validated.

There are a number of unchecked return values for things like
setsockopt() and fcntl().  Not sure if they are worth fixing.


The following changes since commit a812940474a42dfa71a4748fd99ceddf425ccb99:

  Import translations from GNOME (2014-03-16 09:09:21 +0000)

are available in the git repository at:

  git://github.com/cernekee/openconnect coverity-20140318

for you to fetch changes up to c0246ffe7befcf5504170e48b717fff9199aa4e9:

  dtls: Free OpenSSL contexts when the library instance is freed (2014-03-18 20:52:43 -0700)

----------------------------------------------------------------
Kevin Cernekee (11):
      gnutls: Fix double free() prompting for passphrase
      http: fetch_config() argument names are swapped
      xml: Make sure the config file descriptor gets closed on all error paths
      http: Don't leak the auth form when handling <client-cert-request>
      http: Don't leak form_path on error
      tun: Don't leak tun_fd on ioctl errors
      gnutls: Fix inverted return value check in GnuTLS 2.12 compatibility code
      cstp: Fix misplaced parentheses
      jni: Fix a couple of leaked strings
      dtls: Add missing dtls_reconnect() stub for !HAVE_DTLS case
      dtls: Free OpenSSL contexts when the library instance is freed

 cstp.c                 |    2 +-
 dtls.c                 |   21 +++++++++++++++++++++
 gnutls.c               |    3 ++-
 http.c                 |   11 +++++++----
 jni.c                  |    5 +++++
 library.c              |    2 +-
 openconnect-internal.h |    1 +
 tun.c                  |    2 ++
 xml.c                  |   16 +++++++++-------
 9 files changed, 49 insertions(+), 14 deletions(-)

-- 
1.7.9.5



From a556 at drdrb.net  Wed Mar 19 19:39:08 2014
From: a556 at drdrb.net (a556)
Date: Wed, 19 Mar 2014 23:39:08 +0000 (UTC)
Subject: Upload does not work
Message-ID: <loom.20140320T003339-583@post.gmane.org>

When connected to my VPN server testing my internet speed with any speed
testing website, such as speed.io, results in an upload rate of 0. When I
connect to my vpn server with Cisco's AnyConnect, my upload rate is the real
number. I use OpenConnect 5.99 with GnuTLS on Debian Wheezy. 

Browsing the web with OpenConnect works just fine. I have not been able to
do any other testing beyond that.

Any ideas what wrong here?



From jeremy.hou at me.com  Thu Mar 20 01:56:29 2014
From: jeremy.hou at me.com (Jeremy Hou)
Date: Thu, 20 Mar 2014 13:56:29 +0800
Subject: Can not establish a connection.
Message-ID: <3372BF20-4E3A-4D9E-831A-110A6488634F@me.com>

Hi,
I just installed ocserv, I modified the sample.config and generated the cert through the manual.
I use Anyconnect.app on my iPhone to connect to the server, but the connection could not be established successfully, it seems the connection was lost right after the IP was assigned.

Here is the log on my server:

rankjie at rankjie:/etc/ocserv$ sudo ocserv -fdc sample.config
Skipping unknown option 'mobile-dpd'
listening (TCP) on 0.0.0.0:443...
listening (UDP) on 0.0.0.0:443...
ocserv[22445]: [main] initialized ocserv 0.3.1
ocserv[22446]: sec-mod initialized (socket: /var/run/ocserv-socket.22445)
ocserv[22447]: 114.242.249.148:30337 accepted connection
ocserv[22447]: GnuTLS error (at worker-vpn.c:699): A TLS fatal alert has been received.: Unknown certificate
ocserv[22445]: 114.242.249.148:30337 main-misc.c:469: command socket closed
ocserv[22452]: 114.242.249.148:30338 accepted connection
ocserv[22446]: sec-mod received request from pid 22452 and uid 65534
ocserv[22452]: 114.242.249.148:30338 sending message 'resume data store request' to main
ocserv[22445]: 114.242.249.148:30338 main received message 'resume data store request' of 258 bytes
ocserv[22445]: 114.242.249.148:30338 TLS session DB storing 2e3818a32644a7828d542dfa1a35272095342fe631654a3baf327917dc4d77bc
ocserv[22452]: 114.242.249.148:30338 TLS handshake completed
ocserv[22452]: 114.242.249.148:30338 cannot find username in client XML message
ocserv[22452]: 114.242.249.148:30338 failed reading username
ocserv[22452]: 114.242.249.148:30338 sent sid: FWAAVg0tAFTAUqfN
ocserv[22452]: 114.242.249.148:30338 received sid: FWAAVg0tAFTAUqfN
ocserv[22452]: 114.242.249.148:30338 updating SID
ocserv[22452]: 114.242.249.148:30338 sending message 'auth init' to main
ocserv[22445]: 114.242.249.148:30338 main received message 'auth init' of 29 bytes
ocserv[22445]: 114.242.249.148:30338 auth init set SID to FWAAVg0tAFTAUqfN
ocserv[22445]: 114.242.249.148:30338 auth init for user 'rankjie' from '114.242.249.148:30338'
ocserv[22445]: 114.242.249.148:30338 sending message 'auth reply' to worker
ocserv[22452]: 114.242.249.148:30338 received auth reply message (value: 2)
ocserv[22452]: 114.242.249.148:30338 continuing authentication for ''
ocserv[22452]: 114.242.249.148:30338 received sid: FWAAVg0tAFTAUqfN
ocserv[22452]: 114.242.249.148:30338 sending message 'auth request' to main
ocserv[22445]: 114.242.249.148:30338 main received message 'auth request' of 10 bytes
ocserv[22445]: 114.242.249.148:30338 auth req for user 'rankjie'
ocserv[22445]: 114.242.249.148:30338 accepting user 'rankjie'
ocserv[22445]: 114.242.249.148:30338 auth deinit for user 'rankjie'
ocserv[22445]: 114.242.249.148:30338 No user configuration for 'rankjie'
ocserv[22445]: 114.242.249.148:30338 selected IP for 'rankjie': 192.168.1.144
ocserv[22445]: 114.242.249.148:30338 selected IP for 'rankjie': fe80::94:1634:9100%2696246856
ocserv[22445]: 114.242.249.148:30338 assigned IPv4 to 'rankjie': 192.168.1.145
ocserv[22445]: 114.242.249.148:30338 assigned IPv6 to 'rankjie': fe80::94:1634:9101%2696246856
ocserv[22445]: 114.242.249.148:30338 assigning tun device vpns0
ocserv[22445]: 114.242.249.148:30338 user 'rankjie' of group '[unknown]' authenticated
ocserv[22445]: 114.242.249.148:30338 sending (socket) message 2 to worker
ocserv[22452]: 114.242.249.148:30338 received auth reply message (value: 1)
ocserv[22452]: 114.242.249.148:30338 user 'rankjie' logged in
ocserv[22463]: 114.242.249.148:30340 accepted connection
ocserv[22446]: sec-mod received request from pid 22463 and uid 65534
ocserv[22463]: 114.242.249.148:30340 sending message 'resume data store request' to main
ocserv[22445]: 114.242.249.148:30340 main received message 'resume data store request' of 278 bytes
ocserv[22445]: 114.242.249.148:30340 TLS session DB storing 6a583b86b2ce2db23094ab02b4fdc93dfd12b7d9857c5ee4c631b3bb03a6858b
ocserv[22463]: 114.242.249.148:30340 TLS handshake completed
ocserv[22463]: 114.242.249.148:30340 unexpected URL /+CSCOT+/translation-table?type=combined-manifest&textdomain=AnyConnect
ocserv[22445]: 114.242.249.148:30340 main-misc.c:469: command socket closed
ocserv[22464]: 114.242.249.148:30341 accepted connection
ocserv[22446]: sec-mod received request from pid 22464 and uid 65534
ocserv[22464]: GnuTLS error (at worker-vpn.c:699): Error in the pull function.
ocserv[22445]: 114.242.249.148:30341 main-misc.c:469: command socket closed
ocserv[22465]: 114.242.249.148:30342 accepted connection
ocserv[22446]: sec-mod received request from pid 22465 and uid 65534
ocserv[22465]: 114.242.249.148:30342 sending message 'resume data store request' to main
ocserv[22445]: 114.242.249.148:30342 main received message 'resume data store request' of 258 bytes
ocserv[22445]: 114.242.249.148:30342 TLS session DB storing f18cd4253f670e6f001df4cbf961a7edd1b17125dca1d52c71f7f29c46157c3f
ocserv[22465]: 114.242.249.148:30342 TLS handshake completed
ocserv[22465]: 114.242.249.148:30342 sending message 'auth cookie request' to main
ocserv[22445]: 114.242.249.148:30342 main received message 'auth cookie request' of 261 bytes
ocserv[22445]: 114.242.249.148:30342 accepting user 'rankjie'
ocserv[22445]: 114.242.249.148:30342 auth deinit for user 'rankjie'
ocserv[22445]: 114.242.249.148:30338 disconnecting 'rankjie' due to new cookie connection
ocserv[22445]: 114.242.249.148:30342 No user configuration for 'rankjie'
ocserv[22445]: 114.242.249.148:30342 assigned IPv4 to 'rankjie': 192.168.1.145
ocserv[22445]: 114.242.249.148:30342 assigned IPv6 to 'rankjie': fe80::94:1634:9101%2696246856
ocserv[22445]: 114.242.249.148:30342 assigning tun device vpns1
ocserv[22445]: 114.242.249.148:30342 user 'rankjie' of group '[unknown]' re-authenticated (using cookie)
ocserv[22445]: 114.242.249.148:30342 sending (socket) message 2 to worker
ocserv[22465]: 114.242.249.148:30342 received auth reply message (value: 1)
ocserv[22465]: 114.242.249.148:30342 sending IPv4 192.168.1.145
ocserv[22465]: 114.242.249.148:30342 sending IPv6 fe80::94:1634:9101%2696246856
ocserv[22465]: 114.242.249.148:30342 adding split DNS example.com
ocserv[22465]: 114.242.249.148:30342 adding route 192.168.1.0/255.255.255.0
ocserv[22465]: 114.242.249.148:30342 peer's CSTP MTU is 1356 (ignored)
ocserv[22465]: 114.242.249.148:30342 TCP MSS is 1385
ocserv[22465]: 114.242.249.148:30342 reducing MTU due to TCP MSS to 1377
ocserv[22465]: 114.242.249.148:30342 DTLS ciphersuite: AES128-SHA
ocserv[22465]: 114.242.249.148:30342 peer's DTLS MTU is 1356 (overhead: 95)
ocserv[22465]: 114.242.249.148:30342 suggesting DTLS MTU 1311
ocserv[22465]: 114.242.249.148:30342 suggesting CSTP MTU 1311
ocserv[22465]: 114.242.249.148:30342 plaintext MTU is 1376
ocserv[22465]: 114.242.249.148:30342 sending message 'tun mtu change' to main
ocserv[22465]: 114.242.249.148:30342 setting MTU to 1376
ocserv[22445]: 114.242.249.148:30342 main received message 'tun mtu change' of 3 bytes
ocserv[22445]: 114.242.249.148:30342 setting vpns1 MTU to 1376
ocserv[22465]: 114.242.249.148:30342 sending message 'session info' to main
ocserv[22465]: 114.242.249.148:30342 reducing MTU due to TCP MSS to 1356
ocserv[22445]: 114.242.249.148:30342 main received message 'session info' of 51 bytes
ocserv[22465]: 114.242.249.148:30342 sending message 'tun mtu change' to main
ocserv[22465]: 114.242.249.148:30342 setting MTU to 1355
ocserv[22445]: 114.242.249.148:30342 main received message 'tun mtu change' of 3 bytes
ocserv[22445]: 114.242.249.148:30342 setting vpns1 MTU to 1355
ocserv[22465]: 114.242.249.148:30342 sending 48 byte(s)
ocserv[22465]: 114.242.249.148:30342 sending 76 byte(s)
ocserv[22465]: 114.242.249.148:30342 received 120 byte(s) (TLS)
ocserv[22465]: 114.242.249.148:30342 received BYE packet; exiting
ocserv[22445]: 114.242.249.148:30342 main-misc.c:469: command socket closed
ocserv[22445]: 114.242.249.148:30338 main-misc.c:469: command socket closed




======================================




And here is my sample.config:

#mtu = 1356
# User authentication method. Could be set multiple times and in that case
# all should succeed.
# Options: certificate, pam.
#auth = "certificate"
auth = "plain[/etc/ocpwd]"
#auth = "pam"

# A banner to be displayed on clients
#banner = "Welcome"

# Use listen-host to limit to specific IPs or to the IPs of a provided hostname.
#listen-host = [IP|HOSTNAME]

# Limit the number of clients. Unset or set to zero for unlimited.
#max-clients = 1024
max-clients = 0

# Limit the number of client connections to one every X milliseconds
# (X is the provided value). Set to zero for no limit.
#rate-limit-ms = 100

# Limit the number of identical clients (i.e., users connecting multiple times)
# Unset or set to zero for unlimited.
max-same-clients = 0

# TCP and UDP port number
tcp-port = 443
udp-port = 443

# Keepalive in seconds
keepalive = 32400

# Dead peer detection in seconds
dpd = 440
mobile-dpd = 1800
# MTU discovery (DPD must be enabled)
try-mtu-discovery = true
# The key and the certificates of the server
# The key may be a file, or any URL supported by GnuTLS (e.g.,
# tpmkey:uuid=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx;storage=user
# or pkcs11:object=my-vpn-key;object-type=private)
#
# There may be multiple certificate and key pairs and each key
# should correspond to the preceding certificate.
server-cert = /etc/ocserv/server-cert.pem
server-key = /etc/ocserv/server-key.pem

# Diffie-Hellman parameters. Only needed if you require support
# for the DHE ciphersuites (by default this server supports ECDHE).
# Can be generated using:
# certtool --generate-dh-params --outfile /path/to/dh.pem
#dh-params = /path/to/dh.pem

# If you have a certificate from a CA that provides an OCSP
# service you may provide a fresh OCSP status response within
# the TLS handshake. That will prevent the client from connecting
# independently on the OCSP server.
# You can update this response periodically using:
# ocsptool --ask --load-cert=your_cert --load-issuer=your_ca --outfile response
# Make sure that you replace the following file in an atomic way.
#ocsp-response = /path/to/ocsp.der

# In case PKCS #11 or TPM keys are used the PINs should be available
# in files. The srk-pin-file is applicable to TPM keys only (It's the storage
# root key).
#pin-file = /path/to/pin.txt
#srk-pin-file = /path/to/srkpin.txt

# The Certificate Authority that will be used
# to verify clients if certificate authentication
# is set.
#ca-cert = /path/to/ca.pem

# The object identifier that will be used to read the user ID in the client certificate.
# The object identifier should be part of the certificate's DN
# Useful OIDs are:
#  CN = 2.5.4.3, UID = 0.9.2342.19200300.100.1.1
#cert-user-oid = 0.9.2342.19200300.100.1.1

# The object identifier that will be used to read the user group in the client
# certificate. The object identifier should be part of the certificate's DN
# Useful OIDs are:
#  OU (organizational unit) = 2.5.4.11
#cert-group-oid = 2.5.4.11

# A revocation list of ca-cert is set
#crl = /path/to/crl.pem

# GnuTLS priority string
tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT"

# To enforce perfect forward secrecy (PFS) on the main channel.
#tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT:-RSA"

# The time (in seconds) that a client is allowed to stay connected prior
# to authentication
auth-timeout = 40

# The time (in seconds) that a client is not allowed to reconnect after
# a failed authentication attempt.
#min-reauth-time = 2

# Cookie validity time (in seconds)
# Once a client is authenticated he's provided a cookie with
# which he can reconnect. This option sets the maximum lifetime
# of that cookie.
cookie-validity = 86400

# ReKey time (in seconds)
# ocserv will ask the client to refresh keys periodically once
# this amount of seconds is elapsed. Set to zero to disable.
rekey-time = 86400

# Script to call when a client connects and obtains an IP
# Parameters are passed on the environment.
# REASON, USERNAME, GROUPNAME, HOSTNAME (the hostname selected by client),
# DEVICE, IP_REAL (the real IP of the client), IP_LOCAL (the local IP
# in the P-t-P connection), IP_REMOTE (the VPN IP of the client). REASON
# may be "connect" or "disconnect".
#connect-script = /usr/bin/myscript
#disconnect-script = /usr/bin/myscript

# UTMP
use-utmp = true

# D-BUS usage. If disabled occtl tool cannot be used. If enabled
# then ocserv must have access to register org.infradead.ocserv
# D-BUS service. See doc/dbus/org.infradead.ocserv.conf
use-dbus = true

# PID file. It can be overriden in the command line.
pid-file = /var/run/ocserv.pid

# The default server directory. Does not require any devices present.
#chroot-dir = /path/to/chroot

# socket file used for IPC, will be appended with .PID
# It must be accessible within the chroot environment (if any)
socket-file = /var/run/ocserv-socket

# The user the worker processes will be run as. It should be
# unique (no other services run as this user).
run-as-user = nobody
run-as-group = daemon

# Set the protocol-defined priority (SO_PRIORITY) for packets to
# be sent. That is a number from 0 to 6 with 0 being the lowest
# priority. Alternatively this can be used to set the IP Type-
# Of-Service, by setting it to a hexadecimal number (e.g., 0x20).
# This can be set per user/group or globally.
#net-priority = 3

# Set the VPN worker process into a specific cgroup. This is Linux
# specific and can be set per user/group or globally.
#cgroup = "cpuset,cpu:test"

# Network settings

device = vpns

# The default domain to be advertised
default-domain = example.com

ipv4-network = 192.168.1.0
ipv4-netmask = 255.255.255.0

# dns = 192.168.2.1
dns = 8.8.8.8
dns = fe80::1

# The NBNS server (if any)
#nbns = 192.168.2.3

# The IPv6 subnet prefix
ipv6-network = fe80::
ipv6-prefix = 16

# The domains over which the provided DNS should be used. Use
# multiple lines for multiple domains.
split-dns = example.com

# Prior to leasing any IP from the pool ping it to verify that
# it is not in use by another (unrelated to this server) host.
ping-leases = false

# Leave empty to assign the default MTU of the device
# mtu =

# Unset to enable bandwidth restrictions (in bytes/sec). The
# setting here is global, but can also be set per user or per group.
#rx-data-per-sec = 40960
#tx-data-per-sec = 40960

# The number of packets (of MTU size) that are available in
# the output buffer. The default is low to improve latency.
# Setting it higher will improve throughput.
output-buffer = 10

route = 192.168.1.0/255.255.255.0
#route = 116.251.0.0/255.255.0.0
#route = 192.168.5.0/255.255.255.0

# Configuration files that will be applied per user connection or
# per group. Each file name on these directories must match the username
# or the groupname.
# The options allowed in the configuration files are dns, nbns,
#  ipv?-network, ipv?-netmask, ipv6-prefix, rx/tx-per-sec, iroute and route.
#
# Note that the 'iroute' option allows to add routes on the server
# based on a user or group. The syntax depends on the input accepted
# by the commands route-add-cmd and route-del-cmd (see below).

config-per-user = /etc/ocserv/config-per-user/
config-per-group = /etc/ocserv/config-per-group/


# The system command to use to setup a route. %R will be replaced with the
# route/mask and %D with the (tun) device.
#
# The following example is from linux systems. %R should be something
# like 192.168.2.0/24 (so iroute in this system has different syntax than route)

route-add-cmd = "ip route add %R dev %D"
route-del-cmd = "ip route delete %R dev %D"

#
# The following options are for (experimental) AnyConnect client
# compatibility.

# Client profile xml. A sample file exists in doc/profile.xml.
# This file must be accessible from inside the worker's chroot.
# The profile is ignored by the openconnect client.
#user-profile = profile.xml

# Unless set to false it is required for clients to present their
# certificate even if they are authenticating via a previously granted
# cookie. Legacy CISCO clients do not do that, and thus this option
# should be set for them.
cisco-client-compat = true

#Advanced options

# Option to allow sending arbitrary custom headers to the client after
# authentication and prior to VPN tunnel establishment.
#custom-header = "X-My-Header: hi there?









==================================


Any help will be appreciated!

From n.mavrogiannopoulos at gmail.com  Thu Mar 20 02:23:11 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 20 Mar 2014 07:23:11 +0100
Subject: Can not establish a connection.
In-Reply-To: <3372BF20-4E3A-4D9E-831A-110A6488634F@me.com>
References: <3372BF20-4E3A-4D9E-831A-110A6488634F@me.com>
Message-ID: <CAJU7zaJWG+ghJtA_hkjmH3_0D2yP8h8k=m6BTNntBRAmBbuDEg@mail.gmail.com>

On Thu, Mar 20, 2014 at 6:56 AM, Jeremy Hou <jeremy.hou at me.com> wrote:
> Hi,
> I just installed ocserv, I modified the sample.config and generated the cert through the manual.
> I use Anyconnect.app on my iPhone to connect to the server, but the connection could not be established successfully, it seems the connection was lost right after the IP was assigned.
> Here is the log on my server:
> rankjie at rankjie:/etc/ocserv$ sudo ocserv -fdc sample.config
> Skipping unknown option 'mobile-dpd'
> listening (TCP) on 0.0.0.0:443...
> listening (UDP) on 0.0.0.0:443...
> ocserv[22445]: [main] initialized ocserv 0.3.1

Why not 0.3.2?

> ocserv[22445]: 114.242.249.148:30338 selected IP for 'rankjie': fe80::94:1634:9100%2696246856

My guess is that ipv6 is the issue here. What happens if you disable
it? You also use link-local addresses and getaddrinfo appends the zone
index. That may also be something that confuses the client.

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Thu Mar 20 09:17:21 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 20 Mar 2014 14:17:21 +0100
Subject: ocserv + iOS problem
In-Reply-To: <5323A368.7010707@gmail.com>
References: <5323A368.7010707@gmail.com>
Message-ID: <CAJU7zaJ+2u_zOZH6Unap=bneMVVj7U4cxyKK_C7_mtTRh2P91g@mail.gmail.com>

On Sat, Mar 15, 2014 at 1:48 AM, Tony Zhou <tonytzhou at gmail.com> wrote:
> Hi all,
> I have recently migrated an ocserv server from Xen to KVM platform with same
> settings except for IP address and re-generated certificate. After the
> migration all the other clients are fine except for iOS - it always prompts
> "The certificate on the secured gateway is invalid. A VPN connection will
> not be established". Here's the environment:

Hello,
 Do you have the old and the new certificate to compare?

regards,
Nikos


From tonytzhou at gmail.com  Thu Mar 20 09:50:00 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Thu, 20 Mar 2014 09:50:00 -0400
Subject: ocserv + iOS problem
In-Reply-To: <CAJU7zaJ+2u_zOZH6Unap=bneMVVj7U4cxyKK_C7_mtTRh2P91g@mail.gmail.com>
References: <5323A368.7010707@gmail.com>
 <CAJU7zaJ+2u_zOZH6Unap=bneMVVj7U4cxyKK_C7_mtTRh2P91g@mail.gmail.com>
Message-ID: <532AF208.4090508@gmail.com>

Hi Nikos,

They're all generated using the manual on ocserv's website. CA certs 
share the same template, and the server certificates only differs on CN 
- I use IP address of the servers as the CN.

Thanks,
TZ

On 3/20/2014 9:17 AM, Nikos Mavrogiannopoulos wrote:
> On Sat, Mar 15, 2014 at 1:48 AM, Tony Zhou <tonytzhou at gmail.com> wrote:
>> Hi all,
>> I have recently migrated an ocserv server from Xen to KVM platform with same
>> settings except for IP address and re-generated certificate. After the
>> migration all the other clients are fine except for iOS - it always prompts
>> "The certificate on the secured gateway is invalid. A VPN connection will
>> not be established". Here's the environment:
> Hello,
>   Do you have the old and the new certificate to compare?
>
> regards,
> Nikos



From cernekee at gmail.com  Fri Mar 21 00:41:51 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Thu, 20 Mar 2014 21:41:51 -0700
Subject: [PATCH] cstp: Don't call dtls_reconnect() when DTLS is disabled
Message-ID: <1395376911-30884-1-git-send-email-cernekee@gmail.com>

dtls_reconnect() will change dtls_state from DTLS_DISABLED to
DTLS_SLEEPING.  This generates a bunch of spurious "No DTLS address"
errors.

Signed-off-by: Kevin Cernekee <cernekee at gmail.com>
---
 cstp.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cstp.c b/cstp.c
index 209894d..fb801ab 100644
--- a/cstp.c
+++ b/cstp.c
@@ -911,7 +911,8 @@ int cstp_mainloop(struct openconnect_info *vpninfo, int *timeout)
 	do_dtls_reconnect:
 		/* succeeded, let's rekey DTLS, if it is not rekeying
 		 * itself. */
-		if (vpninfo->dtls_times.rekey_method == REKEY_NONE) {
+		if (vpninfo->dtls_state != DTLS_DISABLED &&
+		    vpninfo->dtls_times.rekey_method == REKEY_NONE) {
 			dtls_reconnect(vpninfo);
 		}
 
-- 
1.7.9.5



From rankjie at gmail.com  Fri Mar 21 02:08:46 2014
From: rankjie at gmail.com (Rankjie)
Date: Fri, 21 Mar 2014 14:08:46 +0800
Subject: Maybe a NAT issue
Message-ID: <6A8E0D9F-2987-4B9D-8851-D8225F8A55B2@gmail.com>

Hi,
I installed ocserv 0.3.2, and use anyconnect.app on iPhone to connect to it. 
The connection goes well, but I can not get data through the server. 


I also tried with no route defined, which equals 0.0.0.0/0.0.0.0  .  This time, I can?t access any website on my phone?


=================================================

I have tried these commands:

sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

iptables -I INPUT -j ACCEPT


=================================================

But it still doesn?t work?

Here is my config file:

=================================================


# User authentication method. Could be set multiple times and in that case
# all should succeed.
# Options: certificate, pam.
#auth = "certificate"
auth = "plain[/etc/ocserv/pwd]"
#auth = "pam"

# The plain option requires specifying a password file which contains
# entries of the following format.
# "username:groupname:encoded-password"
# One entry must be listed per line, and 'ocpasswd' can be used
# to generate password entries.
#auth = "plain[/etc/ocserv/ocpasswd]"

# A banner to be displayed on clients
#banner = "Welcome"

# Use listen-host to limit to specific IPs or to the IPs of a provided
# hostname.
#listen-host = [IP|HOSTNAME]

# Limit the number of clients. Unset or set to zero for unlimited.
#max-clients = 1024
max-clients = 0

# Limit the number of client connections to one every X milliseconds
# (X is the provided value). Set to zero for no limit.
#rate-limit-ms = 100

# Limit the number of identical clients (i.e., users connecting
# multiple times). Unset or set to zero for unlimited.
max-same-clients = 2

# TCP and UDP port number
tcp-port = 443
udp-port = 443

# Keepalive in seconds
keepalive = 32400

# Dead peer detection in seconds.
dpd = 240

# Dead peer detection for mobile clients. The needs to
# be much higher to prevent such clients being awaken too
# often by the DPD messages, and save battery.
# (clients that send the X-AnyConnect-Identifier-DeviceType)
mobile-dpd = 1800

# MTU discovery (DPD must be enabled)
try-mtu-discovery = true

# The key and the certificates of the server
# The key may be a file, or any URL supported by GnuTLS (e.g.,
# tpmkey:uuid=xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx;storage=user
# or pkcs11:object=my-vpn-key;object-type=private)
#
# There may be multiple certificate and key pairs and each key
# should correspond to the preceding certificate.
server-cert = /etc/ssl/certs/server-cert.pem
server-key = /etc/ssl/private/server-key.pem

# Diffie-Hellman parameters. Only needed if you require support
# for the DHE ciphersuites (by default this server supports ECDHE).
# Can be generated using:
# certtool --generate-dh-params --outfile /path/to/dh.pem
#dh-params = /path/to/dh.pem

# If you have a certificate from a CA that provides an OCSP
# service you may provide a fresh OCSP status response within
# the TLS handshake. That will prevent the client from connecting
# independently on the OCSP server.
# You can update this response periodically using:
# ocsptool --ask --load-cert=your_cert --load-issuer=your_ca --outfile response
# Make sure that you replace the following file in an atomic way.
#ocsp-response = /path/to/ocsp.der

# In case PKCS #11 or TPM keys are used the PINs should be available
# in files. The srk-pin-file is applicable to TPM keys only, and is the
# storage root key.
#pin-file = /path/to/pin.txt
#srk-pin-file = /path/to/srkpin.txt

# The Certificate Authority that will be used to verify
# client certificates (public keys) if certificate authentication
# is set.

# The object identifier that will be used to read the user ID in the client
# certificate. The object identifier should be part of the certificate's DN
# Useful OIDs are:
#  CN = 2.5.4.3, UID = 0.9.2342.19200300.100.1.1
#cert-user-oid = 0.9.2342.19200300.100.1.1

# The object identifier that will be used to read the user group in the
# client  certificate. The object identifier should be part of the certificate's
# DN. Useful OIDs are:
#  OU (organizational unit) = 2.5.4.11
#cert-group-oid = 2.5.4.11

# The revocation list of the certificates issued by the 'ca-cert' above.
#crl = /path/to/crl.pem

# GnuTLS priority string
tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT"

# To enforce perfect forward secrecy (PFS) on the main channel.
#tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT:-RSA"

# The time (in seconds) that a client is allowed to stay connected prior
# to authentication
auth-timeout = 40

# The time (in seconds) that a client is allowed to stay idle (no traffic)
# before being disconnected. Unset to disable.
#idle-timeout = 1200

# The time (in seconds) that a mobile client is allowed to stay idle (no
# traffic) before being disconnected. Unset to disable.
#mobile-idle-timeout = 2400

# The time (in seconds) that a client is not allowed to reconnect after
# a failed authentication attempt.
#min-reauth-time = 2

# Cookie validity time (in seconds)
# Once a client is authenticated he's provided a cookie with
# which he can reconnect. This option sets the maximum lifetime
# of that cookie.
cookie-validity = 86400

# ReKey time (in seconds)
# ocserv will ask the client to refresh keys periodically once
# this amount of seconds is elapsed. Set to zero to disable.
rekey-time = 172800

# ReKey method
# Valid options: ssl, new-tunnel
#  ssl: Will perform an efficient rehandshake on the channel allowing
#       a seamless connection during rekey.
#  new-tunnel: Will instruct the client to discard and re-establish the channel.
#       Use this option only if the connecting clients have issues with the ssl
#       option.
rekey-method = ssl

# Script to call when a client connects and obtains an IP
# Parameters are passed on the environment.
# REASON, USERNAME, GROUPNAME, HOSTNAME (the hostname selected by client),
# DEVICE, IP_REAL (the real IP of the client), IP_LOCAL (the local IP
# in the P-t-P connection), IP_REMOTE (the VPN IP of the client),
# ID (a unique numeric ID); REASON may be "connect" or "disconnect".
#connect-script = /usr/bin/myscript
#disconnect-script = /usr/bin/myscript

# UTMP
use-utmp = true

# D-BUS usage. If disabled occtl tool cannot be used. If enabled
# then ocserv must have access to register org.infradead.ocserv
# D-BUS service. See doc/dbus/org.infradead.ocserv.conf
use-dbus = true

# PID file. It can be overriden in the command line.
pid-file = /var/run/ocserv.pid

# The default server directory. Does not require any devices present.
#chroot-dir = /path/to/chroot

# socket file used for IPC, will be appended with .PID
# It must be accessible within the chroot environment (if any)
socket-file = /var/run/ocserv-socket

# The user the worker processes will be run as. It should be
# unique (no other services run as this user).
run-as-user = nobody
run-as-group = nogroup

# Set the protocol-defined priority (SO_PRIORITY) for packets to
# be sent. That is a number from 0 to 6 with 0 being the lowest
# priority. Alternatively this can be used to set the IP Type-
# Of-Service, by setting it to a hexadecimal number (e.g., 0x20).
# This can be set per user/group or globally.
#net-priority = 3

# Set the VPN worker process into a specific cgroup. This is Linux
# specific and can be set per user/group or globally.
#cgroup = "cpuset,cpu:test"

#
# Network settings
#

# The name of the tun device
device = vpns

# The default domain to be advertised
default-domain = example.com

# The pool of addresses that leases will be given from.
ipv4-network = 192.168.1.0
ipv4-netmask = 255.255.255.0

# The advertized DNS server. Use multiple lines for
# multiple servers.
# dns = fc00::4be0
dns = 8.8.8.8

# The NBNS server (if any)
#nbns = 192.168.1.3

# The IPv6 subnet that leases will be given from.
#ipv6-network = fc00::
#ipv6-prefix = 16

# The domains over which the provided DNS should be used. Use
# multiple lines for multiple domains.
#split-dns = example.com

# Prior to leasing any IP from the pool ping it to verify that
# it is not in use by another (unrelated to this server) host.
ping-leases = false

# Unset to assign the default MTU of the device
# mtu =

# Unset to enable bandwidth restrictions (in bytes/sec). The
# setting here is global, but can also be set per user or per group.
#rx-data-per-sec = 40000
#tx-data-per-sec = 40000

# The number of packets (of MTU size) that are available in
# the output buffer. The default is low to improve latency.
# Setting it higher will improve throughput.
output-buffer = 10

# Routes to be forwarded to the client. If you need the
# client to forward routes to the server, you may use the
# config-per-user/group or even connect and disconnect scripts.
#
# To set the server as the default gateway for the client just
# comment out all routes from the server.
#route = 192.168.1.0/255.255.255.0
#route = 192.168.5.0/255.255.255.0
#route = fef4:db8:1000:1001::/64

# Configuration files that will be applied per user connection or
# per group. Each file name on these directories must match the username
# or the groupname.
# The options allowed in the configuration files are dns, nbns,
#  ipv?-network, ipv4-netmask, ipv6-prefix, rx/tx-per-sec, iroute, route,
#  net-priority and cgroup.
#
# Note that the 'iroute' option allows to add routes on the server
# based on a user or group. The syntax depends on the input accepted
# by the commands route-add-cmd and route-del-cmd (see below).

#config-per-user = /etc/ocserv/config-per-user/
#config-per-group = /etc/ocserv/config-per-group/

# The system command to use to setup a route. %R will be replaced with the
# route/mask and %D with the (tun) device.
#
# The following example is from linux systems. %R should be something
# like 192.168.2.0/24

#route-add-cmd = "ip route add %R dev %D"
#route-del-cmd = "ip route delete %R dev %D"

#
# The following options are for (experimental) AnyConnect client
# compatibility.

# Client profile xml. A sample file exists in doc/profile.xml.
# This file must be accessible from inside the worker's chroot.
# It is not used by the openconnect client.
#user-profile = profile.xml

# Binary files that may be downloaded by the CISCO client. Must
# be within any chroot environment.
#binary-files = /path/to/binaries

# Unless set to false it is required for clients to present their
# certificate even if they are authenticating via a previously granted
# cookie and complete their authentication in the same TCP connection.
# Legacy CISCO clients do not do that, and thus this option should be
# set for them.
#cisco-client-compat = false


#Advanced options

# Option to allow sending arbitrary custom headers to the client after
# authentication and prior to VPN tunnel establishment.

route = 3.0.0.0/255.0.0.0
route = 4.0.0.0/255.0.0.0
route = 8.0.0.0/255.0.0.0
route = 198.0.0.0/255.0.0.0
route = 209.0.0.0/255.0.0.0
route = 210.0.0.0/255.0.0.0
route = 216.0.0.0/255.0.0.0
route = 61.0.0.0/255.0.0.0
route = 64.0.0.0/255.0.0.0
route = 66.0.0.0/255.0.0.0
route = 70.0.0.0/255.0.0.0
route = 72.0.0.0/255.0.0.0
route = 74.0.0.0/255.0.0.0
route = 173.0.0.0/255.0.0.0
route = 204.0.0.0/255.0.0.0
route = 69.0.0.0/255.0.0.0
route = 199.0.0.0/255.0.0.0
route = 203.0.0.0/255.0.0.0
route = 31.0.0.0/255.0.0.0


#custom-header = "X-My-Header: hi there?


=================================================



The log output from ocserv:


root@(none):/etc/ocserv# ocserv -fd 1 -c ocserv.conf
listening (TCP) on 0.0.0.0:443...
listening (TCP) on [::]:443...
listening (UDP) on 0.0.0.0:443...
listening (UDP) on [::]:443...
ocserv[16755]: main: initialized ocserv 0.3.2
ocserv[16756]: sec-mod initialized (socket: /var/run/ocserv-socket.16755)
ocserv[16757]: worker: 114.242.249.136:49837 accepted connection
ocserv[16756]: sec-mod received request from pid 16757 and uid 65534
ocserv[16757]: worker: 114.242.249.136:49837 sending message 'resume data store request' to main
ocserv[16757]: worker: 114.242.249.136:49837 TLS handshake completed
ocserv[16755]: main: 114.242.249.136:49837 main received message 'resume data store request' of 258 bytes
ocserv[16755]: main: 114.242.249.136:49837 TLS session DB storing 370dbc147d686005ecba7fcdc572ae971e08ce49eb56fbea454a8e92989b7952
ocserv[16757]: worker: 114.242.249.136:49837 cannot find username in client XML message
ocserv[16757]: worker: 114.242.249.136:49837 failed reading username
ocserv[16757]: worker: 114.242.249.136:49837 sent sid: oOXMmwTyvI0p96y+
ocserv[16757]: worker: 114.242.249.136:49837 received sid: oOXMmwTyvI0p96y+
ocserv[16757]: worker: 114.242.249.136:49837 sending message 'auth init' to main
ocserv[16755]: main: 114.242.249.136:49837 main received message 'auth init' of 15 bytes
ocserv[16755]: main: 114.242.249.136:49837 auth init for user 'rankjie' from '114.242.249.136:49837'
ocserv[16755]: main: 114.242.249.136:49837 sending message 'auth reply' to worker
ocserv[16757]: worker: 114.242.249.136:49837 received auth reply message (value: 2)
ocserv[16757]: worker: 114.242.249.136:49837 continuing authentication for ''
ocserv[16757]: worker: 114.242.249.136:49837 received sid: oOXMmwTyvI0p96y+
ocserv[16757]: worker: 114.242.249.136:49837 sending message 'auth request' to main
ocserv[16755]: main: 114.242.249.136:49837 main received message 'auth request' of 10 bytes
ocserv[16755]: main: 114.242.249.136:49837 auth req for user 'rankjie'
ocserv[16755]: main: 114.242.249.136:49837 accepting user 'rankjie'
ocserv[16755]: main: 114.242.249.136:49837 auth deinit for user 'rankjie'
ocserv[16755]: main: 114.242.249.136:49837 selected IP for 'rankjie': 192.168.1.144
ocserv[16755]: main: 114.242.249.136:49837 assigned IPv4 to 'rankjie': 192.168.1.145
ocserv[16755]: main: 114.242.249.136:49837 assigning tun device vpns0
ocserv[16755]: main: 114.242.249.136:49837 user 'rankjie' of group '[unknown]' authenticated
ocserv[16755]: main: 114.242.249.136:49837 sending (socket) message 2 to worker
ocserv[16757]: worker: 114.242.249.136:49837 received auth reply message (value: 1)
ocserv[16757]: worker: 114.242.249.136:49837 user 'rankjie' logged in
ocserv[16765]: worker: 114.242.249.136:49838 accepted connection
ocserv[16756]: sec-mod received request from pid 16765 and uid 65534
ocserv[16765]: worker: 114.242.249.136:49838 sending message 'resume data store request' to main
ocserv[16765]: worker: 114.242.249.136:49838 TLS handshake completed
ocserv[16755]: main: 114.242.249.136:49838 main received message 'resume data store request' of 278 bytes
ocserv[16755]: main: 114.242.249.136:49838 TLS session DB storing bfb58e4c8272fd942edb32c5ea070e7d8529ff735bf931394fcb177a446a5b55
ocserv[16765]: worker: 114.242.249.136:49838 unexpected URL /+CSCOT+/translation-table?type=combined-manifest&textdomain=AnyConnect
ocserv[16755]: main: 114.242.249.136:49838 main-misc.c:487: command socket closed
ocserv[16755]: main: 114.242.249.136:49838 removing client '' with id '16765'
ocserv[16766]: worker: 114.242.249.136:49839 accepted connection
ocserv[16756]: sec-mod received request from pid 16766 and uid 65534
ocserv[16766]: GnuTLS error (at worker-vpn.c:691): A TLS fatal alert has been received.: CA is unknown
ocserv[16755]: main: 114.242.249.136:49839 main-misc.c:487: command socket closed
ocserv[16755]: main: 114.242.249.136:49839 removing client '' with id '16766'
ocserv[16767]: worker: 114.242.249.136:49840 accepted connection
ocserv[16756]: sec-mod received request from pid 16767 and uid 65534
ocserv[16767]: worker: 114.242.249.136:49840 sending message 'resume data store request' to main
ocserv[16767]: worker: 114.242.249.136:49840 TLS handshake completed
ocserv[16755]: main: 114.242.249.136:49840 main received message 'resume data store request' of 258 bytes
ocserv[16755]: main: 114.242.249.136:49840 TLS session DB storing 119d90232ea53289c98711695a9495ed834792d542f165f3ec7a1358b82ab950
ocserv[16767]: worker: 114.242.249.136:49840 sending message 'auth cookie request' to main
ocserv[16755]: main: 114.242.249.136:49840 main received message 'auth cookie request' of 261 bytes
ocserv[16755]: main: 114.242.249.136:49840 accepting user 'rankjie'
ocserv[16755]: main: 114.242.249.136:49840 auth deinit for user 'rankjie'
ocserv[16755]: main: 114.242.249.136:49837 disconnecting 'rankjie' due to new cookie connection
ocserv[16755]: main: 114.242.249.136:49840 assigned IPv4 to 'rankjie': 192.168.1.145
ocserv[16755]: main: 114.242.249.136:49840 assigning tun device vpns1
ocserv[16755]: main: 114.242.249.136:49840 user 'rankjie' of group '[unknown]' re-authenticated (using cookie)
ocserv[16755]: main: 114.242.249.136:49840 sending (socket) message 2 to worker
ocserv[16767]: worker: 114.242.249.136:49840 received auth reply message (value: 1)
ocserv[16767]: worker: 114.242.249.136:49840 suggesting DPD of 1800 secs
ocserv[16767]: worker: 114.242.249.136:49840 sending IPv4 192.168.1.145
ocserv[16767]: worker: 114.242.249.136:49840 adding route 3.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 4.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 8.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 198.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 209.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 210.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 216.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 61.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 64.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 66.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 70.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 72.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 74.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 173.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 204.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 69.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 199.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 203.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 adding route 31.0.0.0/255.0.0.0
ocserv[16767]: worker: 114.242.249.136:49840 peer's CSTP MTU is 1356 (ignored)
ocserv[16767]: worker: 114.242.249.136:49840 TCP MSS is 1397
ocserv[16767]: worker: 114.242.249.136:49840 reducing MTU due to TCP MSS to 1389
ocserv[16767]: worker: 114.242.249.136:49840 DTLS ciphersuite: AES128-SHA
ocserv[16767]: worker: 114.242.249.136:49840 peer's DTLS MTU is 1356 (overhead: 95)
ocserv[16767]: worker: 114.242.249.136:49840 suggesting DTLS MTU 1323
ocserv[16767]: worker: 114.242.249.136:49840 suggesting CSTP MTU 1323
ocserv[16767]: worker: 114.242.249.136:49840 plaintext MTU is 1388
ocserv[16767]: worker: 114.242.249.136:49840 sending message 'tun mtu change' to main
ocserv[16767]: worker: 114.242.249.136:49840 setting MTU to 1388
ocserv[16755]: main: 114.242.249.136:49840 main received message 'tun mtu change' of 3 bytes
ocserv[16755]: main: 114.242.249.136:49840 setting vpns1 MTU to 1388
ocserv[16767]: worker: 114.242.249.136:49840 sending message 'session info' to main
ocserv[16755]: main: 114.242.249.136:49840 main received message 'session info' of 51 bytes
ocserv[16755]: main: 114.242.249.136:49837 main-misc.c:487: command socket closed
ocserv[16755]: main: 114.242.249.136:49837 removing client 'rankjie' with id '16757'
ocserv[16755]: main: DTLS record version: 1.0
ocserv[16755]: main: DTLS hello version: 1.0
ocserv[16755]: main: 114.242.249.136:49840 sending (socket) message 10 to worker
ocserv[16755]: main: 114.242.249.136:49840 passed UDP socket
ocserv[16767]: worker: 114.242.249.136:49840 reducing MTU due to TCP MSS to 1368
ocserv[16767]: worker: 114.242.249.136:49840 sending message 'tun mtu change' to main
ocserv[16767]: worker: 114.242.249.136:49840 setting MTU to 1367
ocserv[16755]: main: 114.242.249.136:49840 main received message 'tun mtu change' of 3 bytes
ocserv[16767]: worker: 114.242.249.136:49840 worker received message udp fd of 0 bytes
ocserv[16767]: worker: 114.242.249.136:49840 received new UDP fd and connected to peerocserv[16755]: main: 114.242.249.136:49840 setting vpns1 MTU to 1367

ocserv[16767]: worker: 114.242.249.136:49840 setting up DTLS connection
ocserv[16767]: worker: 114.242.249.136:49840 sending message 'tun mtu change' to main
ocserv[16767]: worker: 114.242.249.136:49840 setting MTU to 1302
ocserv[16767]: worker: 114.242.249.136:49840 DTLS handshake completed (plaintext MTU: 1302)
ocserv[16755]: main: 114.242.249.136:49840 main received message 'tun mtu change' of 3 bytes
ocserv[16755]: main: 114.242.249.136:49840 setting vpns1 MTU to 1302



From n.mavrogiannopoulos at gmail.com  Fri Mar 21 03:37:15 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 21 Mar 2014 08:37:15 +0100
Subject: Maybe a NAT issue
In-Reply-To: <6A8E0D9F-2987-4B9D-8851-D8225F8A55B2@gmail.com>
References: <6A8E0D9F-2987-4B9D-8851-D8225F8A55B2@gmail.com>
Message-ID: <CAJU7zaLYJM4Xg6JAX+tjNXj+-e4_Y+iPRjunBb7JWLo46Ku5oQ@mail.gmail.com>

On Fri, Mar 21, 2014 at 7:08 AM, Rankjie <rankjie at gmail.com> wrote:
> Hi,
> I installed ocserv 0.3.2, and use anyconnect.app on iPhone to connect to it.
> The connection goes well, but I can not get data through the server.
> I also tried with no route defined, which equals 0.0.0.0/0.0.0.0  .  This time, I can't access any website on my phone...
[...]
> ocserv[16766]: GnuTLS error (at worker-vpn.c:691): A TLS fatal alert has been received.: CA is unknown

Hello Rankjie,
 I think the line above summarizes the issue. Your phone doesn't trust
the CA of your VPN. Unfortunately I have no iphone, so I have no idea
how you can set that up.

regards,
Nikos


From dwmw2 at infradead.org  Fri Mar 21 04:34:33 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 21 Mar 2014 08:34:33 +0000
Subject: Upload does not work
In-Reply-To: <loom.20140320T003339-583@post.gmane.org>
References: <loom.20140320T003339-583@post.gmane.org>
Message-ID: <1395390873.22540.44.camel@shinybook.infradead.org>

On Wed, 2014-03-19 at 23:39 +0000, a556 wrote:
> When connected to my VPN server testing my internet speed with any speed
> testing website, such as speed.io, results in an upload rate of 0. When I
> connect to my vpn server with Cisco's AnyConnect, my upload rate is the real
> number. I use OpenConnect 5.99 with GnuTLS on Debian Wheezy. 

What is the MTU on the VPN interface with each client?

-- 
dwmw2

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

From nmav at gnutls.org  Fri Mar 21 15:19:32 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Mar 2014 20:19:32 +0100
Subject: Maybe a NAT issue
In-Reply-To: <1395405833454.6e87ffb2@Nodemailer>
References: <CAJU7za+GxrUkEHfW8_65TPWq8R81-XTw6CU0KJnxBd3YC5_0Ow@mail.gmail.com>
 <1395405833454.6e87ffb2@Nodemailer>
Message-ID: <1395429572.4407.2.camel@nomad.lan>

On Fri, 2014-03-21 at 05:43 -0700, RankJie wrote:
> Thanks for the advise. I tried to set mtu=800 but with no luck...

At least you know now it is not an mtu issue :) I guess then, you should
check the overall networking in the system and find out whether it is a
packet forwarding issue or a firewall issue.

regards,
Nikos





From kevinchou.c at gmail.com  Sat Mar 22 16:13:56 2014
From: kevinchou.c at gmail.com (Kevin)
Date: Sun, 23 Mar 2014 04:13:56 +0800
Subject: Can't reach some route in Anyconnect
Message-ID: <etPan.532def04.4db127f8.c54@kevindeMacBook-Air.local>

Hi list?

There is a thing goes so weird.?

My VPN Server is located in SG.?
OS is Ubuntu 12.04?
Ocserv is 0.3.2?

In the config file, I added about 20 route?

most of them are working well.?
But the tumblr route 66.0.0.0/255.0.0.0?
and twitter Image server route 199.96.0.0/255.255.0.0 can't be reached.?

I can ping them. but can not get HTTP response through the VPN.?
Then I sshed to my server to try wget to get the webpage, and I got it. So my server's IP is not banned.?

I tried reduce the MTU to 1300, 1200 but not helped.?

do you have any idea about this thing??

Thank you very much.?

--  
Kevin
Sent with Airmail


From rankjie at gmail.com  Sat Mar 22 23:43:55 2014
From: rankjie at gmail.com (Rankjie)
Date: Sun, 23 Mar 2014 11:43:55 +0800
Subject: Certificate Auth Error on iOS ( AnyConnect )
Message-ID: <2806FC8A-D0C7-4C53-B799-308F06CD822A@gmail.com>

Hi,

I use the same user-certificate on my Mac ( client is openconnect ) and my iPhone ( client is anyconnect )

Things were fine on my Mac, but on the iOS, the connection could not be established.

Here is my ocserv.conf: https://gist.github.com/rankjie/bb7c7e4bfe86d323abb6
Server?s log when connect to it on iOS: https://gist.github.com/rankjie/8618400ba3a2075457b0

From the log of ocserv, I can see ?user 'CN=user1' of group '[unknown]' authenticated?

but eventually failed with ?GnuTLS error (at worker-vpn.c:691): No certificate was found.?

The same certificate was all right on my mac with openconnect. So this might be a compatibility issue? 

From rankjie at gmail.com  Sun Mar 23 00:07:21 2014
From: rankjie at gmail.com (Rankjie)
Date: Sun, 23 Mar 2014 12:07:21 +0800
Subject: Maybe a NAT issue
In-Reply-To: <1395429572.4407.2.camel@nomad.lan>
References: <CAJU7za+GxrUkEHfW8_65TPWq8R81-XTw6CU0KJnxBd3YC5_0Ow@mail.gmail.com>
 <1395405833454.6e87ffb2@Nodemailer> <1395429572.4407.2.camel@nomad.lan>
Message-ID: <FEF90D4D-5CFE-4E1E-811F-F465336C6A2E@gmail.com>

Just to update the thread that the issue was fixed.

It was caused by the TCP MSS setting, fixed by command: 

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 


Thank you all for your help and kindness. 

On Mar 22, 2014, at 3:19, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Fri, 2014-03-21 at 05:43 -0700, RankJie wrote:
>> Thanks for the advise. I tried to set mtu=800 but with no luck...
> 
> At least you know now it is not an mtu issue :) I guess then, you should
> check the overall networking in the system and find out whether it is a
> packet forwarding issue or a firewall issue.
> 
> regards,
> Nikos
> 
> 
> 



From nmav at gnutls.org  Sun Mar 23 05:15:00 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Mar 2014 10:15:00 +0100
Subject: Certificate Auth Error on iOS ( AnyConnect )
In-Reply-To: <2806FC8A-D0C7-4C53-B799-308F06CD822A@gmail.com>
References: <2806FC8A-D0C7-4C53-B799-308F06CD822A@gmail.com>
Message-ID: <1395566100.4223.1.camel@nomad.lan>

On Sun, 2014-03-23 at 11:43 +0800, Rankjie wrote:
> Hi,
> 
> I use the same user-certificate on my Mac ( client is openconnect ) and my iPhone ( client is anyconnect )
> Things were fine on my Mac, but on the iOS, the connection could not be established.
> 
> Here is my ocserv.conf: https://gist.github.com/rankjie/bb7c7e4bfe86d323abb6
> Server?s log when connect to it on iOS: https://gist.github.com/rankjie/8618400ba3a2075457b0
> From the log of ocserv, I can see ?user 'CN=user1' of group '[unknown]' authenticated?
> but eventually failed with ?GnuTLS error (at worker-vpn.c:691): No certificate was found.?
> The same certificate was all right on my mac with openconnect. So this
might be a compatibility issue? 

Hello,
 You need to set cisco-client-compat to true and possibly the profile
file, for cisco clients to be able to connect.

regards,
Nikos




From rankjie at gmail.com  Sun Mar 23 05:36:00 2014
From: rankjie at gmail.com (Rankjie)
Date: Sun, 23 Mar 2014 17:36:00 +0800
Subject: Certificate Auth Error on iOS ( AnyConnect )
In-Reply-To: <1395566100.4223.1.camel@nomad.lan>
References: <2806FC8A-D0C7-4C53-B799-308F06CD822A@gmail.com>
 <1395566100.4223.1.camel@nomad.lan>
Message-ID: <D70113C0-B58F-4A40-BE07-44427906F73E@gmail.com>

Well, after set the cisco-client-compat to true, it?s working now.
BTW, how can I use certificate or password auth but not require both?


On Mar 23, 2014, at 17:15, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Sun, 2014-03-23 at 11:43 +0800, Rankjie wrote:
>> Hi,
>> 
>> I use the same user-certificate on my Mac ( client is openconnect ) and my iPhone ( client is anyconnect )
>> Things were fine on my Mac, but on the iOS, the connection could not be established.
>> 
>> Here is my ocserv.conf: https://gist.github.com/rankjie/bb7c7e4bfe86d323abb6
>> Server?s log when connect to it on iOS: https://gist.github.com/rankjie/8618400ba3a2075457b0
>> From the log of ocserv, I can see ?user 'CN=user1' of group '[unknown]' authenticated?
>> but eventually failed with ?GnuTLS error (at worker-vpn.c:691): No certificate was found.?
>> The same certificate was all right on my mac with openconnect. So this
> might be a compatibility issue? 
> 
> Hello,
> You need to set cisco-client-compat to true and possibly the profile
> file, for cisco clients to be able to connect.
> 
> regards,
> Nikos
> 
> 



From kevinchou.c at gmail.com  Sun Mar 23 21:45:54 2014
From: kevinchou.c at gmail.com (Kevin)
Date: Mon, 24 Mar 2014 09:45:54 +0800
Subject: MTU problem on UDP
Message-ID: <etPan.532f8e52.327b23c6.2262@kevindeMacBook-Air.local>

Hi List

days ago I post "Can't reach some route in Anyconnect?
?http://lists.infradead.org/pipermail/openconnect-devel/2014-March/001759.html

and now I finally find out why.

in my iptables I have a role to enable udp like this

-A INPUT -p udp -m udp --dport 443 -j ACCEPT

after I remove this role from the iptables, My problem solved.

seems The TCP backup didn?t have the MTU problem.

but I already added

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

and even tried?

custom-header = "X-DTLS-MTU: 1200"
custom-header = "X-CSTP-MTU: 1200??

set mtu = 1200 in config file. nothing helped.

So I guess this is a MTU bug on UDP?

--  
Kevin
Sent with Airmail


From nmav at gnutls.org  Mon Mar 24 08:28:58 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 24 Mar 2014 13:28:58 +0100
Subject: Certificate Auth Error on iOS ( AnyConnect )
In-Reply-To: <D70113C0-B58F-4A40-BE07-44427906F73E@gmail.com>
References: <2806FC8A-D0C7-4C53-B799-308F06CD822A@gmail.com>
 <1395566100.4223.1.camel@nomad.lan>
 <D70113C0-B58F-4A40-BE07-44427906F73E@gmail.com>
Message-ID: <CAJU7zaLWn6DYFiM2JYKdq+-AL-jhUUtYk38q4Pe_nY97YV9G_Q@mail.gmail.com>

On Sun, Mar 23, 2014 at 10:36 AM, Rankjie <rankjie at gmail.com> wrote:
> Well, after set the cisco-client-compat to true, it's working now.
> BTW, how can I use certificate or password auth but not require both?

No. As it is now, multiple authentication options, imply that they are
all required (and-composition).

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Tue Mar 25 06:23:23 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 25 Mar 2014 11:23:23 +0100
Subject: MTU problem on UDP
In-Reply-To: <etPan.532f8e52.327b23c6.2262@kevindeMacBook-Air.local>
References: <etPan.532f8e52.327b23c6.2262@kevindeMacBook-Air.local>
Message-ID: <CAJU7za+U=eXr_OwAumTssjLGGDiBdw63LCspE=SKvf3kyUkmUg@mail.gmail.com>

On Mon, Mar 24, 2014 at 2:45 AM, Kevin <kevinchou.c at gmail.com> wrote:
> Hi List
>
> days ago I post "Can't reach some route in Anyconnect"
>  http://lists.infradead.org/pipermail/openconnect-devel/2014-March/001759.html
> and now I finally find out why.
> in my iptables I have a role to enable udp like this
> -A INPUT -p udp -m udp --dport 443 -j ACCEPT
> after I remove this role from the iptables, My problem solved.
> seems The TCP backup didn't have the MTU problem.
> but I already added
> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
> and even tried
> custom-header = "X-DTLS-MTU: 1200"
> custom-header = "X-CSTP-MTU: 1200"
> set mtu = 1200 in config file. nothing helped.
> So I guess this is a MTU bug on UDP?

There can be many reasons for an MTU issue in IPv4. Most issues are
caused by firewalls that do not forward icmp packets (e.g., the
fragmentation needed). The best if you want to figure out the issue in
your case is to find out with some tool like wireshark where the
packets disappear.

Some background:
ocserv by default sets the don't fragment bit on its udp packets, and
relies on the fragmentation needed icmp packet to modify (decrease)
its MTU value. The openconnect client uses the initially agreed MTU
and expects any routers in between to fragment the IP packet, and the
receiving host to reassemble it. Both approaches have advantages and
disadvantages. The first behaves very bad when firewalls filter the
icmp fragmentation needed packet, and the latter when an intermediate
router doesn't fragment ip packets.

regards,
Nikos


From onion at facetoface-consulting.de  Thu Mar 27 21:07:30 2014
From: onion at facetoface-consulting.de (Engram Thelen)
Date: Fri, 28 Mar 2014 02:07:30 +0100
Subject: ladened
Message-ID: <5334CB19.9040207@facetoface-consulting.de>

 that "they came 



From tonytzhou at gmail.com  Sat Mar 29 21:24:24 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Sat, 29 Mar 2014 21:24:24 -0400
Subject: How to make configure script look for gnutls3?
Message-ID: <53377248.70006@gmail.com>

Hi,

I am trying to compile ocserv 0.3.2 under FreeBSD 10, and FreeBSD 10 
offers binary package named gnutls3 to provide libraries for gnutls 
3.12.  However, the configure script of ocserv keeps looking for 
gnutls.pc for pkg-config tool, but in FreeBSD it is located at 
/usr/local/libdata/pkg-config/gnutls3.pc instead of gnutls.pc, thus the 
script fails. What part of configure script should I change to make it 
look for gnutls3.pc?

Thanks,
TZ


From nmav at gnutls.org  Sun Mar 30 05:57:25 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 30 Mar 2014 11:57:25 +0200
Subject: RFC: PATCH remember certificate
Message-ID: <1396173445.5227.5.camel@nomad.lan>

Hello,
 What do you think of having openconnect remember the public keys of the
hosts that have been explicitly accepted? That would make its usage
close to ssh, except that this will only take effect when PKI fails (not
sure if that's necessarily good).

This is patch: "Remember the public keys of hosts that have been
explicitly accepted." in:

git://gitorious.org/openconnect-x/openconnect-x.git remember-pubkey

Currently it uses the gnutls default file to store the public keys, but
it can be overriden from the command line or
openconnect_set_pubkeyfile().

regards,
Nikos




From nmav at gnutls.org  Sun Mar 30 05:59:36 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 30 Mar 2014 11:59:36 +0200
Subject: How to make configure script look for gnutls3?
In-Reply-To: <53377248.70006@gmail.com>
References: <53377248.70006@gmail.com>
Message-ID: <1396173576.5227.7.camel@nomad.lan>

On Sat, 2014-03-29 at 21:24 -0400, Tony Zhou wrote:
> Hi,
> 
> I am trying to compile ocserv 0.3.2 under FreeBSD 10, and FreeBSD 10 
> offers binary package named gnutls3 to provide libraries for gnutls 
> 3.12.  However, the configure script of ocserv keeps looking for 
> gnutls.pc for pkg-config tool, but in FreeBSD it is located at 
> /usr/local/libdata/pkg-config/gnutls3.pc instead of gnutls.pc, thus the 
> script fails. What part of configure script should I change to make it 
> look for gnutls3.pc?

In ./configure --help there are some environmental variables lists, that
can be used to override the default paths (PKG_CONFIG_PATH,
PKG_CONFIG_LIBDIR), or even allow you to set the necessary cflags and
libs manually (LIBGNUTLS_CFLAGS, LIBGNUTLS_LIBS).

regards,
Nikos




From tonytzhou at gmail.com  Sun Mar 30 10:23:38 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Sun, 30 Mar 2014 10:23:38 -0400
Subject: How to make configure script look for gnutls3?
In-Reply-To: <1396173576.5227.7.camel@nomad.lan>
References: <53377248.70006@gmail.com> <1396173576.5227.7.camel@nomad.lan>
Message-ID: <533828EA.3040002@gmail.com>

Hi Nikos,

I tried to set the environment variables of these two but still cannot 
compile it.
Here are the environment variables:

LIBGNUTLS_CFLAG='-g -O2 -Wall'
LIBGNUTLS_LIBS=/usr/local/lib/gnutls3

the values are from /usr/local/libdata/pkgconfig/gnutls3.pc.

and make complains that "ocpasswd.c:27:10: fatal error: 
'gnutls/gnutls.h' file not found", which it exists in 
/usr/local/include/gnutls3/gnutls/gnutls.h.
I have tried to set LIBGNUTLS_LIBS to /usr/local/include/gnutls3/ and 
re-ran the configure script, but it still cannot compile.

Thanks,
TZ

On 3/30/2014 5:59 AM, Nikos Mavrogiannopoulos wrote:
> On Sat, 2014-03-29 at 21:24 -0400, Tony Zhou wrote:
>> Hi,
>>
>> I am trying to compile ocserv 0.3.2 under FreeBSD 10, and FreeBSD 10
>> offers binary package named gnutls3 to provide libraries for gnutls
>> 3.12.  However, the configure script of ocserv keeps looking for
>> gnutls.pc for pkg-config tool, but in FreeBSD it is located at
>> /usr/local/libdata/pkg-config/gnutls3.pc instead of gnutls.pc, thus the
>> script fails. What part of configure script should I change to make it
>> look for gnutls3.pc?
> In ./configure --help there are some environmental variables lists, that
> can be used to override the default paths (PKG_CONFIG_PATH,
> PKG_CONFIG_LIBDIR), or even allow you to set the necessary cflags and
> libs manually (LIBGNUTLS_CFLAGS, LIBGNUTLS_LIBS).
>
> regards,
> Nikos
>
>



From nmav at gnutls.org  Mon Mar 31 03:53:58 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 31 Mar 2014 09:53:58 +0200
Subject: How to make configure script look for gnutls3?
In-Reply-To: <533828EA.3040002@gmail.com>
References: <53377248.70006@gmail.com> <1396173576.5227.7.camel@nomad.lan>
 <533828EA.3040002@gmail.com>
Message-ID: <CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>

On Sun, Mar 30, 2014 at 4:23 PM, Tony Zhou <tonytzhou at gmail.com> wrote:
> Hi Nikos,
>
> I tried to set the environment variables of these two but still cannot
> compile it.
> Here are the environment variables:
>
> LIBGNUTLS_CFLAG='-g -O2 -Wall'
> LIBGNUTLS_LIBS=/usr/local/lib/gnutls3
> the values are from /usr/local/libdata/pkgconfig/gnutls3.pc.

If these are the values in gnutls3.pc then you should report the issue
in the maintainer of that package. They are clearly broken.
These are options for the compiler and the linker respectively so it
should be something like:

LIBGNUTLS_CFLAG="-g -O2 -Wall -I/usr/local/include"
LIBGNUTLS_LIBS="-L/usr/local/lib/ -lgnutls"

Nevertheless, ocserv is pretty untested on *BSD. I'd suggest to use it
there only if you are prepared to find and report issues.

regards,
Nikos


From tonytzhou at gmail.com  Mon Mar 31 09:50:43 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Mon, 31 Mar 2014 09:50:43 -0400
Subject: How to make configure script look for gnutls3?
In-Reply-To: <CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>
References: <53377248.70006@gmail.com>	<1396173576.5227.7.camel@nomad.lan>	<533828EA.3040002@gmail.com>
 <CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>
Message-ID: <533972B3.1050602@gmail.com>

Hi Nikos,

Thanks for the correction. I didn't use the correct syntax previously; 
the correct form in gnutls3.pc was

LIBGNUTLS_LIBS="-L/usr/local/lib/gnutls3 -lgnutls"
LIBGNUTLS_CFLAGS="-I/usr/local/include/gnutls3"

However, make still complains about missing "gnutls/gnutls.h". I guess 
there's some intrinsic error in that pkg-conf file probably, since I've 
tried to make a copy of that file named gnutls.pc (so that pkg-config 
can find it), but the compiler still has the same error.

Thanks,
TZ

On 3/31/2014 3:53 AM, Nikos Mavrogiannopoulos wrote:
> LIBGNUTLS_LIBS="-L/usr/local/lib/ -lgnutls"



From nmav at gnutls.org  Mon Mar 31 09:57:25 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 31 Mar 2014 15:57:25 +0200
Subject: How to make configure script look for gnutls3?
In-Reply-To: <533972B3.1050602@gmail.com>
References: <53377248.70006@gmail.com> <1396173576.5227.7.camel@nomad.lan>
 <533828EA.3040002@gmail.com>
 <CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>
 <533972B3.1050602@gmail.com>
Message-ID: <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>

On Mon, Mar 31, 2014 at 3:50 PM, Tony Zhou <tonytzhou at gmail.com> wrote:
> Hi Nikos,
> Thanks for the correction. I didn't use the correct syntax previously; the
> correct form in gnutls3.pc was
> LIBGNUTLS_LIBS="-L/usr/local/lib/gnutls3 -lgnutls"
> LIBGNUTLS_CFLAGS="-I/usr/local/include/gnutls3"

If that's the correct cflag, then /usr/local/include/gnutls3 should
contain a directory named 'gnutls' under which are the header files.
If not you'll need to create it (or make it a link to '.').

regards,
Nikos


From tonytzhou at gmail.com  Mon Mar 31 09:59:04 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Mon, 31 Mar 2014 09:59:04 -0400
Subject: How to make configure script look for gnutls3?
In-Reply-To: <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>
References: <53377248.70006@gmail.com>	<1396173576.5227.7.camel@nomad.lan>	<533828EA.3040002@gmail.com>	<CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>	<533972B3.1050602@gmail.com>
 <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>
Message-ID: <533974A8.5050100@gmail.com>

[tony at vpn ~]$ ls -alh /usr/local/include/gnutls3/
total 12
drwxr-xr-x  3 root  wheel   512B Mar 27 13:22 .
drwxr-xr-x  9 root  wheel   1.0K Mar 31 05:47 ..
drwxr-xr-x  2 root  wheel   512B Mar 27 13:22 gnutls

[tony at vpn ~]$ ls -alh /usr/local/include/gnutls3/gnutls/gnutls.h
-r--r--r--  1 root  wheel    85K Mar 27 13:22 
/usr/local/include/gnutls3/gnutls/gnutls.h

Surely it does... And I'm compiling using root.

On 3/31/2014 9:57 AM, Nikos Mavrogiannopoulos wrote:
> On Mon, Mar 31, 2014 at 3:50 PM, Tony Zhou <tonytzhou at gmail.com> wrote:
>> Hi Nikos,
>> Thanks for the correction. I didn't use the correct syntax previously; the
>> correct form in gnutls3.pc was
>> LIBGNUTLS_LIBS="-L/usr/local/lib/gnutls3 -lgnutls"
>> LIBGNUTLS_CFLAGS="-I/usr/local/include/gnutls3"
> If that's the correct cflag, then /usr/local/include/gnutls3 should
> contain a directory named 'gnutls' under which are the header files.
> If not you'll need to create it (or make it a link to '.').
>
> regards,
> Nikos



From tonytzhou at gmail.com  Mon Mar 31 10:14:01 2014
From: tonytzhou at gmail.com (Tony Zhou)
Date: Mon, 31 Mar 2014 10:14:01 -0400
Subject: How to make configure script look for gnutls3?
In-Reply-To: <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>
References: <53377248.70006@gmail.com>	<1396173576.5227.7.camel@nomad.lan>	<533828EA.3040002@gmail.com>	<CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>	<533972B3.1050602@gmail.com>
 <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>
Message-ID: <53397829.1090206@gmail.com>

I copied the include folder to src folder and it gives another 
compilation error. Guess ocserv is just not ready for *BSD yet. :-)
Thanks for the help anyway!

Regards,
TZ

On 3/31/2014 9:57 AM, Nikos Mavrogiannopoulos wrote:
> On Mon, Mar 31, 2014 at 3:50 PM, Tony Zhou <tonytzhou at gmail.com> wrote:
>> Hi Nikos,
>> Thanks for the correction. I didn't use the correct syntax previously; the
>> correct form in gnutls3.pc was
>> LIBGNUTLS_LIBS="-L/usr/local/lib/gnutls3 -lgnutls"
>> LIBGNUTLS_CFLAGS="-I/usr/local/include/gnutls3"
> If that's the correct cflag, then /usr/local/include/gnutls3 should
> contain a directory named 'gnutls' under which are the header files.
> If not you'll need to create it (or make it a link to '.').
>
> regards,
> Nikos



From stu at spacehopper.org  Mon Mar 31 10:37:24 2014
From: stu at spacehopper.org (Stuart Henderson)
Date: Mon, 31 Mar 2014 15:37:24 +0100
Subject: How to make configure script look for gnutls3?
In-Reply-To: <53397829.1090206@gmail.com>
References: <53377248.70006@gmail.com> <1396173576.5227.7.camel@nomad.lan>
 <533828EA.3040002@gmail.com>
 <CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>
 <533972B3.1050602@gmail.com>
 <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>
 <53397829.1090206@gmail.com>
Message-ID: <20140331143724.GA5596@symphytum.spacehopper.org>

On 2014/03/31 10:14, Tony Zhou wrote:
> I copied the include folder to src folder and it gives another compilation
> error.

Pasting in the actual command lines and error messages might help.

> Guess ocserv is just not ready for *BSD yet. :-)

As far as OpenBSD goes, it needs a few headers adding to get it to compile.
Last time I looked at this I couldn't get compilation to finish at all, but
I've just re-tested with 0.3.2 and it does compile with just these additions,
but I haven't tested running it yet.

sys/uio.h is needed in common.c, main-misc.c, worker-misc.c

limits.h is needed in a few places for _POSIX_PATH_MAX

sys/wait.h is needed for WEXITSTATUS, WIFEXITED in route-add.c



From dwmw2 at infradead.org  Mon Mar 31 10:45:30 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 31 Mar 2014 15:45:30 +0100
Subject: RFC: PATCH remember certificate
In-Reply-To: <1396173445.5227.5.camel@nomad.lan>
References: <1396173445.5227.5.camel@nomad.lan>
Message-ID: <1396277130.8569.76.camel@i7.infradead.org>

On Sun, 2014-03-30 at 11:57 +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  What do you think of having openconnect remember the public keys of the
> hosts that have been explicitly accepted? That would make its usage
> close to ssh, except that this will only take effect when PKI fails (not
> sure if that's necessarily good).
> 
> This is patch: "Remember the public keys of hosts that have been
> explicitly accepted." in:
> 
> git://gitorious.org/openconnect-x/openconnect-x.git remember-pubkey
> 
> Currently it uses the gnutls default file to store the public keys, but
> it can be overriden from the command line or
> openconnect_set_pubkeyfile().

Hm, I think I'd rather encourage people to fetch the CA file and do
things properly.

FWIW the NetworkManager authentication dialog *will* remember servers'
public keys after you manually accept them. The library offers a cert
acceptance callback, which lets it remember the ones that the user
accepted.

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

From nmav at gnutls.org  Mon Mar 31 10:55:27 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 31 Mar 2014 16:55:27 +0200
Subject: RFC: PATCH remember certificate
In-Reply-To: <1396277130.8569.76.camel@i7.infradead.org>
References: <1396173445.5227.5.camel@nomad.lan>
 <1396277130.8569.76.camel@i7.infradead.org>
Message-ID: <CAJU7za+zce62xRdo=cDcGnjygvZCi6mgNfPKrb-jOMcgWw5VNg@mail.gmail.com>

On Mon, Mar 31, 2014 at 4:45 PM, David Woodhouse <dwmw2 at infradead.org> wrote:

>> Currently it uses the gnutls default file to store the public keys, but
>> it can be overriden from the command line or
>> openconnect_set_pubkeyfile().
> Hm, I think I'd rather encourage people to fetch the CA file and do
> things properly.

Well, I think that the "proper way" is far too cumbersome and
undocumented and thus
most people would just use --no-cert-check. In fact my motive for that
was that I saw that
openwrt's openconnect does use --no-cert-check by default. Just remembering the
seen certificates is the simplest way to do things the "proper way"
(and in fact I believe
that remembering public keys per host is far more secure than PKI).

> FWIW the NetworkManager authentication dialog *will* remember servers'
> public keys after you manually accept them. The library offers a cert
> acceptance callback, which lets it remember the ones that the user
> accepted.

That's pretty good.

regards,
Nikos


From nmav at gnutls.org  Mon Mar 31 10:59:15 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 31 Mar 2014 16:59:15 +0200
Subject: How to make configure script look for gnutls3?
In-Reply-To: <20140331143724.GA5596@symphytum.spacehopper.org>
References: <53377248.70006@gmail.com> <1396173576.5227.7.camel@nomad.lan>
 <533828EA.3040002@gmail.com>
 <CAJU7zaK68R9bjhEeJO1aEFUz3jR+Zkv3gCb=kCf8JsFosc082g@mail.gmail.com>
 <533972B3.1050602@gmail.com>
 <CAJU7zaLWcyAeTjTR98OK3OaSg_nGE+o7bMrdV=Eesv4Te_jWQw@mail.gmail.com>
 <53397829.1090206@gmail.com>
 <20140331143724.GA5596@symphytum.spacehopper.org>
Message-ID: <CAJU7zaJfYiheGEbzjTRA3y9Dy=nbpsdHVO9t53uVD9PXGoouqg@mail.gmail.com>

On Mon, Mar 31, 2014 at 4:37 PM, Stuart Henderson > sys/uio.h is
needed in common.c, main-misc.c, worker-misc.c
> limits.h is needed in a few places for _POSIX_PATH_MAX
> sys/wait.h is needed for WEXITSTATUS, WIFEXITED in route-add.c

Thank you; they have been added.

regards,
Nikos


From dwmw2 at infradead.org  Mon Mar 31 11:10:00 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 31 Mar 2014 16:10:00 +0100
Subject: RFC: PATCH remember certificate
In-Reply-To: <CAJU7za+zce62xRdo=cDcGnjygvZCi6mgNfPKrb-jOMcgWw5VNg@mail.gmail.com>
References: <1396173445.5227.5.camel@nomad.lan>
 <1396277130.8569.76.camel@i7.infradead.org>
 <CAJU7za+zce62xRdo=cDcGnjygvZCi6mgNfPKrb-jOMcgWw5VNg@mail.gmail.com>
Message-ID: <1396278600.8569.83.camel@i7.infradead.org>

On Mon, 2014-03-31 at 16:55 +0200, Nikos Mavrogiannopoulos wrote:
> 
> Well, I think that the "proper way" is far too cumbersome and
> undocumented and thus
> most people would just use --no-cert-check. In fact my motive for that
> was that I saw that
> openwrt's openconnect does use --no-cert-check by default.

That might actually be my fault. I meant to fix up the interaction
somehow, so that I could drive the login process through the luci UI.
But never quite got round to doing anything more than the basic
proof-of-concept scripting.

> > FWIW the NetworkManager authentication dialog *will* remember servers'
> > public keys after you manually accept them. The library offers a cert
> > acceptance callback, which lets it remember the ones that the user
> > accepted.
> 
> That's pretty good.

Actually it could be better. I don't pass the *hostname* back from the
library via the callback. If you manually check and accept a given cert
for one server, you'll then blindly accept it for any *other* server
that you see with the same VPN configuration.

I should probably fix that before OpenConnect 6.00 since we've already
bumped the ABI/API version...


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

From cernekee at gmail.com  Mon Mar 31 23:09:15 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Mon, 31 Mar 2014 20:09:15 -0700
Subject: [PATCH 2/3] openssl: Skip password prompt on unencrypted PKCS#12 files
In-Reply-To: <1396321756-4827-1-git-send-email-cernekee@gmail.com>
References: <1396321756-4827-1-git-send-email-cernekee@gmail.com>
Message-ID: <1396321756-4827-3-git-send-email-cernekee@gmail.com>

This brings the OpenSSL load_pkcs12_certificate() behavior in line with
GnuTLS behavior.

Signed-off-by: Kevin Cernekee <cernekee at gmail.com>
---
 openssl.c |   21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/openssl.c b/openssl.c
index f6171ce..67432d9 100644
--- a/openssl.c
+++ b/openssl.c
@@ -403,26 +403,27 @@ static int load_pkcs12_certificate(struct openconnect_info *vpninfo, PKCS12 *p12
 	   when PKCS12_parse() returns an error, but *ca is left pointing
 	   to the freed memory. */
 	ca = NULL;
-	if (!pass && request_passphrase(vpninfo, "openconnect_pkcs12", &pass,
-					_("Enter PKCS#12 pass phrase:")) < 0) {
-		PKCS12_free(p12);
-		return -EINVAL;
-	}
 	if (!PKCS12_parse(p12, pass, &pkey, &cert, &ca)) {
 		unsigned long err = ERR_peek_error();
 
-		openconnect_report_ssl_errors(vpninfo);
-
 		if (ERR_GET_LIB(err) == ERR_LIB_PKCS12 &&
 		    ERR_GET_FUNC(err) == PKCS12_F_PKCS12_PARSE &&
 		    ERR_GET_REASON(err) == PKCS12_R_MAC_VERIFY_FAILURE) {
-			vpn_progress(vpninfo, PRG_ERR,
-				     _("Parse PKCS#12 failed (wrong passphrase?)\n"));
+			if (pass)
+				vpn_progress(vpninfo, PRG_ERR,
+					     _("Failed to decrypt PKCS#12 certificate file\n"));
 			free(pass);
-			pass = NULL;
+			if (request_passphrase(vpninfo, "openconnect_pkcs12", &pass,
+					       _("Enter PKCS#12 pass phrase:")) < 0) {
+				PKCS12_free(p12);
+				return -EINVAL;
+			}
+
 			goto retrypass;
 		}
 
+		openconnect_report_ssl_errors(vpninfo);
+
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Parse PKCS#12 failed (see above errors)\n"));
 		PKCS12_free(p12);
-- 
1.7.9.5



From cernekee at gmail.com  Mon Mar 31 23:09:13 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Mon, 31 Mar 2014 20:09:13 -0700
Subject: [PATCH 0/3] Handle unencrypted certificates
Message-ID: <1396321756-4827-1-git-send-email-cernekee@gmail.com>

This fixes one case in which an unencrypted private key file was not
recognized at all, and two cases where an unnecessary password prompt
showed up and forced the user to submit an empty password to proceed.

As a side effect of harmonizing the OpenSSL and GnuTLS
load_pkcs12_certificate password loops, OpenSSL builds are less noisy
than before when reporting bad PKCS#12 passwords.  I can change this
back if it is a problem.

I still see a minor inconsistency between PEM and PKCS#12 handling
on OpenSSL.  Not sure if it's worth fixing:


1) PEM cert requires a password, but the user just hits enter and
is_pem_password_error() gives up:

Using client certificate '/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=somegroup/CN=test'
Enter PEM pass phrase:
140006881695456:error:0907B068:PEM routines:PEM_READ_BIO_PRIVATEKEY:bad password read:pem_pkey.c:109:
Loading private key failed (see above errors)
Loading certificate failed. Aborting.
Failed to open HTTPS connection to asa
<aborts>

2) PEM cert requires a password, but the user enters the wrong password so
OpenSSL keeps asking:

Using client certificate '/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=somegroup/CN=test'
Enter PEM pass phrase:
139850861938400:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
Loading private key failed (wrong passphrase?)
Enter PEM pass phrase:
139850861938400:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
Loading private key failed (wrong passphrase?)
Enter PEM pass phrase:
139850861938400:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
Loading private key failed (wrong passphrase?)
Enter PEM pass phrase:
<keeps prompting forever>

3) PKCS#12 cert requires a password; user hits enter OR types the wrong
password.  OpenSSL keeps asking:

Enter PKCS#12 pass phrase:
Failed to decrypt PKCS#12 certificate file
Enter PKCS#12 pass phrase:
Failed to decrypt PKCS#12 certificate file
Enter PKCS#12 pass phrase:
Failed to decrypt PKCS#12 certificate file
Enter PKCS#12 pass phrase:
<keeps prompting forever>


Kevin Cernekee (3):
  gnutls: Handle empty (but not NULL) passwords on PKCS#12 certs
  openssl: Skip password prompt on unencrypted PKCS#12 files
  openssl: Support unencrypted PKCS#8 private keys

 gnutls.c  |   10 +++++++++-
 openssl.c |   24 +++++++++++++-----------
 2 files changed, 22 insertions(+), 12 deletions(-)

-- 
1.7.9.5



From cernekee at gmail.com  Mon Mar 31 23:09:16 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Mon, 31 Mar 2014 20:09:16 -0700
Subject: [PATCH 3/3] openssl: Support unencrypted PKCS#8 private keys
In-Reply-To: <1396321756-4827-1-git-send-email-cernekee@gmail.com>
References: <1396321756-4827-1-git-send-email-cernekee@gmail.com>
Message-ID: <1396321756-4827-4-git-send-email-cernekee@gmail.com>

This is verified working with the output from
"openssl pkcs12 -in foo.p12 -nodes" (v1.0.1).

Signed-off-by: Kevin Cernekee <cernekee at gmail.com>
---
 openssl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/openssl.c b/openssl.c
index 67432d9..39db88e 100644
--- a/openssl.c
+++ b/openssl.c
@@ -761,7 +761,8 @@ static int load_certificate(struct openconnect_info *vpninfo)
 				break;
 			} else if (!strcmp(buf, "-----BEGIN RSA PRIVATE KEY-----\n") ||
 				   !strcmp(buf, "-----BEGIN DSA PRIVATE KEY-----\n") ||
-				   !strcmp(buf, "-----BEGIN ENCRYPTED PRIVATE KEY-----\n")) {
+				   !strcmp(buf, "-----BEGIN ENCRYPTED PRIVATE KEY-----\n") ||
+				   !strcmp(buf, "-----BEGIN PRIVATE KEY-----\n")) {
 				vpninfo->cert_type = CERT_TYPE_PEM;
 				break;
 			}
-- 
1.7.9.5



From cernekee at gmail.com  Mon Mar 31 23:09:14 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Mon, 31 Mar 2014 20:09:14 -0700
Subject: [PATCH 1/3] gnutls: Handle empty (but not NULL) passwords on PKCS#12
 certs
In-Reply-To: <1396321756-4827-1-git-send-email-cernekee@gmail.com>
References: <1396321756-4827-1-git-send-email-cernekee@gmail.com>
Message-ID: <1396321756-4827-2-git-send-email-cernekee@gmail.com>

GnuTLS can accept PKCS#12 certs with either empty or NULL passwords[1],
but unlike OpenSSL[2], both options need to be tried separately.

[1] https://gitorious.org/gnutls/gnutls/commit/7c4c21c0e84a539558e3e1689d8a7b8a2c4c0056
[2] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=a331a305e9c9c5353bd42db6dbda78a418285708

Signed-off-by: Kevin Cernekee <cernekee at gmail.com>
---
 gnutls.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gnutls.c b/gnutls.c
index 36164db..7400d17 100644
--- a/gnutls.c
+++ b/gnutls.c
@@ -345,7 +345,15 @@ static int load_pkcs12_certificate(struct openconnect_info *vpninfo,
 
 	pass = vpninfo->cert_password;
 	while ((err = gnutls_pkcs12_verify_mac(p12, pass)) == GNUTLS_E_MAC_VERIFY_FAILED) {
-		if (pass)
+		if (!pass) {
+			/* OpenSSL's PKCS12_parse() code will try both NULL and "" automatically,
+			 * but GnuTLS requires two separate attempts. */
+			err = gnutls_pkcs12_verify_mac(p12, "");
+			if (err != GNUTLS_E_MAC_VERIFY_FAILED) {
+				pass = strdup("");
+				break;
+			}
+		} else
 			vpn_progress(vpninfo, PRG_ERR,
 				     _("Failed to decrypt PKCS#12 certificate file\n"));
 		free(pass);
-- 
1.7.9.5



