From lists-infradead.org at arifsaha.com  Thu Apr  2 20:43:07 2015
From: lists-infradead.org at arifsaha.com (S P Arif Sahari Wibowo)
Date: Thu, 2 Apr 2015 21:43:07 -0600 (MDT)
Subject: Failed to open tun device: Invalid argument
In-Reply-To: <1427283679.12420.3.camel@infradead.org>
References: <alpine.OSX.2.20.1503191555160.1457@macmini2014.local>
 <1427283679.12420.3.camel@infradead.org>
Message-ID: <alpine.OSX.2.20.1504022136530.1457@macmini2014.local>

On 2015-03-25, 05:41, David Woodhouse wrote:
> Do you have TunTapOSX installed?

Great advice! I do have TunTapOSX installed but not running. 
Once I enabled it ("port load tuntaposx"), I can get openconnect 
works as intended.

> What happens if you add '-i utun0' to the openconnect command 
> line?

This produce this error:

Invalid interface name 'utun0'; must match 'tun%d'
Set up tun device failed


Furthermore, there is no "utun*" device in this system:

mycomputer:~ root# ls -l /dev/*tun*
crw-rw----  1 root  wheel   39,   0  2 Apr 21:41 /dev/tun0
crw-rw----  1 root  wheel   39,   1  1 Apr 12:25 /dev/tun1
crw-rw----  1 root  wheel   39,  10  1 Apr 12:25 /dev/tun10
crw-rw----  1 root  wheel   39,  11  1 Apr 12:25 /dev/tun11
crw-rw----  1 root  wheel   39,  12  1 Apr 12:25 /dev/tun12
crw-rw----  1 root  wheel   39,  13  1 Apr 12:25 /dev/tun13
crw-rw----  1 root  wheel   39,  14  1 Apr 12:25 /dev/tun14
crw-rw----  1 root  wheel   39,  15  1 Apr 12:25 /dev/tun15
crw-rw----  1 root  wheel   39,   2  1 Apr 12:25 /dev/tun2
crw-rw----  1 root  wheel   39,   3  1 Apr 12:25 /dev/tun3
crw-rw----  1 root  wheel   39,   4  1 Apr 12:25 /dev/tun4
crw-rw----  1 root  wheel   39,   5  1 Apr 12:25 /dev/tun5
crw-rw----  1 root  wheel   39,   6  1 Apr 12:25 /dev/tun6
crw-rw----  1 root  wheel   39,   7  1 Apr 12:25 /dev/tun7
crw-rw----  1 root  wheel   39,   8  1 Apr 12:25 /dev/tun8
crw-rw----  1 root  wheel   39,   9  1 Apr 12:25 /dev/tun9


Thanks!

-- 
    ____  ____  ____  ____ (stephan paul) Arif Sahari Wibowo
   /___  /___/ /___/ /___      http://www.arifsaha.com/
  ____/ /     /   / ____/
***** http://www.catholic.org/clife/lent/#content *****


From olda at cvut.cz  Fri Apr  3 06:18:19 2015
From: olda at cvut.cz (Olda Bartunek)
Date: Fri, 3 Apr 2015 13:18:19 +0000 (UTC)
Subject: Juniper SSL VPN support
References: <1422281866.5382.55.camel@infradead.org>
 <loom.20150325T230026-33@post.gmane.org>
 <1427327232.20521.5.camel@infradead.org>
 <loom.20150326T205212-69@post.gmane.org>
 <1427402262.17555.1.camel@infradead.org>
 <loom.20150327T000042-117@post.gmane.org>
 <1427414259.7805.3.camel@infradead.org>
Message-ID: <loom.20150403T144928-969@post.gmane.org>

David Woodhouse <dwmw2 <at> infradead.org> writes:

> With -v -v do you see traffic in either direction? Is vpnc-script-win 
> actually doing the right thing?
> 
> > Is there a way how to get debug output or I need to touch esp.c?
> 
> I ripped out all that debugging when I declared the sequence number 
> checking to be working. You'll have to add it back.
> 

with -v -v I see a bit more but it doesn't shows any traffic over the 
tunnel:
....
 Got HTTP response: HTTP/1.1 200 OK
 Content-type: application/octet-stream
 Pragma: no-cache
 NCP-Version: 3
 Set-Cookie: DSLastAccess=1428064535; path=/; Secure
 Connection: close
 0000: 16 00 00 04 00 00 00 09 00 6c 6f 63 61 6c 68 6f
 0010: 73 74 bb 01 00 00 00 00
 Read 3 bytes of SSL record
 Read 657 bytes of SSL record
 Got KMP message 301 of size 635
 Unknown TLV group 3 attr 1 len 1: 00
 Unknown TLV group 3 attr 2 len 1: 00
 Received split include route 172.16.0.0/255.255.0.0
 Received split include route 172.17.0.0/255.255.0.0
 Received MTU 1400 from server
 Received DNS server 172.16.10.14
 Unknown TLV group 2 attr 3 len 4: 01 00 00 00
 ESP compression: 0
 ESP encryption: 0x02 (AES-128)
 ESP HMAC: 0x02 (SHA1)
 ESP key lifetime: 1200 seconds
 ESP key lifetime: 0 bytes
 ESP replay protection: 1
 Unknown TLV group 8 attr 11 len 4: 00 00 00 00
 ESP port: 4500
 ESP to SSL fallback: 15 seconds
 Unknown TLV group 8 attr 8 len 4: 00 00 00 3c
 Received internal IP address 192.168.169.11
 Received netmask 255.255.255.255
 Received internal gateway address 10.200.200.200
 ESP SPI (outbound): ff2028bb
 64 bytes of ESP secrets
 0000: 8e 00 00 00 00 00 00 00 01 2f 01 00 00 00 01 00
 0010: 00 00 00 00 00 10 00 06 00 00 00 0a 00 02 00 00
 0020: 00 04 00 00 05 78 00 00 00 00 00 00 01 2e 01 00
 0030: 00 00 01 00 00 00 00 00 00 56 00 07 00 00 00 50
 0040: 00 01 00 00 00 04 81 a6 34 df 00 02 00 00 00 40
 0050: ae 16 29 9f 54 bd 94 76 15 59 fd 97 bb 93 7f e5
 0060: be 63 b2 4a 46 4b ff d4 75 48 22 87 a8 2d 1d ee
 0070: e0 cc 49 2d 86 f6 80 5c 85 91 0c c7 13 af d1 1d
 0080: 42 84 55 0c f9 79 45 13 e2 ec 89 b1 26 a3 25 9f
 Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Opened tun device Local Area Connection 3
 TAP-Windows driver v9.9 (0)
 Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

VPN Gateway: <IPremoved>
Internal Address: 192.168.169.11
Internal Netmask: 255.255.255.255
Internal Gateway: 192.168.169.12
Interface: "Local Area Connection 3"
MTU: 1400
Configuring "Local Area Connection 3" interface for Legacy IP...
done.
Configuring Legacy IP networks:
Waiting for interface to come up...
Failed to spawn script 'F:\a\a\vpnc-script-win.js' for connect: The 
operation completed successfully.
 Parameters for incoming ESP: SPI 0x225ed42f
 ESP encryption type AES-128-CBC (RFC3602) key 
0x83aba720957bd2a10b4577cf91a0f533
 ESP authentication type HMAC-SHA-1-96 (RFC2404) key 
0x075622223fb68b083f521ab8c
56af1660ad7cf1d
 Parameters for outgoing ESP: SPI 0x06eec4f4
 ESP encryption type AES-128-CBC (RFC3602) key 
0xda0b49074ddc03d81b1ab9a13f727137
 ESP authentication type HMAC-SHA-1-96 (RFC2404) key 
0x682db8d3221c3a49413f0a0a3218060f28906df9
 Send ESP probes
 Connected Local Area Connection 3 as 192.168.169.11, using SSL
 No work to do; sleeping for 60000 ms...
 Received ESP packet of 52 bytes
 Accepting later-than-expected ESP packet with seq 1 (expected 0)
 ESP session established with server
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 1
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 2
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 2
 Packet outgoing:
 0000: 21 00 00 00 00 00 00 00 01 2f 01 00 00 00 01 00
 0010: 00 00 00 00 00 0d 00 06 00 00 00 07 00 01 00 00
 0020: 00 01 01
 Sent ESP enable control packet
 No work to do; sleeping for 15000 ms...
 No work to do; sleeping for 15000 ms...
 Route configuration done.
Send ESP probes for DPD
 No work to do; sleeping for 7000 ms...
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 3
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 3
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 4
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 4
 No work to do; sleeping for 15000 ms...
 No work to do; sleeping for 15000 ms...
 Send ESP probes for DPD
 No work to do; sleeping for 7000 ms...
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 5
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 5
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 6
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 6
 No work to do; sleeping for 15000 ms...
 No work to do; sleeping for 15000 ms...
 Send ESP probes for DPD
 No work to do; sleeping for 7000 ms...
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 7
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 7
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 8
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 8
 No work to do; sleeping for 15000 ms...
 No work to do; sleeping for 15000 ms...
 Send ESP probes for DPD
 No work to do; sleeping for 7000 ms...
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 9
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 9
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 10
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 10
 No work to do; sleeping for 15000 ms...
 No work to do; sleeping for 15000 ms...
 Send ESP probes for DPD
 No work to do; sleeping for 7000 ms...
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 11
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 11
 No work to do; sleeping for 15000 ms...
 Received ESP packet of 52 bytes
 Accepting expected ESP packet with seq 12
 Received ESP packet of 52 bytes
 Discarding replayed ESP packet with seq 12
 No work to do; sleeping for 15000 ms...
 No work to do; sleeping for 15000 ms...
 ^C
.....
(while I run ping)
vpnc-script-win.js script seems to works ok. I got right IP, got routes/DNS, 
only difference is netmask while on linux has /32 while on windows /24 but I 
guess is because of windows...
O.



From brett.higgins at gmail.com  Fri Apr  3 06:53:56 2015
From: brett.higgins at gmail.com (Brett Higgins)
Date: Fri, 3 Apr 2015 09:53:56 -0400
Subject: HostChecker NullPointerException with juniper server
Message-ID: <CAOVC=BVBdpTh4CViojmaaR83OhNOmH-QTNE=VfQimGjwYpa=Mw@mail.gmail.com>

OpenConnect (or host checker) fails with NullPointerException
connecting to a juniper server: http://hastebin.com/xosisuliwa

I can provide more information but I?m not at all sure what would be helpful.

-Brett


From olda at cvut.cz  Fri Apr  3 08:28:52 2015
From: olda at cvut.cz (Olda Bartunek)
Date: Fri, 3 Apr 2015 15:28:52 +0000 (UTC)
Subject: unknow for for preauthentication
Message-ID: <loom.20150403T171643-689@post.gmane.org>

Attempt to use script for host checker failed with error bellow.

OpenConnect on Linux (fedora 21) was executed with
./openconnect --juniper --no-cert-check --useragent  'Mozilla/5.0 (Linux) 
Firefox' --csd-wrapper=./tncc-wrapper.py <vpnIP>

All components was recent versions taken today from git.

in connection state it fail with:
Unknown form ID 'frm'
Dumping unknown HTML form:
<form id="frm_142" name="frm" action="remediate.cgi">

    <input id="action_31" type="hidden" name="action" value="">

    <input id="signinId_2" type="hidden" name="signinId" value="">
    <input id="realmId_10" type="hidden" name="realmId" value="3">
    <input id="executedStep_2" type="hidden" name="executedStep" 
value="rolecheck">
    <input id="stateId_8" type="hidden" name="stateId" 
value="state_4d36c4b88f767133ec51fa22bebc415c">
    <input id="p_16" type="hidden" name="p" value="">

    <input id="showContinue_2" type="hidden" name="showContinue" value="1">
    <input id="showRemedOption_2" type="hidden" name="showRemedOption" 
value="0">

    <input id="hostcheckTS_2" type="hidden" name="hostcheckTS" value="">
    <input id="totalseconds_2" type="hidden" name="totalseconds" value="">

    <input id="executedAction_2" type="hidden" name="executedAction" 
value="">
</form>
Failed to obtain WebVPN cookie
java.lang.NullPointerException
        at net.juniper.tnc.HttpNAR.HttpNAR.processCommands(HttpNAR.java:381)
        at net.juniper.tnc.HttpNAR.HttpNAR.run(HttpNAR.java:261)
        at 
net.juniper.tnc.NARPlatform.linux.LinuxHttpNAR.main(LinuxHttpNAR.java:52)

---
O.



From dwmw2 at infradead.org  Fri Apr  3 09:18:59 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 03 Apr 2015 18:18:59 +0200
Subject: Failed to open tun device: Invalid argument
In-Reply-To: <alpine.OSX.2.20.1504022136530.1457@macmini2014.local>
References: <alpine.OSX.2.20.1503191555160.1457@macmini2014.local>
 <1427283679.12420.3.camel@infradead.org>
 <alpine.OSX.2.20.1504022136530.1457@macmini2014.local>
Message-ID: <1428077939.3235.2.camel@infradead.org>

On Thu, 2015-04-02 at 21:43 -0600, S P Arif Sahari Wibowo wrote:
> On 2015-03-25, 05:41, David Woodhouse wrote:
> > Do you have TunTapOSX installed?
> 
> Great advice! I do have TunTapOSX installed but not running. 
> Once I enabled it ("port load tuntaposx"), I can get openconnect 
> works as intended.

OK, but utun is supposed to be superseding it.

> > What happens if you add '-i utun0' to the openconnect command 
> > line?
> 
> This produce this error:
> 
> Invalid interface name 'utun0'; must match 'tun%d'
> Set up tun device failed
> 
> 
> Furthermore, there is no "utun*" device in this system:

There's no device; it's socket-based. What did the configure script say
when you ran it? Did it not find net/utun.h? 

-- 
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/20150403/fad9066a/attachment-0001.bin>

From uwe.h.schreiber at t-online.de  Sat Apr  4 01:22:58 2015
From: uwe.h.schreiber at t-online.de (Uwe Schreiber)
Date: Sat, 04 Apr 2015 10:22:58 +0200
Subject: openconnect is using SSL instead of TLSv1.2 Protocol
Message-ID: <1428135778.7266.11.camel@uwe-ThinkPad-T540p>

Hello,

i'am using Ubuntu 14.04.2 with all the latest patches.

I installed openconnect v7.06-7-gf2e8cd0 from GIT.
I am trying to connect to a Juniper VPN, but i receive the message

SSL connection failure: A TLS packet with unexpected length was
received.

I did a trace using Wireshark and have seen my client is sending a
"Client Hello" using SSL as protocol.

The VPN server is first responding by an ACK ... but immediately after
that the server is sending an ACK, RST.

I did a test using "openssl s_client connect:my-vpn.host:port"
This creates an "Client Hello" using TLSv1.2 and the handshaking between
my client and the VPN server is successful.

When i specify any other protocol within "openssl s_client" the behavior
is the same like using "openconnect --juniper my-vpn.host".

Is there a possibility to force openconnect using TLSv1.2 as protocol?

Regards 
Uwe Schreiber




From cynix at cynix.org  Sat Apr  4 03:39:03 2015
From: cynix at cynix.org (Brian Chu)
Date: Sat, 4 Apr 2015 21:39:03 +1100
Subject: [PATCH] Fix ocserv tun read/write on FreeBSD
Message-ID: <CALPpbciTZJ5BKOMoeOFoD8r95K6cseumFAJNndQAtwixva63cg@mail.gmail.com>

Hi Nikos,

