From younes.m at gmail.com  Tue Sep  1 13:04:20 2015
From: younes.m at gmail.com (Younes Manton)
Date: Tue, 1 Sep 2015 16:04:20 -0400
Subject: Intermittent xfreerdp hang only through VPN
Message-ID: <CAMVNhxQuGNRmC0cC4otQcvnJrDqQN7vhY=uCvrTRpZ4RAg1PAQ@mail.gmail.com>

Hi,

I've had this problem for at least a couple of years. Whenever I
connect to a Windows machine via xfreerdp over my work place VPN the
xfreerdp client inevitably hangs. Occassionally SSH sessions will also
hang, but this happens much less often. I never see either problem
when not connected over VPN.

I normally run OpenConnect via Network Manager, but I recently ran it
on the command line with -v to watch the output. As best as I can tell
the hangs always follow a CSTP rekey and the only thing that's
different from the usual is that these lines begin to appear:

Send CSTP Keepalive
Send CSTP DPD
Got CSTP DPD response

They seem to stop being emitted once I kill the unresponsive xfreerdp client.

On the Windows side I see the following in the Event Viewer every time
xfreerdp hangs:

The Terminal Server security layer detected an error in the protocol
stream and has disconnected the client. Client IP: <my IP>.

Anything I can do to debug this?


From stu at spacehopper.org  Tue Sep  1 16:00:06 2015
From: stu at spacehopper.org (Stuart Henderson)
Date: Wed, 2 Sep 2015 00:00:06 +0100
Subject: Intermittent xfreerdp hang only through VPN
In-Reply-To: <CAMVNhxQuGNRmC0cC4otQcvnJrDqQN7vhY=uCvrTRpZ4RAg1PAQ@mail.gmail.com>
References: <CAMVNhxQuGNRmC0cC4otQcvnJrDqQN7vhY=uCvrTRpZ4RAg1PAQ@mail.gmail.com>
Message-ID: <20150901230006.GJ22401@symphytum.spacehopper.org>

On 2015/09/01 16:04, Younes Manton wrote:
> Hi,
> 
> I've had this problem for at least a couple of years. Whenever I
> connect to a Windows machine via xfreerdp over my work place VPN the
> xfreerdp client inevitably hangs. Occassionally SSH sessions will also
> hang, but this happens much less often. I never see either problem
> when not connected over VPN.
> 
> I normally run OpenConnect via Network Manager, but I recently ran it
> on the command line with -v to watch the output. As best as I can tell
> the hangs always follow a CSTP rekey and the only thing that's
> different from the usual is that these lines begin to appear:
> 
> Send CSTP Keepalive
> Send CSTP DPD
> Got CSTP DPD response
> 
> They seem to stop being emitted once I kill the unresponsive xfreerdp client.
> 
> On the Windows side I see the following in the Event Viewer every time
> xfreerdp hangs:
> 
> The Terminal Server security layer detected an error in the protocol
> stream and has disconnected the client. Client IP: <my IP>.
> 
> Anything I can do to debug this?