In commit 9d51069 you added handling for the additional 4-byte packet
header that's present on OpenBSD. However, this is broken on FreeBSD
because whilst TUNSIFHEAD is defined, it is not set by default. The
attached patch fixes this by setting this ioctl after creating the tun
device. I've also attached 2 trivial patches for fixing an extraneous
return value and indentation.

Cheers,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-invalid-return-value.patch
Type: application/octet-stream
Size: 668 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150404/825d79be/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Fix-indentation.patch
Type: application/octet-stream
Size: 1857 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150404/825d79be/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Set-TUNSIFHEAD-on-the-tun-device-if-supported.patch
Type: application/octet-stream
Size: 864 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150404/825d79be/attachment-0002.obj>

From nmav at gnutls.org  Sat Apr  4 07:04:32 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 04 Apr 2015 16:04:32 +0200
Subject: [PATCH] Fix ocserv tun read/write on FreeBSD
In-Reply-To: <CALPpbciTZJ5BKOMoeOFoD8r95K6cseumFAJNndQAtwixva63cg@mail.gmail.com>
References: <CALPpbciTZJ5BKOMoeOFoD8r95K6cseumFAJNndQAtwixva63cg@mail.gmail.com>
Message-ID: <1428156272.8035.1.camel@gnutls.org>

On Sat, 2015-04-04 at 21:39 +1100, Brian Chu wrote:
> Hi Nikos,
> 
> In commit 9d51069 you added handling for the additional 4-byte packet
> header that's present on OpenBSD. However, this is broken on FreeBSD
> because whilst TUNSIFHEAD is defined, it is not set by default. The
> attached patch fixes this by setting this ioctl after creating the tun
> device. I've also attached 2 trivial patches for fixing an extraneous
> return value and indentation.

Thanks. Wouldn't however be simpler to define TUN_AF_PREFIX only in
OpenBSD then?

regards,
Nikos




From cynix at cynix.org  Sat Apr  4 07:31:36 2015
From: cynix at cynix.org (Brian Chu)
Date: Sun, 5 Apr 2015 01:31:36 +1100
Subject: [PATCH] Fix ocserv tun read/write on FreeBSD
In-Reply-To: <1428156272.8035.1.camel@gnutls.org>
References: <CALPpbciTZJ5BKOMoeOFoD8r95K6cseumFAJNndQAtwixva63cg@mail.gmail.com>
 <1428156272.8035.1.camel@gnutls.org>
Message-ID: <CALPpbcgYAJmzzCcAJ369dGH8V3aCm_sx6PGcgKhWFiw1_t6zUA@mail.gmail.com>

On Sun, Apr 5, 2015 at 1:04 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Sat, 2015-04-04 at 21:39 +1100, Brian Chu wrote:
>> Hi Nikos,
>>
>> In commit 9d51069 you added handling for the additional 4-byte packet
>> header that's present on OpenBSD. However, this is broken on FreeBSD
>> because whilst TUNSIFHEAD is defined, it is not set by default. The
>> attached patch fixes this by setting this ioctl after creating the tun
>> device. I've also attached 2 trivial patches for fixing an extraneous
>> return value and indentation.
>
> Thanks. Wouldn't however be simpler to define TUN_AF_PREFIX only in
> OpenBSD then?
>

My understanding is that IPv6 won't work if TUNSIFHEAD is not set
(FreeBSD will assume the address family is AF_INET for all packets
written).

Cheers,
Brian


From nmav at gnutls.org  Sat Apr  4 10:16:12 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 04 Apr 2015 19:16:12 +0200
Subject: [PATCH] Fix ocserv tun read/write on FreeBSD
In-Reply-To: <CALPpbcgYAJmzzCcAJ369dGH8V3aCm_sx6PGcgKhWFiw1_t6zUA@mail.gmail.com>
References: <CALPpbciTZJ5BKOMoeOFoD8r95K6cseumFAJNndQAtwixva63cg@mail.gmail.com>
 <1428156272.8035.1.camel@gnutls.org>
 <CALPpbcgYAJmzzCcAJ369dGH8V3aCm_sx6PGcgKhWFiw1_t6zUA@mail.gmail.com>
Message-ID: <1428167772.7176.1.camel@gnutls.org>

On Sun, 2015-04-05 at 01:31 +1100, Brian Chu wrote:
> On Sun, Apr 5, 2015 at 1:04 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > On Sat, 2015-04-04 at 21:39 +1100, Brian Chu wrote:
> >> Hi Nikos,
> >>
> >> In commit 9d51069 you added handling for the additional 4-byte packet
> >> header that's present on OpenBSD. However, this is broken on FreeBSD
> >> because whilst TUNSIFHEAD is defined, it is not set by default. The
> >> attached patch fixes this by setting this ioctl after creating the tun
> >> device. I've also attached 2 trivial patches for fixing an extraneous
> >> return value and indentation.
> >
> > Thanks. Wouldn't however be simpler to define TUN_AF_PREFIX only in
> > OpenBSD then?
> My understanding is that IPv6 won't work if TUNSIFHEAD is not set
> (FreeBSD will assume the address family is AF_INET for all packets
> written).

Didn't know that. I'll apply your original patch then.

Thanks,
Nikos




From samm at infoxchange.org.au  Tue Apr  7 03:36:15 2015
From: samm at infoxchange.org.au (Sam McLeod)
Date: Tue, 7 Apr 2015 10:36:15 +0000
Subject: DNS not resolving on OpenConnect w/ Juniper Pulse Secure Gateway
Message-ID: <6EE1E7EE-1756-49D7-8B4B-0A3E33398E13@infoxchange.org.au>

We're trying to get OpenConnect working to replace the Junos Pulse client on OSX and Linux clients connecting to our Juniper MAG 2600 VPN gateway.
OpenConnect correctly authenticates and establishes the connection however DNS does not work over the link.

- I've checked /etc/resolv.conf on my OSX machine and our internal DNS server has been correctly added.

- A tcpdump shows the DNS request traffic on the utun1 interface however the MAG 2600 returns an NXDomain:

20:20:57.596050 IP <internal IP of MAG>.55812 ><internal IP of DNS Server>.domain: 31256+ A? <internal hostname>. (28)
20:20:57.623131 IP <internal IP of DNS Server>.domain > <internal IP of MAG>.55812: 31256 NXDomain 0/0/0 (28)


- Here's where it gets really strange:


After waiting several minutes I am suddenly able to make DNS requests correctly, however connecting or pinging a host by hostname does not work:


% host <internal server FQDN>
<internal server FQDN> has address <internal server IP>

% ssh <internal server FQDN>
ssh: Could not resolve hostname <internal server FQDN>: nodename nor servname provided, or not known

% ping <internal server FQDN>
ping: cannot resolve <internal server FQDN>: Unknown host

% ping <internal server IP>
PING <internal server IP> (<internal server IP>): 56 data bytes
64 bytes from <internal server IP>: icmp_seq=0 ttl=61 time=28.003 ms
64 bytes from <internal server IP>: icmp_seq=1 ttl=61 time=30.082 ms


- In addition to this strange behaviour it appears that the DNS search domains are not being applied to the connection as well.


Thanks,
Sam McLeod.

From dwmw2 at infradead.org  Tue Apr  7 08:13:07 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 07 Apr 2015 16:13:07 +0100
Subject: DNS not resolving on OpenConnect w/ Juniper Pulse Secure Gateway
In-Reply-To: <6EE1E7EE-1756-49D7-8B4B-0A3E33398E13@infoxchange.org.au>
References: <6EE1E7EE-1756-49D7-8B4B-0A3E33398E13@infoxchange.org.au>
Message-ID: <1428419587.23152.7.camel@infradead.org>

On Tue, 2015-04-07 at 10:36 +0000, Sam McLeod wrote:
> We're trying to get OpenConnect working to replace the Junos Pulse 
> client on OSX and Linux clients connecting to our Juniper MAG 2600 
> VPN gateway.
> OpenConnect correctly authenticates and establishes the connection 
> however DNS does not work over the link.
> 
> - I've checked /etc/resolv.conf on my OSX machine and our internal 
> DNS server has been correctly added.

On OSX it's not sufficient to fix resolv.conf; it has multiple
redundant ways of handing DNS configuration (yay Apple). There was a
fix recently in vpnc-script which ought to have made this work better:
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/e8b30a2be9

> - A tcpdump shows the DNS request traffic on the utun1 interface 
> however the MAG 2600 returns an NXDomain:
> 
> 20:20:57.596050 IP nal IP of MAG>.55812 ><internal IP of DNS Server>.domain: 31256+ A? <internal hostname>. (28)
> 20:20:57.623131 IP .domain > .55812: 31256 NXDomain 0/0/0 (28)

Hm the internal IP address of the MAG? Do you mean the VPN IP address
of the *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/20150407/65c767cf/attachment.bin>

From dwmw2 at infradead.org  Wed Apr  8 05:28:30 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 08 Apr 2015 13:28:30 +0100
Subject: openconnect is using SSL instead of TLSv1.2 Protocol
In-Reply-To: <1428135778.7266.11.camel@uwe-ThinkPad-T540p>
References: <1428135778.7266.11.camel@uwe-ThinkPad-T540p>
Message-ID: <1428496110.9010.18.camel@infradead.org>

On Sat, 2015-04-04 at 10:22 +0200, Uwe Schreiber wrote:
> Hello,
> 
> i'am using Ubuntu 14.04.2 with all the latest patches.
> 
> I installed openconnect v7.06-7-gf2e8cd0 from GIT.
> I am trying to connect to a Juniper VPN, but i receive the message
> 
> SSL connection failure: A TLS packet with unexpected length was
> received.
> 
> I did a trace using Wireshark and have seen my client is sending a
> "Client Hello" using SSL as protocol.

Hm, that shouldn't happen. Were you building against GnuTLS or
OpenSSL? What version?

I did a quick test here. With GnuTLS (3.3.14) I'm definitely seeing it
use TLSv1.2. With OpenSSL (1.0.1k) it uses TLSv1.0.

If I change the TLSv1_client_method() to SSLv23_client_method() at
around line 1401 of openssl,c, *then* it sends a ClientHello for
TLSv1.2. But I think we'd want to explicitly prevent it from actually
allowing anything older than TLSv1.0.

I remember there being odd firewall issues with later protocols, but I
suspect that's all caused by the stupid F5 firewalls with packet size
issues which should be handled now.

-- 
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/20150408/d8eba68b/attachment.bin>

From uwe.h.schreiber at t-online.de  Thu Apr  9 01:01:16 2015
From: uwe.h.schreiber at t-online.de (Uwe Schreiber)
Date: Thu, 09 Apr 2015 10:01:16 +0200
Subject: openconnect is using SSL instead of TLSv1.2 Protocol
In-Reply-To: <1428496110.9010.18.camel@infradead.org>
References: <1428135778.7266.11.camel@uwe-ThinkPad-T540p>
 <1428496110.9010.18.camel@infradead.org>
Message-ID: <1428566476.7086.4.camel@t-online.de>

I was building with and without GnuTLS without any difference.
OpenSSL was on version 1.0.1f and GnuTLS was on version 3.0.21.

After updating my system to Ubuntu 14.10 openconnect is working as
expected.
Now GnuTLS is on version 3.2.16 and OpenSSL is stoll on version 1.0.1f


On Wed, 2015-04-08 at 13:28 +0100, David Woodhouse wrote:
> On Sat, 2015-04-04 at 10:22 +0200, Uwe Schreiber wrote:
> > Hello
> ,
> > 
> > i'am using Ubuntu 14.04.2 with all the latest patches.
> > 
> > I installed openconnect v7.06-7-gf2e8cd0 from GIT.
> > I am trying to connect to a Juniper VPN, but i receive the message
> > 
> > SSL connection failure: A TLS packet with unexpected length was
> > received.
> > 
> > I did a trace using Wireshark and have seen my client is sending a
> > "Client Hello" using SSL as protocol.
> 
> Hm, that shouldn't happen. Were you building against GnuTLS or
> OpenSSL? What version?
> 
> I did a quick test here. With GnuTLS (3.3.14) I'm definitely seeing it
> use TLSv1.2. With OpenSSL (1.0.1k) it uses TLSv1.0.
> 
> If I change the TLSv1_client_method() to SSLv23_client_method() at
> around line 1401 of openssl,c, *then* it sends a ClientHello for
> TLSv1.2. But I think we'd want to explicitly prevent it from actually
> allowing anything older than TLSv1.0.
> 
> I remember there being odd firewall issues with later protocols, but I
> suspect that's all caused by the stupid F5 firewalls with packet size
> issues which should be handled now.
> 




From sebastien.canart at onprvp.fgov.be  Thu Apr  9 01:05:02 2015
From: sebastien.canart at onprvp.fgov.be (Sebastien Canart)
Date: Thu, 9 Apr 2015 10:05:02 +0200
Subject: Issue with recent Belgium Identity Card, openconnect 7.06 and
Message-ID: <552632AE.3000503@onprvp.fgov.be>

Hello,

I'm trying to use openconnect to connect to our corporate vpn.

The command that I'm currently using (I need to go through our internal
proxy):
# openconnect --timestamp --proxy=localhost:3128 -v --dump-http-traffic
-c 'pkcs11:model=PKCS%2315;mycert[...];object-type=cert' vpnserver

I've the following output:
[2015-04-09 09:24:44] POST vpnserver
[2015-04-09 09:24:44] Attempting to connect to server [::1]:3128
[2015-04-09 09:24:44] Attempting to connect to server 127.0.0.1:3128
[2015-04-09 09:24:44] Requesting HTTP proxy connection to vpnserver:443
[2015-04-09 09:24:44] > CONNECT vpnserver:443 HTTP/1.1
[2015-04-09 09:24:44] > Host: vpnserver
[2015-04-09 09:24:44] > User-Agent: Open AnyConnect VPN Agent v7.06
[2015-04-09 09:24:44] > Proxy-Connection: keep-alive
[2015-04-09 09:24:44] > Connection: keep-alive
[2015-04-09 09:24:44] > Accept-Encoding: identity
[2015-04-09 09:24:44] >
[2015-04-09 09:24:44] Got HTTP response: HTTP/1.1 200 Connection established
[2015-04-09 09:24:44] Connection: close
[2015-04-09 09:24:44] Using PKCS#11 certificate
pkcs11:model=PKCS%2315;mycert[...];type=cert
PIN required for BELPIC (Basic PIN)
Enter PIN:
[2015-04-09 09:24:52] Using PKCS#11 key
pkcs11:model=PKCS%2315;mycert[...];type=private
[2015-04-09 09:24:52] Error signing test data with private key: PKCS #11
unsupported feature
[2015-04-09 09:24:52] Loading certificate failed. Aborting.
[2015-04-09 09:24:52] Failed to open HTTPS connection to vpnserver

When I'm using an older identity card, I've the following output:
# openconnect --timestamp --proxy=localhost:3128 -v --dump-http-traffic
-c 'pkcs11:model=PKCS%2315;othercert;type=cert' vpnserver
[2015-04-09 09:30:49] POST vpnserver
[2015-04-09 09:30:49] Attempting to connect to server [::1]:3128
[2015-04-09 09:30:49] Attempting to connect to server 127.0.0.1:3128
[2015-04-09 09:30:49] Requesting HTTP proxy connection to
damona.onprvp.fgov.be:443
[2015-04-09 09:30:49] > CONNECT vpnserver:443 HTTP/1.1
[2015-04-09 09:30:49] > Host: vpnserver
[2015-04-09 09:30:49] > User-Agent: Open AnyConnect VPN Agent v7.06
[2015-04-09 09:30:49] > Proxy-Connection: keep-alive
[2015-04-09 09:30:49] > Connection: keep-alive
[2015-04-09 09:30:49] > Accept-Encoding: identity
[2015-04-09 09:30:49] >
[2015-04-09 09:30:49] Got HTTP response: HTTP/1.1 200 Connection established
[2015-04-09 09:30:49] Connection: close
[2015-04-09 09:30:49] Using PKCS#11 certificate
pkcs11:model=PKCS%2315;othercert;type=cert
PIN required for BELPIC (Basic PIN)
Enter PIN:
[2015-04-09 09:30:58] Using PKCS#11 key
pkcs11:model=PKCS%2315;othercert;type=private
[2015-04-09 09:30:59] Using client certificate 'Firstname Lastname
(Authentication)'
[2015-04-09 09:31:02] Got next CA 'Citizen CA' from PKCS11
[2015-04-09 09:31:02] Got next CA 'Belgium Root CA2' from PKCS11
[2015-04-09 09:31:02] Adding supporting CA 'Citizen CA'
[2015-04-09 09:31:03] SSL negotiation with vnpserver

To retrieve the PKCS#11 url, I'm using the following commands:
# p11tool --list-certs
warning: no token URL was provided for this operation; the available
tokens are:
Token 0:
pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
Token 1: pkcs11:model=PKCS%2315;mycert

With the token 1:

# p11tool --list-all --login 'pkcs11:model=PKCS%2315;mycert'
Object 0:
        URL:
pkcs11:model=PKCS%2315;mycert;object=Authentication;type=private
        Type: Private key
        Label: Authentication
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 02

Object 1:
        URL: pkcs11:model=PKCS%2315;mycert;object=Authentication;type=cert
        Type: X.509 Certificate
        Label: Authentication
        Flags: CKA_PRIVATE;
        ID: 02

Object 2:
        URL: pkcs11:model=PKCS%2315;mycert;object=Authentication;type=public
        Type: Public key
        Label: Authentication
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 02

Object 3:
        URL: pkcs11:model=PKCS%2315;mycert;object=Signature;type=private
        Type: Private key
        Label: Signature
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 03

Object 4:
        URL: pkcs11:model=PKCS%2315;mycert;object=Signature;type=cert
        Type: X.509 Certificate
        Label: Signature
        Flags: CKA_PRIVATE;
        ID: 03

Object 5:
        URL: pkcs11:model=PKCS%2315;mycert;object=Signature;type=public
        Type: Public key
        Label: Signature
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 03

Object 6:
        URL: pkcs11:model=PKCS%2315;mycert;object=CA;type=cert
        Type: X.509 Certificate
        Label: CA
        Flags: CKA_PRIVATE; CKA_TRUSTED;
        ID: 04

Object 7:
        URL: pkcs11:model=PKCS%2315;mycert;object=CA;type=public
        Type: Public key
        Label: CA
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 04

Object 8:
        URL: pkcs11:model=PKCS%2315;mycert;object=Root;type=cert
        Type: X.509 Certificate
        Label: Root
        Flags: CKA_PRIVATE; CKA_TRUSTED;
        ID: 06

Object 9:
        URL: pkcs11:model=PKCS%2315;mycert;object=Root;type=public
        Type: Public key
        Label: Root
        Flags: CKA_PRIVATE; CKA_SENSITIVE;
        ID: 06

And then I'm taking the Object 1, which is a X.509
Certificate/Authentication (it's the same object for both old and new
identity card).

There is currently two batch of identity cards in Belgium:
- the ones with a validity of 5 years (which seems to be working),
- the recent ones with a validity of 10 years (which doesn't seems to be
working).


I'm currently using:
- # uname -a
Linux lp-20140069-linux 3.18.7-gentoo #14 SMP Thu Apr 2 09:46:15 CEST
2015 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz GenuineIntel GNU/Linux
- openconnect --version
OpenConnect version v7.06
Using GnuTLS. Features present: PKCS#11, HOTP software token, TOTP
software token, Yubikey OATH, DTLS
- gnutls 3.3.12
- # pcscd --version
pcsc-lite version 1.8.13.

>From the error I'm getting (Error signing test data with private key:
PKCS #11
unsupported feature), I'm guessing that the error is coming directly
from gnutls.
I've tried upgrading to gnutls-3.3.14 with no luck.
gnutls-3.4.0 has been released yesterday (2015-04-08), but I've haven't
any package on my package manager to install it.

Does anybody have any ideas how I can investigate some more on it?

Thanks,

-- 
Sebastien Canart <sebastien.canart at onprvp.fgov.be>


From n.mavrogiannopoulos at gmail.com  Thu Apr  9 01:20:16 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 9 Apr 2015 10:20:16 +0200
Subject: Issue with recent Belgium Identity Card, openconnect 7.06 and
In-Reply-To: <552632AE.3000503@onprvp.fgov.be>
References: <552632AE.3000503@onprvp.fgov.be>
Message-ID: <CAJU7za+xbqr9fhaXesspo-ZxZFkSwr6-XicReSv8G9PXrXFpxg@mail.gmail.com>

On Thu, Apr 9, 2015 at 10:05 AM, Sebastien Canart
<sebastien.canart at onprvp.fgov.be> wrote:
> Hello,
> The command that I'm currently using (I need to go through our internal
> proxy):
> # openconnect --timestamp --proxy=localhost:3128 -v --dump-http-traffic
> -c 'pkcs11:model=PKCS%2315;mycert[...];object-type=cert' vpnserver
[...]
> From the error I'm getting (Error signing test data with private key:
> PKCS #11
> unsupported feature), I'm guessing that the error is coming directly
> from gnutls.

The error is from the PKCS #11 library (I guess it is opensc) and
probably the card itself.
Do you see any difference in "p11tool --list-mechanisms" with the new
and old card? It may
be that the new key is not allowed to sign using RSA-PKCS.

You can verify whether signing works with pkcs11-tool (from opensc)
using something like:
pkcs11-tool --module /path/to/opensc-pkcs11.so -s -M
pkcs11-tool --module /path/to/opensc-pkcs11.so -s -m RSA-PKCS --id 02

regards,
Nikos


From sebastien.canart at onprvp.fgov.be  Thu Apr  9 01:46:18 2015
From: sebastien.canart at onprvp.fgov.be (Sebastien Canart)
Date: Thu, 9 Apr 2015 10:46:18 +0200
Subject: Issue with recent Belgium Identity Card, openconnect 7.06 and
In-Reply-To: <CAJU7za+xbqr9fhaXesspo-ZxZFkSwr6-XicReSv8G9PXrXFpxg@mail.gmail.com>
References: <552632AE.3000503@onprvp.fgov.be>
 <CAJU7za+xbqr9fhaXesspo-ZxZFkSwr6-XicReSv8G9PXrXFpxg@mail.gmail.com>
Message-ID: <55263C5A.7080705@onprvp.fgov.be>

Hello,

Thanks for your fast feedback.

The command $ p11tool --list-mechanisms produce more or less the same
output. There is just the serial that is different.

Here are the result when signing with pkcs11-tool:
Old:
# pkcs11-tool --module /usr/lib/opensc-pkcs11.so -s -M --id 02
Using slot 1 with a present token (0x1)
Supported mechanisms:
  SHA-1, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  RSA-PKCS, keySize={1024,1024}, hw, decrypt, sign, verify
Logging in to "BELPIC (Basic PIN)".
Please enter User PIN:
Using signature algorithm RSA-PKCS
test message
<some unreadable characters>

New:
# pkcs11-tool --module /usr/lib/opensc-pkcs11.so -s -M --id 02
Using slot 1 with a present token (0x1)
Supported mechanisms:
  SHA-1, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  RSA-PKCS, keySize={1024,1024}, hw, decrypt, sign, verify
Logging in to "BELPIC (Basic PIN)".
Please enter User PIN:
Using signature algorithm RSA-PKCS
test message

Nothing happens.


When I tried to use an input file, I got the following results:
Old:
# pkcs11-tool --module /usr/lib/opensc-pkcs11.so -s -m RSA-PKCS --id 02
 --input-file /tmp/test-file
Using slot 1 with a present token (0x1)
Logging in to "BELPIC (Basic PIN)".
Please enter User PIN:
Using signature algorithm RSA-PKCS
<some unreadable characters>

New:
# pkcs11-tool --module /usr/lib/opensc-pkcs11.so -s -m RSA-PKCS --id 02
 --input-file /tmp/test-file
Using slot 1 with a present token (0x1)
Logging in to "BELPIC (Basic PIN)".
Please enter User PIN:
Using signature algorithm RSA-PKCS
error: PKCS11 function C_SignFinal failed: rv =
CKR_FUNCTION_NOT_SUPPORTED (0x54)

Aborting.

So indeed, it seems that my card couldn't sign.
Is there any solution for it?

Regards,
Sebastien

On 04/09/2015 10:20 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, Apr 9, 2015 at 10:05 AM, Sebastien Canart
> <sebastien.canart at onprvp.fgov.be> wrote:
>> Hello,
>> The command that I'm currently using (I need to go through our internal
>> proxy):
>> # openconnect --timestamp --proxy=localhost:3128 -v --dump-http-traffic
>> -c 'pkcs11:model=PKCS%2315;mycert[...];object-type=cert' vpnserver
> [...]
>> From the error I'm getting (Error signing test data with private key:
>> PKCS #11
>> unsupported feature), I'm guessing that the error is coming directly
>> from gnutls.
> 
> The error is from the PKCS #11 library (I guess it is opensc) and
> probably the card itself.
> Do you see any difference in "p11tool --list-mechanisms" with the new
> and old card? It may
> be that the new key is not allowed to sign using RSA-PKCS.
> 
> You can verify whether signing works with pkcs11-tool (from opensc)
> using something like:
> pkcs11-tool --module /path/to/opensc-pkcs11.so -s -M
> pkcs11-tool --module /path/to/opensc-pkcs11.so -s -m RSA-PKCS --id 02
> 
> regards,
> Nikos
> 

-- 
Sebastien Canart <sebastien.canart at onprvp.fgov.be>


From dwmw2 at infradead.org  Thu Apr  9 02:01:49 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 09 Apr 2015 10:01:49 +0100
Subject: Issue with recent Belgium Identity Card, openconnect 7.06 and
In-Reply-To: <55263C5A.7080705@onprvp.fgov.be>
References: <552632AE.3000503@onprvp.fgov.be>
 <CAJU7za+xbqr9fhaXesspo-ZxZFkSwr6-XicReSv8G9PXrXFpxg@mail.gmail.com>
 <55263C5A.7080705@onprvp.fgov.be>
Message-ID: <1428570109.24587.4.camel@infradead.org>

On Thu, 2015-04-09 at 10:46 +0200, Sebastien Canart wrote:
> So indeed, it seems that my card couldn't sign.
> Is there any solution for it?

Presumably fixed by https://github.com/OpenSC/OpenSC/commit/5149dd3e ? 

-- 
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/20150409/8c531709/attachment-0001.bin>

From sebastien.canart at onprvp.fgov.be  Thu Apr  9 02:14:27 2015
From: sebastien.canart at onprvp.fgov.be (Sebastien Canart)
Date: Thu, 9 Apr 2015 11:14:27 +0200
Subject: Issue with recent Belgium Identity Card, openconnect 7.06 and
In-Reply-To: <1428570109.24587.4.camel@infradead.org>
References: <552632AE.3000503@onprvp.fgov.be>	
 <CAJU7za+xbqr9fhaXesspo-ZxZFkSwr6-XicReSv8G9PXrXFpxg@mail.gmail.com>	
 <55263C5A.7080705@onprvp.fgov.be> <1428570109.24587.4.camel@infradead.org>
Message-ID: <552642F3.9070800@onprvp.fgov.be>

Thank you very much!
I've applied the patch locally and I confirm that it's working.

Thanks for your quick answers!

Sebastien

On 04/09/2015 11:01 AM, David Woodhouse wrote:
> On Thu, 2015-04-09 at 10:46 +0200, Sebastien Canart wrote:
>> So indeed, it seems that my card couldn't sign.
>> Is there any solution for it?
> 
> Presumably fixed by https://github.com/OpenSC/OpenSC/commit/5149dd3e ? 
> 

-- 
Sebastien Canart <sebastien.canart at onprvp.fgov.be>


From tmetro at tommetro.com  Thu Apr  9 14:33:18 2015
From: tmetro at tommetro.com (Tom Metro)
Date: Thu, 09 Apr 2015 17:33:18 -0400
Subject: Juniper SSL VPN login fails
Message-ID: <5526F01E.7020004@tommetro.com>

First, my complements to the developers for taking the time to reverse
engineer this proprietary protocol and giving us an open alternative.

I'm running OpenConnect built from the 7.05 tarball on 32-bit Lubuntu 14.10.

Several weeks ago I tried using OpenConnect to connect to a business
partner's Juniper VPN server using some test credentials, and all worked
fine.

Yesterday they supplied the real credentials, along with a certificate
(test setup didn't use a cert), and a different VPN server URL, and now
I get "Failed to obtain WebVPN cookie."

Below is a redacted transcript of the session. I've skimmed through the
list archives and didn't see any relevant postings. (I also did a web
search on the above error messages and a few of the messages that appear
upstream of it in the log.)

I see on:
http://www.infradead.org/openconnect/juniper.html

a section regarding "Host Checker." What would be the displayed error
message if that was required?

(The link to the repository for the tncc-wrapper.py script seems to be
obsolete. I found a copy here:
http://git.infradead.org/users/dwmw2/openconnect.git/blob_plain/HEAD:/tncc-wrapper.py
It was also unclear whether this approach needs just that script, or
also the compiled libraries from the ncsvc-socks-wrapper project.

Running OpenConnect with the addition of '--useragent  'Mozilla/5.0
(Linux) Firefox' --csd-wrapper=../tncc-wrapper/tncc-wrapper.py' has no
apparent impact on the behavior or logged transcript.)


(It may also be relevant to note that I'm also seeing a failure when I
attempt a traditional login to this VPN via a web browser. When I tried
connecting to the partner's test server via Firefox, it successfully
authenticated and launched the Java VPN client. Now it is successfully
authenticating (including accepting the installed certificate), but not
launching the Java app.

While debugging this I also tried using the partner's VPN server that
they use for employees, rather than business partners, and in that case
it launched tncc.jar, but never went beyond that. This might suggest
they don't have tncc.jar as a requirement for the VPN connections with
partners.)


Transcript:

$ sudo ./openconnect -v -v --juniper -c /path/cert.pfx --disable-ipv6
https://example.com/dana-na/auth/url_3/welcome.cgi
WARNING: Juniper Network Connect support is experimental.
It will probably be superseded by Junos Pulse support.
GET https://example.com/dana-na/auth/url_3/welcome.cgi
Attempting to connect to server 167.79.177.50:443
Using certificate file /path/cert.pfx
Enter PKCS#12 pass phrase:
Using client certificate 'cert'
SSL negotiation with example.com
Connected to HTTPS on example.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Thu, 09 Apr 2015 21:01:21 GMT
x-frame-options: SAMEORIGIN
Connection: close
Pragma: no-cache
Cache-Control: no-store
Expires: -1
HTTP body http 1.0 (-1)
SSL socket closed uncleanly
frmLogin
username:myid
password:
POST https://example.com/dana-na/auth/url_3/login.cgi
SSL negotiation with example.com
Connected to HTTPS on example.com
Failed to read from SSL socket: Rehandshake was requested by the peer.
Error fetching HTTPS response
Failed to obtain WebVPN cookie


Suggestions?

Thanks,
 -Tom