Try reducing the mtu requested (openconnect's -m flag).



From younes.m at gmail.com  Tue Sep  1 22:46:52 2015
From: younes.m at gmail.com (Younes Manton)
Date: Wed, 2 Sep 2015 01:46:52 -0400
Subject: Intermittent xfreerdp hang only through VPN
In-Reply-To: <20150901230006.GJ22401@symphytum.spacehopper.org>
References: <CAMVNhxQuGNRmC0cC4otQcvnJrDqQN7vhY=uCvrTRpZ4RAg1PAQ@mail.gmail.com>
 <20150901230006.GJ22401@symphytum.spacehopper.org>
Message-ID: <CAMVNhxQKzXeS1iHo2+GUsRG4-ajGt1aBZ+J2oGmj8tTG=9bAZA@mail.gmail.com>

On Tue, Sep 1, 2015 at 7:00 PM, Stuart Henderson <stu at spacehopper.org> wrote:
> On 2015/09/01 16:04, Younes Manton wrote:
>> Hi,
>>
>> I've had this problem for at least a couple of years. Whenever I
>> connect to a Windows machine via xfreerdp over my work place VPN the
>> xfreerdp client inevitably hangs. Occassionally SSH sessions will also
>> hang, but this happens much less often. I never see either problem
>> when not connected over VPN.
>>
>> I normally run OpenConnect via Network Manager, but I recently ran it
>> on the command line with -v to watch the output. As best as I can tell
>> the hangs always follow a CSTP rekey and the only thing that's
>> different from the usual is that these lines begin to appear:
>>
>> Send CSTP Keepalive
>> Send CSTP DPD
>> Got CSTP DPD response
>>
>> They seem to stop being emitted once I kill the unresponsive xfreerdp client.
>>
>> On the Windows side I see the following in the Event Viewer every time
>> xfreerdp hangs:
>>
>> The Terminal Server security layer detected an error in the protocol
>> stream and has disconnected the client. Client IP: <my IP>.
>>
>> Anything I can do to debug this?
>
> Try reducing the mtu requested (openconnect's -m flag).
>

Thanks. Seems like the server doesn't allow anything outside of
1280-1300, the values I pass to -m are clamped to that range. Neither
helps my problem.


From nmav at gnutls.org  Fri Sep  4 12:35:37 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 04 Sep 2015 21:35:37 +0200
Subject: ocserv 0.10.8
Message-ID: <1441395337.1788.1.camel@gnutls.org>

Hello,
  I've just released ocserv 0.10.8. This is a minor feature enhancement
release in the 0.10.x branch.

* Version 0.10.8 (released 2015-09-04)
- Pass the proxy protocol information at earlier stage to main process,
  to allow the correct information to be passed at the connect script
  and occtl. Reported by Niels Peen.
- Added the IP_REAL_LOCAL environment variable to scripts. This passes
  the local IP the client connected to.
- The PAM accounting method was dropped as there was no practical
  usage of it, the way it was implemented.
- When assigning IPv6 addresses use the whole available netmask.
- occtl: Print the local IP the client connected to, with the client
  information.
- occtl: Print the configured for the client split-dns domains.


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

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

regards,
Nikos


From zpljd258 at hotmail.com  Fri Sep  4 18:56:37 2015
From: zpljd258 at hotmail.com (=?gb2312?B?way+/bXP?=)
Date: Sat, 5 Sep 2015 09:56:37 +0800
Subject: ocserv can support anyconnect's app rules?
Message-ID: <SNT147-W77968E4C76682B109E65A998560@phx.gbl>

hello!

Many thanks for your program. It is very helpful to protect my privacy in China

but now,Cisco IOS client have a new app rules. Unfortunately I do not seem to see the relevant configuration in ocserv.I was wondering if I missed what information?

It may be useful, you know, the Chinese government blocked a large number of sites, including the APP. If we can use the app rules than easier routing table

wait for your reply!Thank you for your work again!

Best

JunD Lian 		 	   		  

From n.mavrogiannopoulos at gmail.com  Sat Sep  5 05:01:19 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 05 Sep 2015 14:01:19 +0200
Subject: ocserv can support anyconnect's app rules?
In-Reply-To: <SNT147-W77968E4C76682B109E65A998560@phx.gbl>
References: <SNT147-W77968E4C76682B109E65A998560@phx.gbl>
Message-ID: <1441454479.17138.1.camel@gmail.com>

On Sat, 2015-09-05 at 09:56 +0800, ??? wrote:
> hello!
> 
> but now,Cisco IOS client have a new app rules. Unfortunately I do not 
> seem to see the relevant configuration in ocserv.I was wondering if I 
> missed what information?

Hello,
 I am not sure what do you mean about new app rules. What does the
client output when you connect to ocserv, and what is the output you
see with ocserv -f -d 99 when you connect with that client?

regards,
Nikos




From cattyhouse at gmail.com  Sat Sep  5 05:07:40 2015
From: cattyhouse at gmail.com (Justin)
Date: Sat, 5 Sep 2015 20:07:40 +0800
Subject: ocserv can support anyconnect's app rules?
In-Reply-To: <1441454479.17138.1.camel@gmail.com>
References: <SNT147-W77968E4C76682B109E65A998560@phx.gbl>
 <1441454479.17138.1.camel@gmail.com>
Message-ID: <CAKzEKseMzSMkoB5Z+99fKqzTLq8sawCGMUF61UpEeDPiP0=aWA@mail.gmail.com>

Hello Nikos

I think he/she meant the new feature of AnyConnect 4.0 for iOS, the
Per App VPN, on the changelog, it says it requires a Cisco AnyConnect
Server/Device. If AnyConnect for iOS connects to the server built by
Ocserv, user is not able to use the feature,  the Per App VPN in
AnyConnect's menu is empty, user can not choose any of the apps
installed on iOS.

On Saturday, September 5, 2015, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
>
> On Sat, 2015-09-05 at 09:56 +0800, ??? wrote:
> > hello!
> >
> > but now,Cisco IOS client have a new app rules. Unfortunately I do not
> > seem to see the relevant configuration in ocserv.I was wondering if I
> > missed what information?
>
> Hello,
>  I am not sure what do you mean about new app rules. What does the
> client output when you connect to ocserv, and what is the output you
> see with ocserv -f -d 99 when you connect with that client?
>
> regards,
> Nikos
>
>
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From n.mavrogiannopoulos at gmail.com  Sat Sep  5 05:25:53 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 05 Sep 2015 14:25:53 +0200
Subject: ocserv can support anyconnect's app rules?
In-Reply-To: <CAKzEKseMzSMkoB5Z+99fKqzTLq8sawCGMUF61UpEeDPiP0=aWA@mail.gmail.com>
References: <SNT147-W77968E4C76682B109E65A998560@phx.gbl>
 <1441454479.17138.1.camel@gmail.com>
 <CAKzEKseMzSMkoB5Z+99fKqzTLq8sawCGMUF61UpEeDPiP0=aWA@mail.gmail.com>
Message-ID: <1441455953.17696.0.camel@gmail.com>

On Sat, 2015-09-05 at 20:07 +0800, Justin wrote:
> Hello Nikos
> 
> I think he/she meant the new feature of AnyConnect 4.0 for iOS, the
> Per App VPN, on the changelog, it says it requires a Cisco AnyConnect
> Server/Device. If AnyConnect for iOS connects to the server built by
> Ocserv, user is not able to use the feature,  the Per App VPN in
> AnyConnect's menu is empty, user can not choose any of the apps
> installed on iOS.

Most likely we need an iOS version of openconnect. Anyone to kickstart
it?







From alexsu1113 at icloud.com  Tue Sep  8 14:43:17 2015
From: alexsu1113 at icloud.com (Antairez)
Date: Tue, 08 Sep 2015 17:43:17 -0400
Subject: Captive Portal Detection when using Cisco AnyConnect
Message-ID: <80EBEB99-F1D0-4027-9640-5D7078F8FA8B@icloud.com>

Server is running the latest server software 0.10.8, all certificates have been verified to be installed correctly, authentication method is radius.

On my Mac machine, both running AnyConnect 3.0 and 3.1 yield the same result in console after network interface has changed (restart WiFi switch or waking up laptop from sleep):

9/8/15 5:21:31.020 PM UserEventAgent[40]: Captive: CNPluginHandler en0: Inactive
9/8/15 5:21:36.576 PM UserEventAgent[40]: Captive: [CNInfoNetworkActive:1709] en0: SSID 'Cheng 5Ghz' making interface primary (cache indicates network not captive)
9/8/15 5:21:36.577 PM UserEventAgent[40]: Captive: CNPluginHandler en0: Evaluating
9/8/15 5:21:36.596 PM UserEventAgent[40]: Captive: en0: Not probing 'Cheng 5Ghz' (cache indicates not captive)
9/8/15 5:21:36.598 PM UserEventAgent[40]: Captive: CNPluginHandler en0: Authenticated
9/8/15 5:21:41.375 PM acvpnagent[42779]: Function: TestNetEnv File: NetEnvironment.cpp Line: 334 Captive portal detected. Retesting connectivity to the secure gateway in 10 seconds.
9/8/15 5:21:41.375 PM acvpnagent[42779]: Current network state: Captive portal detected

Have tried both including and excluding profile.xml on client connection to no avail. Playing with settings inside numerous times yield no results as well.

Both 3.0 and 3.1 clients produce the following message on GUI: ?Web authentication required?, but 3.0 will continue the login process while 3.1 will reject user from any further login attempts.

As far as I can see ocserv seems to only support AnyConnect 3.0 at this moment, I guess this is Cisco?s way of stopping user from using their products if they are not licensed and ripped off? Will ocserv support the new clients anytime soon?

Same rules apply to Windows machine. 3.0 Ok 3.1 No go.

From cattyhouse at gmail.com  Tue Sep  8 16:53:46 2015
From: cattyhouse at gmail.com (Justin)
Date: Wed, 9 Sep 2015 07:53:46 +0800
Subject: Captive Portal Detection when using Cisco AnyConnect
In-Reply-To: <80EBEB99-F1D0-4027-9640-5D7078F8FA8B@icloud.com>
References: <80EBEB99-F1D0-4027-9640-5D7078F8FA8B@icloud.com>
Message-ID: <CAKzEKscOpgx72jX_LHUrEZdjYMKKHZHKYALa5Fe3QxL2yvpm7A@mail.gmail.com>

Hello Antairez

I'm also a Mac user, there is Anyconnect 4.1 for Mac now, if you would
like to upgrade to the latest version.

As for me, I don't use AnyConnect client anymore, because it is not as
good as OpenConnect Client. If you have installed Homebrew on your
Mac, you can just "brew install openconnect". it works much better
than Anyconnect, it has only a command line interface, but you can
create a Launch Daemon for it so that It can keep alive in the
background and automatically reconnect on network change, also you can
add your own routes to the script included, I've been using it for 2
weeks, works just perfect. I'd recommend to give openconnect client a
try, if you have issues, then I may help with my experiences.


Regards
Justin He


On Wed, Sep 9, 2015 at 5:43 AM, Antairez <alexsu1113 at icloud.com> wrote:
> Server is running the latest server software 0.10.8, all certificates have been verified to be installed correctly, authentication method is radius.
>
> On my Mac machine, both running AnyConnect 3.0 and 3.1 yield the same result in console after network interface has changed (restart WiFi switch or waking up laptop from sleep):
>
> 9/8/15 5:21:31.020 PM UserEventAgent[40]: Captive: CNPluginHandler en0: Inactive
> 9/8/15 5:21:36.576 PM UserEventAgent[40]: Captive: [CNInfoNetworkActive:1709] en0: SSID 'Cheng 5Ghz' making interface primary (cache indicates network not captive)
> 9/8/15 5:21:36.577 PM UserEventAgent[40]: Captive: CNPluginHandler en0: Evaluating
> 9/8/15 5:21:36.596 PM UserEventAgent[40]: Captive: en0: Not probing 'Cheng 5Ghz' (cache indicates not captive)
> 9/8/15 5:21:36.598 PM UserEventAgent[40]: Captive: CNPluginHandler en0: Authenticated
> 9/8/15 5:21:41.375 PM acvpnagent[42779]: Function: TestNetEnv File: NetEnvironment.cpp Line: 334 Captive portal detected. Retesting connectivity to the secure gateway in 10 seconds.
> 9/8/15 5:21:41.375 PM acvpnagent[42779]: Current network state: Captive portal detected
>
> Have tried both including and excluding profile.xml on client connection to no avail. Playing with settings inside numerous times yield no results as well.
>
> Both 3.0 and 3.1 clients produce the following message on GUI: ?Web authentication required?, but 3.0 will continue the login process while 3.1 will reject user from any further login attempts.
>
> As far as I can see ocserv seems to only support AnyConnect 3.0 at this moment, I guess this is Cisco?s way of stopping user from using their products if they are not licensed and ripped off? Will ocserv support the new clients anytime soon?
>
> Same rules apply to Windows machine. 3.0 Ok 3.1 No go.
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From younes.m at gmail.com  Wed Sep  9 21:36:57 2015
From: younes.m at gmail.com (Younes Manton)
Date: Thu, 10 Sep 2015 00:36:57 -0400
Subject: Intermittent xfreerdp hang only through VPN
In-Reply-To: <CAMVNhxQKzXeS1iHo2+GUsRG4-ajGt1aBZ+J2oGmj8tTG=9bAZA@mail.gmail.com>
References: <CAMVNhxQuGNRmC0cC4otQcvnJrDqQN7vhY=uCvrTRpZ4RAg1PAQ@mail.gmail.com>
 <20150901230006.GJ22401@symphytum.spacehopper.org>
 <CAMVNhxQKzXeS1iHo2+GUsRG4-ajGt1aBZ+J2oGmj8tTG=9bAZA@mail.gmail.com>
Message-ID: <CAMVNhxQhAAfwwpCY36uBhY8Zb1QU34Bm2LLBVLmoY+_MVq6fOQ@mail.gmail.com>

On Wed, Sep 2, 2015 at 1:46 AM, Younes Manton <younes.m at gmail.com> wrote:
> On Tue, Sep 1, 2015 at 7:00 PM, Stuart Henderson <stu at spacehopper.org> wrote:
>> On 2015/09/01 16:04, Younes Manton wrote:
>>> Hi,
>>>
>>> I've had this problem for at least a couple of years. Whenever I
>>> connect to a Windows machine via xfreerdp over my work place VPN the
>>> xfreerdp client inevitably hangs. Occassionally SSH sessions will also
>>> hang, but this happens much less often. I never see either problem
>>> when not connected over VPN.
>>>
>>> I normally run OpenConnect via Network Manager, but I recently ran it
>>> on the command line with -v to watch the output. As best as I can tell
>>> the hangs always follow a CSTP rekey and the only thing that's
>>> different from the usual is that these lines begin to appear:
>>>
>>> Send CSTP Keepalive
>>> Send CSTP DPD
>>> Got CSTP DPD response
>>>
>>> They seem to stop being emitted once I kill the unresponsive xfreerdp client.
>>>
>>> On the Windows side I see the following in the Event Viewer every time
>>> xfreerdp hangs:
>>>
>>> The Terminal Server security layer detected an error in the protocol
>>> stream and has disconnected the client. Client IP: <my IP>.
>>>
>>> Anything I can do to debug this?
>>
>> Try reducing the mtu requested (openconnect's -m flag).
>>
>
> Thanks. Seems like the server doesn't allow anything outside of
> 1280-1300, the values I pass to -m are clamped to that range. Neither
> helps my problem.

So I tried using ifconfig to change the MTU on the vpn interface
rather than relying on openconnect; lowered to 1100, but that didn't
help. Is there anything else I can do to debug this?


From cattyhouse at gmail.com  Thu Sep 10 00:43:08 2015
From: cattyhouse at gmail.com (Justin)
Date: Thu, 10 Sep 2015 15:43:08 +0800
Subject: Intermittent xfreerdp hang only through VPN
In-Reply-To: <CAMVNhxQhAAfwwpCY36uBhY8Zb1QU34Bm2LLBVLmoY+_MVq6fOQ@mail.gmail.com>
References: <CAMVNhxQuGNRmC0cC4otQcvnJrDqQN7vhY=uCvrTRpZ4RAg1PAQ@mail.gmail.com>
 <20150901230006.GJ22401@symphytum.spacehopper.org>
 <CAMVNhxQKzXeS1iHo2+GUsRG4-ajGt1aBZ+J2oGmj8tTG=9bAZA@mail.gmail.com>
 <CAMVNhxQhAAfwwpCY36uBhY8Zb1QU34Bm2LLBVLmoY+_MVq6fOQ@mail.gmail.com>
Message-ID: <CAKzEKsczwJEAT--y15MVThOK6hPh4K5tEXu9hptFRQbND1xuuQ@mail.gmail.com>

According to your description, you have the following machines, can
you let us know the ip address of those machines?

1. the machine that have openconnect client installed.
2. the machine that have openconnect server installed.
3. the Windows machine
4. the machine that you intent to ssh into
5. the machine that you start the ssh session.

I GUESS it is a routing problem.


Regards
Justin He


On Thu, Sep 10, 2015 at 12:36 PM, Younes Manton <younes.m at gmail.com> wrote:
> On Wed, Sep 2, 2015 at 1:46 AM, Younes Manton <younes.m at gmail.com> wrote:
>> On Tue, Sep 1, 2015 at 7:00 PM, Stuart Henderson <stu at spacehopper.org> wrote:
>>> On 2015/09/01 16:04, Younes Manton wrote:
>>>> Hi,
>>>>
>>>> I've had this problem for at least a couple of years. Whenever I
>>>> connect to a Windows machine via xfreerdp over my work place VPN the
>>>> xfreerdp client inevitably hangs. Occassionally SSH sessions will also
>>>> hang, but this happens much less often. I never see either problem
>>>> when not connected over VPN.
>>>>
>>>> I normally run OpenConnect via Network Manager, but I recently ran it
>>>> on the command line with -v to watch the output. As best as I can tell
>>>> the hangs always follow a CSTP rekey and the only thing that's
>>>> different from the usual is that these lines begin to appear:
>>>>
>>>> Send CSTP Keepalive
>>>> Send CSTP DPD
>>>> Got CSTP DPD response
>>>>
>>>> They seem to stop being emitted once I kill the unresponsive xfreerdp client.
>>>>
>>>> On the Windows side I see the following in the Event Viewer every time
>>>> xfreerdp hangs:
>>>>
>>>> The Terminal Server security layer detected an error in the protocol
>>>> stream and has disconnected the client. Client IP: <my IP>.
>>>>
>>>> Anything I can do to debug this?
>>>
>>> Try reducing the mtu requested (openconnect's -m flag).
>>>
>>
>> Thanks. Seems like the server doesn't allow anything outside of
>> 1280-1300, the values I pass to -m are clamped to that range. Neither
>> helps my problem.
>
> So I tried using ifconfig to change the MTU on the vpn interface
> rather than relying on openconnect; lowered to 1100, but that didn't
> help. Is there anything else I can do to debug this?
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From tom.lippincott at gmail.com  Fri Sep 11 07:06:57 2015
From: tom.lippincott at gmail.com (Thomas Lippincott)
Date: Fri, 11 Sep 2015 10:06:57 -0400
Subject: issue with a (possibly idiosyncratic) Juniper server
Message-ID: <55F2E001.7000902@gmail.com>

Hello,
I'm in the unenviable position of needing to connect to a university VPN 
from a linux laptop, and it appears that there is a barrier where one 
needs to log in via a university page before proceeding to the actual 
VPN log in (at least, that's what I gather from the output, I've 
included the redacted output below).  I was wondering if this is 
something that has come up before and has a known solution/workaround, 
or what the best way to proceed.  Thanks!
-Tom

root at laptop:/home/tom# openconnect --juniper https://JUNIPER.SCHOOL.edu 
--no-cert-check
WARNING: Juniper Network Connect support is experimental.
It will probably be superseded by Junos Pulse support.
GET https://JUNIPER.SCHOOL.edu/
Attempting to connect to server SERVER:443
SSL negotiation with JUNIPER.SCHOOL.edu
Connected to HTTPS on JUNIPER.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Found
GET https://JUNIPER.SCHOOL.edu/dana-na/auth/url_default/welcome.cgi
SSL negotiation with JUNIPER.SCHOOL.edu
Connected to HTTPS on JUNIPER.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Moved
GET https://JUNIPER.SCHOOL.edu/dana-na/auth/url_default/login.cgi?realm=ECG
SSL negotiation with JUNIPER.SCHOOL.edu
Connected to HTTPS on JUNIPER.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Moved
GET 
https://shibboleth.SCHOOL.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=rZJdb4MgFIb%2FiuFeUaPtJNWlW7OsyT6a1uxiNwsCrXQUGAf38e%2Bndsm6m17t%0AmvccnueFGdCDsmTe%2BVavxVsnwAefB6WBjAcl6pwmhoIEoulBAPGMbOb3dySN%0AYmKd8YYZhYJFPyc19dLoErXeWyAYQyubxijh22jfRoJ3WHKL%2B6GtVAIPW1K8%0AFlw6wTzebB5RcGMcEyNLiWIULBcleqGTfBrH22LCOGVZXjQZb4pps2UXcZbF%0Ak6aPAXRiqcFT7UuUxkkexkWYJHWSkiwn6fQZBasf1CupudS7817NMQTktq5X%0A4epxU48L3iUX7qFP%2FyruW9spENHetBpaY1%2BlhtGUU01DTTHtZfBQZSg0t0Zq%0AH7GdvLQl2AwFT8LBWFl%2FK6pmQ46MNu7kEc6zUgDhht5R9S9QM3xCcUSyZJBe%0ALlZGSfYVzJUyH9dOUN8XkSBcHUf%2BfqLqGw%3D%3D%0A&RelayState=https%3A%2F%2FJUNIPER.SCHOOL.edu&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=12zan5Nnnk4gOdoVBoL3Y5bTaWo1FmIsgEcwY0ufKI5FjEQHVNVdCXz9RxnmXLNIp6To4dofu4PVxpCxAAGdWvenUuWPwW7XxcTt0xWYxSfACtxdu9yU5X6UQedAAlwedcfIsfZvjlRBSVeoT1bdYvWYDtzjARyLEne76KpEW7PyIYAwSPm8%2F%2FLV7i5NfbVC6oh15u%2BCIsdq1DJoOR51nLM6WIsvEZNg8Mt4TXKgoUyhy7kJNqlYb3%2BOfH6yzfQJlE12yMXNOd%2BounmYHetG2NhKarH%2BWVuW4WmKbppKBNs%2F4snz%2FS6672tj5KIxI0RZeQIHeHmRDKNV6r1Qz36gAQ%3D%3D
Attempting to connect to server SERVER:443
SSL negotiation with shibboleth.SCHOOL.edu
Connected to HTTPS on shibboleth.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Found
GET https://shibboleth.SCHOOL.edu/idp/AuthnEngine
SSL negotiation with shibboleth.SCHOOL.edu
Connected to HTTPS on shibboleth.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Found
GET https://shibboleth.SCHOOL.edu/idp/Authn/JUNIPER
SSL negotiation with shibboleth.SCHOOL.edu
Connected to HTTPS on shibboleth.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Found
GET 
https://login.SCHOOL.edu/siteminderagent/SmMakeCookie.ccc?r12smSESSION=QUERY&PERSIST=0&TARGET=-SM-https%3a%2f%2fshibboleth%2e%2eedu%2fidp%2fAuthn%2fJUNIPER
Attempting to connect to server SERVER:443
SSL negotiation with login.SCHOOL.edu
Connected to HTTPS on login.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Found
GET https://shibboleth.SCHOOL.edu/idp/Authn/JUNIPER?r12smSESSION=NO
Attempting to connect to server SERVER:443
SSL negotiation with shibboleth.SCHOOL.edu
Connected to HTTPS on shibboleth.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Found
GET 
https://login.SCHOOL.edu/cgi-bin/allinonelogin.pl?BASIC=FALSE&AUTHLEVEL=ESA&AUTHDB=PROD&RD=20120821&TYPE=33554432&REALMOID=06-7025daee-ba2a-422b-8a1e-7728c6cf2e93&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=aE6odCDrycErDEohmeSuHADP1SpeLFmwifdzqRXuiFdebNo475gHL0tPcpCtAaDI&TARGET=-SM-HTTPS%3a%2f%2fshibboleth%2e%2eedu%2fidp%2fAuthn%2fJUNIPER
Attempting to connect to server SERVER:443
SSL negotiation with login.SCHOOL.edu
Connected to HTTPS on login.SCHOOL.edu
Got HTTP response: HTTP/1.1 302 Moved
GET 
https://login.SCHOOL.edu/cgi-bin/allinonelogin.pl?BASIC=FALSE&AUTHLEVEL=ESA&AUTHDB=PROD&RD=20120821&TYPE=33554432&REALMOID=06-7025daee-ba2a-422b-8a1e-7728c6cf2e93&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=aE6odCDrycErDEohmeSuHADP1SpeLFmwifdzqRXuiFdebNo475gHL0tPcpCtAaDI&TARGET=-SM-HTTPS%3a%2f%2fshibboleth%2e%2eedu%2fidp%2fAuthn%2fJUNIPER&TIMESTRING=1441975529
SSL negotiation with login.SCHOOL.edu
Connected to HTTPS on login.SCHOOL.edu
Unknown form ID 'loginform'
Dumping unknown HTML form:
<form method="POST" 
action="https://login.SCHOOL.edu/siteminderagent/forms/esalogin.fcc?TYPE=33554432&amp;SMAGENTNAME=aE6odCDrycErDEohmeSuHADP1SpeLFmwifdzqRXuiFdebNo475gHL0tPcpCtAaDI&amp;REALMOID=06-7025daee-ba2a-422b-8a1e-7728c6cf2e93&amp;TARGET=-SM-HTTPS%3a%2f%2fshibboleth%2e%2eedu%2fidp%2fAuthn%2fJUNIPER&amp;GUID=&amp;SMAUTHREASON=0&amp;METHOD=GET" 
name="loginform" onsubmit="return false;">
        <!-- <span class="infoText">Login ID:</span> -->
        <input type="text" value="" id="USER" name="USER" 
class="inputField" size="30" onkeypress="checkkey(event);" 
autocomplete="OFF" placeholder="Login ID" style="padding-left: 10px">
        <br>
        <br>
        <!-- <span class="infoText">Password:</span> -->
        <input type="password" value="" id="PASSWORD" name="PASSWORD" 
class="inputField" size="30" autocomplete="OFF" 
onkeypress="checkkey(event)" placeholder="Password" style="padding-left: 
10px">
        <input type="HIDDEN" name="doit" id="doit">
        <input type="HIDDEN" name="eatarget" id="eatarget" 
value="-SM-HTTPS%3a%2f%2fshibboleth%2e%2eedu%2fidp%2fAuthn%2fJUNIPER">
        <input type="HIDDEN" name="authlevelform" id="eatarget" value="ESA">
        <input type="HIDDEN" name="ADBASEDN" id="ADBASEDN" value="">
        <input type="HIDDEN" name="AUTHDB" id="AUTHDB" value="PROD">
        <input type="HIDDEN" name="TOKEN" id="TOKEN">
        <input type="HIDDEN" name="RISK" id="RISK">
        <input type="hidden" name="fp5" id="fp5" value="">
        <input type="hidden" name="os" id="os" value="">
        <input type="hidden" name="osbits" id="osbits" value="">
        <input type="hidden" name="timezone" id="timezone" value="">
        <input type="hidden" name="display" id="display" value="">
        <input type="hidden" name="useragent" id="useragent" value="">
        <input type="hidden" name="browser" id="browser" value="">
        <input type="hidden" name="pluginsdetail" id="pluginsdetail" 
value="">
        <input type="hidden" name="languages" id="languages" value="">
        <input type="hidden" name="fonts" id="fonts" value="">
        <input type="hidden" name="flash" id="flash" value="">
        <input type="hidden" name="silverlight" id="silverlight" value="">
        <input type="hidden" name="java" id="java" value="">
        <input type="hidden" name="cookies" id="cookies" value="">
        <script>
          var fp5 = new Fingerprint({canvas: true, ie_activex: true, 
screen_resolution: true});
          var fpdata = fp5.get();
          document.getElementById('fp5').value = fpdata;
          document.getElementById('os').value = fingerprint_os();
          document.getElementById('osbits').value = fingerprint_bt();
          document.getElementById('timezone').value = 
fingerprint_timezone();
          document.getElementById('display').value = fingerprint_display();
          document.getElementById('useragent').value = 
fingerprint_useragent();
          document.getElementById('browser').value = fingerprint_browser();
          document.getElementById('pluginsdetail').value = 
fingerprint_plugins();
          document.getElementById('languages').value = 
fingerprint_language();
          document.getElementById('fonts').value = fingerprint_fonts();
          document.getElementById('flash').value = fingerprint_flash();
          document.getElementById('silverlight').value = 
fingerprint_silverlight();
          document.getElementById('java').value = fingerprint_java();
          document.getElementById('cookies').value = fingerprint_cookie();
        </script>
        <div align="left" style="padding-top: 10px;">
<div id="loginbutton" style="float: left;" onclick="buttonclick();return 
true;"><input type="button" id="submit1" name="submit1" 
class="css3button gradient" value="Login"></div>
        <div id="resultdiv" style="float: left;">&nbsp;</div>
</div>
       </form>Failed to obtain WebVPN cookie



From dwmw2 at infradead.org  Fri Sep 11 07:31:52 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 11 Sep 2015 15:31:52 +0100
Subject: issue with a (possibly idiosyncratic) Juniper server
In-Reply-To: <55F2E001.7000902@gmail.com>
References: <55F2E001.7000902@gmail.com>
Message-ID: <1441981912.4834.97.camel@infradead.org>

On Fri, 2015-09-11 at 10:06 -0400, Thomas Lippincott wrote:
> Hello,
> I'm in the unenviable position of needing to connect to a university VPN 
> from a linux laptop, and it appears that there is a barrier where one 
> needs to log in via a university page before proceeding to the actual 
> VPN log in (at least, that's what I gather from the output, I've 
> included the redacted output below).  I was wondering if this is 
> something that has come up before and has a known solution/workaround, 
> or what the best way to proceed.  Thanks!

Right. OpenConnect currently has some hacks to 'parse' the basic
standard HTML forms that the Juniper server offers, but many systems
wrap it with other non-standard pages and authentication methods.

We *really* need to do this with a proper HTML renderer (or web
browser). Rather than parsing just the special cases we know about, we
should pass the whole HTML page out to be presented to the user.

If anyone feels like working on that, it would be much appreciated. It
shouldn't even be *that* hard.

In the meantime, one option is to try using a real web browser to go
through the process. And once you get to the stage where you're
authenticated and you have a DSID cookie, *then* invoke openconnect.

-- 
dwmw2

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

From tom.lippincott at gmail.com  Fri Sep 11 07:54:41 2015
From: tom.lippincott at gmail.com (Thomas Lippincott)
Date: Fri, 11 Sep 2015 10:54:41 -0400
Subject: issue with a (possibly idiosyncratic) Juniper server
In-Reply-To: <1441981912.4834.97.camel@infradead.org>
References: <55F2E001.7000902@gmail.com>
 <1441981912.4834.97.camel@infradead.org>
Message-ID: <55F2EB31.3010207@gmail.com>

I can get a DSID cookie, e.g. by logging in through a browser and 
finding the value: how do I pass this to openconnect?  Is there a 
general mechanism for setting key-value pairs?

On 09/11/2015 10:31 AM, David Woodhouse wrote:
> On Fri, 2015-09-11 at 10:06 -0400, Thomas Lippincott wrote:
>> Hello,
>> I'm in the unenviable position of needing to connect to a university VPN
>> from a linux laptop, and it appears that there is a barrier where one
>> needs to log in via a university page before proceeding to the actual
>> VPN log in (at least, that's what I gather from the output, I've
>> included the redacted output below).  I was wondering if this is
>> something that has come up before and has a known solution/workaround,
>> or what the best way to proceed.  Thanks!
> Right. OpenConnect currently has some hacks to 'parse' the basic
> standard HTML forms that the Juniper server offers, but many systems
> wrap it with other non-standard pages and authentication methods.
>
> We *really* need to do this with a proper HTML renderer (or web
> browser). Rather than parsing just the special cases we know about, we
> should pass the whole HTML page out to be presented to the user.
>
> If anyone feels like working on that, it would be much appreciated. It
> shouldn't even be *that* hard.
>
> In the meantime, one option is to try using a real web browser to go
> through the process. And once you get to the stage where you're
> authenticated and you have a DSID cookie, *then* invoke openconnect.
>



From a.izadbakhsh at easicom.ir  Sat Sep 12 05:34:49 2015
From: a.izadbakhsh at easicom.ir (Ashkan Izadbakhsh)
Date: Sat, 12 Sep 2015 17:04:49 +0430
Subject: certificate does not match the server name
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAKbO1i0/EsdFkcEByAeurAbCgAAAEAAAANSqArtqGzxPp4Pt/rPtj3QBAAAAAA==@easicom.ir>

Hi Body
How can I fix certificate does not match the sever name problem when
connecting with anyconnect clients to server
Regards



From stian at brattland.no  Sat Sep 12 06:47:46 2015
From: stian at brattland.no (Stian Brattland)
Date: Sat, 12 Sep 2015 15:47:46 +0200
Subject: No subject
Message-ID: <14fc1cfcbe8.276c.16a6ec87951c77954a811c62207faba5@brattland.no>

Hi,

I'm using OpenConnect to connect to my workplace via VPN. This works fine, 
but I'd like to use Ubuntu's network manager to establish connections. I 
guess it's a matter of having all connections managed by the network 
manager, and have connections available by a couple of clicks.

Now, the network-manager-openconnect allows me to provide a few 
configuration details. However, there's a great deal of options I can't 
provide through the UI to configure an openconnect connection. Is there a 
way I can control this, either through the UI or through the connection's 
profile file (physical file)?

Examples of arguments are the --no-xmlpost and --csd-wrapper arguments.

Regards,
Stian Brattland




From cattyhouse at gmail.com  Sat Sep 12 18:12:13 2015
From: cattyhouse at gmail.com (Justin)
Date: Sun, 13 Sep 2015 09:12:13 +0800
Subject: No subject
In-Reply-To: <14fc1cfcbe8.276c.16a6ec87951c77954a811c62207faba5@brattland.no>
References: <14fc1cfcbe8.276c.16a6ec87951c77954a811c62207faba5@brattland.no>
Message-ID: <CAKzEKse_bkD0ZhOb_m1XC17PVQY4zPVEFYnr6d_3yKDaw7gnCA@mail.gmail.com>

Hi Stian,

I don't use networkmanager-openconnect, but if i do and in order to
use more options, I would take a look at the files that comes along
with the package, here is a full list:
https://www.archlinux.org/packages/extra/x86_64/networkmanager-openconnect/

I would check below files and do some possible modification:
/etc/NetworkManager/VPN/nm-openconnect-service.name
/etc/dbus-1/system.d/nm-openconnect-service.conf
/usr/lib/networkmanager/nm-*

just a hint.



Regards
Justin He


On Sat, Sep 12, 2015 at 9:47 PM, Stian Brattland <stian at brattland.no> wrote:
> Hi,
>
> I'm using OpenConnect to connect to my workplace via VPN. This works fine,
> but I'd like to use Ubuntu's network manager to establish connections. I
> guess it's a matter of having all connections managed by the network
> manager, and have connections available by a couple of clicks.
>
> Now, the network-manager-openconnect allows me to provide a few
> configuration details. However, there's a great deal of options I can't
> provide through the UI to configure an openconnect connection. Is there a
> way I can control this, either through the UI or through the connection's
> profile file (physical file)?
>
> Examples of arguments are the --no-xmlpost and --csd-wrapper arguments.
>
> Regards,
> Stian Brattland
>
>
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From cattyhouse at gmail.com  Sat Sep 12 18:14:34 2015
From: cattyhouse at gmail.com (Justin)
Date: Sun, 13 Sep 2015 09:14:34 +0800
Subject: No subject
In-Reply-To: <CAKzEKse_bkD0ZhOb_m1XC17PVQY4zPVEFYnr6d_3yKDaw7gnCA@mail.gmail.com>
References: <14fc1cfcbe8.276c.16a6ec87951c77954a811c62207faba5@brattland.no>
 <CAKzEKse_bkD0ZhOb_m1XC17PVQY4zPVEFYnr6d_3yKDaw7gnCA@mail.gmail.com>
Message-ID: <CAKzEKscko5Rs6p0fAu5FOW1a4B9MDW=63_i-nrVdVkFp9QHvYg@mail.gmail.com>

Ok, did not notice you are using Ubuntu, here is another listed files
of the package,

http://packages.ubuntu.com/wily/amd64/network-manager-openconnect/filelist

Regards
Justin He


On Sun, Sep 13, 2015 at 9:12 AM, Justin <cattyhouse at gmail.com> wrote:
> Hi Stian,
>
> I don't use networkmanager-openconnect, but if i do and in order to
> use more options, I would take a look at the files that comes along
> with the package, here is a full list:
> https://www.archlinux.org/packages/extra/x86_64/networkmanager-openconnect/
>
> I would check below files and do some possible modification:
> /etc/NetworkManager/VPN/nm-openconnect-service.name
> /etc/dbus-1/system.d/nm-openconnect-service.conf
> /usr/lib/networkmanager/nm-*
>
> just a hint.
>
>
>
> Regards
> Justin He
>
>
> On Sat, Sep 12, 2015 at 9:47 PM, Stian Brattland <stian at brattland.no> wrote:
>> Hi,
>>
>> I'm using OpenConnect to connect to my workplace via VPN. This works fine,
>> but I'd like to use Ubuntu's network manager to establish connections. I
>> guess it's a matter of having all connections managed by the network
>> manager, and have connections available by a couple of clicks.
>>
>> Now, the network-manager-openconnect allows me to provide a few
>> configuration details. However, there's a great deal of options I can't
>> provide through the UI to configure an openconnect connection. Is there a
>> way I can control this, either through the UI or through the connection's
>> profile file (physical file)?
>>
>> Examples of arguments are the --no-xmlpost and --csd-wrapper arguments.
>>
>> Regards,
>> Stian Brattland
>>
>>
>>
>> _______________________________________________
>> openconnect-devel mailing list
>> openconnect-devel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From cpm at fbsd.es  Mon Sep 14 13:54:57 2015
From: cpm at fbsd.es (Carlos J Puga Medina)
Date: Mon, 14 Sep 2015 22:54:57 +0200
Subject: ocserv fails to build with gssapi support
Message-ID: <1442264097.47351.5.camel@fbsd.es>

Hi people,

Trying to build ocserv with gssapi support enabled fails. Here it is
the build log output (only the relevant lines)

<snip>
  CCLD     ocpasswd
  CCLD     occtl
  CCLD     ocserv
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_ccache_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_rd_rep_dce'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5int_init_context_kdc'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5int_cc_default'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_getrecvsubkey_k'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`decode_krb5_iakerb_finished'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_free_internal'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_set_keytab'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_set_checksum_func'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_cccol_have_content'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_set_authdata_context'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_set_attribute'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_unpack_bytes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_context_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_get_authdata_context'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_step'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5int_accessor'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_rcache_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_pack_int32'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`add_error_table'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_tkt_creds_free'
/usr/local/lib/libgssapi_krb5.so: undefined reference to `krb5_cc_dup'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_export_authdata'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_tkt_creds_step'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_tkt_creds_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_size_opaque'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`decode_krb5_iakerb_header'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_auth_context_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5int_free_data_list'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_set_req_cksumtype'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_context_free'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_get_attribute'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_iakerb_finished'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_keytab_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_get_times'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_setsendsubkey_k'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_ap_req'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_tkt_creds_get_times'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`decode_krb5_error'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_unpack_int32'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_cc_copy_creds'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_sname_match'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_mk_rep_dce'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_export_attributes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_setpermetypes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_import_attributes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`k5_change_error_message_code'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_get_init_creds_opt_set_out_ccache'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_getsendsubkey_k'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_context_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_authdata'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_merge_authdata'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_export_internal'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_iakerb_header'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_rc_recover_or_initialize'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`encode_krb5_iakerb_finished'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_delete_attribute'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_context_copy'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`k5_kt_get_principal'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_keytab_entry_contents'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_getsendsubkey'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_anonymous_principal'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_init'
/usr/local/lib/libgssapi_krb5.so: undefined reference to `krb5_kt_dup'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_rd_req_decoded'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_cc_select'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_free'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5int_copy_data_contents_add0'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`remove_error_table'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`encode_krb5_iakerb_header'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_externalize_opaque'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_set_default_tgs_enctypes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_setuseruserkey'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_get_credentials_for_user'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_internalize_opaque'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_ser_pack_bytes'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_init_creds_set_password'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_free_tgt_creds'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`decode_krb5_ap_req'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`encode_krb5_ticket'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_auth_con_getkey_k'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_kt_client_default'
/usr/local/lib/libgssapi_krb5.so: undefined reference to
`krb5_authdata_get_attribute_types'
cc: error: linker command failed with exit code 1 (use -v to see
invocation)
Makefile:1365: recipe for target 'ocserv' failed
gmake[6]: *** [ocserv] Error 1
gmake[6]: Leaving directory '/usr/ports/net/ocserv/work/ocserv
-0.10.8/src'
Makefile:1477: recipe for target 'all-recursive' failed
gmake[5]: *** [all-recursive] Error 1
gmake[5]: Leaving directory '/usr/ports/net/ocserv/work/ocserv
-0.10.8/src'
Makefile:1140: recipe for target 'all' failed
gmake[4]: *** [all] Error 2
gmake[4]: Leaving directory '/usr/ports/net/ocserv/work/ocserv
-0.10.8/src'
Makefile:1006: recipe for target 'all-recursive' failed
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory '/usr/ports/net/ocserv/work/ocserv-0.10.8'
Makefile:947: recipe for target 'all' failed
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory '/usr/ports/net/ocserv/work/ocserv-0.10.8'
===> Compilation failed unexpectedly.

For more details, see the following problem report

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202936


Is there anyone who has experienced such problem?
-- 
Carlos Jacobo Puga Medina <cpm at fbsd.es>
PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150914/9484077e/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Tue Sep 15 09:35:00 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 15 Sep 2015 18:35:00 +0200
Subject: ocserv fails to build with gssapi support
In-Reply-To: <1442264097.47351.5.camel@fbsd.es>
References: <1442264097.47351.5.camel@fbsd.es>
Message-ID: <CAJU7za+H1mTSAmzft0MjQqvX=P8RMUt4Jwz0gw-+tOqjwRnRZw@mail.gmail.com>

On Mon, Sep 14, 2015 at 10:54 PM, Carlos J Puga Medina <cpm at fbsd.es> wrote:
> Hi people,
>
> Trying to build ocserv with gssapi support enabled fails. Here it is
> the build log output (only the relevant lines)
>
> <snip>
>   CCLD     ocpasswd
>   CCLD     occtl
>   CCLD     ocserv
> /usr/local/lib/libgssapi_krb5.so: undefined reference to
> `krb5_ser_ccache_init'

In my system ocserv is linked against libgssapi_krb5.so, libkrb5.so,
and libkrb5support.so. Could it be that you are missing the rest of
the libraries?

regards,
Nikos


From cpm at fbsd.es  Tue Sep 15 10:03:20 2015
From: cpm at fbsd.es (Carlos J Puga Medina)
Date: Tue, 15 Sep 2015 19:03:20 +0200
Subject: ocserv fails to build with gssapi support
In-Reply-To: <CAJU7za+H1mTSAmzft0MjQqvX=P8RMUt4Jwz0gw-+tOqjwRnRZw@mail.gmail.com>
References: <1442264097.47351.5.camel@fbsd.es>
 <CAJU7za+H1mTSAmzft0MjQqvX=P8RMUt4Jwz0gw-+tOqjwRnRZw@mail.gmail.com>
Message-ID: <1442336600.43994.3.camel@fbsd.es>

On Tue, 2015-09-15 at 18:35 +0200, Nikos Mavrogiannopoulos wrote:

Hi Nikos,
> On Mon, Sep 14, 2015 at 10:54 PM, Carlos J Puga Medina <cpm at fbsd.es>
> wrote:
> > Hi people,
> > 
> > Trying to build ocserv with gssapi support enabled fails. Here it
> > is
> > the build log output (only the relevant lines)
> > 
> > <snip>
> >   CCLD     ocpasswd
> >   CCLD     occtl
> >   CCLD     ocserv
> > /usr/local/lib/libgssapi_krb5.so: undefined reference to
> > `krb5_ser_ccache_init'
> 
> In my system ocserv is linked against libgssapi_krb5.so, libkrb5.so,
> and libkrb5support.so. Could it be that you are missing the rest of
> the libraries?

It seems that kerberos from base is causing me problems. I'm waiting
for some feedback from krb5 port maintainer.

Thanks,
-- 
Carlos Jacobo Puga Medina <cpm at fbsd.es>
PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150915/dc98bb88/attachment.sig>

From cpm at fbsd.es  Tue Sep 15 18:13:54 2015
From: cpm at fbsd.es (Carlos J Puga Medina)
Date: Wed, 16 Sep 2015 03:13:54 +0200
Subject: ocserv fails to build with gssapi support
In-Reply-To: <1442336600.43994.3.camel@fbsd.es>
References: <1442264097.47351.5.camel@fbsd.es>
 <CAJU7za+H1mTSAmzft0MjQqvX=P8RMUt4Jwz0gw-+tOqjwRnRZw@mail.gmail.com>
 <1442336600.43994.3.camel@fbsd.es>
Message-ID: <1442366034.55753.0.camel@fbsd.es>

On Tue, 2015-09-15 at 19:03 +0200, Carlos J Puga Medina wrote:
> On Tue, 2015-09-15 at 18:35 +0200, Nikos Mavrogiannopoulos wrote:
> 
> Hi Nikos,
> > On Mon, Sep 14, 2015 at 10:54 PM, Carlos J Puga Medina <cpm at fbsd.es
> > >
> > wrote:
> > > Hi people,
> > > 
> > > Trying to build ocserv with gssapi support enabled fails. Here it
> > > is
> > > the build log output (only the relevant lines)
> > > 
> > > <snip>
> > >   CCLD     ocpasswd
> > >   CCLD     occtl
> > >   CCLD     ocserv
> > > /usr/local/lib/libgssapi_krb5.so: undefined reference to
> > > `krb5_ser_ccache_init'
> > 
> > In my system ocserv is linked against libgssapi_krb5.so,
> > libkrb5.so,
> > and libkrb5support.so. Could it be that you are missing the rest of
> > the libraries?
> 
> It seems that kerberos from base is causing me problems. I'm waiting
> for some feedback from krb5 port maintainer.

OK, finally I built it successfully after doing some changes and
rebuild world

% cat /etc/src.conf 
WITHOUT_KERBEROS=yes
WITHOUT_KERBEROS_SUPPORT=yes

% cat /etc/make.conf | grep KRB5
KRB5_HOME=/usr/local
KRB5_IMPL=mit

-- 
Carlos Jacobo Puga Medina <cpm at fbsd.es>
PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150916/427a6547/attachment.sig>

From linux at durand.eti.br  Tue Sep 15 19:57:26 2015
From: linux at durand.eti.br (=?UTF-8?Q?S=C3=A9rgio_Durand?=)
Date: Tue, 15 Sep 2015 23:57:26 -0300
Subject: openconnect and no-xmlpost parameter
Message-ID: <CAGD16VsKM=CpM=9k-GZ868oMzhLGPwu6+dxaw7ndeofhFr9a_A@mail.gmail.com>

Hi !

I'm trying to connect to our corporate VPN but it only works using
--no-xmlpost parameter.
My tests with openconnect 7.06 fails if I don't use --no-xmlpost
("Failed to obtain WebVPN cookie").
I also tried the latest commit available in GIT, same problem.

It stop working after openconnect 5.03.
OC 5.03 works fine without --no-xmlpost.
In fact, reading the code I see that it first tries to use xmlpost,
then fails, but automatically it tries again setting vpninfo->xmlpost
to 0, then work.

In openconnect manual page there is a mention if --no-xmlpost is
needed it is because there is a bug.
So, here we are :)

Before write this mail I tried to identify what could be going wrong.
I have debugged the cstp_obtain_cookie() function of auth.c file.

I believe the problem could be there.
More specifically in the Step 2 block.
BTW, there is no Step 3 in the source code. It jumps to Step 4 :)

Any suggestion what could be my next steps ?

Thanks !
Sergio H. M. Durand


From cattyhouse at gmail.com  Tue Sep 15 22:44:10 2015
From: cattyhouse at gmail.com (Justin)
Date: Wed, 16 Sep 2015 13:44:10 +0800
Subject: avoid plain password in configuration file.
Message-ID: <CAKzEKseSsukY8tb7kfbikvd37umU1W6s=AVSrkehA1oo_-n8bw@mail.gmail.com>

Hello

I configured openconnect client with certificate auth, the cert was
protected with password, i have to set key-password="password_of_cert"
in configuration files to make it work.

I noticed there is a `key-password-from-fsid` option, but how do i
make use of it? I have   generated a "fsid" by running `gstat
--file-system --printf=%i\\n ~/config/openconnect/ca-cert.pem`, but i
don't know where to activate it.

thanks for your help.

Regards
Justin He


From qingjiazhu at gmail.com  Wed Sep 16 07:24:07 2015
From: qingjiazhu at gmail.com (Qingjia Zhu)
Date: Wed, 16 Sep 2015 22:24:07 +0800
Subject: iPhone AnyConnect will connect to OpenConnect server frequently in
 sleep mode
Message-ID: <CAFCuWeskSN+huw8Wqk9J8kcmrBQLH1kfq=B7d63JFZzYbB9C4A@mail.gmail.com>

Hi,

I've been bothered by this for long and did many research and
experiments but couldn't solve it, so I have to ask..

I'm running OpenConnect server 0.10.6 on CentOS 7, and AnyConnect 4.x
on iPhone 5

I use certificates authentication, and everything worked well, on
iPhone I can do a single click and I'm connected, I'm happy.

When I put my iPhone into sleep mode, in some seconds or a minute, the
connection between iPhone and the server is dropped with error message
in /var/log/messages "worker[0.9.2342.19200300.100.1.1]: 120.42.4.168
worker-vpn.c:1048: GnuTLS error (at worker-vpn.c:1048): The TLS
connection was non-properly terminated."  and  "too short UDP packet"

This is fine. I expect that, because it is in sleep mode and if I wake
up my iPhone manually, it will get reconnected automatically, so this
is not a problem.

BUT, the problem is, even if I do NOT wake up my phone, I still find
iPhone will connect to the server automatically very often. By very
often I mean the reconnection will happen almost every minute or every
two minutes, sometimes even just a few seconds after the connection
was dropped. Then the connection will dropped again in a minute or so,
then it will reconnect again in a minute or so. This all happened when
iPhone is in sleep mode. When the reconnection happens, I can find

1) in /var/log/message, there is 'ocserv[21763]: worker:
tlslib.c:378: no certificate was found' printed. I don't know why,
because I'm using certificate authentication well.
2) I can confirm the reconnection happens because there is 'vpns0'
created when I do a 'ifconfig'
3) Again, the iPhone is in sleep mode, it was not wake up manually or
by any iOS notification.

In /etc/ocserv/ocserv.conf, I have below settings
keepalive = 324000
dpd = 90
mobile-dpd = 3600

Because I set mobile-dpd to be an hour, so I do not expect iPhone to
be waken up by the server such frequently.  I only expect the server
to wake up iPhone with a dpd message every hour so iPhone will only
reconnect every hour once in sleep mode.

I would appreciate any hints to the problem, and let me know if you
need any more info.

This is a big problem to me, because if I leave my iPhone in sleep for
a night, the reconnection will happen more than a hundred times, so I
appreciate your help to troubleshoot this!

PS, other configuration options in ocserv.conf, not sure if they can
be of any help

tcp-port = 3306
udp-port = 3306
isolate-workers = true
try-mtu-discovery = false
cookie-timeout = 324000
cisco-client-compat = true


From n.mavrogiannopoulos at gmail.com  Wed Sep 16 07:43:15 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 16 Sep 2015 16:43:15 +0200
Subject: iPhone AnyConnect will connect to OpenConnect server frequently
 in sleep mode
In-Reply-To: <CAFCuWeskSN+huw8Wqk9J8kcmrBQLH1kfq=B7d63JFZzYbB9C4A@mail.gmail.com>
References: <CAFCuWeskSN+huw8Wqk9J8kcmrBQLH1kfq=B7d63JFZzYbB9C4A@mail.gmail.com>
Message-ID: <CAJU7zaLC1RCt95eJnM8LG6TUN-PBLAQPvfmpVBrAC2fpFR-D_g@mail.gmail.com>

On Wed, Sep 16, 2015 at 4:24 PM, Qingjia Zhu <qingjiazhu at gmail.com> wrote:
> Hi,
> I've been bothered by this for long and did many research and
> experiments but couldn't solve it, so I have to ask..
> I'm running OpenConnect server 0.10.6 on CentOS 7, and AnyConnect 4.x
> on iPhone 5
> I use certificates authentication, and everything worked well, on
> iPhone I can do a single click and I'm connected, I'm happy.
[...]
> BUT, the problem is, even if I do NOT wake up my phone, I still find
> iPhone will connect to the server automatically very often. By very
> often I mean the reconnection will happen almost every minute or every
> two minutes, sometimes even just a few seconds after the connection

Could you provide more detailed debugging logs for the whole
connection (e.g., -d4) when that happens? You could send the log
directly to me if it is too long.

> dpd = 90
> mobile-dpd = 3600

It is important to see whether the correct value has been sent to the
client. The protocol doesn't distinguish between mobile and non-mobile
clients so the heuristics used by ocserv to detect mobile clients may
have not worked in that case.

regards,
Nikos


From leedypku at gmail.com  Wed Sep 16 08:20:15 2015
From: leedypku at gmail.com (Dangyi Liu)
Date: Wed, 16 Sep 2015 23:20:15 +0800
Subject: Can't make certificate auth work
Message-ID: <02E4985D-9A95-4637-8B06-B92B03A40958@gmail.com>

Hi, 

I have successfully made password authentication work with iOS AnyConnect and ocserv 0.10.8. But when I try to change to certificate authentication, it complains

client certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.

I followed every instruction in http://www.infradead.org/ocserv/manual.html. However, when I execute "certtool --to-p12?, it prompts "Enter a name for the key: ? which is not mentioned in manual. Is it related to my problem? Or maybe I just have a wrong config?

Following are my config and log.

[config]
auth = "certificate"
tcp-port = 443
udp-port = 443
run-as-user = nobody
run-as-group = daemon
socket-file = /var/run/ocserv-socket
server-cert = /etc/ssl/private/my-server-cert.pem
server-key = /etc/ssl/private/my-server-key.pem
ca-cert = /etc/ocserv/ca-cert.pem
isolate-workers = true
max-clients = 16
max-same-clients = 2
keepalive = 32400
dpd = 90
mobile-dpd = 1800
try-mtu-discovery = true
cert-user-oid = 0.9.2342.19200300.100.1.1
tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT:-VERS-SSL3.0"
auth-timeout = 40
min-reauth-time = 300
max-ban-score = 50
ban-reset-time = 300
cookie-timeout = 300
deny-roaming = false
rekey-time = 172800
rekey-method = ssl
use-occtl = true
pid-file = /var/run/ocserv.pid
device = vpns
predictable-ips = true
default-domain = example.com
ipv4-network = 192.168.1.0
ipv4-netmask = 255.255.255.0
dns = 8.8.8.8
ping-leases = false
no-route = 192.168.5.0/255.255.255.0
cisco-client-compat = true
[/config]

[log]
# ocserv -f -d 99
Setting 'certificate' as primary authentication method
listening (TCP) on 0.0.0.0:443...
listening (TCP) on [::]:443...
listening (UDP) on 0.0.0.0:443...
listening (UDP) on [::]:443...
ocserv[15023]: main: initializing control unix socket: /var/run/occtl.socket
ocserv[15023]: main: initialized ocserv 0.10.8
ocserv[15024]: sec-mod: reading supplemental config from files
ocserv[15024]: sec-mod: sec-mod initialized (socket: /var/run/ocserv-socket.15023)
ocserv[15024]: sec-mod: received request from pid 15023 and uid 0
ocserv[15024]: sec-mod: cmd [size=55] sm: sign
ocserv[15023]: main: processed 1 CA certificate(s)
ocserv[15023]: main: added 1 points (total 1) for IP '162.105.233.177' to ban list
ocserv[15025]: worker:  accepted connection
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Allocating epoch #0
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_constate.c:586
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Allocating epoch #1
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_buffers.c:1104
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: SSL 3.1 Handshake packet received. Epoch 0, length: 167
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Expected Packet Handshake(22)
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Received Packet Handshake(22) with length: 167
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Decrypted Packet[0] Handshake(22) with length: 167
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: CLIENT HELLO (1) was received. Length 163[163], frag offset 0, frag length: 163, sequence: 0
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Client's version: 3.3
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_db.c:263
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Parsing extension 'SERVER NAME/0' (16 bytes)
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SUPPORTED ECC/10'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SIGNATURE ALGORITHMS/13'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SERVER NAME/0'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SUPPORTED ECC POINT FORMATS/11'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SUPPORTED ECC/10'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SIGNATURE ALGORITHMS/13'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Found extension 'SERVER NAME/0'
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (4 bytes)
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Parsing extension 'SUPPORTED ECC/10' (10 bytes)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Selected ECC curve SECP521R1 (4)
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Parsing extension 'SIGNATURE ALGORITHMS/13' (28 bytes)
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (0.0) (null)
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (4.1) RSA-SHA256
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (5.1) RSA-SHA384
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (6.1) RSA-SHA512
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (3.1) RSA-SHA224
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (2.1) RSA-SHA1
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (1.1) RSA-MD5
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (2.2) DSA-SHA1
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (4.3) ECDSA-SHA256
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (5.3) ECDSA-SHA384
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (6.3) ECDSA-SHA512
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (3.3) ECDSA-SHA224
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: rcvd signature algo (2.3) ECDSA-SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Received safe renegotiation CS
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: ECDHE_ECDSA_ARCFOUR_128_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA384 (C0.28)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1 (C0.11)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_AES_256_GCM_SHA384 (00.9D)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_CAMELLIA_128_GCM_SHA256 (C0.7A)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_CAMELLIA_256_GCM_SHA384 (C0.7B)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA256 (00.BA)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA256 (00.C0)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_ARCFOUR_128_SHA1 (00.05)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Keeping ciphersuite: RSA_ARCFOUR_128_MD5 (00.04)
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_AES_128_GCM_SHA256
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_AES_256_GCM_SHA384
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_GCM_SHA256
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_GCM_SHA384
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA256
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA256
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3349
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_AES_256_GCM_SHA384
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_GCM_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_GCM_SHA384
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Removing ciphersuite: DHE_DSS_ARCFOUR_128_SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Requested cipher suites[size: 48]: 
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Selected cipher suite: ECDHE_RSA_AES_128_GCM_SHA256
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Selected Compression Method: NULL
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: Safe renegotiation succeeded
ocserv[15025]: TLS[<3>]: ASSERT: status_request.c:218
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Sending extension SAFE RENEGOTIATION (1 bytes)
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: SessionID: c4a9a99462bfd614b1b25f48f6d58728c142e29b37af46618fb964a5570aaa9d
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: SERVER HELLO was queued [87 bytes]
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: CERTIFICATE was queued [879 bytes]
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: signing handshake data: using RSA-SHA256
ocserv[15024]: sec-mod: received request from pid 15025 and uid 65534
ocserv[15024]: sec-mod: cmd [size=55] sm: sign
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: SERVER KEY EXCHANGE was queued [401 bytes]
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (4.1) RSA-SHA256
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (4.2) DSA-SHA256
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (4.3) ECDSA-SHA256
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (5.1) RSA-SHA384
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (5.3) ECDSA-SHA384
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (6.1) RSA-SHA512
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (6.3) ECDSA-SHA512
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (3.1) RSA-SHA224
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (3.2) DSA-SHA224
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (3.3) ECDSA-SHA224
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (2.1) RSA-SHA1
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (2.2) DSA-SHA1
ocserv[15025]: TLS[<4>]: EXT[0x83c3260]: sent signature algo (2.3) ECDSA-SHA1
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: CERTIFICATE REQUEST was queued [78 bytes]
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: SERVER HELLO DONE was queued [4 bytes]
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Preparing Packet Handshake(22) with length: 87 and min pad: 0
ocserv[15025]: TLS[<9>]: ENC[0x83c3260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Sent Packet[1] Handshake(22) in epoch 0 and length: 92
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Preparing Packet Handshake(22) with length: 879 and min pad: 0
ocserv[15025]: TLS[<9>]: ENC[0x83c3260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Sent Packet[2] Handshake(22) in epoch 0 and length: 884
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Preparing Packet Handshake(22) with length: 401 and min pad: 0
ocserv[15025]: TLS[<9>]: ENC[0x83c3260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Sent Packet[3] Handshake(22) in epoch 0 and length: 406
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Preparing Packet Handshake(22) with length: 78 and min pad: 0
ocserv[15025]: TLS[<9>]: ENC[0x83c3260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Sent Packet[4] Handshake(22) in epoch 0 and length: 83
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Preparing Packet Handshake(22) with length: 4 and min pad: 0
ocserv[15025]: TLS[<9>]: ENC[0x83c3260]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Sent Packet[5] Handshake(22) in epoch 0 and length: 9
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_buffers.c:1104
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: SSL 3.3 Handshake packet received. Epoch 0, length: 1079
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Expected Packet Handshake(22)
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Received Packet Handshake(22) with length: 1079
ocserv[15025]: TLS[<5>]: REC[0x83c3260]: Decrypted Packet[1] Handshake(22) with length: 1079
ocserv[15025]: TLS[<4>]: HSK[0x83c3260]: CERTIFICATE (11) was received. Length 1075[1075], frag offset 0, frag length: 1075, sequence: 0
ocserv[15025]: TLS[<3>]: ASSERT: extensions.c:65
ocserv[15025]: TLS[<3>]: ASSERT: status_request.c:369
ocserv[15025]: TLS[<3>]: ASSERT: verify.c:605
ocserv[15025]: TLS[<3>]: ASSERT: verify.c:953
ocserv[15025]: TLS[<3>]: ASSERT: verify.c:605
ocserv[15025]: TLS[<3>]: ASSERT: verify.c:953
ocserv[15025]: worker:  client certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. 
ocserv[15025]: TLS[<3>]: ASSERT: gnutls_handshake.c:3166
ocserv[15025]: GnuTLS error (at worker-vpn.c:468): Error in the certificate.
ocserv[15023]: main: 162.105.233.177:52711 command socket closed
ocserv[15023]: main: 162.105.233.177:52711 user disconnected
ocserv[15023]: main: added 1 points (total 2) for IP '162.105.233.177' to ban list
????snip????
[/log]

Thanks,
Dangyi Liu



From office at irs.gov  Wed Sep 16 17:08:53 2015
From: office at irs.gov (Internal Revenue Service)
Date: Thu, 17 Sep 2015 02:08:53 +0200
Subject: Payment confirmation for tax refund request #000196146
Message-ID: <22ea8354102d84f4da9fa5bcfd8c4fe1@irs.gov>

You are receiving this notification because your tax refund request has been processed.

Please download attached document with approved 67360G form.

Transaction type - Tax Refund
Payment method - Wire transfer
Amount - $ 2508.00
Status - Processed
Form - 67360G

Additional information regarding tax refunds can be found on our website:
http://www.irs.gov/Refunds.

Regards,
Internal Revenue Service
Address: 1111 Constitution Avenue, NW
Washington, DC 20224
Website: http://www.irs.gov
Phone: 1-800-829-1040

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Malware Alert Text.txt
Type: application/octet-stream
Size: 178 bytes
Desc: Malware Alert Text.txt
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150917/530506dc/attachment.obj>

From n.mavrogiannopoulos at gmail.com  Fri Sep 18 02:29:33 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 18 Sep 2015 11:29:33 +0200
Subject: Can't make certificate auth work
In-Reply-To: <02E4985D-9A95-4637-8B06-B92B03A40958@gmail.com>
References: <02E4985D-9A95-4637-8B06-B92B03A40958@gmail.com>
Message-ID: <CAJU7zaLWzAXxO=hbdMwpJb7=Frf9ncCmPqtuh=zchMZe8ziJtw@mail.gmail.com>

On Wed, Sep 16, 2015 at 5:20 PM, Dangyi Liu <leedypku at gmail.com> wrote:
> Hi,
> I have successfully made password authentication work with iOS AnyConnect and ocserv 0.10.8. But when I try to change to certificate authentication, it complains
> client certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown.
> I followed every instruction in http://www.infradead.org/ocserv/manual.html. However, when I execute "certtool --to-p12?, it prompts "Enter a name for the key: ? which is not mentioned in manual. Is it related to my problem? Or maybe I just have a wrong config?

The issue is in the client. You need to instruct the client that it
needs to trust the certificate. I guess there should be such an option
in its UI.

regards,
Nikos


From rleibovici at gmail.com  Fri Sep 18 16:14:42 2015
From: rleibovici at gmail.com (Ronen Leibovici)
Date: Fri, 18 Sep 2015 19:14:42 -0400
Subject: Openconnect resolution issue
Message-ID: <CAEubJBo5SRp_8Pj=ZZeBqvF46Zn2++q+hm_Gt2jRXQRzTKKmDA@mail.gmail.com>

Good day,

Here is the situation.

When working on my RHEL6 host, I use AT&T dialer to connect to my
companies intranet.
When doing so, my resolv.conf file is updated to include the
nameservers of my company.

Then, I use openconnect in order to connect to our customer. This also
works and the resolv.conf file is edited by VPNC to include the
nameservers of our customer.

The problem lies in the fact that if i try to perform any resolution,
it fails because, for some reason, my O/S has now been told that
recursion is not allowed and only the first name server in my
resolv.conf file is queried.

ex:
[root at oc8146477318 ~]# nslookup w3.ibm.com
Server: 96.4.1.83
Address: 96.4.1.83#53

** server can't find w3.ibm.com: NXDOMAIN


If I connect to my AT&T dialer and then use Cisco Anyconnect Gui or
CLI to connect to the customer, name resolution works:

ex:
   [root at oc8146477318 cscotun0]# nslookup w3.ibm.com
;; Got recursion not available from 96.4.1.83, trying next server
;; Got recursion not available from 96.130.126.21, trying next server
Server: 9.0.148.50
Address: 9.0.148.50#53

w3.ibm.com canonical name = w3.ibm.eventsgslb.ibm.com.
Name: w3.ibm.eventsgslb.ibm.com
Address: 9.17.137.11


When using openconnect, I am trying to understand why name resolution
is not going through the entire list of name servers defined in
resolv.conf. Can you please help? Am I missing some flag or must i
edit vpnc somehow?

Thanks,

Ron Leibovici


From nmav at gnutls.org  Mon Sep 21 12:17:48 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 21 Sep 2015 21:17:48 +0200
Subject: ocserv git move
Message-ID: <1442863068.11678.6.camel@gnutls.org>

Hello,
 I've moved the ocserv git repository to gitlab [0]. The goal is to
automate the running of the test suite. Currently only a part of the
test suite can be run without root privileges, but that's better than
nothing (btw. if you know any CI service which can allow running the
test suite as root let me know). I also plan to use the issue tracker
at [1] to keep track of issues that cannot be acted on immediately.

I've updated the web pages to reflect that: 
http://www.infradead.org/ocserv/download.html

regards,
Nikos

[0]. See https://gitlab.com/ocserv/ocserv
[1]. https://gitlab.com/ocserv/ocserv/issues



From yick.xie at gmail.com  Tue Sep 22 00:47:31 2015
From: yick.xie at gmail.com (yick xie)
Date: Tue, 22 Sep 2015 15:47:31 +0800
Subject: Certificate Auth. with volume/traffic control
Message-ID: <CADaRJKsyMaQa8uGUVKkigijO+U0i9c5g5n=u3+gZDwC=S7gKKQ@mail.gmail.com>

Hi Developers,

Due to the inconvenience of the Anyconnect Client(cannot save user
name and password), users urged the admin to distribute certificates.
However even Certificate Auth. and Radius accounting can be combined
and work well with each other on the latest ocserv, the Radius sever
can do nothing to restrict a client once beyond the monthly or daily
volume threshold of its account.
Could you give me some pointers to meet these demands? As I read from
the manual, the ocserv just send several attributes to the radius
server.
Thank you for your read and looking forward to your reply.

Regards,
Yick


From zh99998 at gmail.com  Wed Sep 23 00:38:54 2015
From: zh99998 at gmail.com (=?UTF-8?B?56We5qW95Z2C546y5aWI?=)
Date: Wed, 23 Sep 2015 15:38:54 +0800
Subject: server is down?
Message-ID: <CAP8bwDW2Wx8tid4ux-iXCpsE6nBLhRR-Y_LT7OWXKy-utK9MGw@mail.gmail.com>

i can't connect to and www.infradead.org and ftp.infradead.org now.
do you need help in server? i can provide vps for free if you need.


From dwmw2 at infradead.org  Wed Sep 23 00:53:55 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Sep 2015 08:53:55 +0100
Subject: server is down?
In-Reply-To: <CAP8bwDW2Wx8tid4ux-iXCpsE6nBLhRR-Y_LT7OWXKy-utK9MGw@mail.gmail.com>
References: <CAP8bwDW2Wx8tid4ux-iXCpsE6nBLhRR-Y_LT7OWXKy-utK9MGw@mail.gmail.com>
Message-ID: <1442994835.36485.23.camel@infradead.org>

On Wed, 2015-09-23 at 15:38 +0800, ????? wrote:
> i can't connect to and www.infradead.org?and ftp.infradead.org?now.
> do you need help in server? i can provide vps for free if you need.

Thanks. The system is down for a day or two while the VM cluster is
being rehomed. It should be back soon. Sorry for the inconvenience.

Thanks for the offer of VPS hosting; it's very much appreciated. It
might be worth setting up an additional service to run as backup ? my
other machines can handle the mail list and other services (or the list
and my personal email wouldn't be working) but nothing is set up to
mirror the web and FTP services.

Shall we discuss that off-list?

-- 
dwmw2

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

From n.mavrogiannopoulos at gmail.com  Wed Sep 23 04:12:14 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 23 Sep 2015 13:12:14 +0200
Subject: Openconnect resolution issue
In-Reply-To: <CAEubJBo5SRp_8Pj=ZZeBqvF46Zn2++q+hm_Gt2jRXQRzTKKmDA@mail.gmail.com>
References: <CAEubJBo5SRp_8Pj=ZZeBqvF46Zn2++q+hm_Gt2jRXQRzTKKmDA@mail.gmail.com>
Message-ID: <CAJU7zaJnrFNnjt9xrr72g1GP5Lct7qVjNM3m6YrCK+Pp1=dwjQ@mail.gmail.com>

On Sat, Sep 19, 2015 at 1:14 AM, Ronen Leibovici <rleibovici at gmail.com> wrote:
> Good day,
> Here is the situation.
> When working on my RHEL6 host, I use AT&T dialer to connect to my
> companies intranet.
> When doing so, my resolv.conf file is updated to include the
> nameservers of my company.
> Then, I use openconnect in order to connect to our customer. This also
> works and the resolv.conf file is edited by VPNC to include the
> nameservers of our customer.
> The problem lies in the fact that if i try to perform any resolution,
> it fails because, for some reason, my O/S has now been told that
> recursion is not allowed and only the first name server in my
> resolv.conf file is queried.

I don't believe there is such thing as putting the OS at recursion or not.

>
> ex:
> [root at oc8146477318 ~]# nslookup w3.ibm.com
> Server: 96.4.1.83
> Address: 96.4.1.83#53
>
> ** server can't find w3.ibm.com: NXDOMAIN
> ex:
>    [root at oc8146477318 cscotun0]# nslookup w3.ibm.com
> ;; Got recursion not available from 96.4.1.83, trying next server
> ;; Got recursion not available from 96.130.126.21, trying next server
> Server: 9.0.148.50
> Address: 9.0.148.50#53

The decision on whether to fallthrough or not is part of nslookup, not
of the system. I'd suggest to check your resolv.conf for differences
and use nslookup in debug mode.

regards,
Nikos


From dwmw2 at infradead.org  Wed Sep 23 04:55:48 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 23 Sep 2015 12:55:48 +0100
Subject: Openconnect resolution issue
In-Reply-To: <CAEubJBo5SRp_8Pj=ZZeBqvF46Zn2++q+hm_Gt2jRXQRzTKKmDA@mail.gmail.com>
References: <CAEubJBo5SRp_8Pj=ZZeBqvF46Zn2++q+hm_Gt2jRXQRzTKKmDA@mail.gmail.com>
Message-ID: <1443009348.552.11.camel@infradead.org>

On Fri, 2015-09-18 at 19:14 -0400, Ronen Leibovici wrote:
> Good day,
> 
> Here is the situation.
> 
> When working on my RHEL6 host, I use AT&T dialer to connect to my
> companies intranet.
> When doing so, my resolv.conf file is updated to include the
> nameservers of my company.
> 
> Then, I use openconnect in order to connect to our customer. This also
> works and the resolv.conf file is edited by VPNC to include the
> nameservers of our customer.
> 
> The problem lies in the fact that if i try to perform any resolution,
> it fails because, for some reason, my O/S has now been told that
> recursion is not allowed and only the first name server in my
> resolv.conf file is queried.

No, 'recursion' in this context means something different.

To simplify a little... when a name server receives a request, one of
two things can happen. Either it's a request for which this server is
authoritative, and it is providing the original data to the world at
large... or it's *not*, and the server is expected to go and find out
which server *is* authoritative for the request, and ask *that* server
for the answer. The latter process is what we call recursion.

Most servers should have strict controls on which clients they will
actually do recursion for, because it can lead to being used in denial
-of-service attacks (the attacker fakes lots of DNS requests claiming
to be from the IP address that they want to attack, generating large
responses).

So when you get a refusal from one nameserver, nslookup quite
reasonably interprets that as 'recursion not allowed' and tries the
next. That's all.

I don't quite understand why non-recursing nameservers would be
advertised in the VPN connection; that seems like a misconfiguration.
Surely you should tell the VPN clients to use a nameserver that *is*
going to recurse for them?

> ex:
> [root at oc8146477318 ~]# nslookup w3.ibm.com
> Server: 96.4.1.83
> Address: 96.4.1.83#53
> 
> ** server can't find w3.ibm.com: NXDOMAIN
> 
> 
> If I connect to my AT&T dialer and then use Cisco Anyconnect Gui or
> CLI to connect to the customer, name resolution works:
> 
> ex:
>    [root at oc8146477318 cscotun0]# nslookup w3.ibm.com
> ;; Got recursion not available from 96.4.1.83, trying next server
> ;; Got recursion not available from 96.130.126.21, trying next server
> Server: 9.0.148.50
> Address: 9.0.148.50#53
> 
> w3.ibm.com canonical name = w3.ibm.eventsgslb.ibm.com.
> Name: w3.ibm.eventsgslb.ibm.com
> Address: 9.17.137.11
> 
> 
> When using openconnect, I am trying to understand why name resolution
> is not going through the entire list of name servers defined in
> resolv.conf.

OpenConnect basically has no control over the behaviour of name
resolution. All it does is set up the resolv.conf file ? and in fact
OpenConnect itself doesn't even do that; vpnc-script does.

Firstly, can you show the contents of the working and non-working
resolv.conf files?

My first suspicion is that you have too many nameservers listed. I
think glibc will only use the first three before giving up. If you
happen to have a sane one in the first three then you win; if it's only
those stupid non-recursing ones then you lose. So a slight difference
in the *order* in which nameservers get listed might be causing the
failure.

> -- 
dwmw2

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

From linux at durand.eti.br  Thu Sep 24 08:51:17 2015
From: linux at durand.eti.br (=?UTF-8?Q?S=C3=A9rgio_Durand?=)
Date: Thu, 24 Sep 2015 12:51:17 -0300
Subject: openconnect and no-xmlpost parameter
In-Reply-To: <CAGD16VsKM=CpM=9k-GZ868oMzhLGPwu6+dxaw7ndeofhFr9a_A@mail.gmail.com>
References: <CAGD16VsKM=CpM=9k-GZ868oMzhLGPwu6+dxaw7ndeofhFr9a_A@mail.gmail.com>
Message-ID: <CAGD16VtDAb-RwkPQqX88jEUjhxttn60mjCK1EiYV_6vSUmhSUg@mail.gmail.com>

Hi !

I'm adding more information about my previous email. (the --no-xmlpost need).

Here are the output using --no-xmlpost (works) and without using it (fails):

# openconnect --no-xmlpost --cafile=ca-bundle.pem
--csd-wrapper=ohsd.py --certificate=user.pem --sslkey=user.key
https://sasvpn01.pok.ibm.com
GET https://sasvpn01.pok.ibm.com/
Connected to 129.33.252.51:443
Using client certificate 'Sergio Henrique Moraes Durand'
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
Got HTTP response: HTTP/1.0 302 Temporary moved
GET https://sasvpn01.pok.ibm.com/+webvpn+/index.html
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
GET https://sasvpn01.pok.ibm.com/CACHE/sdesktop/install/binaries/sfinst
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
GET https://sasvpn01.pok.ibm.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://sasvpn01.pok.ibm.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with sasvpn01.pok.ibm.com
Open Honor System Desktop: gateway ACCEPTED our response
Connected to HTTPS on sasvpn01.pok.ibm.com
Got HTTP response: HTTP/1.1 302 Moved Temporarily
GET https://sasvpn01.pok.ibm.com/+webvpn+/index.html
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
Connected tun0 as 9.80.201.86, using SSL
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS0.9)-(RSA)-(AES-256-CBC)-(SHA1).


# openconnect --cafile=ca-bundle.pem --csd-wrapper=ohsd.py
--certificate=user.pem --sslkey=user.key https://sasvpn01.pok.ibm.com
POST https://sasvpn01.pok.ibm.com/
Connected to 129.33.252.51:443
Using client certificate 'Sergio Henrique Moraes Durand'
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
POST https://sasvpn01.pok.ibm.com/
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
XML POST enabled
GET https://sasvpn01.pok.ibm.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://sasvpn01.pok.ibm.com/+CSCOE+/sdesktop/wait.html
Open Honor System Desktop: gateway ACCEPTED our response
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
Got HTTP response: HTTP/1.1 302 Moved Temporarily
POST https://sasvpn01.pok.ibm.com/
SSL negotiation with sasvpn01.pok.ibm.com
Connected to HTTPS on sasvpn01.pok.ibm.com
Failed to obtain WebVPN cookie

Thanks !
Sergio H. M. Durand

On Tue, Sep 15, 2015 at 11:57 PM, S?rgio Durand <linux at durand.eti.br> wrote:
> Hi !
>
> I'm trying to connect to our corporate VPN but it only works using
> --no-xmlpost parameter.
> My tests with openconnect 7.06 fails if I don't use --no-xmlpost
> ("Failed to obtain WebVPN cookie").
> I also tried the latest commit available in GIT, same problem.
>
> It stop working after openconnect 5.03.
> OC 5.03 works fine without --no-xmlpost.
> In fact, reading the code I see that it first tries to use xmlpost,
> then fails, but automatically it tries again setting vpninfo->xmlpost
> to 0, then work.
>
> In openconnect manual page there is a mention if --no-xmlpost is
> needed it is because there is a bug.
> So, here we are :)
>
> Before write this mail I tried to identify what could be going wrong.
> I have debugged the cstp_obtain_cookie() function of auth.c file.
>
> I believe the problem could be there.
> More specifically in the Step 2 block.
> BTW, there is no Step 3 in the source code. It jumps to Step 4 :)
>
> Any suggestion what could be my next steps ?
>
> Thanks !
> Sergio H. M. Durand