From brett.higgins at gmail.com  Fri Apr 10 07:40:15 2015
From: brett.higgins at gmail.com (Brett Higgins)
Date: Fri, 10 Apr 2015 10:40:15 -0400
Subject: HostChecker NullPointerException with juniper server
In-Reply-To: <CAOVC=BVBdpTh4CViojmaaR83OhNOmH-QTNE=VfQimGjwYpa=Mw@mail.gmail.com>
References: <CAOVC=BVBdpTh4CViojmaaR83OhNOmH-QTNE=VfQimGjwYpa=Mw@mail.gmail.com>
Message-ID: <CAOVC=BVoEYG2DMLHj7UDnC46_vk6j80OdHUF8ftCfg8Y4mnBHA@mail.gmail.com>

Follow-up from IRC discussion: this patch fixed the issue:

http://david.woodhou.se/large-conf-pkt-v3.patch

On Fri, Apr 3, 2015 at 9:53 AM, Brett Higgins <brett.higgins at gmail.com> wrote:
> OpenConnect (or host checker) fails with NullPointerException
> connecting to a juniper server: http://hastebin.com/xosisuliwa
>
> I can provide more information but I?m not at all sure what would be helpful.
>
> -Brett


From tmetro+openconnect at gmail.com  Fri Apr 10 15:19:47 2015
From: tmetro+openconnect at gmail.com (Tom Metro)
Date: Fri, 10 Apr 2015 18:19:47 -0400
Subject: Juniper SSL VPN login fails
In-Reply-To: <5526F01E.7020004@tommetro.com>
References: <5526F01E.7020004@tommetro.com>
Message-ID: <55284C83.7030403@gmail.com>

Tom Metro wrote:
> (It may also be relevant to note that I'm also seeing a failure when I
> attempt a traditional login to this VPN via a web browser. ...it is successfully
> authenticating...but not launching the Java app.

I've since resolved this issue. (Apparently the server had my account
flagged as being a Mac user instead of a Linux user and was attempting
to launch the wrong VPN client.)

But OpenConnect still fails in the same manner.

The most significant difference now between the previously successful
connection I made to the partner's test server using OpenConnect and the
current setup is that I am now using a client certificate. Is there a
problem with OpenConnect's handling of the client certificate?

 -Tom



From dwmw2 at infradead.org  Sun Apr 12 04:27:06 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 12 Apr 2015 12:27:06 +0100
Subject: Juniper SSL VPN login fails
In-Reply-To: <5526F01E.7020004@tommetro.com>
References: <5526F01E.7020004@tommetro.com>
Message-ID: <1428838026.4808.31.camel@infradead.org>

On Thu, 2015-04-09 at 17:33 -0400, Tom Metro wrote:
> POST https://example.com/dana-na/auth/url_3/login.cgi
> SSL negotiation with example.com
> Connected to HTTPS on example.com
> Failed to read from SSL socket: Rehandshake was requested by the peer.

Right. The Juniper server asks for a rehandshake when it decides it
wants to see a client certificate ? even if you already offered one in
the initial connection. Which we do but their client presumably
doesn't.

We need to make our code handle that. You could probably do that as a
quick hack without much difficulty. Before actually committing it I'd
want to familiarise myself with the insecure handshake security issues
from last year and make sure that whatever we do isn't opening a
vulnerability, and make sure it works sanely with both GnuTLS and
OpenSSL builds of OpenConnect.

I do still plan to ditch or at least deprecate the Network Connect
support in favour of the newer Junos Pulse protocol which is generally
saner and isn't limited to Legacy IP. This is one of the areas where
Junos Pulse is more fun though; it makes the HTTPS connection and then
"upgrades" from HTTP to IF-T inside that TLS session. It then does EAP
within that ? and if it needs certificate auth it does EAP-TLS
*within* that, instead of using the TLS session it's using for the
outermost transport.

That's going to be fun to implement (and it has other fun levels of
EAP within EAP too, even before you get to the way they do Host
Checker within it). Which is partly why I haven't got round to it yet;
I've been fairly busy with real work and since my employer doesn't
even use Juniper it isn't as quite as easy to justify it as "making
life easier for my colleagues so they don't have to use that Cisco
crap" :)

I do plan to get to it soon though. Unless someone beats me to it...

The simpler case of certificate auth for NC shouldn't be hard to fix
if you want to take a look.

--?dwmw2
? http://www.trustedcomputinggroup.org/resources/tnc_ift_binding_to_tls
-------------- 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/20150412/9d0a0892/attachment.bin>

From tmetro+openconnect at gmail.com  Sun Apr 12 16:02:41 2015
From: tmetro+openconnect at gmail.com (Tom Metro)
Date: Sun, 12 Apr 2015 19:02:41 -0400
Subject: Juniper SSL VPN login fails
In-Reply-To: <1428838026.4808.31.camel@infradead.org>
References: <5526F01E.7020004@tommetro.com>
 <1428838026.4808.31.camel@infradead.org>
Message-ID: <552AF991.4030005@gmail.com>

David Woodhouse wrote:
>Tom Metro wrote:
>> Failed to read from SSL socket: Rehandshake was requested by the peer.
> 
> Right. The Juniper server asks for a rehandshake when it decides it
> wants to see a client certificate - even if you already offered one in
> the initial connection. Which we do but their client presumably
> doesn't.
> 
> We need to make our code handle that.

So this is either a known limitation you've encountered already, or at
least logically follows based on what you know about the behavior of the
OpenConnect code? OK, then at least we don't need to go hunting for the
underlying cause.

I haven't looked up the SSL terminology to know the distinction between
a renegotiation and a rehandshake (if there is one), but isn't it
logical that the server would want to see the client's credentials if
the parameters of the link are being reexamined?


> You could probably do that as a
> quick hack without much difficulty. 

./openconnect --version

reports:
OpenConnect version v7.05
Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP
software token, TOTP software token, DTLS

So I gather I'd start by looking in the GnuTLS related files. Although...

I can't find "Rehandshake was requested by the peer" in the code. Is
that an error message generated by GnuTLS? I see similar error messages
in other source files:

cstp.c:	vpn_progress(vpninfo, PRG_ERR, _("Rehandshake failed; attempting
new-tunnel\n"));
dtls.c:	vpn_progress(vpninfo, PRG_ERR, _("DTLS Rehandshake failed;
reconnecting.\n"));
oncp.c:	vpn_progress(vpninfo, PRG_ERR, _("Rehandshake failed; attempting
new-tunnel\n"));

auth-juniper.c suggests that it might be using code in oncp.c for the
transport, and oncp.c seems to be the layer at which rehandshake
problems are addressed (I was expecting to find that in the ssl.c or
lower layer), and oncp.c seems to sit above gnutls.c (is ssl.c another
layer in the middle?). If that's correct, then the modification needs to
go into oncp.c, and should be applicable to either GnuTLS or OpenSSL.

Am I anywhere close to being on the right track?


> ...make sure it works sanely with both GnuTLS and
> OpenSSL builds of OpenConnect.

Do you have reason to believe the fix will be library specific?


> Before actually committing it I'd
> want to familiarise myself with the insecure handshake security issues
> from last year and make sure that whatever we do isn't opening a
> vulnerability...

Sure. There are versions of that problem dating back to 2009:
http://itknowledgeexchange.techtarget.com/Irregular-Expressions/ssl-tls-renegotiation/

 -Tom



From cynix at cynix.org  Mon Apr 13 07:25:44 2015
From: cynix at cynix.org (Brian Chu)
Date: Tue, 14 Apr 2015 00:25:44 +1000
Subject: [PATCH] Remove addresses from old tun device when stealing leases
Message-ID: <CALPpbcgMb1xxw3rYfTqM70N+HQ2HwFtewv57_KF15w0ryCbdog@mail.gmail.com>

Hi Nikos,

On FreeBSD (and probably OpenBSD), when a user resumes a session using
cookie (e.g. when quickly switching between Wi-Fi and 3G on a mobile
device), we must first remove addresses from the old tun device before
assigning them to the new tun device, otherwise the assignment may
fail with something like "main: tun.c:197: tun1: Error setting IPv6:
Address already in use". I have attached a patch to fix this issue.
This problem was reported to me by hshh <hunreal at gmail.com>.

I'm not sure if the same behaviour is required on Linux -- probably
not, since nobody has reported this problem so far.

Cheers,
Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Remove-addresses-from-old-tun-device-when-stealing-l.patch
Type: application/octet-stream
Size: 2249 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150414/d14126ed/attachment.obj>

From dwmw2 at infradead.org  Mon Apr 13 09:29:42 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 13 Apr 2015 17:29:42 +0100
Subject: Juniper SSL VPN login fails
In-Reply-To: <552AF991.4030005@gmail.com>
References: <5526F01E.7020004@tommetro.com>
 <1428838026.4808.31.camel@infradead.org> <552AF991.4030005@gmail.com>
Message-ID: <1428942582.4808.102.camel@infradead.org>

On Sun, 2015-04-12 at 19:02 -0400, Tom Metro wrote:
> David Woodhouse wrote:
> > Tom Metro wrote:
> > > Failed to read from SSL socket: Rehandshake was requested by the 
> > > peer.
> > 
> > Right. The Juniper server asks for a rehandshake when it decides it
> > wants to see a client certificate - even if you already offered 
> > one in
> > the initial connection. Which we do but their client presumably
> > doesn't.
> > 
> > We need to make our code handle that.
> 
> So this is either a known limitation you've encountered already,

Yes, I've been given admin access to a spare server and had briefly
configured it for certificate auth ? and had seen the behaviour you
report.

> I haven't looked up the SSL terminology to know the distinction
> between a renegotiation and a rehandshake (if there is one), but 
> isn't it logical that the server would want to see the client's 
> credentials if the parameters of the link are being reexamined?

If the client presented its credentials when it first made the
connection, there doesn't seem to be any reason to trigger a
renegotiation just to see the same information *again*.

> 
> > You could probably do that as a
> > quick hack without much difficulty. 
> 
> ./openconnect --version
> 
> reports:
> OpenConnect version v7.05
> Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP
> software token, TOTP software token, DTLS
> 
> So I gather I'd start by looking in the GnuTLS related files. 
> Although...
> 
> I can't find "Rehandshake was requested by the peer" in the code. Is
> that an error message generated by GnuTLS? I see similar error 
> messages in other source files:

GnuTLS returns the GNUTLS_E_REHANDSHAKE "error" code when we attempt
to read from the socket. We are expected to react accordingly, if we
want to actually do the renegotiation. Try the patch below.

...make sure it works sanely with both GnuTLS and
> > OpenSSL builds of OpenConnect.
> 
> Do you have reason to believe the fix will be library specific?

Yes, but actually the OpenSSL build seems to renegotiate all by itself
without requiring the application to do anything. So probably all we
need is this:

diff --git a/gnutls.c b/gnutls.c
index 3f79a22..bf20b41 100644
--- a/gnutls.c
+++ b/gnutls.c
@@ -148,6 +148,10 @@ static int openconnect_gnutls_read(struct openconnect_info *vpninfo, char *buf,
                        vpn_progress(vpninfo, PRG_DEBUG, _("SSL socket closed uncleanly\n"));
                        return 0;
 #endif
+               } else if (done == GNUTLS_E_REHANDSHAKE) {
+                       int ret = cstp_handshake(vpninfo, 0);
+                       if (ret)
+                               return ret;
                } else {
                        vpn_progress(vpninfo, PRG_ERR, _("Failed to read from SSL socket: %s\n"),
                                     gnutls_strerror(done));
@@ -203,6 +207,10 @@ static int openconnect_gnutls_gets(struct openconnect_info *vpninfo, char *buf,
                                ret = -EINTR;
                                break;
                        }
+               } else if (ret == GNUTLS_E_REHANDSHAKE) {
+                       ret = cstp_handshake(vpninfo, 0);
+                       if (ret)
+                               return ret;
                } else {
                        vpn_progress(vpninfo, PRG_ERR, _("Failed to read from SSL socket: %s\n"),
                                     gnutls_strerror(ret));


-- 
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/20150413/923e8993/attachment.bin>

From tmetro+openconnect at gmail.com  Mon Apr 13 14:38:40 2015
From: tmetro+openconnect at gmail.com (Tom Metro)
Date: Mon, 13 Apr 2015 17:38:40 -0400
Subject: Juniper SSL VPN login fails
In-Reply-To: <1428942582.4808.102.camel@infradead.org>
References: <5526F01E.7020004@tommetro.com>	
 <1428838026.4808.31.camel@infradead.org> <552AF991.4030005@gmail.com>
 <1428942582.4808.102.camel@infradead.org>
Message-ID: <552C3760.8090705@gmail.com>

David Woodhouse wrote:
> GnuTLS returns the GNUTLS_E_REHANDSHAKE "error" code when we attempt
> to read from the socket. We are expected to react accordingly, if we
> want to actually do the renegotiation. 
>
> Try the patch below.

Fantastic. That worked. Thanks for taking the time to create the patch.


> ...actually the OpenSSL build seems to renegotiate all by itself
> without requiring the application to do anything.

My expectations are that an SSL library would provide hooks, in case you
want to do something custom, but by default handle this internally. I
guess the GnuTLS developers disagree.

 -Tom



From nmav at gnutls.org  Tue Apr 14 05:07:21 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 14 Apr 2015 15:07:21 +0300
Subject: Juniper SSL VPN login fails
In-Reply-To: <552C3760.8090705@gmail.com>
References: <5526F01E.7020004@tommetro.com>
 <1428838026.4808.31.camel@infradead.org> <552AF991.4030005@gmail.com>
 <1428942582.4808.102.camel@infradead.org> <552C3760.8090705@gmail.com>
Message-ID: <1429013241.2231.4.camel@gnutls.org>

On Mon, 2015-04-13 at 17:38 -0400, Tom Metro wrote:

> > ...actually the OpenSSL build seems to renegotiate all by itself
> > without requiring the application to do anything.
> My expectations are that an SSL library would provide hooks, in case you
> want to do something custom, but by default handle this internally. I
> guess the GnuTLS developers disagree.

Indeed. Re-authentication cannot happen transparently in an application,
i.e., suddenly the server or client change identity and no-one is
notified. The fact that gnutls insists on explicit re-authentication by
the application, protected applications from attacks like the triple
handshake attack and the other re-handshake-based attacks on TLS.

regards,
Nikos




From nmav at gnutls.org  Tue Apr 14 05:20:26 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 14 Apr 2015 15:20:26 +0300
Subject: [PATCH] Remove addresses from old tun device when stealing leases
In-Reply-To: <CALPpbcgMb1xxw3rYfTqM70N+HQ2HwFtewv57_KF15w0ryCbdog@mail.gmail.com>
References: <CALPpbcgMb1xxw3rYfTqM70N+HQ2HwFtewv57_KF15w0ryCbdog@mail.gmail.com>
Message-ID: <1429014026.2231.9.camel@gnutls.org>

On Tue, 2015-04-14 at 00:25 +1000, Brian Chu wrote:
> Hi Nikos,
> 
> On FreeBSD (and probably OpenBSD), when a user resumes a session using
> cookie (e.g. when quickly switching between Wi-Fi and 3G on a mobile
> device), we must first remove addresses from the old tun device before
> assigning them to the new tun device, otherwise the assignment may
> fail with something like "main: tun.c:197: tun1: Error setting IPv6:
> Address already in use". I have attached a patch to fix this issue.
> This problem was reported to me by hshh <hunreal at gmail.com>.

Thanks. I think that this deallocation should be done in tun.c and then
be called by ip-leases. Something like reset_tun() or so. If you can
update the patch would be nice, otherwise I'll try to check it, next
week.

> I'm not sure if the same behaviour is required on Linux -- probably
> not, since nobody has reported this problem so far.

Most probably we would need to add some code for ipv6 in linux as well. 

regards,
Nikos




From dwmw2 at infradead.org  Tue Apr 14 05:29:10 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 14 Apr 2015 13:29:10 +0100
Subject: Juniper SSL VPN login fails
In-Reply-To: <1429013241.2231.4.camel@gnutls.org>
References: <5526F01E.7020004@tommetro.com>
 <1428838026.4808.31.camel@infradead.org> <552AF991.4030005@gmail.com>
 <1428942582.4808.102.camel@infradead.org> <552C3760.8090705@gmail.com>
 <1429013241.2231.4.camel@gnutls.org>
Message-ID: <1429014550.4808.129.camel@infradead.org>

On Tue, 2015-04-14 at 15:07 +0300, Nikos Mavrogiannopoulos wrote:
> Indeed. Re-authentication cannot happen transparently in an application,
> i.e., suddenly the server or client change identity and no-one is
> notified. The fact that gnutls insists on explicit re-authentication by
> the application, protected applications from attacks like the triple
> handshake attack and the other re-handshake-based attacks on TLS.

... which is why I need to think hard about the fact that my patch
automatically just *does* the renegotiation whenever it's asked to.
And check it'll do the right thing if the server identity changes, etc.

Currently if we are suddenly offered a different cert we might just
accept it (if it's valid), or maybe even trigger a certificate
validation callback if it's not. We should probably make it accept
*only* the *same* certificate as before.

And might also want to limit the circumstances in which it tolerates
renegotiation at all ? only when talking to a Network Connect server,
and only at certain points in the connection.

Not this week though.


-- 
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/20150414/67b2e160/attachment.bin>

From nmav at gnutls.org  Tue Apr 14 05:48:08 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 14 Apr 2015 15:48:08 +0300
Subject: Juniper SSL VPN login fails
In-Reply-To: <1429014550.4808.129.camel@infradead.org>
References: <5526F01E.7020004@tommetro.com>
 <1428838026.4808.31.camel@infradead.org> <552AF991.4030005@gmail.com>
 <1428942582.4808.102.camel@infradead.org> <552C3760.8090705@gmail.com>
 <1429013241.2231.4.camel@gnutls.org>
 <1429014550.4808.129.camel@infradead.org>
Message-ID: <1429015688.2231.14.camel@gnutls.org>

On Tue, 2015-04-14 at 13:29 +0100, David Woodhouse wrote:
> On Tue, 2015-04-14 at 15:07 +0300, Nikos Mavrogiannopoulos wrote:
> > Indeed. Re-authentication cannot happen transparently in an application,
> > i.e., suddenly the server or client change identity and no-one is
> > notified. The fact that gnutls insists on explicit re-authentication by
> > the application, protected applications from attacks like the triple
> > handshake attack and the other re-handshake-based attacks on TLS.
> 
> ... which is why I need to think hard about the fact that my patch
> automatically just *does* the renegotiation whenever it's asked to.
> And check it'll do the right thing if the server identity changes, etc.

The safest approach is to check gnutls_safe_renegotiation_status() and
only allow renegotiation if it is in use. That way you can be assured
that you will be talking to the same server as the first negotiation
(i.e., the server didn't forward the connection somewhere else). If that
is not available (e.g., if the juniper servers are too old to support
safe renegotiation) you may have to resort into checking that the
certificate presented remained the same.

> And might also want to limit the circumstances in which it tolerates
> renegotiation at all ? only when talking to a Network Connect server,
> and only at certain points in the connection.

That's what I do in ocserv as well, mostly to prevent DoS attacks by
clients who ask for renegotiation too many times.

regards,
Nikos




From cynix at cynix.org  Wed Apr 15 02:42:26 2015
From: cynix at cynix.org (Brian Chu)
Date: Wed, 15 Apr 2015 19:42:26 +1000
Subject: [PATCH] Remove addresses from old tun device when stealing leases
In-Reply-To: <1429014026.2231.9.camel@gnutls.org>
References: <CALPpbcgMb1xxw3rYfTqM70N+HQ2HwFtewv57_KF15w0ryCbdog@mail.gmail.com>
 <1429014026.2231.9.camel@gnutls.org>
Message-ID: <CALPpbciatF-hT7w24r4oVaTx_Zb-c5dK75tjE61wkKmFhjPfSQ@mail.gmail.com>

Hi Nikos,

Thanks for the suggestion. Please see updated patch.

Cheers,
Brian

On Tue, Apr 14, 2015 at 10:20 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Tue, 2015-04-14 at 00:25 +1000, Brian Chu wrote:
>> Hi Nikos,
>>
>> On FreeBSD (and probably OpenBSD), when a user resumes a session using
>> cookie (e.g. when quickly switching between Wi-Fi and 3G on a mobile
>> device), we must first remove addresses from the old tun device before
>> assigning them to the new tun device, otherwise the assignment may
>> fail with something like "main: tun.c:197: tun1: Error setting IPv6:
>> Address already in use". I have attached a patch to fix this issue.
>> This problem was reported to me by hshh <hunreal at gmail.com>.
>
> Thanks. I think that this deallocation should be done in tun.c and then
> be called by ip-leases. Something like reset_tun() or so. If you can
> update the patch would be nice, otherwise I'll try to check it, next
> week.
>
>> I'm not sure if the same behaviour is required on Linux -- probably
>> not, since nobody has reported this problem so far.
>
> Most probably we would need to add some code for ipv6 in linux as well.
>
> regards,
> Nikos
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Remove-addresses-from-old-tun-device-when-stealing-l.patch
Type: application/octet-stream
Size: 2635 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150415/72d72639/attachment.obj>

From mehrzadjalali at yahoo.com  Tue Apr 14 18:09:45 2015
From: mehrzadjalali at yahoo.com (Mehrzad Jalali)
Date: Wed, 15 Apr 2015 01:09:45 +0000 (UTC)
Subject: radius problem
Message-ID: <1498238331.3870505.1429060185066.JavaMail.yahoo@mail.yahoo.com>

hi
I install ocserv 0.10.2 in centos 6.5 freeradius 2 & radiusclient 1.1.7, daloradius 0.9.9 all is work well but when user disconnected daloradius show user online and after 6 7 min daloradius clean user, I test with pam but have same problem, by this problem when i limit sim connection to 1 user must wait 6 7 minute to connect after disconnect, in the same vps i test openvpn, openvpn don't have any problem imidiatly after disconnect clean user from online list 
my nas settting is [127.0.0.1] nas type [other] auto and act for radius in config file in uncommented and daloradius show data usage but don't detect user disconnect

please inform that if i must set any other type of nas or change config file 

note: that i test same config with IBSng that is other radius that not use freeradius and core is from IBS but have same problem

thanks


From nmav at gnutls.org  Wed Apr 15 06:01:59 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 15 Apr 2015 16:01:59 +0300
Subject: [PATCH] Remove addresses from old tun device when stealing leases
In-Reply-To: <CALPpbciatF-hT7w24r4oVaTx_Zb-c5dK75tjE61wkKmFhjPfSQ@mail.gmail.com>
References: <CALPpbcgMb1xxw3rYfTqM70N+HQ2HwFtewv57_KF15w0ryCbdog@mail.gmail.com>
 <1429014026.2231.9.camel@gnutls.org>
 <CALPpbciatF-hT7w24r4oVaTx_Zb-c5dK75tjE61wkKmFhjPfSQ@mail.gmail.com>
Message-ID: <1429102919.18414.0.camel@gnutls.org>

On Wed, 2015-04-15 at 19:42 +1000, Brian Chu wrote:
> Hi Nikos,
> 
> Thanks for the suggestion. Please see updated patch.

Applied (with some tweak to compile in linux).

regards,
Nikos




From iceberg.90427 at gmail.com  Thu Apr 16 08:14:55 2015
From: iceberg.90427 at gmail.com (Jafar habibi livar)
Date: Thu, 16 Apr 2015 19:44:55 +0430
Subject: radius simultaneous-use and max-same-clients
Message-ID: <CADZNCU=BjAocMuc0tjQP6ZwqkGf2AEQ5cfQkUd_tvAka7b3fzQ@mail.gmail.com>

Hi there

if I set max-same-clients = 0 and assign simultaneous-use to 2 in for
a specific user in  radius server. the question is that, is user only
able to connect 2 simultaneously or the user will be unlimited?

thanks


From nmav at gnutls.org  Fri Apr 17 03:19:48 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 17 Apr 2015 13:19:48 +0300
Subject: radius simultaneous-use and max-same-clients
In-Reply-To: <CADZNCU=BjAocMuc0tjQP6ZwqkGf2AEQ5cfQkUd_tvAka7b3fzQ@mail.gmail.com>
References: <CADZNCU=BjAocMuc0tjQP6ZwqkGf2AEQ5cfQkUd_tvAka7b3fzQ@mail.gmail.com>
Message-ID: <1429265988.2453.2.camel@gnutls.org>

On Thu, 2015-04-16 at 19:44 +0430, Jafar habibi livar wrote:
> Hi there
> 
> if I set max-same-clients = 0 and assign simultaneous-use to 2 in for
> a specific user in  radius server. the question is that, is user only
> able to connect 2 simultaneously or the user will be unlimited?

If you delegate the check to your radius servers, than your radius
server will enforce the limit on authentication.

regards,
Nikos




From lnp at healy.washington.dc.us  Sun Apr 19 07:42:41 2015
From: lnp at healy.washington.dc.us (Liam Healy)
Date: Sun, 19 Apr 2015 10:42:41 -0400
Subject: Failed to determine type of private key
Message-ID: <CADe9tL6rYGKXTBZoyvCkmjfdQ7hNPTD2Y3bo55uY3Vm81KKRXw@mail.gmail.com>

I am trying to write a script to connect to a server which I can
successfully connect to using the Network Manager interface to
OpenConnect. My script is:

 NAME="myusername"
      GROUP="MYGROUP"
      PIDFILE="openconnect.pid"
      CERT="/etc/ssl/certs/servercert.pem"
      HOST="https://vpn.example.com"
      SCRIPT="/etc/vpnc/vpnc-script"

      openconnect -b -c $CERT --script $SCRIPT --pid-file=$PIDFILE
--user=$NAME --usergroup=$GROUP

What I expect when I run this from the shell is that I will be
prompted for my password and then I will connect to the server, as
happens when run from network manager. What I get is:

 POST https://vpn.example.com/MYGROUP
      Attempting to connect to server 1.1.1.4:443
      Failed to determine type of private key /etc/ssl/certs/servercert.pem
      Loading certificate failed. Aborting.
      Failed to open HTTPS connection to vpn.example.com
      GET https://vpn.example.com/MYGROUP
      Attempting to connect to server 1.1.1.6:443
      Failed to determine type of private key /etc/ssl/certs/servercert.pem
      Loading certificate failed. Aborting.
      Failed to open HTTPS connection to vpn.example.com
      Failed to obtain WebVPN cookie

and no connection. On nm, I do get a message "SSL certificate
authentication failed", but it connects.

My questions: How do I connect to the VPN from the command line? How
do I remove the message about the certificate authentication when
using nm? Is it possible to find out the command-line equivalent of
what nm is doing?

Ubuntu 14.04LTS
OpenConnect version v5.02
Using GnuTLS. Features present: PKCS#11, TOTP software token, DTLS
(using OpenSSL)
Linux 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux


Thank you,
Liam


From dwmw2 at infradead.org  Sun Apr 19 08:27:47 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 19 Apr 2015 15:27:47 -0000
Subject: Failed to determine type of private key
In-Reply-To: <CADe9tL6rYGKXTBZoyvCkmjfdQ7hNPTD2Y3bo55uY3Vm81KKRXw@mail.gmail.com>
References: <CADe9tL6rYGKXTBZoyvCkmjfdQ7hNPTD2Y3bo55uY3Vm81KKRXw@mail.gmail.com>
Message-ID: <30bc1434e5248a3d7010ef5413c9dd68.squirrel@twosheds.infradead.org>

The -c optiin is for your client certificate, which requires a
corresponding private key is you're going to use it to prove your
identity.

For a server-side cert you want --servercert. Or just give the server a
proper cert!

Note that --servercert takes a hash of the cert (which is shown if you ask
for the cert info) not the full cert in a file as you seem to have.

-- 
dwmw2



From magicfish1990 at gmail.com  Mon Apr 20 02:08:11 2015
From: magicfish1990 at gmail.com (MagicFish1990)
Date: Mon, 20 Apr 2015 05:08:11 -0400
Subject: Strange connection problem
Message-ID: <CA+OdDBWtCP3BsN48G0fyB=58TW6+pwf7m2TYbqcP00_njU-Z5w@mail.gmail.com>

Hi all,

I encountered a problem that I can not understand. It is a bit like an
upgraded version of my previous encounter problems.

Before the problem is I can not access many sites in a mobile network
(still not resolved). For example, I can access the twitter, telegram,
etc, but google now, some games (COC, Ingress), can not connect to the
server. However, they work when use WiFi, so I think that is network
operators NAT problem.

However, when I upgraded ocserv to 0.10.2, it becomes everywhere.
I cannot loading Twitter image, cannot open speedtest.net, the games
cannot connect server even though I use WiFi/LAN and computer.

At first I thought it was the MTU problem, and then I found that even
reducing the MTU has no effect, and like YouTube and other large data
packets website work properly.

So I need help. I totally not find a common characteristics in those
website. TCP/UDP work, large/small data packets work, no error on
ocserv log and client log, meanwhile some software work as normal.

Example:

curl -vvvvv "http://www.speedtest.net/"
*   Trying 72.21.92.82...
* Connected to www.speedtest.net (72.21.92.82) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.41.0
> Host: www.speedtest.net
> Accept: */*
>

[Long time....]

* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer


Thanks
MagicFish1990


From lnp at healy.washington.dc.us  Mon Apr 20 20:04:49 2015
From: lnp at healy.washington.dc.us (Liam Healy)
Date: Mon, 20 Apr 2015 23:04:49 -0400
Subject: Failed to determine type of private key
In-Reply-To: <30bc1434e5248a3d7010ef5413c9dd68.squirrel@twosheds.infradead.org>
References: <CADe9tL6rYGKXTBZoyvCkmjfdQ7hNPTD2Y3bo55uY3Vm81KKRXw@mail.gmail.com>
 <30bc1434e5248a3d7010ef5413c9dd68.squirrel@twosheds.infradead.org>
Message-ID: <CADe9tL4-Xm6u_8UGXduk7r3k+nXU2rjLSVpJJb6+1n6qX=brUg@mail.gmail.com>

Thanks for the reply. I was able to generate the server cert
fingerprint, but I had it wrong, because when I connected in the shell
openconnect reported the correct one.

Liam

On Sun, Apr 19, 2015 at 11:27 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> The -c optiin is for your client certificate, which requires a
> corresponding private key is you're going to use it to prove your
> identity.
>
> For a server-side cert you want --servercert. Or just give the server a
> proper cert!
>
> Note that --servercert takes a hash of the cert (which is shown if you ask
> for the cert info) not the full cert in a file as you seem to have.
>
> --
> dwmw2
>


From phil at steitz.com  Tue Apr 21 14:09:31 2015
From: phil at steitz.com (Phil Steitz)
Date: Tue, 21 Apr 2015 14:09:31 -0700
Subject: Is is possible to build openconnect-7.06 from source on OSX?
Message-ID: <5536BC8B.4060300@steitz.com>

First, are there OSX binaries somewhere so I don't have to do this
at all?

Assuming no, I tried to build with

gcc (Homebrew gcc 4.9.2_1) 4.9.2
On Mac OSX Yosemite 10.10.3

but got this error from make:

Undefined symbols for architecture x86_64:
  "_esp_shutdown", referenced from:
      _oncp_mainloop in libopenconnect_la-oncp.o
ld: symbol(s) not found for architecture x86_64

Thanks!

Phil



-- 



From qzhou at live.de  Tue Apr 21 20:03:20 2015
From: qzhou at live.de (Quan Zhou)
Date: Wed, 22 Apr 2015 11:03:20 +0800
Subject: Possibility to automatically issue/deliver certificates to users via
 AnyConnect?
Message-ID: <BLU436-SMTP1566494CC2B9DD781BE372CBAEE0@phx.gbl>

Hi everyone,

I?m ready to roll out ocserv to a larger part in my office, but now I have to deliver the certificates to each one of them.

Soon, I figured out that AnyConnect does have a feature to retrieve certs with proper authentication, like user/pass combination, would that be possible for ocserv to do the same?

Regards,

Quan Zhou

+------------------------+
|pub [expires 2015-09-05]|
|44D2 0307 1643 E80F 2E31|
|F081 FAFA 6643 7F9F D46F|
+------------------------+
|qzhou at live.de           |
|https://keybase.io/qzhou|
+------------------------+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150422/c0a96552/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Wed Apr 22 02:27:37 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 22 Apr 2015 11:27:37 +0200
Subject: Possibility to automatically issue/deliver certificates to users
 via AnyConnect?
In-Reply-To: <BLU436-SMTP1566494CC2B9DD781BE372CBAEE0@phx.gbl>
References: <BLU436-SMTP1566494CC2B9DD781BE372CBAEE0@phx.gbl>
Message-ID: <CAJU7zaKayJD7a+zHNcX2RCxpkD2d2dqDqzH1wjhSY1D2+2Qi9Q@mail.gmail.com>

On Wed, Apr 22, 2015 at 5:03 AM, Quan Zhou <qzhou at live.de> wrote:
> Hi everyone,
> I'm ready to roll out ocserv to a larger part in my office, but now I have to deliver the certificates to each one of them.
> Soon, I figured out that AnyConnect does have a feature to retrieve certs with proper authentication, like user/pass combination, would that be possible for ocserv to do the same?

Let's ignore about practicalities on how that could be deployed on a
linux server (where to store these certificates etc.). Can you take a
trace of the protocol used to assign certificates?

regards,
Nikos


From phil at steitz.com  Wed Apr 22 09:47:47 2015
From: phil at steitz.com (Phil Steitz)
Date: Wed, 22 Apr 2015 09:47:47 -0700
Subject: Is is possible to build openconnect-7.06 from source on OSX?
In-Reply-To: <AF6057CB-4B96-4EBC-9D0E-5FF7EACC6CF0@hydroxide.nl>
References: <5536BC8B.4060300@steitz.com>
 <AF6057CB-4B96-4EBC-9D0E-5FF7EACC6CF0@hydroxide.nl>
Message-ID: <5537D0B3.5030709@steitz.com>

On 4/21/15 10:58 PM, Bj?rn Ketelaars wrote:
> You could checkout macports or Brew. Both offer a portfile for
> openconnect.
>
> Advantage is that portfiles are maintained so  future upgrading is
> easy...

works4me

Thanks!

Phil
>
> -- 
> Bj?rn Ketelaars
> GPG key: 0x4F0E5F21
>
> On 21 Apr 2015, at 23:09, Phil Steitz <phil at steitz.com
> <mailto:phil at steitz.com>> wrote:
>
>> First, are there OSX binaries somewhere so I don't have to do this
>> at all?
>>
>> Assuming no, I tried to build with
>>
>> gcc (Homebrew gcc 4.9.2_1) 4.9.2
>> On Mac OSX Yosemite 10.10.3
>>
>> but got this error from make:
>>
>> Undefined symbols for architecture x86_64:
>>  "_esp_shutdown", referenced from:
>>      _oncp_mainloop in libopenconnect_la-oncp.o
>> ld: symbol(s) not found for architecture x86_64
>>
>> Thanks!
>>
>> Phil
>>
>>
>>
>> -- 
>>
>>
>> _______________________________________________
>> openconnect-devel mailing list
>> openconnect-devel at lists.infradead.org
>> <mailto:openconnect-devel at lists.infradead.org>
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel


-- 



From dwmw2 at infradead.org  Thu Apr 23 04:05:29 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Apr 2015 12:05:29 +0100
Subject: Is is possible to build openconnect-7.06 from source on OSX?
In-Reply-To: <5537D0B3.5030709@steitz.com>
References: <5536BC8B.4060300@steitz.com>
 <AF6057CB-4B96-4EBC-9D0E-5FF7EACC6CF0@hydroxide.nl>
 <5537D0B3.5030709@steitz.com>
Message-ID: <1429787129.26734.30.camel@infradead.org>

On Wed, 2015-04-22 at 09:47 -0700, Phil Steitz wrote:
> On 4/21/15 10:58 PM, Bj?rn Ketelaars wrote:
> > You could checkout macports or Brew. Both offer a portfile for
> > openconnect.
> >
> > Advantage is that portfiles are maintained so  future upgrading is
> > easy...
> 
> works4me

And just for completeness, the original problem was fixed in git here:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/25e2d3a
8e6

However, you'll only be hitting that error if you're using a crappy
version of OpenSSL which doesn't easily support ESP. I thought OSX had
something newer... or better still, build against GnuTLS.

-- 
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/20150423/3711fc99/attachment.bin>

From hutchins at tarcanfel.org  Thu Apr 23 08:38:43 2015
From: hutchins at tarcanfel.org (Jonathan Hutchins)
Date: Thu, 23 Apr 2015 10:38:43 -0500 (CDT)
Subject: Routing Problem
Message-ID: <86edec0855c0482f8f5f104c8c1f10cb.squirrel@minerva>

With Anyconnect, I get 16 explicit 255.255.255.255 routes for 8.33.3.
addresses through the local gateway.  With Openconnect, I only get the
first one, and I can't reach 8.33.3.80 for some reason.  Anything I can do
about this?  I'm running 3.20-4 on Debian Wheezy i386, using
Network-Manger to manage the connection.



From dwmw2 at infradead.org  Thu Apr 23 08:58:35 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Apr 2015 16:58:35 +0100
Subject: Routing Problem
In-Reply-To: <86edec0855c0482f8f5f104c8c1f10cb.squirrel@minerva>
References: <86edec0855c0482f8f5f104c8c1f10cb.squirrel@minerva>
Message-ID: <1429804715.7857.16.camel@infradead.org>

On Thu, 2015-04-23 at 10:38 -0500, Jonathan Hutchins wrote:
> With Anyconnect, I get 16 explicit 255.255.255.255 routes for 8.33.3.
> addresses through the local gateway.  With Openconnect, I only get the
> first one, and I can't reach 8.33.3.80 for some reason.  Anything I can do
> about this?  I'm running 3.20-4 on Debian Wheezy i386, using
> Network-Manger to manage the connection.

Firstly, does it magically get better if you use a version of
OpenConnect that isn't so ancient?

Can you show the output of OpenConnect if you add '-v -v' to the
command line when you connect?

-- 
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/20150423/e08cb980/attachment.bin>

From hutchins at tarcanfel.org  Thu Apr 23 09:28:53 2015
From: hutchins at tarcanfel.org (Jonathan Hutchins)
Date: Thu, 23 Apr 2015 11:28:53 -0500 (CDT)
Subject: Routing Problem
In-Reply-To: <1429804715.7857.16.camel@infradead.org>
References: <86edec0855c0482f8f5f104c8c1f10cb.squirrel@minerva>
 <1429804715.7857.16.camel@infradead.org>
Message-ID: <9e4139b6dc639a4719de4166d3500734.squirrel@minerva>

> Firstly, does it magically get better if you use a version of
> OpenConnect that isn't so ancient?

The Debian package should be patched with any functional or security
updates, but the next release is scheduled for this weekend and I could
begin testing it next week.  It looks like Jessie has 6.00-2.

> Can you show the output of OpenConnect if you add '-v -v' to the
> command line when you connect?

I'll see if I can configure a CLI connection.  As I said, I'm using
network-manager to configure it as I switch it on and off frequently.

That is a pretty significant increase in version, so I'll report back
after I upgrade.



From nmav at gnutls.org  Sat Apr 25 01:18:35 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 25 Apr 2015 10:18:35 +0200
Subject: ocserv 0.10.3
Message-ID: <1429949915.3515.0.camel@gnutls.org>

Hello,
  I've just released ocserv 0.10.2. This is a bug fix release which 
resolves all known issues in the 0.10.x branch.

* Version 0.10.3 (2015-04-25)
- Detection of gnutls capabilities was made dynamic. That would allow
  the server to be compiled with old gnutls version but still use new
  functionality when linked with a newer version.
- The DBUS communication channel with occtl was brought up in par
  with the unix socket based one.
- Fixed issues with FreeBSD tun device handling. Reports and patches
  by Brian Chu.
- When multiple authentication methods are set and the primary includes
  a certificate, no longer require a certificate for all clients.
- When receiving non-minimal DPD messages, reflect their contents.
  This allows using DPD for MTU detection.
- The 'try-mtu-discovery' config option was fixed to affect the DF bit
  setting in UDP packets.
- Invalidate cookies when the user terminates the session explicitly.
- Fixed 'user-profile' option when isolate-workers is set to true.
- sec-mod: Do not impose timeouts on reads from main. That would prevent
  issues when reading in a very busy system.


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

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

regards,
Nikos




From huangjiesin at 163.com  Sat Apr 25 01:56:44 2015
From: huangjiesin at 163.com (163)
Date: Sat, 25 Apr 2015 16:56:44 +0800
Subject: doesn't  work on KVM VPS
Message-ID: <553B56CC.8090904@163.com>

Hello,

  I tried ocserv on several KVM server and none of them can run ocserv. 
all exits with the following error when starting:

ocserv[24913]: main: initializing control unix socket: /var/run/occtl.socket
ocserv[24913]: main: initialized ocserv 0.9.2
ocserv[24913]: main: main.c:469: ocserv-secmod died unexpectedly
ocserv[24913]: main: main.c:490: Child 24914 died with sigsegv
ocserv[24913]: main: termination request received; waiting for children 
to die

the latest version is no different

ocserv[32366]: main: initializing control unix socket: /var/run/occtl.socket
ocserv[32366]: main: initialized ocserv 0.10.3
ocserv[32366]: main: main.c:479: ocserv-secmod died unexpectedly
ocserv[32366]: main: main.c:500: Child 32367 died with sigsegv
ocserv[32366]: main: termination request received; waiting for children 
to die

Thank you






From nmav at gnutls.org  Sat Apr 25 02:32:41 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 25 Apr 2015 11:32:41 +0200
Subject: doesn't  work on KVM VPS
In-Reply-To: <553B56CC.8090904@163.com>
References: <553B56CC.8090904@163.com>
Message-ID: <1429954361.19583.0.camel@gnutls.org>

On Sat, 2015-04-25 at 16:56 +0800, 163 wrote:
> Hello,
> 
>   I tried ocserv on several KVM server and none of them can run ocserv. 
> all exits with the following error when starting:
> 
> ocserv[24913]: main: initializing control unix socket: /var/run/occtl.socket
> ocserv[24913]: main: initialized ocserv 0.9.2
> ocserv[24913]: main: main.c:469: ocserv-secmod died unexpectedly
> ocserv[24913]: main: main.c:490: Child 24914 died with sigsegv
> ocserv[24913]: main: termination request received; waiting for children 
> to die
> the latest version is no different

Hi,
 Run the latest version under valgrind and attach the output.

regards,
Nikos




From riteki at gmail.com  Sun Apr 26 04:19:37 2015
From: riteki at gmail.com (Teki Ri)
Date: Sun, 26 Apr 2015 19:19:37 +0800
Subject: Freeradius couldn't receive stop time/termination info from ocserv
 0.10.3
Message-ID: <CA+w5XF5a_Uce3FJrhh7N_j0nPNUbLfNNG47Vfsdv2WtFnC1waQ@mail.gmail.com>

Hi,

After upgraded to 0.10.3 I found that stop time and termination info
(User-Request or Lost-Carrier) are always empty on freeradius server,
but 0.10.2 worked fine with my freeradius server, those info will be
updated to freeradius after several minutes after client terminated
the connection on 0.10.2.

Thanks,
David


From nmav at gnutls.org  Sun Apr 26 08:18:58 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 26 Apr 2015 17:18:58 +0200
Subject: Freeradius couldn't receive stop time/termination info from
 ocserv 0.10.3
In-Reply-To: <CA+w5XF5a_Uce3FJrhh7N_j0nPNUbLfNNG47Vfsdv2WtFnC1waQ@mail.gmail.com>
References: <CA+w5XF5a_Uce3FJrhh7N_j0nPNUbLfNNG47Vfsdv2WtFnC1waQ@mail.gmail.com>
Message-ID: <1430061538.32190.2.camel@gnutls.org>

On Sun, 2015-04-26 at 19:19 +0800, Teki Ri wrote:
> Hi,
> 
> After upgraded to 0.10.3 I found that stop time and termination info
> (User-Request or Lost-Carrier) are always empty on freeradius server,
> but 0.10.2 worked fine with my freeradius server, those info will be
> updated to freeradius after several minutes after client terminated
> the connection on 0.10.2.

It seems there is a regression. Does the version in the git repository
work for you?

regards,
Nikos




From riteki at gmail.com  Mon Apr 27 00:59:36 2015
From: riteki at gmail.com (Teki Ri)
Date: Mon, 27 Apr 2015 15:59:36 +0800
Subject: Freeradius couldn't receive stop time/termination info from
 ocserv 0.10.3
In-Reply-To: <1430061538.32190.2.camel@gnutls.org>
References: <CA+w5XF5a_Uce3FJrhh7N_j0nPNUbLfNNG47Vfsdv2WtFnC1waQ@mail.gmail.com>
 <1430061538.32190.2.camel@gnutls.org>
Message-ID: <CA+w5XF5EBm+=-eZrhqnAy_LSkS4T=Ge7o_fXU_6ZUKYu_yyWew@mail.gmail.com>

Hi Nikos,

I patched 0.10.3 and it works fine now, thanks!

Regards,
Di

On Sun, Apr 26, 2015 at 11:18 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Sun, 2015-04-26 at 19:19 +0800, Teki Ri wrote:
>> Hi,
>>
>> After upgraded to 0.10.3 I found that stop time and termination info
>> (User-Request or Lost-Carrier) are always empty on freeradius server,
>> but 0.10.2 worked fine with my freeradius server, those info will be
>> updated to freeradius after several minutes after client terminated
>> the connection on 0.10.2.
>
> It seems there is a regression. Does the version in the git repository
> work for you?
>
> regards,
> Nikos
>
>


From nmav at gnutls.org  Mon Apr 27 01:07:25 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 27 Apr 2015 10:07:25 +0200
Subject: Freeradius couldn't receive stop time/termination info from
 ocserv 0.10.3
In-Reply-To: <CA+w5XF5EBm+=-eZrhqnAy_LSkS4T=Ge7o_fXU_6ZUKYu_yyWew@mail.gmail.com>
References: <CA+w5XF5a_Uce3FJrhh7N_j0nPNUbLfNNG47Vfsdv2WtFnC1waQ@mail.gmail.com>
 <1430061538.32190.2.camel@gnutls.org>
 <CA+w5XF5EBm+=-eZrhqnAy_LSkS4T=Ge7o_fXU_6ZUKYu_yyWew@mail.gmail.com>
Message-ID: <CAJU7za+hSjsY4+68pULqkobW8Nacc9qgfJ2L2y0SG2D7cXS1SA@mail.gmail.com>

On Mon, Apr 27, 2015 at 9:59 AM, Teki Ri <riteki at gmail.com> wrote:
> Hi Nikos,
> I patched 0.10.3 and it works fine now, thanks!

Thank you for testing it. I've released 0.10.4 to address that issue
and added a check in the test suite.

regards,
Nikos


From peter.brant at gmail.com  Mon Apr 27 14:11:04 2015
From: peter.brant at gmail.com (Peter Brant)
Date: Mon, 27 Apr 2015 23:11:04 +0200
Subject: Slow connections (something other than packet fragmentation?)
Message-ID: <CAFA7iJKRTK=34pXbzuoPrQ=vF2Lc=XqoShiWuRBQy_UkJsgo5A@mail.gmail.com>

Hi all,

We're trying to switch from vpnc to openconnect. I can connect fine,
but the connection is extremely slow (about 1Mb/sec compared with
about 15Mb/sec with vpnc).

>From searching the archives, it looks like the typical cause of this
is packet fragmentation. I've experimented with setting --mtu=xxx for
various values between 500 and 1400 with no change either for the
better or worse.

Should I see the value I set there somewhere in the output for ifconfig?

I do see an MTU for 1406 for tun0 and vpn0. Ping times to an internal
address with the VPN connected for ping -s 1378 (1406) and ping -s
1379 (1407) do indeed double. Ping times for -s < 1378 are normal
(unchanged from before).

Also, with --verbose output, I see something like

Attempt new DTLS connection
Send CSTP DPD
No work to do; sleeping for 15000 ms...
Got CSTP DPD response
No work to do; sleeping for 20000 ms...
DTLS handshake timed out
DTLS handshake failed: 2

every two minutes or so. Starting openconnect with --no-dtls
predictably removes the above. Performance is unchanged.

Capturing the SSL traffic with tcpdump looks unsuspicious to my
relatively inexperienced eye.

The OpenConnect version is 5.02, running on Linux Mint 17 / Ubuntu
14.04.1.  I'm not sure of the hardware / software version on the other
side, but can easily find out.

Is there other information that would be helpful?

Thanks very much for any ideas.

Peter


From dwmw2 at infradead.org  Mon Apr 27 14:13:56 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 27 Apr 2015 22:13:56 +0100
Subject: Slow connections (something other than packet fragmentation?)
In-Reply-To: <CAFA7iJKRTK=34pXbzuoPrQ=vF2Lc=XqoShiWuRBQy_UkJsgo5A@mail.gmail.com>
References: <CAFA7iJKRTK=34pXbzuoPrQ=vF2Lc=XqoShiWuRBQy_UkJsgo5A@mail.gmail.com>
Message-ID: <1430169236.6377.35.camel@infradead.org>

On Mon, 2015-04-27 at 23:11 +0200, Peter Brant wrote:.
> DTLS handshake timed out
> DTLS handshake failed: 2

You're running your VPN over TCP. That's never going to perform well.

Why is UDP connectivity to the server not working correctly? Are you
behind some broken NAT, or does the server have broken firewalling?

-- 
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/20150427/8000ef3a/attachment.bin>

From peter.brant at gmail.com  Mon Apr 27 15:14:37 2015
From: peter.brant at gmail.com (Peter Brant)
Date: Tue, 28 Apr 2015 00:14:37 +0200
Subject: Slow connections (something other than packet fragmentation?)
In-Reply-To: <1430169236.6377.35.camel@infradead.org>
References: <CAFA7iJKRTK=34pXbzuoPrQ=vF2Lc=XqoShiWuRBQy_UkJsgo5A@mail.gmail.com>
 <1430169236.6377.35.camel@infradead.org>
Message-ID: <CAFA7iJ+bh-cEsgDdZ+uFbUZBZqv+ByWhQoMkOnvTti_Ui1ukeA@mail.gmail.com>

On Mon, Apr 27, 2015 at 11:13 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> You're running your VPN over TCP. That's never going to perform well.
>
Ah, I didn't know that the performance overhead of using TCP was that severe.

> Why is UDP connectivity to the server not working correctly? Are you
> behind some broken NAT, or does the server have broken firewalling?
>
Either is entirely possible. Besides my router, there is quite a bit
of network between me and the server (including my Austrian ISP [UPC]
and a couple of layers of State of Wisconsin [US] infrastructure).

I am forwarding UDP port 443 from my router to computer. Are there
other ports I should be forwarding too? Going the other direction,
what port(s) on the server needs to be accessible?

Thanks,

Peter


From hszhsz at gmail.com  Tue Apr 28 00:32:59 2015
From: hszhsz at gmail.com (=?UTF-8?Q?Horv=C3=A1th_Szabolcs?=)
Date: Tue, 28 Apr 2015 09:32:59 +0200
Subject: Fwd: openconnect v7.06 for Windows issue
In-Reply-To: <CABAPnR4q_e+8qD_vL4WWLB-ejfANNnoK+HDYMiTOKAKoE=j3KQ@mail.gmail.com>
References: <CABAPnR4q_e+8qD_vL4WWLB-ejfANNnoK+HDYMiTOKAKoE=j3KQ@mail.gmail.com>
Message-ID: <CABAPnR7RaeAErqRNBuGDgqqa0B2J720wiGQ55RW5yfrr7wZq8g@mail.gmail.com>

Dear All,

I have an issue connecting to one of our partner with openconnect.
Symptoms are the following:
- we can build a VPN with Openconnect on Linux to our partner and it
is working fine (traffic is passing through as expected)
- we can build a VPN with Cisco Anyconnect on Windows to our partner
- we CANNOT build a VPN with Openconnect on Windows to our partner
(technically, VPN is built but traffic is not passing through, details
below)
- we CAN build VPN with OpenConnect on Windows to other partners

>From all of these, I would say there is nothing wrong with the partner
VPN (because connecting to it from windows/anyconnect and
linux/openconnect combination are working fine).

After days of investigation I found out that there are no ARP replies
on the tun interface when connecting from openconnect/windows.

Logs attached:
- openconnect-logs.txt: openconnect binary logs
- openconnect-ipconfig.txt ipconfig output
- openconnect-after.txt: routes after the vpn connection has been built

When I'm using AnyConnect, then I'm seeing ARP traffic (both requests
and answers) on Cisco Anyconnect VPN Virtual Miniport Adapter for
Windows x64:
12    2015-04-28 08:43:26.030225000    Cisco_3c:7a:00    Broadcast
ARP    42    Who has 10.219.35.3?  Tell 10.219.35.2
13    2015-04-28 08:43:26.030333000    Cimsys_33:44:55
Cisco_3c:7a:00    ARP    42    10.219.35.3 is at 00:11:22:33:44:55

When I'm using OpenConnect on Windows, then I'm seeing only ARP
requests on TAP-Windows Adapter v9:
3    2015-04-28 08:45:33.158621000    00:ff:11:26:6c:fd    Broadcast
 ARP    42    Who has 10.219.35.8?  Tell 10.219.35.7

However, connecting to another partner with OpenConnect on Windows is
working fine.

I don't know where to go next, because VPN guys said the VPN
concentrator is working well (can connect from anyconnect and
openconnect on linux, just openconnect on windows does not work)

Any help would be very much appreciated because this is driving me crazy.

Best regards,
  Szabolcs Horvath
-------------- next part --------------
C:\Program Files (x86)\OpenConnect>openconnect --cookie=4252DopDN6ElsHKovbiously-not-this-mFXq
 --no-cert-check 195.228.84.1 -v --mtu 1300 --base-mtu 1300 --script vpnc-script-win.js
WARNING: This version of openconnect is v7.06 but
         the libopenconnect library is v7.06-unknown
 Attempting to connect to server 195.228.84.1:443
 Connected to 195.228.84.1:443
 SSL negotiation with 195.228.84.1
 Server certificate verify failed: certificate does not match hostname
 Connected to HTTPS on 195.228.84.1
 Got CONNECT response: HTTP/1.1 200 OK
 X-CSTP-Version: 1
 X-CSTP-Address: 10.219.35.7
 X-CSTP-Netmask: 255.255.255.255
 X-CSTP-DNS: 172.19.230.44
 X-CSTP-DNS: 172.18.2.7
 X-CSTP-Lease-Duration: 1209600
 X-CSTP-Session-Timeout: none
 X-CSTP-Idle-Timeout: 1800
 X-CSTP-Disconnected-Timeout: 1800
 X-CSTP-Split-Include: 10.219.0.0/255.255.0.0
 X-CSTP-Split-Include: 172.19.230.44/255.255.255.255
 X-CSTP-Split-Include: 172.18.2.7/255.255.255.255
 X-CSTP-Split-DNS: elmu.hu
 X-CSTP-Split-DNS: rwehun.local
 X-CSTP-Keep: true
 X-CSTP-Tunnel-All-DNS: false
 X-CSTP-DPD: 30
 X-CSTP-Keepalive: 20
 X-CSTP-MSIE-Proxy-Lockdown: true
 X-CSTP-Smartcard-Removal-Disconnect: true
 X-DTLS-Session-ID: 92B12E7BE78DDD60E5DEB65C2F105D39F9808F2905F22309C857960802577980
 X-DTLS-Port: 443
 X-DTLS-Keepalive: 20
 X-DTLS-DPD: 30
 X-CSTP-MTU: 1300
 X-DTLS-CipherSuite: AES128-SHA
 X-CSTP-Routing-Filtering-Ignore: false
 X-CSTP-Quarantine: false
 X-CSTP-Disable-Always-On-VPN: false
 X-CSTP-TCP-Keepalive: true
 CSTP connected. DPD 30, Keepalive 20
 CSTP Ciphersuite: (TLS1.0)-(RSA)-(AES-128-CBC)-(SHA1)
 Microsoft (R) Windows Script Host 5.8 verzi?
Copyright (C) Microsoft Corporation 1996-2001. Minden jog fenntartva.

Opened tun device tun
 TAP-Windows driver v9.21 (0)
 Microsoft (R) Windows Script Host 5.8 verzi?
Copyright (C) Microsoft Corporation 1996-2001. Minden jog fenntartva.

route print
VPN Gateway: 195.228.84.1
Internal Address: 10.219.35.7
Internal Netmask: 255.255.255.255
Internal Gateway: 10.219.35.8
Interface: "tun"
MTU: 1300
netsh interface ipv4 set subinterface "tun" mtu=1300 store=active
Configuring "tun" interface for Legacy IP...
netsh interface ip set address "tun" static 10.219.35.7 255.255.255.255
route add 195.228.84.1 mask 255.255.255.255 10.35.76.1
netsh interface ip add dns "tun" 172.19.230.44 index=1
netsh interface ip add dns "tun" 172.18.2.7 index=2
done.
Configuring Legacy IP networks:
Waiting for interface to come up...
route print
Waiting for interface to come up...
route print
route add 172.18.2.7 mask 255.255.255.255 10.219.35.8
route add 172.19.230.44 mask 255.255.255.255 10.219.35.8
route add 10.219.0.0 mask 255.255.0.0 10.219.35.8
Route configuration done.
DTLS option X-DTLS-Session-ID : 92B12E7BE78DDD60E5DEB65C2F105D39F9808F2905F22309C857960802577980
 DTLS option X-DTLS-Port : 443
 DTLS option X-DTLS-Keepalive : 20
 DTLS option X-DTLS-DPD : 30
 DTLS option X-DTLS-CipherSuite : AES128-SHA
 DTLS initialised. DPD 30, Keepalive 20
 Connected tun as 10.219.35.7, using SSL
 Established DTLS connection (using GnuTLS). Ciphersuite (DTLS0.9)-(RSA)-(AES-128-CBC)-(SHA1).
-------------- next part --------------

Ethernet-adapter tun:

   Kapcsolatspecifikus DNS-ut?tag. . :
   Le?r?s. . . . . . . . . . . . . . : TAP-Windows Adapter V9
   Fizikai c?m . . . . . . . . . . . : 00-FF-11-26-6C-FD
   DHCP enged?lyezve . . . . . . . . : Nem
   Automatikus konfigur?ci? enged?lyezve : Igen
   Kapcsolati szint? IPv6-c?m  . . . : fe80::61c9:bee8:8db2:6c28%34(K?v?nt)
   IPv4-c?m. . . . . . . . . . . . . : 10.219.35.7(K?v?nt)
   Alh?l?zati maszk. . . . . . . . . : 255.255.255.255
   Alap?rtelmezett ?tj?r?. . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 402718481
   DHCPv6-?gyf?l DUID azonos?t?ja . . . . . . . : 00-01-00-01-17-6B-BF-B1-D4-BE-D9-0C-74-6A
   DNS-kiszolg?l?k . . . . . . . . . : 172.19.230.44
                                       172.18.2.7
   NetBIOS a TCP/IP felett . . . . . : Enged?lyezve
-------------- next part --------------
C:\>route print -4
===========================================================================
Kapcsolatlista
 34...00 ff 11 26 6c fd ......TAP-Windows Adapter V9
 26...54 26 24 db a2 1d ......Check Point Virtual Network Adapter For Endpoint VPN Client
 18...54 79 95 48 d1 14 ......Check Point Virtual Network Adapter For SSL Network Extender
 17...10 0b a9 03 19 e5 ......Microsoft Virtual WiFi Miniport Adapter
 12...10 0b a9 03 19 e4 ......Intel(R) Centrino(R) Advanced-N 6205
 11...d4 be d9 0c 74 6a ......Intel(R) 82579LM Gigabit Network Connection
 29...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
 30...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
  1...........................Software Loopback Interface 1
 22...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 21...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 19...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
 15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
 20...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #5
 23...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #6
 25...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #7
 27...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #8
===========================================================================

IPv4 ?tvonalt?bla
===========================================================================
Akt?v ?tvonalak:
H?l?zati c?l               H?l?zati maszk   ?tj?r?        Kapcsolat  Metrika
          0.0.0.0          0.0.0.0       10.35.76.1      10.35.76.20     10
       10.35.76.0    255.255.255.0   Kapcsolaton bel?li       10.35.76.20    266
      10.35.76.20  255.255.255.255   Kapcsolaton bel?li       10.35.76.20    266
     10.35.76.255  255.255.255.255   Kapcsolaton bel?li       10.35.76.20    266
       10.219.0.0      255.255.0.0      10.219.35.8      10.219.35.7     21
      10.219.35.7  255.255.255.255   Kapcsolaton bel?li       10.219.35.7    276
      10.219.40.0    255.255.255.0         46.0.0.1      10.219.35.7     21
       46.107.8.0    255.255.255.0         46.0.0.1      10.219.35.7     21
        127.0.0.0        255.0.0.0   Kapcsolaton bel?li         127.0.0.1    306
        127.0.0.1  255.255.255.255   Kapcsolaton bel?li         127.0.0.1    306
  127.255.255.255  255.255.255.255   Kapcsolaton bel?li         127.0.0.1    306
       172.18.2.7  255.255.255.255      10.219.35.8      10.219.35.7     21
    172.19.230.44  255.255.255.255      10.219.35.8      10.219.35.7     21
       172.25.0.0      255.255.0.0         46.0.0.1      10.219.35.7     21
     195.228.84.1  255.255.255.255       10.35.76.1      10.35.76.20     11
===========================================================================
?lland? ?tvonalak:
  Nincs

From dwmw2 at infradead.org  Tue Apr 28 00:44:45 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 28 Apr 2015 08:44:45 +0100
Subject: Fwd: openconnect v7.06 for Windows issue
In-Reply-To: <CABAPnR7RaeAErqRNBuGDgqqa0B2J720wiGQ55RW5yfrr7wZq8g@mail.gmail.com>
References: <CABAPnR4q_e+8qD_vL4WWLB-ejfANNnoK+HDYMiTOKAKoE=j3KQ@mail.gmail.com>
 <CABAPnR7RaeAErqRNBuGDgqqa0B2J720wiGQ55RW5yfrr7wZq8g@mail.gmail.com>
Message-ID: <1430207085.1291.3.camel@infradead.org>

On Tue, 2015-04-28 at 09:32 +0200, Horv?th Szabolcs wrote:
> ,
> 
> I have an issue connecting to one of our partner with openconnect.
> Symptoms are the following:
> - we can build a VPN with Openconnect on Linux to our partner and it
> is working fine (traffic is passing through as expected)
> - we can build a VPN with Cisco Anyconnect on Windows to our partner
> - we CANNOT build a VPN with Openconnect on Windows to our partner
> (technically, VPN is built but traffic is not passing through, 
> details
> below)
> - we CAN build VPN with OpenConnect on Windows to other partners
> 
> From all of these, I would say there is nothing wrong with the 
> partner
> VPN (because connecting to it from windows/anyconnect and
> linux/openconnect combination are working fine).
> 
> After days of investigation I found out that there are no ARP replies
> on the tun interface when connecting from openconnect/windows.

I can't look hard at this for another few hours at least, and I have a
2-year-old trying to "help" me type this.... first thought is to look
at the netmasks.

The whole ARP thing is a fiction because Windows doesn't do tunnel
devices properly; it makes us pretend to be Ethernet. So we have to
*fake* ARP in the driver for Legacy IP (and ND for IPv6).

We tell the driver the IP address of the faked "router" on the subnet,
and it fakes ARP replies from that IP address. This falls over when
the netmask is 255.255.255.255 though, or something like that...

-- 
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/20150428/ec7bb871/attachment.bin>

From iceberg.1369 at gmail.com  Tue Apr 28 05:23:32 2015
From: iceberg.1369 at gmail.com (jafar habibi)
Date: Tue, 28 Apr 2015 16:53:32 +0430
Subject: ocserv did not send stop accounting once user disconnected
Message-ID: <CANVGr0ZsPD_v6wvTzJd_pa7yxnQnSfFw5KtCAo-hFxZ4VoxZtA@mail.gmail.com>

I have installed ocserv 0.10.4
I can successfully authenticate against radius server. and accounting
interim updates works well. but once user get disconnected ocserv
dosn't send stop accounting to radius server and hence radius server
treats it as a stale session.
actually ocserv send stop session (stop accounting) after long delay
after user gets disconnected and this makes a huge problem when
simultaneous-us attribute is used in radius server cause user will not
be able to login again until stop session packet is sent to radius
server.
so question is that how we can send stop accounting to radius server
once user disconnected?


[Client disconnected]
Apr 28 03:18:12 debian ocserv[30293]: worker[test]: 5.*.*.*
worker-vpn.c:986: GnuTLS error (at worker-vpn.c:986): The TLS
connection was non-properly terminated.
Apr 28 03:18:12 debian ocserv[29304]: radius-auth: sending session
interim update
Apr 28 03:18:12 debian ocserv[29303]: main[test]: 5.*.*.*:10340 user
disconnected
Apr 28 03:18:12 debian ocserv[29304]: sec-mod: temporarily closing
session for test (session: HUJ9R)


[stop session sent by ocserv to radius server]
Apr 28 03:22:32 debian ocserv[29304]: radius-auth: closing session


From n.mavrogiannopoulos at gmail.com  Tue Apr 28 07:05:25 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 28 Apr 2015 16:05:25 +0200
Subject: ocserv did not send stop accounting once user disconnected
In-Reply-To: <CANVGr0ZsPD_v6wvTzJd_pa7yxnQnSfFw5KtCAo-hFxZ4VoxZtA@mail.gmail.com>
References: <CANVGr0ZsPD_v6wvTzJd_pa7yxnQnSfFw5KtCAo-hFxZ4VoxZtA@mail.gmail.com>
Message-ID: <CAJU7za+WBbkAyK8RQtenD81pci05pnSE4eLE7OxpcaGNVg5_3w@mail.gmail.com>

On Tue, Apr 28, 2015 at 2:23 PM, jafar habibi <iceberg.1369 at gmail.com> wrote:
> I have installed ocserv 0.10.4
> I can successfully authenticate against radius server. and accounting
> interim updates works well. but once user get disconnected ocserv
> dosn't send stop accounting to radius server and hence radius server
> treats it as a stale session.
> actually ocserv send stop session (stop accounting) after long delay
> after user gets disconnected and this makes a huge problem when
> simultaneous-us attribute is used in radius server cause user will not
> be able to login again until stop session packet is sent to radius
> server.
> so question is that how we can send stop accounting to radius server
> once user disconnected?

ocserv will send updates to radius every 5 minutes. That's why you see a delay.
Currently there is no way to modify that period except editing src/sec-mod.c and
modify MAINTAINANCE_TIME.

Said that, that behavior could be improved. Currently there are two types of
disconnection. Explicit user termination, and termination due to network (e.g.,
the mobile user turned off wireless). In the first case the disconnection of the
user is complete and the radius server will be notified on the next update.
However, in the second case, the connection is put in some "limbo" state and
the user can still reconnect using the cookie. On that state the
radius server will
not be notified, until that cookie expires.

So ocserv could be modified to immediately send the disconnection requests for
the first scenario, but there is no apparent fix for the "temporary"
disconnects, and
you'll have to cope with them anyway. So if that is acceptable, and
you'll be willing
to test I could modify ocserv in git to send user termination requests as soon.

regards,
Nikos


From peter.brant at gmail.com  Tue Apr 28 09:52:52 2015
From: peter.brant at gmail.com (Peter Brant)
Date: Tue, 28 Apr 2015 18:52:52 +0200
Subject: Slow connections (something other than packet fragmentation?)
In-Reply-To: <1430173662.23874.3.camel@infradead.org>
References: <CAFA7iJKRTK=34pXbzuoPrQ=vF2Lc=XqoShiWuRBQy_UkJsgo5A@mail.gmail.com>
 <1430169236.6377.35.camel@infradead.org>
 <CAFA7iJ+bh-cEsgDdZ+uFbUZBZqv+ByWhQoMkOnvTti_Ui1ukeA@mail.gmail.com>
 <1430173662.23874.3.camel@infradead.org>
Message-ID: <CAFA7iJK98WYisrtKGimzMCzqVhddO-73gd8CQGK-8Y5LE4uSAQ@mail.gmail.com>

On Tue, Apr 28, 2015 at 12:27 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2015-04-28 at 00:14 +0200, Peter Brant wrote:
>> >
>> Ah, I didn't know that the performance overhead of using TCP was that severe.
>
> Usually it shouldn't be. But if you have a lossy path, it's going to
> hurt a lot. It's best to eliminate it first.
>
Just a short follow-up to report that in my particular case, the
performance overhead of using TCP was indeed that severe.

The upstream firewall at my workplace is now passing DTLS traffic and
I'm happy to report that I was able scp a large (170MB) tgz file down
from an internal server with an average transfer rate (over four
transfers) of 3.7 MB/s as compared with about 100 KB/s yesterday. As
another point of comparison, the network admins were able to revive
the previous IPsec VPN too. Average transfer speed there with the same
test was 2.4 MB/s.

In short, I'm converted. Thanks again for the help.

Peter


From nmav at gnutls.org  Tue Apr 28 12:35:30 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 28 Apr 2015 21:35:30 +0200
Subject: Slow connections (something other than packet fragmentation?)
In-Reply-To: <CAFA7iJK98WYisrtKGimzMCzqVhddO-73gd8CQGK-8Y5LE4uSAQ@mail.gmail.com>
References: <CAFA7iJKRTK=34pXbzuoPrQ=vF2Lc=XqoShiWuRBQy_UkJsgo5A@mail.gmail.com>
 <1430169236.6377.35.camel@infradead.org>
 <CAFA7iJ+bh-cEsgDdZ+uFbUZBZqv+ByWhQoMkOnvTti_Ui1ukeA@mail.gmail.com>
 <1430173662.23874.3.camel@infradead.org>
 <CAFA7iJK98WYisrtKGimzMCzqVhddO-73gd8CQGK-8Y5LE4uSAQ@mail.gmail.com>
Message-ID: <1430249730.1717.3.camel@gnutls.org>

On Tue, 2015-04-28 at 18:52 +0200, Peter Brant wrote:
> On Tue, Apr 28, 2015 at 12:27 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > On Tue, 2015-04-28 at 00:14 +0200, Peter Brant wrote:
> >> >
> >> Ah, I didn't know that the performance overhead of using TCP was that severe.
> >
> > Usually it shouldn't be. But if you have a lossy path, it's going to
> > hurt a lot. It's best to eliminate it first.
> >
> Just a short follow-up to report that in my particular case, the
> performance overhead of using TCP was indeed that severe.
> The upstream firewall at my workplace is now passing DTLS traffic and
> I'm happy to report that I was able scp a large (170MB) tgz file down
> from an internal server with an average transfer rate (over four
> transfers) of 3.7 MB/s as compared with about 100 KB/s yesterday.

Interesting. On these speeds it also matters the ciphersuite in use.
Currently the fastest supported is AES-GCM and is supported by
openconnect only. Hopefully chacha20-poly1305 will also be added which
will allow higher speeds and less resources spent in server side.

regards,
Nikos




From ilvipero at dazuzu.com  Thu Apr 30 01:41:29 2015
From: ilvipero at dazuzu.com (Mauro Gaspari)
Date: Thu, 30 Apr 2015 16:41:29 +0800
Subject: ocserv installation on debian (arm)
Message-ID: <CAH_uthJtQxsMDW5Foa+fPeaKjWkoz57V_XDXHZ0gktfmHn2WMw@mail.gmail.com>

Hello


I recently found this project, and it looks very interesting. I have
been trying to install versions 0.10.2, 0.10.3, and 0.10.4 on a few
machines (and virtual machines) based on debian, ubuntu, and openSUSE.
So far, I had no issues on x86 or x86_64, but I was not able to
complete the "make" process on arm architecture (debian).
I have a couple of testing boards, banana pi bpi-r1 with bananian
installed (debian 7 arm).

1. First issue was with debian wheezy dependencies. wheezy backports
repository (deb http://http.debian.net/debian wheezy-backports main)
includes the needed package "libgnutls28-dev" for the x86 and x86_64
architectures, but not for armhf yet.
Since I am on testing phase, I quickly resolved changing my repos from
wheezy to testing. I am pretty sure this will be solved in the future,
just wanted to report that, hopefully it helps someone.

2. once all dependencies were installed, I tried to install ocserv by
running ./configure --prefix=/usr --sysconfdir=/etc && make && make
install

this works perfectly on x86 and x86_64, but fails on arm. I have all
required packages per README file. Since the output is very long, I
will only paste a few lines here.

Any help will be greatly appreciated.I am available to help for
further testing, troubleshooting. If needed I can connect one spare
device to a public IP and provide remote access for as long as it
takes.

Best Regards
Mauro


Begin Output from ./config && make && make install

...

CC       main-user.o

  CC       worker-misc.o

  CC       route-add.o

  CC       worker-privs.o

In file included from worker-privs.c:26:0:

worker-privs.c: In function ?disable_system_calls?:

worker-privs.c:41:46: error: ?__NR_time? undeclared (first use in this function)

  ret = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(name), __VA_ARGS__); \

                                              ^

worker-privs.c:54:2: note: in expansion of macro ?ADD_SYSCALL?

  ADD_SYSCALL(time, 0);

  ^

worker-privs.c:41:46: note: each undeclared identifier is reported
only once for each function it appears in

  ret = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(name), __VA_ARGS__); \

                                              ^

worker-privs.c:54:2: note: in expansion of macro ?ADD_SYSCALL?

  ADD_SYSCALL(time, 0);

  ^

worker-privs.c:41:46: error: ?__NR_alarm? undeclared (first use in
this function)

  ret = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(name), __VA_ARGS__); \

                                              ^

worker-privs.c:61:2: note: in expansion of macro ?ADD_SYSCALL?

  ADD_SYSCALL(alarm, 0);

  ^

worker-privs.c:41:46: error: ?__NR_select? undeclared (first use in
this function)

  ret = seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(name), __VA_ARGS__); \

                                              ^

worker-privs.c:89:2: note: in expansion of macro ?ADD_SYSCALL?

  ADD_SYSCALL(select, 0);

  ^

Makefile:1459: recipe for target 'worker-privs.o' failed

make[4]: *** [worker-privs.o] Error 1

make[4]: Leaving directory '/usr/src/ocserv-0.10.4/src'

Makefile:1481: recipe for target 'all-recursive' failed

make[3]: *** [all-recursive] Error 1

make[3]: Leaving directory '/usr/src/ocserv-0.10.4/src'

Makefile:1143: recipe for target 'all' failed

make[2]: *** [all] Error 2

make[2]: Leaving directory '/usr/src/ocserv-0.10.4/src'

Makefile:1000: recipe for target 'all-recursive' failed

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory '/usr/src/ocserv-0.10.4'

Makefile:940: recipe for target 'all' failed

make: *** [all] Error 2


From n.mavrogiannopoulos at gmail.com  Thu Apr 30 02:19:00 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 30 Apr 2015 11:19:00 +0200
Subject: ocserv installation on debian (arm)
In-Reply-To: <CAH_uthJtQxsMDW5Foa+fPeaKjWkoz57V_XDXHZ0gktfmHn2WMw@mail.gmail.com>
References: <CAH_uthJtQxsMDW5Foa+fPeaKjWkoz57V_XDXHZ0gktfmHn2WMw@mail.gmail.com>
Message-ID: <CAJU7za+3yJ6hyu4V7Si6jCWej3anjOY=B7OHBd3h-4EviyoExw@mail.gmail.com>

On Thu, Apr 30, 2015 at 10:41 AM, Mauro Gaspari <ilvipero at dazuzu.com> wrote:
> Hello
> I recently found this project, and it looks very interesting. I have
> been trying to install versions 0.10.2, 0.10.3, and 0.10.4 on a few
> machines (and virtual machines) based on debian, ubuntu, and openSUSE.
> So far, I had no issues on x86 or x86_64, but I was not able to
> complete the "make" process on arm architecture (debian).
> I have a couple of testing boards, banana pi bpi-r1 with bananian
> installed (debian 7 arm).
> 1. First issue was with debian wheezy dependencies. wheezy backports
> repository (deb http://http.debian.net/debian wheezy-backports main)
> includes the needed package "libgnutls28-dev" for the x86 and x86_64
> architectures, but not for armhf yet.
> Since I am on testing phase, I quickly resolved changing my repos from
> wheezy to testing. I am pretty sure this will be solved in the future,
> just wanted to report that, hopefully it helps someone.
> 2. once all dependencies were installed, I tried to install ocserv by
> running ./configure --prefix=/usr --sysconfdir=/etc && make && make
> install
> this works perfectly on x86 and x86_64, but fails on arm. I have all
> required packages per README file. Since the output is very long, I
> will only paste a few lines here.
> Any help will be greatly appreciated.I am available to help for
> further testing, troubleshooting. If needed I can connect one spare
> device to a public IP and provide remote access for as long as it
> takes.

For non-x86/x86-64 systems it matters to have the latest libseccomp.
If you have it and you still see that issue, most probably your
platform isn't supported by seccomp. You'll have to use
"--disable-seccomp" with configure.

regards,
Nikos


