From niels at peen.ch  Sun Nov  2 06:34:52 2014
From: niels at peen.ch (Niels Peen)
Date: Sun, 2 Nov 2014 22:34:52 +0800
Subject: OpenConnect-GUI: A record packet with illegal version was received.
Message-ID: <349D908E-8A20-417E-95D7-818A55982D3F@peen.ch>

Hi guys,

Any idea what would cause the ?illegal version? error? I?m assuming it?s 
referring to the SSL/TLS version. This server (ocserv) works fine for other 
users  of OpenConnect-GUI and also for this particular user if he uses 
OpenConnect on Android instead of Windows. (Also OpenVPN on the
same computer works without issues.)

2014-11-02 17:54 POST https://XXXXX/
2014-11-02 17:54 Attempting to connect to server 123.123.123.123:443
2014-11-02 17:54 SSL negotiation with XXXXX
2014-11-02 17:54 SSL connection failure: A record packet with illegal version was received.
2014-11-02 17:54 Failed to open HTTPS connection to XXXXXX
2014-11-02 17:54 Authentication error; cannot obtain cookie
2014-11-02 17:54 Disconnected

Thanks,
Niels



From nmav at gnutls.org  Sun Nov  2 07:01:24 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 02 Nov 2014 16:01:24 +0100
Subject: OpenConnect-GUI: A record packet with illegal version was
 received.
In-Reply-To: <349D908E-8A20-417E-95D7-818A55982D3F@peen.ch>
References: <349D908E-8A20-417E-95D7-818A55982D3F@peen.ch>
Message-ID: <1414940484.11111.2.camel@nomad.lan>

On Sun, 2014-11-02 at 22:34 +0800, Niels Peen wrote:
> Hi guys,
> Any idea what would cause the ?illegal version? error? I?m assuming it?s 
> referring to the SSL/TLS version. This server (ocserv) works fine for other 
> users  of OpenConnect-GUI and also for this particular user if he uses 
> OpenConnect on Android instead of Windows. (Also OpenVPN on the
> same computer works without issues.)
> 
> 2014-11-02 17:54 POST https://XXXXX/
> 2014-11-02 17:54 Attempting to connect to server 123.123.123.123:443
> 2014-11-02 17:54 SSL negotiation with XXXXX
> 2014-11-02 17:54 SSL connection failure: A record packet with illegal version was received.

The cases that this can happen is when there are no commonly supported
protocols, or the peer doesn't correctly set the TLS record versions.
That's almost impossible to occur between two gnutls peers. Could that
again be related to a firewall that modifies the packets sent/received?

regards,
Nikos




From dwmw2 at infradead.org  Mon Nov  3 06:54:10 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 03 Nov 2014 14:54:10 +0000
Subject: API to get ciphersuite
In-Reply-To: <1414449634.2469.5.camel@nomad.lan>
References: <CAJU7zaLbs_t1Kv2qEWWhC4dd374D8EUuXq3qL+arApMNuiEPDg@mail.gmail.com>
 <1414414299.26550.14.camel@infradead.org>
 <CAJU7zaJMzW8qUuzxD=YqxB6EgbA2m0WRk1DFPQUeQBzPFDgsNg@mail.gmail.com>
 <1414449634.2469.5.camel@nomad.lan>
Message-ID: <1415026450.32461.6.camel@infradead.org>

Hm, I added a call to this in the Java process_auth_form() callback, to
print the cipher before asking the user to fill in the form. Just as a
test.

It's crashing with Connection:close or HTTP/1.0, because by the time we
call openconnect_get_cstp_cipher() vpninfo->https_sess is NULL.

There's an obvious defensive-coding fix to make it return NULL in this
case, but perhaps we *do* actually want it to return valid results?

We could potentially declare that it's only valid to call
openconnect_get_cstp_cipher() when CSTP is actually *connected*... but
CSTP can disconnect due to DPD and reconnect at *any* time, so that
seems a little inappropriate.


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

From david.woodhouse at intel.com  Mon Nov  3 09:50:09 2014
From: david.woodhouse at intel.com (Woodhouse, David)
Date: Mon, 3 Nov 2014 17:50:09 +0000
Subject: Server certificate hash checking
Message-ID: <1415037007.32461.13.camel@intel.com>

I've just pushed out some changes to the way we handle server
certificates.

Firstly, the OPENCONNECT_X509 opaque type is dead, along with the
openconnect_get_peer_cert() function.

The openconnect_get_cert_DER() and openconnect_get_cert_details()
functions were *only* ever called on the peer cert (there was no way of
getting any *other* object of the OPENCONNECT_X509 type), and they have
been changes to openconnect_get_peer_cert_DER() and
openconnect_get_peer_cert_details() respectively.

The openconnect_get_cert_sha1() function has been changed to
openconnect_get_peer_cert_hash() and it no longer returns a SHA1 of the
whole certificate DER. Instead, it returns a hash (*currently* SHA1) of
the server's public key. the horrid "pass me a pointer to a 41-character
buffer" part of the libopenconnect API is also now gone, as this new
function returns a const char *.

Hashing just the public key means that the certificate can be reissued
and as long as the key remains the same, the user doesn't have to
manually accept the key again. It also defends against social
engineering attacks where a MITM repeatedly tampers with non-critical
parts of the certificate, effectively training the user to just click
'accept' each time... until one time, the attacker *has* hijacked the
connection.

There is a new openconnect_check_peer_cert_hash() function which, given
a hash, will check it against the server's certificate. It will accept
either the old-style 40-digit SHA1 of the whole cert, *or* the new-style
SHA1 of the pubkey, which is prefixed by 'sha1:'.

In future, the new style may use something better than SHA1 and the
openconnect_check_peer_cert_hash() function will obviously be adjusted
to cope.

A client is expected to use openconnect_check_peer_cert_hash() to check
if a 'remembered' certificate is indeed a match for the one currently
offered by the server ? don't use strcmp() against the new hash because
you'll get false negatives. Even on a match, the client is expected to
update its storage to contain *new* hash returned by
openconnect_get_peer_cert_hash().

The --servercert and --authenticate command line options now behave this
way too. The former will accept either type of hash, and the latter
generates the new style only for its FINGERPRINT= output.


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

From nmav at gnutls.org  Mon Nov  3 12:14:24 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Nov 2014 21:14:24 +0100
Subject: API to get ciphersuite
In-Reply-To: <1415026450.32461.6.camel@infradead.org>
References: <CAJU7zaLbs_t1Kv2qEWWhC4dd374D8EUuXq3qL+arApMNuiEPDg@mail.gmail.com>
 <1414414299.26550.14.camel@infradead.org>
 <CAJU7zaJMzW8qUuzxD=YqxB6EgbA2m0WRk1DFPQUeQBzPFDgsNg@mail.gmail.com>
 <1414449634.2469.5.camel@nomad.lan>
 <1415026450.32461.6.camel@infradead.org>
Message-ID: <1415045664.2435.2.camel@nomad.lan>

On Mon, 2014-11-03 at 14:54 +0000, David Woodhouse wrote:

> We could potentially declare that it's only valid to call
> openconnect_get_cstp_cipher() when CSTP is actually *connected*... but
> CSTP can disconnect due to DPD and reconnect at *any* time, so that
> seems a little inappropriate.

Maybe it makes sense to cache that value once a handshake is complete,
and return the const string from the get_cipher functions. In that case
it would return the value of the last channel that was available.

regards,
Nikos




From pet.magnusson at gmail.com  Tue Nov  4 02:15:54 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Tue, 4 Nov 2014 11:15:54 +0100
Subject: Openconnect no-xmlpost
Message-ID: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>

Hi,

Ive been trying to use Openconnect to connect to our Cisco VPN server
for a couple of days and im having some trouble.

Im using my smartcard for authentication and the VPN server requires
me to perform a hostscan before letting me in.

Im trying this on RHEL7 with version:
OpenConnect version v6.00
Using GnuTLS. Features present: TPM, PKCS#11, RSA software token, HOTP
software token, TOTP software token, DTLS (using OpenSSL)

Ive been using this guide http://blog.yunak.eu/2013/07/19/openconnect/
to get the hostscan(CSD) parts to work, the wrapper script is copied
from there. And this guide for the smartcard parts
http://www.gooze.eu/forums/support/howto-connect-to-cisco-anyconnect-vpn-using-openconnect-and-pki-token
.

The command im running is this:
sudo openconnect -c 'pkcs11:<PKCS11-PATH>' --csd-user=MYUSER -v
--csd-wrapper=./script/ciscowrapper.sh https://vpn.smhi.se

This works, i get a prompt asking for my PIN code(for the smartcard)
and then it asks wich group i belong to. When ive entered that
information i get connected. Then i disconnect and try again, this
time it does not work(exact same command). Output is this, it loops
indefinetly:

PIN required for Instant EID IP8 (identification)
Enter PIN:
Using client certificate 'MYUSER'
Adding supporting CA 'MYCA'
SSL negotiation with vpn.xyz.com
Connected to HTTPS on vpn.xyz.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive
Date: Tue, 04 Nov 2014 09:48:11 GMT
X-Aggregate-Auth: 1
HTTP body chunked (-2)
XML POST enabled
GET https://vpn.xyz.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.xyz.com
Connected to HTTPS on vpn.xyz.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Tue, 04 Nov 2014 09:48:12 GMT
HTTP body chunked (-2)
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.xyz.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.xyz.com
Connected to HTTPS on vpn.xyz.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Tue, 04 Nov 2014 09:48:14 GMT
HTTP body chunked (-2)
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.smhi.se/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.xyz.com
Connected to HTTPS on vpn.xyz.com
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Cache-Control: no-cache
Pragma: no-cache
Connection: Close

This goes on forever until i press ctrl+c, then it says:
Socket connect cancelled
Failed to reconnect to host vpn.smhi.se
Failed to open HTTPS connection to vpn.smhi.se
Failed to obtain WebVPN cookie

In the server logs it says "Certificate was succesfully validated"
over and over each time it loops trough the parts above. Nothing more.

The interesting part is if i wait for exactly 2 minutes and try again
it will work again like it did the first time. So this seems like a
timeout of some sort.

However, if i try the openconnect command with ??no?xmlpost it works
perfectly every time. The problem is that in the next step i would
like to use the Openconnect NetworkManager plugin and this does not
seem to have support for the ??no?xmlpost flag. Also the manual
(http://www.infradead.org/openconnect/manual.html) says to report if
the ??no?xmlpost flag is needed.

Can anyone give me any suggestions as to why this is not working as
expected ? Please let me know if i can provide any more information.


Best regards
Peter


From dwmw2 at infradead.org  Tue Nov  4 04:27:32 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 04 Nov 2014 12:27:32 +0000
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
Message-ID: <1415104052.32461.36.camel@infradead.org>

On Tue, 2014-11-04 at 11:15 +0100, Peter Magnusson wrote:
> In the server logs it says "Certificate was succesfully validated"
> over and over each time it loops trough the parts above. Nothing more.
> 
> The interesting part is if i wait for exactly 2 minutes and try again
> it will work again like it did the first time. So this seems like a
> timeout of some sort.
> 
> However, if i try the openconnect command with ??no?xmlpost it works
> perfectly every time. The problem is that in the next step i would
> like to use the Openconnect NetworkManager plugin and this does not
> seem to have support for the ??no?xmlpost flag. Also the manual
> (http://www.infradead.org/openconnect/manual.html) says to report if
> the ??no?xmlpost flag is needed.
> 
> Can anyone give me any suggestions as to why this is not working as
> expected ? Please let me know if i can provide any more information.

You should get a lot of log output in ~/.cisco/hostscan/log/cstub.log ?
especially if you set '-log debug' in your csd-wrapper.sh.

Can you compare those logs between successful and unsuccessful runs?

Also, how are you killing openconnect? Does it make a difference if you
send it SIGHUP and let it sign off gracefully, vs. SIGTERM to just kill
it. You're looking for a message saying 'Send BYE packet:' in the
graceful termination case.

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

From pet.magnusson at gmail.com  Tue Nov  4 06:41:28 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Tue, 4 Nov 2014 15:41:28 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <1415104052.32461.36.camel@infradead.org>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
Message-ID: <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>

Hi David,

Thank you for the reply. Ive enabled verbose log on cstub and compared
the logs now. On the run where it is Not working (the second run)
there are nothing at all being logged to the cstub.log.
So it seems the hostscan parts are not being executed at all for some
reason. On the run that is working(first run) i have alot of logentrys
in cstub.log. Also when running with --no-xmlpost cstub.log looks
normal aswell.

There is no difference in the behavior if i kill the openconnect
process with SIGTERM or SIGHUP. I can see that there are two
openconnect processes (one is the parent of the other) and when i
tested this i killed the parentprocess with SIGHUP/SIGTERM.

Best regards
Peter


On Tue, Nov 4, 2014 at 1:27 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2014-11-04 at 11:15 +0100, Peter Magnusson wrote:
>> In the server logs it says "Certificate was succesfully validated"
>> over and over each time it loops trough the parts above. Nothing more.
>>
>> The interesting part is if i wait for exactly 2 minutes and try again
>> it will work again like it did the first time. So this seems like a
>> timeout of some sort.
>>
>> However, if i try the openconnect command with ??no?xmlpost it works
>> perfectly every time. The problem is that in the next step i would
>> like to use the Openconnect NetworkManager plugin and this does not
>> seem to have support for the ??no?xmlpost flag. Also the manual
>> (http://www.infradead.org/openconnect/manual.html) says to report if
>> the ??no?xmlpost flag is needed.
>>
>> Can anyone give me any suggestions as to why this is not working as
>> expected ? Please let me know if i can provide any more information.
>
> You should get a lot of log output in ~/.cisco/hostscan/log/cstub.log ?
> especially if you set '-log debug' in your csd-wrapper.sh.
>
> Can you compare those logs between successful and unsuccessful runs?
>
> Also, how are you killing openconnect? Does it make a difference if you
> send it SIGHUP and let it sign off gracefully, vs. SIGTERM to just kill
> it. You're looking for a message saying 'Send BYE packet:' in the
> graceful termination case.
>
> --
> dwmw2


From pet.magnusson at gmail.com  Tue Nov  4 08:07:54 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Tue, 4 Nov 2014 17:07:54 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
Message-ID: <CAK0fpBgSAD_rG-qQXdVqYF-McAdFSSLcKi54sXwKeq8XjoKGBw@mail.gmail.com>

Just adding some more information. I just tested this with another
type of authentication (OTP) and this works fine. So the problem only
seems to be present when im authenticating with my smartcard.

On Tue, Nov 4, 2014 at 3:41 PM, Peter Magnusson <pet.magnusson at gmail.com> wrote:
> Hi David,
>
> Thank you for the reply. Ive enabled verbose log on cstub and compared
> the logs now. On the run where it is Not working (the second run)
> there are nothing at all being logged to the cstub.log.
> So it seems the hostscan parts are not being executed at all for some
> reason. On the run that is working(first run) i have alot of logentrys
> in cstub.log. Also when running with --no-xmlpost cstub.log looks
> normal aswell.
>
> There is no difference in the behavior if i kill the openconnect
> process with SIGTERM or SIGHUP. I can see that there are two
> openconnect processes (one is the parent of the other) and when i
> tested this i killed the parentprocess with SIGHUP/SIGTERM.
>
> Best regards
> Peter
>
>
> On Tue, Nov 4, 2014 at 1:27 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> On Tue, 2014-11-04 at 11:15 +0100, Peter Magnusson wrote:
>>> In the server logs it says "Certificate was succesfully validated"
>>> over and over each time it loops trough the parts above. Nothing more.
>>>
>>> The interesting part is if i wait for exactly 2 minutes and try again
>>> it will work again like it did the first time. So this seems like a
>>> timeout of some sort.
>>>
>>> However, if i try the openconnect command with ??no?xmlpost it works
>>> perfectly every time. The problem is that in the next step i would
>>> like to use the Openconnect NetworkManager plugin and this does not
>>> seem to have support for the ??no?xmlpost flag. Also the manual
>>> (http://www.infradead.org/openconnect/manual.html) says to report if
>>> the ??no?xmlpost flag is needed.
>>>
>>> Can anyone give me any suggestions as to why this is not working as
>>> expected ? Please let me know if i can provide any more information.
>>
>> You should get a lot of log output in ~/.cisco/hostscan/log/cstub.log ?
>> especially if you set '-log debug' in your csd-wrapper.sh.
>>
>> Can you compare those logs between successful and unsuccessful runs?
>>
>> Also, how are you killing openconnect? Does it make a difference if you
>> send it SIGHUP and let it sign off gracefully, vs. SIGTERM to just kill
>> it. You're looking for a message saying 'Send BYE packet:' in the
>> graceful termination case.
>>
>> --
>> dwmw2


From dwmw2 at infradead.org  Tue Nov  4 08:18:35 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 04 Nov 2014 16:18:35 +0000
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBgSAD_rG-qQXdVqYF-McAdFSSLcKi54sXwKeq8XjoKGBw@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAK0fpBgSAD_rG-qQXdVqYF-McAdFSSLcKi54sXwKeq8XjoKGBw@mail.gmail.com>
Message-ID: <1415117915.4591.0.camel@infradead.org>

On Tue, 2014-11-04 at 17:07 +0100, Peter Magnusson wrote:
> Just adding some more information. I just tested this with another
> type of authentication (OTP) and this works fine. So the problem only
> seems to be present when im authenticating with my smartcard.

That's interesting. What happens if you add --no-http-keepalive to the
command line?

-- 
dwmw2

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

From pet.magnusson at gmail.com  Tue Nov  4 08:51:51 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Tue, 4 Nov 2014 17:51:51 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <1415117915.4591.0.camel@infradead.org>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAK0fpBgSAD_rG-qQXdVqYF-McAdFSSLcKi54sXwKeq8XjoKGBw@mail.gmail.com>
 <1415117915.4591.0.camel@infradead.org>
Message-ID: <CAK0fpBi4W5pFmNq9B0SOB3VnP7XkfKEOk4_qrEg62LqKwP6WAA@mail.gmail.com>

Yea, this also interesting. When i try with --no-http-keepalive i
cannot connect at all and i get the behavior of the second run but all
the time.

Without --no-http-keepalive i can wait for two minutes and then i am
able to connect again buth with --no-http-keepalive i cannot connect
regardless of how long i wait (well atleast far more then 2 minutes).
It actually doesnt even work when i set --no-xmlpost flag.

On Tue, Nov 4, 2014 at 5:18 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Tue, 2014-11-04 at 17:07 +0100, Peter Magnusson wrote:
>> Just adding some more information. I just tested this with another
>> type of authentication (OTP) and this works fine. So the problem only
>> seems to be present when im authenticating with my smartcard.
>
> That's interesting. What happens if you add --no-http-keepalive to the
> command line?
>
> --
> dwmw2
>


From cernekee at gmail.com  Tue Nov  4 09:33:30 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Tue, 4 Nov 2014 09:33:30 -0800
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
Message-ID: <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>

On Tue, Nov 4, 2014 at 6:41 AM, Peter Magnusson <pet.magnusson at gmail.com> wrote:
> Hi David,
>
> Thank you for the reply. Ive enabled verbose log on cstub and compared
> the logs now. On the run where it is Not working (the second run)
> there are nothing at all being logged to the cstub.log.
> So it seems the hostscan parts are not being executed at all for some
> reason. On the run that is working(first run) i have alot of logentrys
> in cstub.log. Also when running with --no-xmlpost cstub.log looks
> normal aswell.

Are the arguments provided to the wrapper script different between the
two cases?

Is there any evidence that cstub is crashing on entry?  Do you see a
core file if you set "ulimit -c unlimited"?


From pet.magnusson at gmail.com  Wed Nov  5 00:53:17 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Wed, 5 Nov 2014 09:53:17 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
Message-ID: <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>

I tested this by editing the wrapperscript and adding an  'echo
"Arguments: $ARGS" >> /tmp/foo' . It seems the wrapperscript isnt
being run at all on the cases where it is not working cause nothing is
being written to /tmp/foo . When its working it looks like this:
-log debug -ticket "XXXXXXXXX" -stub "0" -group "" -host
"https://vpn.xyz.com/CACHE" -certhash "XXXXXXXXX:?
??ef?,?K^z??11T??D"

So if the wrapperscript is not being executed then cstub isnt being
executed either i guess so it cant be due to a cstub crash

On Tue, Nov 4, 2014 at 6:33 PM, Kevin Cernekee <cernekee at gmail.com> wrote:
> On Tue, Nov 4, 2014 at 6:41 AM, Peter Magnusson <pet.magnusson at gmail.com> wrote:
>> Hi David,
>>
>> Thank you for the reply. Ive enabled verbose log on cstub and compared
>> the logs now. On the run where it is Not working (the second run)
>> there are nothing at all being logged to the cstub.log.
>> So it seems the hostscan parts are not being executed at all for some
>> reason. On the run that is working(first run) i have alot of logentrys
>> in cstub.log. Also when running with --no-xmlpost cstub.log looks
>> normal aswell.
>
> Are the arguments provided to the wrapper script different between the
> two cases?
>
> Is there any evidence that cstub is crashing on entry?  Do you see a
> core file if you set "ulimit -c unlimited"?


From dwmw2 at infradead.org  Wed Nov  5 01:48:30 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 Nov 2014 09:48:30 +0000
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
 <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
Message-ID: <1415180910.17370.5.camel@infradead.org>

On Wed, 2014-11-05 at 09:53 +0100, Peter Magnusson wrote:
> I tested this by editing the wrapperscript and adding an  'echo
> "Arguments: $ARGS" >> /tmp/foo' . It seems the wrapperscript isnt
> being run at all on the cases where it is not working cause nothing is
> being written to /tmp/foo . When its working it looks like this:
> -log debug -ticket "XXXXXXXXX" -stub "0" -group "" -host
> "https://vpn.xyz.com/CACHE" -certhash "XXXXXXXXX:?
> ??ef?,?K^z??11T??D"

That -certhash argument looks horribly wrong. This ought to fix it but I
can't easily test because for me, gnutls_certificate_get_ours() is
returning failure (both for file and PKCS#11 certs). Got to run now;
will hassle Nikos about that later :)

diff --git a/gnutls.c b/gnutls.c
index 6e343d9..c8f2bae 100644
--- a/gnutls.c
+++ b/gnutls.c
@@ -2261,8 +2261,10 @@ int openconnect_local_cert_md5(struct
openconnect_info *vpninfo,
 			       char *buf)
 {
 	const gnutls_datum_t *d;
-	size_t md5len = 16;
-
+	unsigned char md5[MD5_SIZE];
+	size_t md5len = sizeof(md5);
+	int i;
+	
 	buf[0] = 0;
 
 	d = gnutls_certificate_get_ours(vpninfo->https_sess);
@@ -2272,6 +2274,9 @@ int openconnect_local_cert_md5(struct
openconnect_info *vpninfo,
 	if (gnutls_fingerprint(GNUTLS_DIG_MD5, d, buf, &md5len))
 		return -EIO;
 
+	for (i = 0; i < md5len; i++)
+		sprintf(&buf[i*2], "%02X", md5[i]);
+	
 	return 0;
 }
 



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

From pet.magnusson at gmail.com  Wed Nov  5 02:19:09 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Wed, 5 Nov 2014 11:19:09 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <1415180910.17370.5.camel@infradead.org>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
 <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
 <1415180910.17370.5.camel@infradead.org>
Message-ID: <CAK0fpBgjbrS6_xMP=5=kfEygG8nkzv4KVWFexGLGSL0+ynXG6Q@mail.gmail.com>

Just so there is no misunderstanding. The certhash that i posted,
thats how it looks when i works (apart from that i replaced the
readable parts with XXXXX).
When it doesnt work i cant see the certhash at all cause the
wrapperscript isnt being executed.



On Wed, Nov 5, 2014 at 10:48 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Wed, 2014-11-05 at 09:53 +0100, Peter Magnusson wrote:
>> I tested this by editing the wrapperscript and adding an  'echo
>> "Arguments: $ARGS" >> /tmp/foo' . It seems the wrapperscript isnt
>> being run at all on the cases where it is not working cause nothing is
>> being written to /tmp/foo . When its working it looks like this:
>> -log debug -ticket "XXXXXXXXX" -stub "0" -group "" -host
>> "https://vpn.xyz.com/CACHE" -certhash "XXXXXXXXX:?
>> ??ef?,?K^z??11T??D "
>
> That -certhash argument looks horribly wrong. This ought to fix it but I
> can't easily test because for me, gnutls_certificate_get_ours() is
> returning failure (both for file and PKCS#11 certs). Got to run now;
> will hassle Nikos about that later :)
>
> diff --git a/gnutls.c b/gnutls.c
> index 6e343d9..c8f2bae 100644
> --- a/gnutls.c
> +++ b/gnutls.c
> @@ -2261,8 +2261,10 @@ int openconnect_local_cert_md5(struct
> openconnect_info *vpninfo,
>                                char *buf)
>  {
>         const gnutls_datum_t *d;
> -       size_t md5len = 16;
> -
> +       unsigned char md5[MD5_SIZE];
> +       size_t md5len = sizeof(md5);
> +       int i;
> +
>         buf[0] = 0;
>
>         d = gnutls_certificate_get_ours(vpninfo->https_sess);
> @@ -2272,6 +2274,9 @@ int openconnect_local_cert_md5(struct
> openconnect_info *vpninfo,
>         if (gnutls_fingerprint(GNUTLS_DIG_MD5, d, buf, &md5len))
>                 return -EIO;
>
> +       for (i = 0; i < md5len; i++)
> +               sprintf(&buf[i*2], "%02X", md5[i]);
> +
>         return 0;
>  }
>
>
>
>
> --
> dwmw2


From n.mavrogiannopoulos at gmail.com  Wed Nov  5 02:50:08 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 5 Nov 2014 11:50:08 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <1415180910.17370.5.camel@infradead.org>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
 <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
 <1415180910.17370.5.camel@infradead.org>
Message-ID: <CAJU7zaJ2KJEViD8BVHJ63uSwvAJhGM=x186qCSccsXJgG7h0vA@mail.gmail.com>

On Wed, Nov 5, 2014 at 10:48 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> I tested this by editing the wrapperscript and adding an  'echo
>> "Arguments: $ARGS" >> /tmp/foo' . It seems the wrapperscript isnt
>> being run at all on the cases where it is not working cause nothing is
>> being written to /tmp/foo . When its working it looks like this:
>> -log debug -ticket "XXXXXXXXX" -stub "0" -group "" -host
>> "https://vpn.xyz.com/CACHE" -certhash "XXXXXXXXX:?
>> ??ef?,?K^z??11T??D "
> That -certhash argument looks horribly wrong. This ought to fix it but I
> can't easily test because for me, gnutls_certificate_get_ours() is
> returning failure (both for file and PKCS#11 certs). Got to run now;
> will hassle Nikos about that later :)

That prompted me to add a unit test and realized it works ok. My
understanding of the cisco server is that it requires and asks the
certificate once, on the first connection to the server (i.e., the one
that gets the cookie). After that you can establish new ssl
connections with the cookie without the certificate. Could that issue
be because of that (e.g., no hash to supply to the script)?

regards,
Nikos


From pet.magnusson at gmail.com  Wed Nov  5 03:03:03 2014
From: pet.magnusson at gmail.com (Peter Magnusson)
Date: Wed, 5 Nov 2014 12:03:03 +0100
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBgjbrS6_xMP=5=kfEygG8nkzv4KVWFexGLGSL0+ynXG6Q@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
 <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
 <1415180910.17370.5.camel@infradead.org>
 <CAK0fpBgjbrS6_xMP=5=kfEygG8nkzv4KVWFexGLGSL0+ynXG6Q@mail.gmail.com>
Message-ID: <CAK0fpBg77eQ1_S_Di4SYkGSwm95CjB1mmYfHxBRG=prwrd-TuA@mail.gmail.com>

I tested the patch you provided and it does make the certhash look
much nicer so that part seems to work fine now. Unfortunately im still
having the same problem as i described before.

On Wed, Nov 5, 2014 at 11:19 AM, Peter Magnusson
<pet.magnusson at gmail.com> wrote:
> Just so there is no misunderstanding. The certhash that i posted,
> thats how it looks when i works (apart from that i replaced the
> readable parts with XXXXX).
> When it doesnt work i cant see the certhash at all cause the
> wrapperscript isnt being executed.
>
>
>
> On Wed, Nov 5, 2014 at 10:48 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> On Wed, 2014-11-05 at 09:53 +0100, Peter Magnusson wrote:
>>> I tested this by editing the wrapperscript and adding an  'echo
>>> "Arguments: $ARGS" >> /tmp/foo' . It seems the wrapperscript isnt
>>> being run at all on the cases where it is not working cause nothing is
>>> being written to /tmp/foo . When its working it looks like this:
>>> -log debug -ticket "XXXXXXXXX" -stub "0" -group "" -host
>>> "https://vpn.xyz.com/CACHE" -certhash "XXXXXXXXX:?
>>> ??ef?,?K^z??11T??D "
>>
>> That -certhash argument looks horribly wrong. This ought to fix it but I
>> can't easily test because for me, gnutls_certificate_get_ours() is
>> returning failure (both for file and PKCS#11 certs). Got to run now;
>> will hassle Nikos about that later :)
>>
>> diff --git a/gnutls.c b/gnutls.c
>> index 6e343d9..c8f2bae 100644
>> --- a/gnutls.c
>> +++ b/gnutls.c
>> @@ -2261,8 +2261,10 @@ int openconnect_local_cert_md5(struct
>> openconnect_info *vpninfo,
>>                                char *buf)
>>  {
>>         const gnutls_datum_t *d;
>> -       size_t md5len = 16;
>> -
>> +       unsigned char md5[MD5_SIZE];
>> +       size_t md5len = sizeof(md5);
>> +       int i;
>> +
>>         buf[0] = 0;
>>
>>         d = gnutls_certificate_get_ours(vpninfo->https_sess);
>> @@ -2272,6 +2274,9 @@ int openconnect_local_cert_md5(struct
>> openconnect_info *vpninfo,
>>         if (gnutls_fingerprint(GNUTLS_DIG_MD5, d, buf, &md5len))
>>                 return -EIO;
>>
>> +       for (i = 0; i < md5len; i++)
>> +               sprintf(&buf[i*2], "%02X", md5[i]);
>> +
>>         return 0;
>>  }
>>
>>
>>
>>
>> --
>> dwmw2


From dwmw2 at infradead.org  Wed Nov  5 03:07:01 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 Nov 2014 11:07:01 +0000
Subject: Openconnect no-xmlpost
In-Reply-To: <CAJU7zaJ2KJEViD8BVHJ63uSwvAJhGM=x186qCSccsXJgG7h0vA@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
 <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
 <1415180910.17370.5.camel@infradead.org>
 <CAJU7zaJ2KJEViD8BVHJ63uSwvAJhGM=x186qCSccsXJgG7h0vA@mail.gmail.com>
Message-ID: <1415185621.17370.7.camel@infradead.org>

On Wed, 2014-11-05 at 11:50 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, Nov 5, 2014 at 10:48 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> >> I tested this by editing the wrapperscript and adding an  'echo
> >> "Arguments: $ARGS" >> /tmp/foo' . It seems the wrapperscript isnt
> >> being run at all on the cases where it is not working cause nothing is
> >> being written to /tmp/foo . When its working it looks like this:
> >> -log debug -ticket "XXXXXXXXX" -stub "0" -group "" -host
> >> "https://vpn.xyz.com/CACHE" -certhash "XXXXXXXXX:?
> >> ??ef?,?K^z??11T??D "
> > That -certhash argument looks horribly wrong. This ought to fix it but I
> > can't easily test because for me, gnutls_certificate_get_ours() is
> > returning failure (both for file and PKCS#11 certs). Got to run now;
> > will hassle Nikos about that later :)
> 
> That prompted me to add a unit test and realized it works ok. My
> understanding of the cisco server is that it requires and asks the
> certificate once, on the first connection to the server (i.e., the one
> that gets the cookie). After that you can establish new ssl
> connections with the cookie without the certificate. Could that issue
> be because of that (e.g., no hash to supply to the script)?

Yeah, I'm just looking at it now. If we *do* get asked for the client
cert, then gnutls_certificate_get_ours() returns it. If we happen to
have *not* been asked for the certificate on the latest connection to
the server, then gnutls_certificate_get_ours() doesn't do what we want.

I think I need a way to return the hash of the certificate which we
*would* have offered, if the server had asked for it. Which might mean
precalculating it in our load_certificate() function.

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

From dwmw2 at infradead.org  Wed Nov  5 03:17:05 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 Nov 2014 11:17:05 +0000
Subject: Openconnect no-xmlpost
In-Reply-To: <CAK0fpBg77eQ1_S_Di4SYkGSwm95CjB1mmYfHxBRG=prwrd-TuA@mail.gmail.com>
References: <CAK0fpBh9u_yV9TThrxW4TN6qmBDqyUSw+0E=duRPdGJP69h38A@mail.gmail.com>
 <1415104052.32461.36.camel@infradead.org>
 <CAK0fpBhk_8qiAEHyN6uW0xxYcdcZ=FibzjFvRWeePea-fywbyA@mail.gmail.com>
 <CAJiQ=7Deds6AWENmkz5XWQ5aYiuo8vcVNkuZZxTXLEWK6J=q1A@mail.gmail.com>
 <CAK0fpBjU2qS3Df8+_gEorpgxQ+xgOKR72DDD2bdVQSCuVy85hw@mail.gmail.com>
 <1415180910.17370.5.camel@infradead.org>
 <CAK0fpBgjbrS6_xMP=5=kfEygG8nkzv4KVWFexGLGSL0+ynXG6Q@mail.gmail.com>
 <CAK0fpBg77eQ1_S_Di4SYkGSwm95CjB1mmYfHxBRG=prwrd-TuA@mail.gmail.com>
Message-ID: <1415186225.17370.9.camel@infradead.org>

On Wed, 2014-11-05 at 12:03 +0100, Peter Magnusson wrote:
> I tested the patch you provided and it does make the certhash look
> much nicer so that part seems to work fine now.

The patch I sent wasn't quite correct; you were just getting a hex dump
of a random part of the stack instead of a hash of the cert. Fixed and
pushed to git now.

>  Unfortunately im still having the same problem as i described before.

Right. That will be an orthogonal issue. Can we see the full output of
'openconnect -vv --dump-http-traffic' on the offending run, please?

Perhaps just to Kevin and/or myself, and/or vet it for sensitive
information first. But I don't think you've entered any passwords by the
time it goes wrong, have you? And you already gave us the hostname, so I
don't *think* there'll be anything sensitive in there. Do check though.

I wonder if the server is conflating the two connection attempts. When
we're asked to run the CSD trojan, we're given a 'CSD token' for it to
submit its results with. We are expected to put that token into a cookie
named 'sdesktop' for the subsequent HTTP requests from OpenConnect.

If you run OpenConnect again too soon, perhaps it's still expecting your
requests to bear the *same* CSD token, and that's why it doesn't tell
you to run the CSD trojan again.

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

From dwmw2 at infradead.org  Wed Nov  5 13:59:26 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 05 Nov 2014 21:59:26 +0000
Subject: Release imminent
Message-ID: <1415224766.17370.30.camel@infradead.org>

I think I've fairly much done everything that I had on the TODO list for
the next release. I've fixed up the GNOME and KDE dialogs to cope with
the new APIs. Unless Nikos or Kevin scream that I've broken something
for Windows or Android, or something comes up in testing in the next
week or so, I'll probably release it as 7.00.

Anything I've missed?

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

From kajmagnus79 at gmail.com  Wed Nov  5 22:38:40 2014
From: kajmagnus79 at gmail.com (Kaj Magnus Lindberg)
Date: Thu, 6 Nov 2014 07:38:40 +0100
Subject: OpenConnect suddenly cannot connect to VPN server: refreshes
 wait.html forever
Message-ID: <CAKb=CArzPqSzk=Wyc+fX9vqJE4TC5bunafi64CuONjbq6u0qyg@mail.gmail.com>

Hi,

(I posted this question at SuperUser.com [1] yesterday, but no reply
thus far, so I thought I should ask the mailing list; it seems to be
the official help channel.)

In the past I could connect to a certain Cisco VPN server. I've been
away travelling for 7 weeks, and now I'm back home, but no longer able
to connect to the VPN server. Now the server suddenly asks me to run a
'Cisco Secure Desktop' trojan, and I've configured OpenConnect to do
this (both via a GUI dialog, and the `--csd-user` command line option
to `openconnect`), still I'm no longer able to get the VPN connection
working.

The VPN connection log ends with these four lines repeated over and over again:
```
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
```

Do you have any idea about what's happening or how I can fix this?

Would you guess that the problem is a VPN server side configuration
change? The 'Cisco Secure Desctop' script perhaps? The VPN server has
never asked me to run the 'Cisco Secure Desktop' script before, when I
was able to connect. ? Or do you think my OS has upgraded OpenConnect
to a somehow incompatible version?

Other people are able to connect to the VPN server ? they use Mac or
Windows, not Linux, though.
My OS: Linux Mint 17. OpenConnect version v5.02.

Things I've tested:

1. I read at:  https://bbs.archlinux.org/viewtopic.php?pid=1172567#p1172567
that I could wrap the 'Cisco Secure Desktop' script in a shell script,
via the --csd-wrapperoption; the suggested script looks like below,
but running it had no effect.
```
#!/bin/bash -x
exec 2>&1 > /dev/null
CSD_BINARY="$1"
shift
$CSD_BINARY "$@"
```

2. I read at:
http://lists.infradead.org/pipermail/openconnect-devel/2013-July/001119.html
that the `--no-xmlpost` flag might help; it didn't have any effect though.

3. I read at:  http://lists.infradead.org/pipermail/openconnect-devel/2013-July/001117.html
that the 'Cisco Secure Desctop' script might need 32 bit support, but
apparently my OS already has that:
```
$ dpkg --print-foreign-architectures
i386
```

Someone else has encountered the same problem:
http://nerdanswer.com/answer.php?q=327709
(It's a ServerFault question, but it was apparently deleted at
ServerFault, off-topic over there I'd guess. There were no answers to
the question.)

Here's the full OpenConnect log:
```
POST https://vpn.server.com/
Attempting to connect to server 111.222.333.444:443
Using client certificate 'My-Full-Name'
Adding supporting CA 'TC TrustCenter Class 2 L1 CA XI'
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://vpn.server.com/
Attempting to connect to server 111.222.333.444:443
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Got HTTP response: HTTP/1.0 302 Object Moved
GET https://vpn.server.com/+webvpn+/index.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
GET https://vpn.server.com/CACHE/sdesktop/install/binaries/sfinst
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
GET https://vpn.server.com/+CSCOE+/sdesktop/wait.html
SSL negotiation with vpn.server.com
Connected to HTTPS on vpn.server.com
Refreshing +CSCOE+/sdesktop/wait.html after 1 second...
(... continues forever)
```

Thanks for your time and any help,
Best regards,
KajMagnus

[1]: http://superuser.com/questions/836157/openconnect-cannot-connect-to-vpn-server-refreshes-wait-html-forever


From altangerel at mobicom.mn  Wed Nov  5 23:00:23 2014
From: altangerel at mobicom.mn (altangerel at mobicom.mn)
Date: Thu, 6 Nov 2014 07:00:23 +0000
Subject: Cannot install Openconnect 6.0 on Kali linux
Message-ID: <8338B0524F9FA44A97CF7E8D768130A330A003CC@MAILMB2.net.mobicom>

Hi all,

I'm trying to install OpenConnect 6.0 and Network manager 0.9.10 on Kali 1.0.9. Because latest version is not available in apt, I'm trying to install it from the source tarball. Unfortunately, I could not  do that because of too much dependency issues. How can I install it with easier way?

Regards,
Aggie


This email (including any attachments) is intended only to be read and used by the addressee.
It may contain confidential or legally privileged information, which is not waived if it is mistakenly delivered to you.
If you are not the intended recipient please immediately notify the sender by return email and delete both messages from your system.


From mybluebluesky2 at 163.com  Thu Nov  6 17:59:03 2014
From: mybluebluesky2 at 163.com (xiao)
Date: Fri, 7 Nov 2014 09:59:03 +0800 (CST)
Subject: A problem with openconnect On Windows
Message-ID: <62c1868c.301b.14987f9eb7c.Coremail.mybluebluesky2@163.com>

Hello,

I compiled the ?newest openconnect in git for Windows?And run it on Win 7 (in a LAN) to connect the ocserv 0.8.4 (in the public network)?
Everything is OK when connecting.

And I ?can visit the internet by browser ?through the VPN tunnel.

But sometimes I can't ?visit the internet through the VPN tunnel,although the VPN tunnel exists well.

At this moment ,I find the route table is right. like below


IPv4 Route Table
===========================================================================
Active Routes:
Network Destination ? ? ? ?Netmask ? ? ? ? ?Gateway ? ? ? Interface ?Metric
? ? ? ? ?0.0.0.0 ? ? ? ? ?0.0.0.0 ? ? ?192.168.0.1 ? ?192.168.0.216 ? ? 20
? ? ? ? ?0.0.0.0 ? ? ? ? ?0.0.0.0 ? ? ? ? 10.1.1.1 ? ? ? 10.1.1.209 ? ? ?2
? ? ? ? 10.1.1.0 ? ?255.255.255.0 ? ? ? ? On-link ? ? ? ?10.1.1.209 ? ?257
? ? ? 10.1.1.209 ?255.255.255.255 ? ? ? ? On-link ? ? ? ?10.1.1.209 ? ?257
? ? ? 10.1.1.255 ?255.255.255.255 ? ? ? ? On-link ? ? ? ?10.1.1.209 ? ?257
? ?104.149.5.138 ?255.255.255.255 ? ? ?192.168.0.1 ? ?192.168.0.216 ? ? 21
? ? ? ?127.0.0.0 ? ? ? ?255.0.0.0 ? ? ? ? On-link ? ? ? ? 127.0.0.1 ? ?306
? ? ? ?127.0.0.1 ?255.255.255.255 ? ? ? ? On-link ? ? ? ? 127.0.0.1 ? ?306
?127.255.255.255 ?255.255.255.255 ? ? ? ? On-link ? ? ? ? 127.0.0.1 ? ?306
? ? ?192.168.0.0 ? ?255.255.255.0 ? ? ? ? On-link ? ? 192.168.0.216 ? ?276
? ?192.168.0.216 ?255.255.255.255 ? ? ? ? On-link ? ? 192.168.0.216 ? ?276
? ?192.168.0.255 ?255.255.255.255 ? ? ? ? On-link ? ? 192.168.0.216 ? ?276
? ? 192.168.71.0 ? ?255.255.255.0 ? ? ? ? On-link ? ? ?192.168.71.1 ? ?276
? ? 192.168.71.1 ?255.255.255.255 ? ? ? ? On-link ? ? ?192.168.71.1 ? ?276
? 192.168.71.255 ?255.255.255.255 ? ? ? ? On-link ? ? ?192.168.71.1 ? ?276
? ?192.168.252.0 ? ?255.255.255.0 ? ? ? ? On-link ? ? 192.168.252.1 ? ?276
? ?192.168.252.1 ?255.255.255.255 ? ? ? ? On-link ? ? 192.168.252.1 ? ?276
?192.168.252.255 ?255.255.255.255 ? ? ? ? On-link ? ? 192.168.252.1 ? ?276
? ? ? ?224.0.0.0 ? ? ? ?240.0.0.0 ? ? ? ? On-link ? ? ? ? 127.0.0.1 ? ?306
? ? ? ?224.0.0.0 ? ? ? ?240.0.0.0 ? ? ? ? On-link ? ? 192.168.0.216 ? ?276
? ? ? ?224.0.0.0 ? ? ? ?240.0.0.0 ? ? ? ? On-link ? ? ? ?10.1.1.209 ? ?257
? ? ? ?224.0.0.0 ? ? ? ?240.0.0.0 ? ? ? ? On-link ? ? ?192.168.71.1 ? ?276
? ? ? ?224.0.0.0 ? ? ? ?240.0.0.0 ? ? ? ? On-link ? ? 192.168.252.1 ? ?276
?255.255.255.255 ?255.255.255.255 ? ? ? ? On-link ? ? ? ? 127.0.0.1 ? ?306
?255.255.255.255 ?255.255.255.255 ? ? ? ? On-link ? ? 192.168.0.216 ? ?276
?255.255.255.255 ?255.255.255.255 ? ? ? ? On-link ? ? ? ?10.1.1.209 ? ?257
?255.255.255.255 ?255.255.255.255 ? ? ? ? On-link ? ? ?192.168.71.1 ? ?276
?255.255.255.255 ?255.255.255.255 ? ? ? ? On-link ? ? 192.168.252.1 ? ?276
===========================================================================
Persistent Routes:
?Network Address ? ? ? ? ?Netmask ?Gateway Address ?Metric
? ? ? ? ?0.0.0.0 ? ? ? ? ?0.0.0.0 ? ? ? ? 10.1.1.1 ? ? ? 1
===========================================================================



But when I use the tracert tool under cmd ?,I find that the first hop is not the interface " 10.1.1.209" but ?my ?real public IP.

And when I wait for sometime, I use the tracert tool under cmd ,the first hop change to ?the interface " 10.1.1.208" ,And at this moment I can visist the internet Again.

This Situation will Repeat.

best regards
xiao

From cernekee at gmail.com  Thu Nov  6 18:07:28 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Thu, 6 Nov 2014 18:07:28 -0800
Subject: Release imminent
In-Reply-To: <1415224766.17370.30.camel@infradead.org>
References: <1415224766.17370.30.camel@infradead.org>
Message-ID: <CAJiQ=7A=VKo_=Gpd87c-3PQcWo9Ap3mZ8HDK7UkzeUqM+CMV6Q@mail.gmail.com>

On Wed, Nov 5, 2014 at 1:59 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> I think I've fairly much done everything that I had on the TODO list for
> the next release. I've fixed up the GNOME and KDE dialogs to cope with
> the new APIs. Unless Nikos or Kevin scream that I've broken something
> for Windows or Android, or something comes up in testing in the next
> week or so, I'll probably release it as 7.00.

I suppose we may want to fix up (or document) some of the Android
Lollipop compatibility issues, now that the new Nexus devices have
been released:

1) Enable PIE builds.  Required for Lollipop, but it breaks ICS and below:

https://code.google.com/p/android-developer-preview/issues/detail?id=888

2) Allow building for 64-bit CPUs.  I started on this a few months ago
but there were some changes in Bionic that caused compile failures in
gnulib, breaking some of our dependencies.  Need to retest with NDK
r10c and/or fix gnulib.


From kajmagnus79 at gmail.com  Thu Nov  6 20:12:39 2014
From: kajmagnus79 at gmail.com (Kaj Magnus Lindberg)
Date: Fri, 7 Nov 2014 05:12:39 +0100
Subject: OpenConnect suddenly cannot connect to VPN server: refreshes
 wait.html forever
In-Reply-To: <CAKb=CArzPqSzk=Wyc+fX9vqJE4TC5bunafi64CuONjbq6u0qyg@mail.gmail.com>
References: <CAKb=CArzPqSzk=Wyc+fX9vqJE4TC5bunafi64CuONjbq6u0qyg@mail.gmail.com>
Message-ID: <CAKb=CArn4TXc0UhQ-xMs-GRkv+rW=Q3X4-PQViWJDCXcba_g9g@mail.gmail.com>

Hi again,

I just found out that the problem is that the VPN server has been
replaced / modified to no longer support Linux, and all old
certificates have been invalidated.

So I think there were two problems causing the weird error messages:
1) Linux not supported, and 2) wrong certificate.

Best regards,
KajMagnus

On Thu, Nov 6, 2014 at 7:38 AM, Kaj Magnus Lindberg
<kajmagnus79 at gmail.com> wrote:
> Hi,
[...]
>
> In the past I could connect to a certain Cisco VPN server. I've been
> away travelling for 7 weeks, and now I'm back home, but no longer able
> to connect to the VPN server.
[...]


From dwmw2 at infradead.org  Fri Nov  7 01:21:41 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 07 Nov 2014 09:21:41 +0000
Subject: Release imminent
In-Reply-To: <CAJiQ=7A=VKo_=Gpd87c-3PQcWo9Ap3mZ8HDK7UkzeUqM+CMV6Q@mail.gmail.com>
References: <1415224766.17370.30.camel@infradead.org>
 <CAJiQ=7A=VKo_=Gpd87c-3PQcWo9Ap3mZ8HDK7UkzeUqM+CMV6Q@mail.gmail.com>
Message-ID: <1415352101.17370.56.camel@infradead.org>

On Thu, 2014-11-06 at 18:07 -0800, Kevin Cernekee wrote:
> On Wed, Nov 5, 2014 at 1:59 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> > I think I've fairly much done everything that I had on the TODO list for
> > the next release. I've fixed up the GNOME and KDE dialogs to cope with
> > the new APIs. Unless Nikos or Kevin scream that I've broken something
> > for Windows or Android, or something comes up in testing in the next
> > week or so, I'll probably release it as 7.00.
> 
> I suppose we may want to fix up (or document) some of the Android
> Lollipop compatibility issues, now that the new Nexus devices have
> been released:
> 
> 1) Enable PIE builds.  Required for Lollipop, but it breaks ICS and below:
> 
> https://code.google.com/p/android-developer-preview/issues/detail?id=888
> 
> 2) Allow building for 64-bit CPUs.  I started on this a few months ago
> but there were some changes in Bionic that caused compile failures in
> gnulib, breaking some of our dependencies.  Need to retest with NDK
> r10c and/or fix gnulib.

You may also want something like this in libstoken
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/17a18f1f8

To use the updated libopenconnect, at the very least you need this:

--- a/src/app/openconnect/core/OpenConnectManagementThread.java
+++ b/src/app/openconnect/core/OpenConnectManagementThread.java
@@ -164,7 +164,7 @@ public class OpenConnectManagementThread implements Runnable, OpenVPNManagement
 			log("CALLBACK: onValidatePeerCert");
 
 			// This can be called repeatedly on the same (re)connection attempt
-			String hash = getCertSHA1().toLowerCase(Locale.US);
+			String hash = getPeerCertHash();
 			if (isCertAccepted(hash)) {
 				return 0;
 			}



... but actually, there are other issues with the cert management.
Ideally you should be storing the host/port for which a cert was
manually accepted, and only accepting it in future for that host/port
rather than for *anything*. And for the certs which are stored
permanently you should now be using checkPeerCertHash() instead of just
comparing the string for equality.

It's OK to still do the simple check against mAcceptedCerts and
mRejectedCerts because we don't expect the library to change the hash it
uses in the lifetime of a single process. But the cert hashes stored in
the ACCEPTED-CERT-* keys need to be use the comparison function.

One option is to use ACCEPTED-CERT-$HOST-$PORT as the key name, and then
compare the value you get. Having done that for NetworkManager, though,
it now occurs to me that it doesn't allow for multiple certs per host ?
which might be wanted if it's a r?le address (like vpn.intel.com is).
But then again, in such situations there really *ought* to be a CA you
should be installing, rather than just manually accepting a self-signed
cert from a standalone server. So maybe it's OK.

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

From dwmw2 at infradead.org  Fri Nov  7 01:26:57 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 07 Nov 2014 09:26:57 +0000
Subject: OpenConnect suddenly cannot connect to VPN server: refreshes
 wait.html forever
In-Reply-To: <CAKb=CArn4TXc0UhQ-xMs-GRkv+rW=Q3X4-PQViWJDCXcba_g9g@mail.gmail.com>
References: <CAKb=CArzPqSzk=Wyc+fX9vqJE4TC5bunafi64CuONjbq6u0qyg@mail.gmail.com>
 <CAKb=CArn4TXc0UhQ-xMs-GRkv+rW=Q3X4-PQViWJDCXcba_g9g@mail.gmail.com>
Message-ID: <1415352417.17370.58.camel@infradead.org>

On Fri, 2014-11-07 at 05:12 +0100, Kaj Magnus Lindberg wrote:
> Hi again,
> 
> I just found out that the problem is that the VPN server has been
> replaced / modified to no longer support Linux, and all old
> certificates have been invalidated.
> 
> So I think there were two problems causing the weird error messages:
> 1) Linux not supported, and 2) wrong certificate.

Perhaps you can get a certificate from a Windows box using JailBreak,
and then it shouldn't be impossible to make the CSD stuff work even if
it does only support Windows. You just need to work out what a 'valid'
response from a Windows box looks like, and rig something up to always
post that :)

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

From niels at peen.ch  Fri Nov  7 04:57:01 2014
From: niels at peen.ch (Niels Peen)
Date: Fri, 7 Nov 2014 20:57:01 +0800
Subject: OpenConnect-GUI: A record packet with illegal version was
 received.
In-Reply-To: <1414940484.11111.2.camel@nomad.lan>
References: <349D908E-8A20-417E-95D7-818A55982D3F@peen.ch>
 <1414940484.11111.2.camel@nomad.lan>
Message-ID: <BEBA621D-3C8A-4034-949D-DEC0588E0207@peen.ch>

>> 2014-11-02 17:54 POST https://XXXXX/
>> 2014-11-02 17:54 Attempting to connect to server 123.123.123.123:443
>> 2014-11-02 17:54 SSL negotiation with XXXXX
>> 2014-11-02 17:54 SSL connection failure: A record packet with illegal version was received.
> 
> The cases that this can happen is when there are no commonly supported
> protocols, or the peer doesn't correctly set the TLS record versions.
> That's almost impossible to occur between two gnutls peers. Could that
> again be related to a firewall that modifies the packets sent/received?

Possible. The user turned off their firewall (ESET), but I?m not convinced 
that turning it off completely restores normal behaviour.

Niels

From nmav at gnutls.org  Fri Nov  7 07:08:54 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 7 Nov 2014 16:08:54 +0100
Subject: OpenConnect-GUI: A record packet with illegal version was
 received.
In-Reply-To: <BEBA621D-3C8A-4034-949D-DEC0588E0207@peen.ch>
References: <349D908E-8A20-417E-95D7-818A55982D3F@peen.ch>
 <1414940484.11111.2.camel@nomad.lan>
 <BEBA621D-3C8A-4034-949D-DEC0588E0207@peen.ch>
Message-ID: <CAJU7zaKU9zDokDLfAUmpR4-U0RXOfXsT13dfmwCCZf+jv8BR9w@mail.gmail.com>

On Fri, Nov 7, 2014 at 1:57 PM, Niels Peen <niels at peen.ch> wrote:

>> The cases that this can happen is when there are no commonly supported
>> protocols, or the peer doesn't correctly set the TLS record versions.
>> That's almost impossible to occur between two gnutls peers. Could that
>> again be related to a firewall that modifies the packets sent/received?
> Possible. The user turned off their firewall (ESET), but I'm not convinced
> that turning it off completely restores normal behaviour.

You mean he still cannot connect even after turning it off? If he gets
the same error, could he be in a corporate firewall that tries to
perform man-in-the-middle? Having a wireshark transcript of his
sessions would help identify the issue.

regards,
Nikos


From dwmw2 at infradead.org  Fri Nov  7 08:45:22 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 07 Nov 2014 16:45:22 +0000
Subject: Intend to remove openconnect_set_server_cert_sha1()
Message-ID: <1415378722.17370.71.camel@infradead.org>

I don't think anyone uses this except openconnect(8). It's redundant
since you can just call openconnect_set_system_trust(vpninfo, 0) and
then do the check in your own verify_cert callback.

I know that none of the Windows, Android, GNOME and KDE tools use it,
and I'd be surprised if Shimo does.

So I'm going to move the handling of --servercert into main.c and kill
the API function. At some point over the weekend, unless someone
screams.

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

From n.mavrogiannopoulos at gmail.com  Fri Nov  7 14:11:27 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 7 Nov 2014 23:11:27 +0100
Subject: A problem with openconnect On Windows
In-Reply-To: <62c1868c.301b.14987f9eb7c.Coremail.mybluebluesky2@163.com>
References: <62c1868c.301b.14987f9eb7c.Coremail.mybluebluesky2@163.com>
Message-ID: <CAJU7za+WMKPj_wW8RwvCaS3jOgzD5a_Wa9pCZwxt+cEme+Yuyg@mail.gmail.com>

On Fri, Nov 7, 2014 at 2:59 AM, xiao <mybluebluesky2 at 163.com> wrote:
> Hello,
>
> I compiled the  newest openconnect in git for Windows?And run it on Win 7 (in a LAN) to connect the ocserv 0.8.4 (in the public network)?
> Everything is OK when connecting.
>
> And I  can visit the internet by browser  through the VPN tunnel.
>
> But sometimes I can't  visit the internet through the VPN tunnel,although the VPN tunnel exists well.
> At this moment ,I find the route table is right. like below
[...]
> But when I use the tracert tool under cmd  ,I find that the first hop is not the interface " 10.1.1.209" but  my  real public IP.
> And when I wait for sometime, I use the tracert tool under cmd ,the first hop change to  the interface " 10.1.1.208" ,And at this moment I can visist the internet Again.

As far as I understand that is because you have two default routes.
Your real public IP gw has one with metric 20, and your VPN's has
metric 2.
You'll have to play with vpnc-script-win.js to achieve what you'd like
to do. Once you do, please let us know too...

regards,
Nikos


From ismail at donmez.ws  Mon Nov 10 06:37:13 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Mon, 10 Nov 2014 16:37:13 +0200
Subject: oscserv error: "could not determine the owner of received UDP packet"
Message-ID: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>

Hi,

I am using NetworkManager-openconnect (version 0.9.10.0) against
ocserv.git and after being connected for like ~30 minutes VPN stops
accepting any packets. Turns out that there is some weird stuff going
on.

Looking at the attached log first connection happens at 14:11:12 and
even though I don't click anything from the UI to reconnect etc a new
connection starts at 14:25:56 and this wreaks havoc. I am not sure if
this is a client bug or a server one.

Any help is appreciated.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openconnect.log
Type: text/x-log
Size: 16410 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141110/bcf3560c/attachment.bin>

From n.mavrogiannopoulos at gmail.com  Mon Nov 10 07:05:18 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 10 Nov 2014 16:05:18 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
Message-ID: <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>

On Mon, Nov 10, 2014 at 3:37 PM, ?smail D?nmez <ismail at donmez.ws> wrote:
> Hi,
>
> I am using NetworkManager-openconnect (version 0.9.10.0) against
> ocserv.git and after being connected for like ~30 minutes VPN stops
> accepting any packets. Turns out that there is some weird stuff going
> on.

Hello,
 From the log that you sent it seems that your firewall discarded the
previous UDP session association. That is the new UDP traffic is being
received from a different port, and the main server is now receiving
the UDP traffic. This is harmless, as ocserv will forward the new
session to worker.

> Looking at the attached log first connection happens at 14:11:12 and
> even though I don't click anything from the UI to reconnect etc a new
> connection starts at 14:25:56 and this wreaks havoc. I am not sure if
> this is a client bug or a server one.

That is when the main process received the new session and forwarded
it to the worker process, the worker process believed the previous was
active (received some message from the previous session the last 30
seconds). That should cancel out after 30 seconds. I've reduced the
severity of these messages to avoid spamming the log.

regards,
Nikos


From mybluebluesky2 at 163.com  Mon Nov 10 18:12:45 2014
From: mybluebluesky2 at 163.com (xiao)
Date: Tue, 11 Nov 2014 10:12:45 +0800 (CST)
Subject: A problem with openconnect On Windows
In-Reply-To: <CAJU7za+WMKPj_wW8RwvCaS3jOgzD5a_Wa9pCZwxt+cEme+Yuyg@mail.gmail.com>
References: <62c1868c.301b.14987f9eb7c.Coremail.mybluebluesky2@163.com>
 <CAJU7za+WMKPj_wW8RwvCaS3jOgzD5a_Wa9pCZwxt+cEme+Yuyg@mail.gmail.com>
Message-ID: <5c3b88e5.2fb7.1499c9fe7ea.Coremail.mybluebluesky2@163.com>

>As far as I understand that is because you have two default routes.

>Your real public IP gw has one with metric 20, and your VPN's has
>metric 2.
  
  Yes, I delete the default route like " route delete 0.0.0.0 mask 0.0.0.0 192.168.0.1" after the connection being established,and test it ,it  is  effective .  

>You'll have to play with vpnc-script-win.js to achieve what you'd like
>to do. Once you do, please let us know too...

   OK,I will delete the default route after connection established ,and add it after disconnect(just like OpenVPN do)
 
   I find that the openconnect source code of Windows do not  receive the cancel signal  sended by the user (although the linux version do it ).

   so the  disconnect item  of the vpnc-script-win.js will not run on Windows.  I want to add the default route in the disconnect item.

regards,
xiao guang

From n.mavrogiannopoulos at gmail.com  Tue Nov 11 03:48:37 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 11 Nov 2014 12:48:37 +0100
Subject: A problem with openconnect On Windows
In-Reply-To: <5c3b88e5.2fb7.1499c9fe7ea.Coremail.mybluebluesky2@163.com>
References: <62c1868c.301b.14987f9eb7c.Coremail.mybluebluesky2@163.com>
 <CAJU7za+WMKPj_wW8RwvCaS3jOgzD5a_Wa9pCZwxt+cEme+Yuyg@mail.gmail.com>
 <5c3b88e5.2fb7.1499c9fe7ea.Coremail.mybluebluesky2@163.com>
Message-ID: <CAJU7za+ULCZsaVMypTx=o8qfo5isFgihS872oJm_9E=yyj6gFA@mail.gmail.com>

On Tue, Nov 11, 2014 at 3:12 AM, xiao <mybluebluesky2 at 163.com> wrote:
>>You'll have to play with vpnc-script-win.js to achieve what you'd like
>>to do. Once you do, please let us know too...
>    OK,I will delete the default route after connection established ,and add it after disconnect(just like OpenVPN do)
>    I find that the openconnect source code of Windows do not  receive the cancel signal  sended by the user (although the linux version do it ).
>    so the  disconnect item  of the vpnc-script-win.js will not run on Windows.  I want to add the default route in the disconnect item.

Interesting. When you press the disconnect button openconnect-gui
sends the detach command to libopenconnect which should have ran the
script. Isn't that the case?

regards,
Nikos


From mybluebluesky2 at 163.com  Wed Nov 12 02:00:30 2014
From: mybluebluesky2 at 163.com (xiao)
Date: Wed, 12 Nov 2014 18:00:30 +0800 (CST)
Subject: A problem with openconnect On Windows
In-Reply-To: <CAJU7za+ULCZsaVMypTx=o8qfo5isFgihS872oJm_9E=yyj6gFA@mail.gmail.com>
References: <62c1868c.301b.14987f9eb7c.Coremail.mybluebluesky2@163.com>
 <CAJU7za+WMKPj_wW8RwvCaS3jOgzD5a_Wa9pCZwxt+cEme+Yuyg@mail.gmail.com>
 <5c3b88e5.2fb7.1499c9fe7ea.Coremail.mybluebluesky2@163.com>
 <CAJU7za+ULCZsaVMypTx=o8qfo5isFgihS872oJm_9E=yyj6gFA@mail.gmail.com>
Message-ID: <2ec733b0.24337.149a37280c3.Coremail.mybluebluesky2@163.com>


Hi,

>Interesting. When you press the disconnect button openconnect-gui
>sends the detach command to libopenconnect which should have ran the
>script. Isn't that the case?

 
  Sorry about that I hadn't explained it well. In fact,I am testing the openconnect of command line version in git(not gui)(I need the  console  client).
 ?
  I mean that  , at  the ? line 1309 of the main.c , didn't  set the signal handler on Windows.


  so,  I try to  modify it like below , but It does not work ( I hope that the?console client can receive the kill signal sended by  another process).


 diff --git a/main.c b/main.cindex df57698..753b24a 100644
--- a/main.c
+++ b/main.c
@@ -47,6 +47,8 @@
 #include "openconnect-internal.h"
 
 #ifdef _WIN32
+#include <signal.h>
+#include <winsock2.h>
 #include <shlwapi.h>
 #include <wtypes.h>
 #include <wincon.h>
@@ -668,6 +670,30 @@ static void set_default_vpncscript(void)
                default_vpncscript = "cscript " DEFAULT_VPNCSCRIPT;
        }
 }
+
+static void handle_signal_windows(int sig)
+{
+       char cmd=-1;
+
+       switch (sig) {
+       case SIGINT://interrupt(Ctrl+C)
+       case SIGTERM://Software termination signal from kill
+       case SIGABRT://abnormal termination triggered by abort call(Abort)
+               cmd = OC_CMD_CANCEL;
+               break;
+       case SIGFPE:
+       case SIGILL:
+       case SIGSEGV:
+       default:
+               return;
+               //cmd = OC_CMD_PAUSE;
+               //break;
+       }
+
+       if (send(sig_cmd_fd, &cmd, 1,0) < 0) {
+       /* suppress warn_unused_result */
+       }
+}
 #endif
 
 static void usage(void)
@@ -1292,6 +1318,10 @@ int main(int argc, char **argv)
        sigaction(SIGINT, &sa, NULL);
        sigaction(SIGHUP, &sa, NULL);
        sigaction(SIGUSR2, &sa, NULL);
+#else
+       signal(SIGINT,  handle_signal_windows);
+       signal(SIGTERM, handle_signal_windows);
+       signal(SIGABRT, handle_signal_windows);
 #endif /* !_WIN32 */
 
        sig_cmd_fd = openconnect_setup_cmd_pipe(vpninfo);



thanks,
xiao guang


From ismail at donmez.ws  Wed Nov 12 06:08:30 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Wed, 12 Nov 2014 16:08:30 +0200
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
Message-ID: <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>

Hi,

On Mon, Nov 10, 2014 at 5:05 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Mon, Nov 10, 2014 at 3:37 PM, ?smail D?nmez <ismail at donmez.ws> wrote:
>> Hi,
>>
>> I am using NetworkManager-openconnect (version 0.9.10.0) against
>> ocserv.git and after being connected for like ~30 minutes VPN stops
>> accepting any packets. Turns out that there is some weird stuff going
>> on.
>
> Hello,
>  From the log that you sent it seems that your firewall discarded the
> previous UDP session association. That is the new UDP traffic is being
> received from a different port, and the main server is now receiving
> the UDP traffic. This is harmless, as ocserv will forward the new
> session to worker.
>
>> Looking at the attached log first connection happens at 14:11:12 and
>> even though I don't click anything from the UI to reconnect etc a new
>> connection starts at 14:25:56 and this wreaks havoc. I am not sure if
>> this is a client bug or a server one.
>
> That is when the main process received the new session and forwarded
> it to the worker process, the worker process believed the previous was
> active (received some message from the previous session the last 30
> seconds). That should cancel out after 30 seconds. I've reduced the
> severity of these messages to avoid spamming the log.

This sounds fine but it never recovers it seems, here is the log when
openconnect clients detect the connection as dead and reconnects:

Nov 12 14:04:25 i10z ocserv[57992]: worker: 212.156.31.134:3351
accepted connection
Nov 12 14:04:25 i10z ocserv[54496]: sec-mod: received request from pid
57992 and uid 65534
Nov 12 14:04:25 i10z ocserv[54496]: sec-mod: cmd [size=55] sm: sign
Nov 12 14:04:25 i10z ocserv[57992]: worker: 212.156.31.134:3351
sending message 'resume data store request' to main
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351 main
received message 'resume data store request' of 370 bytes
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351 TLS
session DB storing
704172649867259ed82fc0f9509d3f3f16faddcb16f285f7089763d1ed153734
Nov 12 14:04:25 i10z ocserv[57992]: worker: 212.156.31.134:3351 TLS
handshake completed
Nov 12 14:04:25 i10z ocserv[57992]: worker: 212.156.31.134:3351
User-agent: 'Open AnyConnect VPN Agent v6.00-214-g17a18f1'
Nov 12 14:04:25 i10z ocserv[57992]: worker: 212.156.31.134:3351
sending message 'auth cookie request' to main
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351 main
received message 'auth cookie request' of 126 bytes
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
reusing cookie for 'ismail' (57992)
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:8023[ismail]
disconnecting 'ismail' (57971) due to new cookie connection
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
accepting user 'ismail'
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
assigned IPv4 to 'ismail': 10.10.0.121
Nov 12 14:04:25 i10z ocserv[57971]: worker:
212.156.31.134:8023[ismail] sending message 'cli stats' to main
Nov 12 14:04:25 i10z ocserv[57971]: worker:
212.156.31.134:8023[ismail] sending stats (in: 1739039, out: 19196827)
to main
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
assigning tun device vpns1
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
user 'ismail' of group 'ismail' authenticated (using cookie)
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
sending (socket) message 2 to worker
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:8023[ismail]
main received message 'cli stats' of 9 bytes
Nov 12 14:04:25 i10z ocserv[57992]: worker: 212.156.31.134:3351
received auth reply message (value: 1)
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] suggesting DPD of 440 secs
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] sending IPv4 10.10.0.121
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] TCP MSS is 1435
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] reducing MTU due to TCP MSS to 1435
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] CSTP Base MTU is 1435 bytes
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] DTLS ciphersuite: OC-DTLS1_2-AES128-GCM
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] DTLS overhead is 66
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] suggesting DTLS MTU 1369
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] sending message 'tun mtu change' to main
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
main received message 'tun mtu change' of 3 bytes
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
setting vpns1 MTU to 1369
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] setting MTU to 1369
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] sending message 'session info' to main
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
main received message 'session info' of 94 bytes
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:8023[ismail]
main-misc.c:425: command socket closed
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:8023[ismail]
removing client 'ismail' with id '57971'
Nov 12 14:04:25 i10z ocserv[54495]: main: new DTLS session from
212.156.31.134:37353 (record v254.253, hello v0.1)
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:37353:
unexpected DTLS content type: 23; a firewall disassociated a UDP
session
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
sending (socket) message 10 to worker
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
passed UDP socket from 212.156.31.134:37353
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] worker received message udp fd of 2 bytes
Nov 12 14:04:25 i10z ocserv[57992]: worker:
212.156.31.134:3351[ismail] received UDP fd message but our session is
active!
Nov 12 14:04:25 i10z ocserv[54495]: main: new DTLS session from
212.156.31.134:37353 (record v254.253, hello v0.1)
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:37353:
unexpected DTLS content type: 23; a firewall disassociated a UDP
session


Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
received UDP connection too soon from 212.156.31.134:37353
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:37353: too short packet
Nov 12 14:04:25 i10z ocserv[54495]: main: new DTLS session from
212.156.31.134:37353 (record v254.253, hello v0.1)
Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:37353:
unexpected DTLS content type: 23; a firewall disassociated a UDP
session

Now the last 4 lines are repeated forever and connection never
recovers. Using openconnect.git didn't help.
Using ocserv.git atm.


From nmav at gnutls.org  Sat Nov 15 00:46:53 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2014 09:46:53 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
Message-ID: <1416041213.3615.1.camel@gnutls.org>

On Thu, 2014-11-13 at 11:23 +0200, ?smail D?nmez wrote:
> Hi,
> 
> On Wed, Nov 12, 2014 at 11:41 PM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
> > On Wed, 2014-11-12 at 16:08 +0200, ?smail D?nmez wrote:
> >
> >> Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:3351[ismail]
> >> received UDP connection too soon from 212.156.31.134:37353
> >> Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:37353: too short packet
> >> Nov 12 14:04:25 i10z ocserv[54495]: main: new DTLS session from
> >> 212.156.31.134:37353 (record v254.253, hello v0.1)
> >> Nov 12 14:04:25 i10z ocserv[54495]: main: 212.156.31.134:37353:
> >> unexpected DTLS content type: 23; a firewall disassociated a UDP
> >> session
> >> Now the last 4 lines are repeated forever and connection never
> >> recovers. Using openconnect.git didn't help.
> >> Using ocserv.git atm.

>From your full log I realize that your case is different, and you'll be
able to figure the issue. There are two clients connecting. The first
disconnects the TCP session, but then from the same IP you seem to start
receiving UDP packets which are not associated with a session. That's
why ocserv tries to forward the packets to the only other existing
session from the same IP. Because that session is active already it
rejects that forward.

So the issue is to figure who is sending the UDP packets without an
associated TCP session.

regards,
Nikos

Nov 13 09:18:44 i10z ocserv[1164]: worker: 212.156.31.134:35277
User-agent: 'Open AnyConnect VPN Agent v6.00-214-g17a18f1'
Nov 13 09:04:04 i10z ocserv[697]: worker: 212.156.31.134:42709[ismail]
User-agent: 'Open AnyConnect VPN Agent v6.00-214-g17a18f1'

Nov 13 09:18:44 i10z ocserv[1164]: worker: 212.156.31.134:35277[ismail]
suggesting DPD of 440 secs

Nov 13 09:18:44 i10z ocserv[54495]: main: 212.156.31.134:42709[ismail]
main-misc.c:425: command socket closed
Nov 13 09:18:44 i10z ocserv[54495]: main: 212.156.31.134:42709[ismail]
removing client 'ismail' with id '697'

Nov 13 09:18:48 i10z ocserv[54495]: main: 212.156.31.134:22839:
unexpected DTLS content type: 23; a firewall disassociated a UDP session


Nov 13 09:18:48 i10z ocserv[1164]: worker: 212.156.31.134:35277[ismail]
received UDP fd message but our session is active!




From dwmw2 at infradead.org  Sat Nov 15 02:04:31 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 15 Nov 2014 10:04:31 -0000
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416041213.3615.1.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
Message-ID: <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>


> So the issue is to figure who is sending the UDP packets without an
> associated TCP session.


If a client is afflicted by NAT, especially CG-NAT, it's possible that
separate connections may appear to come from *different* IP addresses.
Some NAT setups have a *pool* of public-facing addresses.

-- 
dwmw2



From ismail at donmez.ws  Sat Nov 15 03:15:47 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Sat, 15 Nov 2014 13:15:47 +0200
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
Message-ID: <CAJ1KOAgpcoQABSfVDcECBJkoyebnKdG9r0jjaXkJZXXaCujDpQ@mail.gmail.com>

On Sat, Nov 15, 2014 at 12:04 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>
>> So the issue is to figure who is sending the UDP packets without an
>> associated TCP session.
>
>
> If a client is afflicted by NAT, especially CG-NAT, it's possible that
> separate connections may appear to come from *different* IP addresses.
> Some NAT setups have a *pool* of public-facing addresses.

Indeed I am behind a NAT which I don't know the exact setup (This is
@work). So I guess thats the problem since I run one openconnect
client at a time.

Thanks for debugging this!


From nmav at gnutls.org  Sat Nov 15 03:26:06 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2014 12:26:06 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
Message-ID: <1416050766.6493.2.camel@gnutls.org>

On Sat, 2014-11-15 at 10:04 +0000, David Woodhouse wrote:
> > So the issue is to figure who is sending the UDP packets without an
> > associated TCP session.
> 
> 
> If a client is afflicted by NAT, especially CG-NAT, it's possible that
> separate connections may appear to come from *different* IP addresses.
> Some NAT setups have a *pool* of public-facing addresses.

clients behind these nat types will have no issue as long as the nat
keeps the UDP association. If it is lost there is nothing in the
received packets that could allow ocserv to reassociate the session with
the correct server. The recovery of such clients would depend on the
timeout of openconnect client (after which a new DTLS session will be
established).

regards,
Nikos




From nmav at gnutls.org  Sat Nov 15 03:45:45 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2014 12:45:45 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAgpcoQABSfVDcECBJkoyebnKdG9r0jjaXkJZXXaCujDpQ@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <CAJ1KOAgpcoQABSfVDcECBJkoyebnKdG9r0jjaXkJZXXaCujDpQ@mail.gmail.com>
Message-ID: <1416051945.6493.4.camel@gnutls.org>

On Sat, 2014-11-15 at 13:15 +0200, ?smail D?nmez wrote:
> On Sat, Nov 15, 2014 at 12:04 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
> >
> >> So the issue is to figure who is sending the UDP packets without an
> >> associated TCP session.
> >
> >
> > If a client is afflicted by NAT, especially CG-NAT, it's possible that
> > separate connections may appear to come from *different* IP addresses.
> > Some NAT setups have a *pool* of public-facing addresses.
> 
> Indeed I am behind a NAT which I don't know the exact setup (This is
> @work). So I guess thats the problem since I run one openconnect
> client at a time.

The log is a bit strange to justify a nat issue. David could openconnect
reconnect the TLS channel only but continue sending on the old DTLS
channel? That is what is seems to be happening here.

Nov 13 09:04:00 i10z ocserv[697]: worker: 212.156.31.134:42709 TLS
handshake completed
Nov 13 09:04:04 i10z ocserv[54495]: main: new DTLS session from
212.156.31.134:22839 (record v254.255, hello v1.0)
Nov 13 09:04:04 i10z ocserv[697]: worker: 212.156.31.134:42709[ismail]
DTLS handshake completed

(the TLS and DTLS channels are established)

Nov 13 09:18:44 i10z ocserv[54495]: main: 212.156.31.134:42709[ismail]
main-misc.c:425: command socket closed
Nov 13 09:18:44 i10z ocserv[54495]: main: 212.156.31.134:42709[ismail]
removing client 'ismail' with id '697'

(old session was discarded - the old TLS channel was terminated)

Nov 13 09:18:44 i10z ocserv[1164]: worker: 212.156.31.134:35277 TLS
handshake completed

(a new TLS channel is established)

Nov 13 09:04:04 i10z ocserv[54495]: main: new DTLS session from
212.156.31.134:22839 (record v254.255, hello v1.0)
Nov 13 09:18:48 i10z ocserv[54495]: main: 212.156.31.134:22839:
unexpected DTLS content type: 23; a firewall disassociated a UDP session

(the DTLS channel didn't restart even though the keys have changed. The
port of the received packets is suspiciously the same)

regards,
Nikos




From dwmw2 at infradead.org  Sat Nov 15 05:39:38 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 15 Nov 2014 13:39:38 +0000
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416050766.6493.2.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
Message-ID: <1416058778.9631.94.camel@infradead.org>

On Sat, 2014-11-15 at 12:26 +0100, Nikos Mavrogiannopoulos wrote:
> 
> clients behind these nat types will have no issue as long as the nat
> keeps the UDP association. If it is lost there is nothing in the
> received packets that could allow ocserv to reassociate the session
> with the correct server.

Er, don't they have the session-id in the ClientHello? And the server
*provides* the session-id, so it could make it something which helps
with finding the correct server.

On Sat, 2014-11-15 at 12:45 +0100, Nikos Mavrogiannopoulos wrote:
> David could openconnect reconnect the TLS channel only but continue 
> sending on the old DTLS channel? That is what is seems to be happening
> here.

Yes. See your own commit
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/14d807f5

It'll automatically reconnect DTLS after any CSTP reconnect, but *only*
if DTLS doesn't have its own rehandshake timer/mechanism set up.

And that's probably the right thing to do. If there's been packet loss
and the TCP connection is stalled, DTLS could be running just fine and
the user might not even have *noticed*. We can reconnect the CSTP
without even a momentary blip in actual *traffic* over DTLS.

If the CSTP gives us a new session-id, though, we probably *should*
reconnect DTLS. I think we're careful not to change our
DTLS-Master-Secret on reconnect, aren't we?

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

From nmav at gnutls.org  Sat Nov 15 07:03:47 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2014 16:03:47 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416058778.9631.94.camel@infradead.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
Message-ID: <1416063827.8484.1.camel@gnutls.org>

On Sat, 2014-11-15 at 13:39 +0000, David Woodhouse wrote:
> On Sat, 2014-11-15 at 12:26 +0100, Nikos Mavrogiannopoulos wrote:
> > 
> > clients behind these nat types will have no issue as long as the nat
> > keeps the UDP association. If it is lost there is nothing in the
> > received packets that could allow ocserv to reassociate the session
> > with the correct server.
> 
> Er, don't they have the session-id in the ClientHello? And the server
> *provides* the session-id, so it could make it something which helps
> with finding the correct server.

That only works if the client detects the lost packets and restarts the
DTLS session.

> On Sat, 2014-11-15 at 12:45 +0100, Nikos Mavrogiannopoulos wrote:
> > David could openconnect reconnect the TLS channel only but continue 
> > sending on the old DTLS channel? That is what is seems to be happening
> > here.
> 
> Yes. See your own commit
> http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/14d807f5
> 
> It'll automatically reconnect DTLS after any CSTP reconnect, but *only*
> if DTLS doesn't have its own rehandshake timer/mechanism set up.

Correct. That seems to be an issue of semantic difference in ocserv and
anyconnect servers. ocserv gives a new DTLS session ID on every
reconnection and requires DTLS to reconnect too. That can detected by
openconnect by checking the session ID for match.

An untested patch for openconnect follows. Would that Ismail fix the
issue you notice?

> And that's probably the right thing to do. If there's been packet loss
> and the TCP connection is stalled, DTLS could be running just fine and
> the user might not even have *noticed*. We can reconnect the CSTP
> without even a momentary blip in actual *traffic* over DTLS.
> If the CSTP gives us a new session-id, though, we probably *should*
> reconnect DTLS. I think we're careful not to change our
> DTLS-Master-Secret on reconnect, aren't we?

Indeed. However, the keys being the same wouldn't help ocserv, as a DTLS
handshake has to be performed anyway. As it is the DTLS packets move to
a black hole with ocserv (on every TLS connection you get a different
DTLS session).

As I understand that case can be triggered by a random failure in the
TLS channel (e.g., cstp_write failed because the TCP session was reset),
or by setting "rekey-method = new-tunnel" in ocserv.

(in an unrelated issue for some reason DPD detection here didn't work
for DTLS which didn't try to reconnect - I don't know if Ismail has the
output of openconnect)

regards,
Nikos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-force-DTLS-reconnect-if-the-session-ID-we-get-from-T.patch
Type: text/x-patch
Size: 2175 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141115/f5eaa27e/attachment.bin>

From ismail at donmez.ws  Sat Nov 15 07:19:02 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Sat, 15 Nov 2014 17:19:02 +0200
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416063827.8484.1.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org> <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
Message-ID: <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>

Hi,

On Sat, Nov 15, 2014 at 5:03 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> An untested patch for openconnect follows. Would that Ismail fix the
> issue you notice?

Testing the patch now, but...

> (in an unrelated issue for some reason DPD detection here didn't work
> for DTLS which didn't try to reconnect - I don't know if Ismail has the
> output of openconnect)

I don't have the openconnect logs BUT it said DPD detected and
reconnect, this is when the ocserv sets up the second connection and
at this point everything goes berserk.

Though, this time I'll save openconnect logs too.

Regards,
ismail


From ismail at donmez.ws  Sat Nov 15 09:55:14 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Sat, 15 Nov 2014 19:55:14 +0200
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org> <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
Message-ID: <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>

Hi,

On Sat, Nov 15, 2014 at 5:19 PM, ?smail D?nmez <ismail at donmez.ws> wrote:
> Hi,
>
> On Sat, Nov 15, 2014 at 5:03 PM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> An untested patch for openconnect follows. Would that Ismail fix the
>> issue you notice?
>
> Testing the patch now, but...
>
>> (in an unrelated issue for some reason DPD detection here didn't work
>> for DTLS which didn't try to reconnect - I don't know if Ismail has the
>> output of openconnect)
>
> I don't have the openconnect logs BUT it said DPD detected and
> reconnect, this is when the ocserv sets up the second connection and
> at this point everything goes berserk.

Patch didn't help, here is the openconnect(.git) logs:

POST https://i10z.com:1443/
                                                [37/37]
Attempting to connect to server 104.40.138.253:1443
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
XML POST enabled
Please enter your username
POST https://i10z.com:1443/auth
Please enter your password.
Password:
POST https://i10z.com:1443/auth
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
Connected tun1 as 10.10.0.121, using SSL
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
DTLS handshake failed: Resource temporarily unavailable, try again.
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
DTLS handshake failed: Resource temporarily unavailable, try again.
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
DTLS handshake failed: Resource temporarily unavailable, try again.
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
DTLS handshake failed: Resource temporarily unavailable, try again.
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
DTLS Dead Peer Detection detected dead peer!
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400

Even though log says connected, I don't have any internet connection.
Server is just printing this in a loop:

Nov 15 17:49:22 i10z ocserv[54495]: main: 212.156.31.134:28910[ismail]
received UDP connection too soon from 212.156.31.134:21539
Nov 15 17:49:22 i10z ocserv[54495]: main: new DTLS session from
212.156.31.134:21539 (record v254.253, hello v0.1)
Nov 15 17:49:22 i10z ocserv[54495]: main: 212.156.31.134:21539:
unexpected DTLS content type: 23; a firewall disassociated a UDP
session


From nmav at gnutls.org  Sat Nov 15 11:32:36 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2014 20:32:36 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
 <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
Message-ID: <1416079956.30407.1.camel@gnutls.org>

On Sat, 2014-11-15 at 19:55 +0200, ?smail D?nmez wrote:

> Patch didn't help, here is the openconnect(.git) logs:
> POST https://i10z.com:1443/
>                                                 [37/37]
> Attempting to connect to server 104.40.138.253:1443
> SSL negotiation with i10z.com
> Connected to HTTPS on i10z.com
> XML POST enabled
> Please enter your username
> POST https://i10z.com:1443/auth
> Please enter your password.
> Password:
> POST https://i10z.com:1443/auth
> Got CONNECT response: HTTP/1.1 200 CONNECTED
> CSTP connected. DPD 440, Keepalive 32400
> Connected tun1 as 10.10.0.121, using SSL
> Established DTLS connection (using GnuTLS). Ciphersuite
> (DTLS1.2)-(RSA)-(AES-128-GCM).
> CSTP Dead Peer Detection detected dead peer!
> SSL negotiation with i10z.com
> Connected to HTTPS on i10z.com
> Got CONNECT response: HTTP/1.1 200 CONNECTED
> CSTP connected. DPD 440, Keepalive 32400
> DTLS Dead Peer Detection detected dead peer!

Thanks. For that I re-used the DTLS connection pause, and it may be
buggy. I'll try to check it.

regards,
Nikos




From nmav at gnutls.org  Sun Nov 16 01:01:22 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 16 Nov 2014 10:01:22 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
 <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
Message-ID: <1416128482.2048.1.camel@gnutls.org>

On Sat, 2014-11-15 at 19:55 +0200, ?smail D?nmez wrote:
> Hi,
> 
> On Sat, Nov 15, 2014 at 5:19 PM, ?smail D?nmez <ismail at donmez.ws> wrote:
> > Hi,
> >
> > On Sat, Nov 15, 2014 at 5:03 PM, Nikos Mavrogiannopoulos
> > <nmav at gnutls.org> wrote:
> >> An untested patch for openconnect follows. Would that Ismail fix the
> >> issue you notice?
> >
> > Testing the patch now, but...
> >
> >> (in an unrelated issue for some reason DPD detection here didn't work
> >> for DTLS which didn't try to reconnect - I don't know if Ismail has the
> >> output of openconnect)
> >
> > I don't have the openconnect logs BUT it said DPD detected and
> > reconnect, this is when the ocserv sets up the second connection and
> > at this point everything goes berserk.
> 
> Patch didn't help, here is the openconnect(.git) logs:

Hi,
 Thanks to tcpkill I managed to simulate your use case. Could you try
the openconnect patch as well as the latest ocserv in git?

regards,
Nikos




From ismail at donmez.ws  Sun Nov 16 02:50:34 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Sun, 16 Nov 2014 12:50:34 +0200
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416128482.2048.1.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org> <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
 <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
 <1416128482.2048.1.camel@gnutls.org>
Message-ID: <CAJ1KOAhVeUAXsf9rHw196sBh42wSo1BSQZcqGZkyzmhLvFvcnA@mail.gmail.com>

Hi,

On Sun, Nov 16, 2014 at 11:01 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Sat, 2014-11-15 at 19:55 +0200, ?smail D?nmez wrote:
>> Hi,
>>
>> On Sat, Nov 15, 2014 at 5:19 PM, ?smail D?nmez <ismail at donmez.ws> wrote:
>> > Hi,
>> >
>> > On Sat, Nov 15, 2014 at 5:03 PM, Nikos Mavrogiannopoulos
>> > <nmav at gnutls.org> wrote:
>> >> An untested patch for openconnect follows. Would that Ismail fix the
>> >> issue you notice?
>> >
>> > Testing the patch now, but...
>> >
>> >> (in an unrelated issue for some reason DPD detection here didn't work
>> >> for DTLS which didn't try to reconnect - I don't know if Ismail has the
>> >> output of openconnect)
>> >
>> > I don't have the openconnect logs BUT it said DPD detected and
>> > reconnect, this is when the ocserv sets up the second connection and
>> > at this point everything goes berserk.
>>
>> Patch didn't help, here is the openconnect(.git) logs:
>
> Hi,
>  Thanks to tcpkill I managed to simulate your use case. Could you try
> the openconnect patch as well as the latest ocserv in git?

This version seems to be creating a new session every minute. On the
client side:

POST https://i10z.com:1443/
Attempting to connect to server 104.40.138.253:1443
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
XML POST enabled
Please enter your username
POST https://i10z.com:1443/auth
Please enter your password.
Password:
POST https://i10z.com:1443/auth
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
Connected tun1 as 10.10.0.121, using SSL
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.
DTLS handshake failed: Resource temporarily unavailable, try again.

On the server side:

Nov 16 10:42:42 i10z ocserv[45018]: sec-mod: performing maintenance
Nov 16 10:42:42 i10z ocserv[45018]: sec-mod: active sessions 0, banned entries 0
Nov 16 10:41:58 i10z ocserv[45017]: message repeated 3 times: [ main:
new DTLS session from 212.156.31.134:51296 (record v254.255, hello
v1.0)]
Nov 16 10:43:03 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:22620 (record v254.255, hello v1.0)
Nov 16 10:43:21 i10z ocserv[45017]: message repeated 2 times: [ main:
new DTLS session from 212.156.31.134:22620 (record v254.255, hello
v1.0)]
Nov 16 10:44:21 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:9870 (record v254.255, hello v1.0)
Nov 16 10:44:37 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:9870 (record v254.255, hello v1.0)
Nov 16 10:45:36 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:22008 (record v254.255, hello v1.0)
Nov 16 10:46:13 i10z ocserv[45017]: message repeated 2 times: [ main:
new DTLS session from 212.156.31.134:22008 (record v254.255, hello
v1.0)]
Nov 16 10:47:13 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:24857 (record v254.255, hello v1.0)
Nov 16 10:47:42 i10z ocserv[45018]: sec-mod: performing maintenance
Nov 16 10:47:42 i10z ocserv[45018]: sec-mod: active sessions 0, banned entries 0
Nov 16 10:47:43 i10z ocserv[45017]: message repeated 2 times: [ main:
new DTLS session from 212.156.31.134:24857 (record v254.255, hello
v1.0)]
Nov 16 10:48:43 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:2323 (record v254.255, hello v1.0)
Nov 16 10:49:13 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:2323 (record v254.255, hello v1.0)
Nov 16 10:50:13 i10z ocserv[45017]: main: new DTLS session from
212.156.31.134:29242 (record v254.255, hello v1.0)


The connection never dropped, I am still running it to see if it
breaks. But the speed really got slowed down. I would get 500-600kb/s
easily now I only get 100kb/s.

Thanks!


From nmav at gnutls.org  Sun Nov 16 03:44:44 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 16 Nov 2014 12:44:44 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <CAJ1KOAhVeUAXsf9rHw196sBh42wSo1BSQZcqGZkyzmhLvFvcnA@mail.gmail.com>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
 <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
 <1416128482.2048.1.camel@gnutls.org>
 <CAJ1KOAhVeUAXsf9rHw196sBh42wSo1BSQZcqGZkyzmhLvFvcnA@mail.gmail.com>
Message-ID: <1416138284.23147.1.camel@gnutls.org>

On Sun, 2014-11-16 at 12:50 +0200, ?smail D?nmez wrote:

> > Hi,
> >  Thanks to tcpkill I managed to simulate your use case. Could you try
> > the openconnect patch as well as the latest ocserv in git?
> This version seems to be creating a new session every minute. On the
> client side:

That's my mistake. The fix in ocserv wasn't complete. Could you try the
current version?

regards,
Nikos




From ismail at donmez.ws  Sun Nov 16 04:18:03 2014
From: ismail at donmez.ws (=?UTF-8?B?xLBzbWFpbCBEw7ZubWV6?=)
Date: Sun, 16 Nov 2014 14:18:03 +0200
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416138284.23147.1.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org> <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <CAJ1KOAixs0=jt_fGUHo2Cy-=21fvZNJtkac5YUUCoB-JsvMvog@mail.gmail.com>
 <CAJ1KOAiVs+asKObTVqGmFHUoe1=NABE5FYE7zdHpOuseWrHMsA@mail.gmail.com>
 <1416128482.2048.1.camel@gnutls.org>
 <CAJ1KOAhVeUAXsf9rHw196sBh42wSo1BSQZcqGZkyzmhLvFvcnA@mail.gmail.com>
 <1416138284.23147.1.camel@gnutls.org>
Message-ID: <CAJ1KOAi7Sv=yv1c-KuFTn4GrzHg+webRuFJgkeZYhWZk+Oi1eg@mail.gmail.com>

Hi,

On Sun, Nov 16, 2014 at 1:44 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Sun, 2014-11-16 at 12:50 +0200, ?smail D?nmez wrote:
>
>> > Hi,
>> >  Thanks to tcpkill I managed to simulate your use case. Could you try
>> > the openconnect patch as well as the latest ocserv in git?
>> This version seems to be creating a new session every minute. On the
>> client side:
>
> That's my mistake. The fix in ocserv wasn't complete. Could you try the
> current version?

Success finally it seems:

POST https://i10z.com:1443/
Attempting to connect to server 104.40.138.253:1443
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
XML POST enabled
Please enter your username
POST https://i10z.com:1443/auth
Please enter your password.
Password:
POST https://i10z.com:1443/auth
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
Connected tun1 as 10.10.0.121, using SSL
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).
CSTP Dead Peer Detection detected dead peer!
SSL negotiation with i10z.com
Connected to HTTPS on i10z.com
Got CONNECT response: HTTP/1.1 200 CONNECTED
CSTP connected. DPD 440, Keepalive 32400
Established DTLS connection (using GnuTLS). Ciphersuite
(DTLS1.2)-(RSA)-(AES-128-GCM).

Thanks!


From dwmw2 at infradead.org  Mon Nov 17 10:39:56 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 17 Nov 2014 18:39:56 +0000
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416063827.8484.1.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
Message-ID: <1416249596.9631.152.camel@infradead.org>

On Sat, 2014-11-15 at 16:03 +0100, Nikos Mavrogiannopoulos wrote:
> +				if (vpninfo->dtls_session_id_set) {
> +					if (memcmp(vpninfo->dtls_session_id, dtls_session_id, 32) != 0) {
> +						if (vpninfo->dtls_state != DTLS_DISABLED) {
> +							dtls_close(vpninfo);
> +							vpninfo->dtls_state = DTLS_SLEEPING;
> +							vpninfo->new_dtls_started = 0;
> +						}
> +					}

Couldn't we just call dtls_reconnect() here?

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

From nmav at gnutls.org  Mon Nov 17 10:51:21 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 17 Nov 2014 19:51:21 +0100
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416249596.9631.152.camel@infradead.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <1416249596.9631.152.camel@infradead.org>
Message-ID: <1416250281.18236.2.camel@gnutls.org>

On Mon, 2014-11-17 at 18:39 +0000, David Woodhouse wrote:
> On Sat, 2014-11-15 at 16:03 +0100, Nikos Mavrogiannopoulos wrote:
> > +				if (vpninfo->dtls_session_id_set) {
> > +					if (memcmp(vpninfo->dtls_session_id, dtls_session_id, 32) != 0) {
> > +						if (vpninfo->dtls_state != DTLS_DISABLED) {
> > +							dtls_close(vpninfo);
> > +							vpninfo->dtls_state = DTLS_SLEEPING;
> > +							vpninfo->new_dtls_started = 0;
> > +						}
> > +					}
> 
> Couldn't we just call dtls_reconnect() here?

Not sure. That would start the DTLS connection while parsing the headers
and that didn't seem quite right at the moment.





From dwmw2 at infradead.org  Tue Nov 18 05:23:36 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 18 Nov 2014 13:23:36 +0000
Subject: Does anyone care about GnuTLS 2.12 support
Message-ID: <1416317016.9631.187.camel@infradead.org>

We have a lot of baggage in order to support GnuTLS 2.12. Does anyone
actually care about it?

It's lived this long because it's been relatively harmless, but now we'd
like to switch the PIN handling to gnutls_certificate_set_pin_function()
instead of using the p11-kit PIN callbacks, and that's a pain in the
arse.

Anyone who still really cares about GnuTLS 2.12 support (i.e. building
for an 'enterprise' distribution stuck with GnuTLS 2.12 and doesn't want
to lose PKCS#11 and KDE support by building with OpenSSL), now would be
a good time to speak up if you care about it being dropped from the
OpenConnect 7.00 release.

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

From mtmiller at debian.org  Tue Nov 18 12:16:49 2014
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 18 Nov 2014 15:16:49 -0500
Subject: Does anyone care about GnuTLS 2.12 support
In-Reply-To: <1416317016.9631.187.camel@infradead.org>
References: <1416317016.9631.187.camel@infradead.org>
Message-ID: <CAD6LDLL8WAXmBOF-EnwKHaWZLFEq=bwayKmgZsp3a7Z3iUfyiw@mail.gmail.com>

On Tue, Nov 18, 2014 at 13:23:36 +0000, David Woodhouse wrote:
> We have a lot of baggage in order to support GnuTLS 2.12. Does anyone
> actually care about it?

As one of those (few?) who used to care, no I don't care about it for
any current or future releases. Debian and Ubuntu have effectively
migrated to GnuTLS 3.x, I only need to support 2.12 for any potential
future stable release security patches.

Thanks,

-- 
mike


From dwmw2 at infradead.org  Tue Nov 18 13:53:24 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 18 Nov 2014 21:53:24 +0000
Subject: oscserv error: "could not determine the owner of received UDP
 packet"
In-Reply-To: <1416250281.18236.2.camel@gnutls.org>
References: <CAJ1KOAjh8wrOfkXO9qweyt_B6SOnuD4yg0ic4rkOPyvfPpsS9A@mail.gmail.com>
 <CAJU7zaL+JskpavkfgEE-1tMWOrSr8V2o55o_hVOapkfMRpR63g@mail.gmail.com>
 <CAJ1KOAiwDDO+qNT1F=z0Tsw4XR=rQt-JzfROq2rtPJU2HWq9Tg@mail.gmail.com>
 <1415828489.32504.1.camel@gnutls.org>
 <CAJ1KOAhzoM4dCvwqvNPp0S8Cdy+qOpNKdS0brP=5fiHTaPdamg@mail.gmail.com>
 <1416041213.3615.1.camel@gnutls.org>
 <e681dd8cb8f6029e035ddae23aa2d6eb.squirrel@twosheds.infradead.org>
 <1416050766.6493.2.camel@gnutls.org>
 <1416058778.9631.94.camel@infradead.org>
 <1416063827.8484.1.camel@gnutls.org>
 <1416249596.9631.152.camel@infradead.org>
 <1416250281.18236.2.camel@gnutls.org>
Message-ID: <1416347604.9631.202.camel@infradead.org>

On Mon, 2014-11-17 at 19:51 +0100, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-11-17 at 18:39 +0000, David Woodhouse wrote:
> > On Sat, 2014-11-15 at 16:03 +0100, Nikos Mavrogiannopoulos wrote:
> > > +				if (vpninfo->dtls_session_id_set) {
> > > +					if (memcmp(vpninfo->dtls_session_id, dtls_session_id, 32) != 0) {
> > > +						if (vpninfo->dtls_state != DTLS_DISABLED) {
> > > +							dtls_close(vpninfo);
> > > +							vpninfo->dtls_state = DTLS_SLEEPING;
> > > +							vpninfo->new_dtls_started = 0;
> > > +						}
> > > +					}
> > 
> > Couldn't we just call dtls_reconnect() here?
> 
> Not sure. That would start the DTLS connection while parsing the headers
> and that didn't seem quite right at the moment.

Yeah, in fact none of the dtls_reconnect() calls in cstp.c are really
very nice. I've switched to a 'need_dtls_reconnect' flag and let
dtls_mainloop() handle *actually* reconnecting.

Which also fixes the fact that if we *do* just call the old
dtls_reconnect() function right there as I'd suggested, we might
actually end up calling it twice in quick succession.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/038ba9e22

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

From dwmw2 at infradead.org  Tue Nov 18 14:03:25 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 18 Nov 2014 22:03:25 +0000
Subject: Does anyone care about GnuTLS 2.12 support
In-Reply-To: <CAD6LDLL8WAXmBOF-EnwKHaWZLFEq=bwayKmgZsp3a7Z3iUfyiw@mail.gmail.com>
References: <1416317016.9631.187.camel@infradead.org>
 <CAD6LDLL8WAXmBOF-EnwKHaWZLFEq=bwayKmgZsp3a7Z3iUfyiw@mail.gmail.com>
Message-ID: <1416348205.9631.211.camel@infradead.org>

On Tue, 2014-11-18 at 15:16 -0500, Mike Miller wrote:
> On Tue, Nov 18, 2014 at 13:23:36 +0000, David Woodhouse wrote:
> > We have a lot of baggage in order to support GnuTLS 2.12. Does anyone
> > actually care about it?
> 
> As one of those (few?) who used to care, no I don't care about it for
> any current or future releases. Debian and Ubuntu have effectively
> migrated to GnuTLS 3.x, I only need to support 2.12 for any potential
> future stable release security patches.

Thanks. It was Debian/Ubuntu I was most concerned about ? I see even
Ubuntu 14.04 seems to have GnuTLS 2.12 according to
http://packages.ubuntu.com/trusty/openconnect

Btw, do you have any clue about 
https://bugs.launchpad.net/bugs/1297849 ? I haven't been following
closely looks like NM VPN support is fairly broken in Ubuntu and nobody
seems to care very much apart from the affected users...

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

From mtmiller at debian.org  Tue Nov 18 17:40:14 2014
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 18 Nov 2014 20:40:14 -0500
Subject: Does anyone care about GnuTLS 2.12 support
In-Reply-To: <1416348205.9631.211.camel@infradead.org>
References: <1416317016.9631.187.camel@infradead.org>
 <CAD6LDLL8WAXmBOF-EnwKHaWZLFEq=bwayKmgZsp3a7Z3iUfyiw@mail.gmail.com>
 <1416348205.9631.211.camel@infradead.org>
Message-ID: <20141119014014.GA2745@xps14z.home.local>

On Tue, Nov 18, 2014 at 22:03:25 +0000, David Woodhouse wrote:
> Thanks. It was Debian/Ubuntu I was most concerned about ? I see even
> Ubuntu 14.04 seems to have GnuTLS 2.12 according to
> http://packages.ubuntu.com/trusty/openconnect

It does, and is also on OpenConnect 5.02 / libopenconnect.so.2. I don't
see any chance of that changing in the official archive, so no need to
worry about that version from my point of view.

If others are interested in building new versions of OpenConnect on
14.04 for their own use, they should be able to with the GnuTLS 3.2.11
that is also available, it looks usable to me. OpenConnect won't be
linked against a GPLv2-compatible GMP and it won't service the version
of NM in 14.04, but should work otherwise.

> Btw, do you have any clue about 
> https://bugs.launchpad.net/bugs/1297849 ? I haven't been following
> closely looks like NM VPN support is fairly broken in Ubuntu and nobody
> seems to care very much apart from the affected users...

No clue at the moment. I've been keeping my eye on it but nothing to add
at this point. It works for me in a stock 14.04 install is all I can say
for now.

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

From dwmw2 at infradead.org  Wed Nov 19 00:16:32 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 19 Nov 2014 08:16:32 +0000
Subject: Does anyone care about GnuTLS 2.12 support
In-Reply-To: <20141119014014.GA2745@xps14z.home.local>
References: <1416317016.9631.187.camel@infradead.org>
 <CAD6LDLL8WAXmBOF-EnwKHaWZLFEq=bwayKmgZsp3a7Z3iUfyiw@mail.gmail.com>
 <1416348205.9631.211.camel@infradead.org>
 <20141119014014.GA2745@xps14z.home.local>
Message-ID: <1416384992.9631.220.camel@infradead.org>

On Tue, 2014-11-18 at 20:40 -0500, Mike Miller wrote:
> On Tue, Nov 18, 2014 at 22:03:25 +0000, David Woodhouse wrote:
> > Thanks. It was Debian/Ubuntu I was most concerned about ? I see even
> > Ubuntu 14.04 seems to have GnuTLS 2.12 according to
> > http://packages.ubuntu.com/trusty/openconnect
> 
> It does, and is also on OpenConnect 5.02 / libopenconnect.so.2. I don't
> see any chance of that changing in the official archive, so no need to
> worry about that version from my point of view.
> 
> If others are interested in building new versions of OpenConnect on
> 14.04 for their own use, they should be able to with the GnuTLS 3.2.11
> that is also available, it looks usable to me. OpenConnect won't be
> linked against a GPLv2-compatible GMP and it won't service the version
> of NM in 14.04, but should work otherwise.


OK, thanks.

In fact the 2.12 received a stay of execution in commit b3f306d21 when I
preserved the old-style p11-kit PIN callbacks in parallel with the
native GnuTLS callbacks. It turned out not to be *that* hard to make a
wrapper from one to the other. It's a few more #ifdefs in gnutls.c but
by this point that frog is almost at boiling point anyway.

We'll continue to support GnuTLS 2.12 in the 7.00 release, but won't do
serious work to preserve it after that.

I am aware that we don't really do 'stable bugfix' releases for older
branches, so there isn't a clear upgrade path. For Fedora/RHEL we do
just update OpenConnect *and* the NM auth-dialogs (for GNOME and KDE)
when there's a library change. Although library changes ought to be less
frequent now, hopefully.

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

From ioann.sys at gmail.com  Wed Nov 19 12:20:46 2014
From: ioann.sys at gmail.com (ioann sys)
Date: Thu, 20 Nov 2014 00:20:46 +0400
Subject: VPN + Internet
Message-ID: <CAC=6hNESTftay+QZ9R8A-W5hf3_g7ESZg2BkBZRLg6Cvf9s0ew@mail.gmail.com>

Hello!
tell me please, how to connect to office network, with Internet?
After connecting to my offce network, i dont have access for internet.

sorry for my bad english.


From ivonne.nirich at gmail.com  Thu Nov 20 15:28:37 2014
From: ivonne.nirich at gmail.com (Iv Njrc)
Date: Fri, 21 Nov 2014 00:28:37 +0100
Subject: Script '/etc/vpnc/vpnc-script' returned error 127
Message-ID: <CABN=OSirbhaoXW_cY5aY1gk65Pf0aQO_B1sfnMZUCeO8pkibww@mail.gmail.com>

Hello Team!

I am in need of some help:

1) How to check that the VPN is effectively working/up? Is there any command?

2) When I tried to connect to the VPN server, the command shows an error,
due to that I was not able to link the vpnc-script with the application.

Steps done:
a) First, I downloaded the script from
http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob_plain/HEAD:/vpnc-script

and added it to the /etc/vpnc/ directory, as follow:

*************************************************************

[root at cl123rnasv2 etc]# ls -ltr | grep vpn
drwxr-xr-x. 2 root root 4096 Nov 19 15:53 vpnc
[root at cl123rnasv2]# cd vpnc/
[root at cl123rnasv2 vpnc]# ls -ltr
total 24
-rwxrwxrwx. 1 root root 23766 Nov 19 15:53 vpnc-script.sh
[root at cl123rnasv2 vpnc]#

****************************************************************
b) When installing, I executed the following command:

./configure --with-vpnc-script=/etc/vpnc/vpnc-script


c) Then I wrote the command once the apps seems to be installed.

***********************************************************

[root at cl123rnasv2 /]# openconnect -u NA32 216.231.151.115
POST https://216.231.151.115/
Attempting to connect to server 216.231.151.115:443
SSL negotiation with 216.231.151.115
Server certificate verify failed: unable to get local issuer certificate

Certificate from VPN server "216.231.151.115" failed verification.
Reason: unable to get local issuer certificate
Enter 'yes' to accept, 'no' to abort; anything else to view: yes
Connected to HTTPS on 216.231.151.115
XML POST enabled
Password:
POST https://216.231.151.115/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
sh: /etc/vpnc/vpnc-script: No such file or directory
Script '/etc/vpnc/vpnc-script' returned error 127
sh: /etc/vpnc/vpnc-script: No such file or directory
Script '/etc/vpnc/vpnc-script' returned error 127
Connected tun0 as 192.168.252.118, using SSL
Established DTLS connection (using OpenSSL). Ciphersuite AES128-SHA.
Received server disconnect: b0 'Idle Timeout'
Send BYE packet: Server request
sh: /etc/vpnc/vpnc-script: No such file or directory
Script '/etc/vpnc/vpnc-script' returned error 127
Session terminated by server; exiting.
[root at cl123rnasv2 /]#
[root at cl123rnasv2 /]#
[root at cl123rnasv2 /]#
[root at cl123rnasv2 /]#

*****************************************************************

Will you be able to help me on having this error solve?

And how I will be able to check if the vpn is up?



Thanks in advance for your help fellows!



Cheers,



Ivonne


From dwmw2 at infradead.org  Thu Nov 20 15:35:13 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 20 Nov 2014 23:35:13 +0000
Subject: Script '/etc/vpnc/vpnc-script' returned error 127
In-Reply-To: <CABN=OSirbhaoXW_cY5aY1gk65Pf0aQO_B1sfnMZUCeO8pkibww@mail.gmail.com>
References: <CABN=OSirbhaoXW_cY5aY1gk65Pf0aQO_B1sfnMZUCeO8pkibww@mail.gmail.com>
Message-ID: <1416526513.9631.231.camel@infradead.org>

On Fri, 2014-11-21 at 00:28 +0100, Iv Njrc wrote:
> 
> 1) How to check that the VPN is effectively working/up? Is there any
> command?

You can look at the output of openconnect. Or try to reach a server
which is on the VPN. Or use 'ip addr' or 'ip route' to show interface
addresses and routes respectively.

If you're using NetworkManager to connect then you'll have a graphical
indication that you're connected to the VPN.

> 2) When I tried to connect to the VPN server, the command shows an
> error, due to that I was not able to link the vpnc-script with the
> application.

Can you run /etc/vpnc/vpnc-script directly?

Maybe some security check is preventing the root user from running a
script which is writeable by any unprivileged user?

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

From cernekee at gmail.com  Thu Nov 20 15:38:29 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Thu, 20 Nov 2014 15:38:29 -0800
Subject: Script '/etc/vpnc/vpnc-script' returned error 127
In-Reply-To: <CABN=OSirbhaoXW_cY5aY1gk65Pf0aQO_B1sfnMZUCeO8pkibww@mail.gmail.com>
References: <CABN=OSirbhaoXW_cY5aY1gk65Pf0aQO_B1sfnMZUCeO8pkibww@mail.gmail.com>
Message-ID: <CAJiQ=7C_K2AJB-CwOvz2OGr81MVL=ujo3_tw8kk-2BQ9rHzeig@mail.gmail.com>

On Thu, Nov 20, 2014 at 3:28 PM, Iv Njrc <ivonne.nirich at gmail.com> wrote:
> [root at cl123rnasv2 vpnc]# ls -ltr
> total 24
> -rwxrwxrwx. 1 root root 23766 Nov 19 15:53 vpnc-script.sh
> [root at cl123rnasv2 vpnc]#
>
> ****************************************************************
> b) When installing, I executed the following command:
>
> ./configure --with-vpnc-script=/etc/vpnc/vpnc-script

Can you check to make sure these are named consistently
(vpnc-script.sh versus vpnc-script)?

Also, use "file" to see if the script was accidentally saved in DOS format.


From david at lang.hm  Thu Nov 20 19:13:49 2014
From: david at lang.hm (David Lang)
Date: Thu, 20 Nov 2014 19:13:49 -0800 (PST)
Subject: how can I convert from a .pcf config file?
Message-ID: <alpine.DEB.2.02.1411201908540.12576@nftneq.ynat.uz>

My Corp IT team has provided me with a .pcf file that looks like a windows .ini 
file ([main] followed by name=value pairs)

I'm trying to figure out if there's a way to use it with openconnect.

The base VPN connection works with no parameters, but we're trying to test an 
alternate config, and they setup a different group for testing, adding -g 
groupname to the openconnect command line results in the error:

XML POST enabled
Invalid host entry. Please re-enter.
Failed to obtain WebVPN cookie


sanitized version of the config file:

[main]
Description=
Host=vpn1.company.com
AuthType=1
GroupName=vpn3
GroupPwd=
enc_GroupPwd=<hex data>
EnableISPConnect=0
ISPConnectType=0
ISPConnect=
ISPPhonebook=
ISPCommand=
Username=
SaveUserPassword=0
UserPassword=
enc_UserPassword=
NTDomain=
EnableBackup=0
BackupServer=
EnableMSLogon=1
MSLogonType=0
EnableNat=1
TunnelingMode=0
TcpTunnelingPort=10000
CertStore=0
CertName=
CertPath=
CertSubjectName=
CertSerialHash=00000000000000000000000000000000
SendCertChain=0
PeerTimeout=90
EnableLocalLAN=0



From dwmw2 at infradead.org  Fri Nov 21 04:12:08 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 21 Nov 2014 12:12:08 +0000
Subject: Script '/etc/vpnc/vpnc-script' returned error 127
In-Reply-To: <CABN=OShcQBVpUeYEtfCMG0CGAtA6ZVSq=np4ZWyqDdYXYTZpRg@mail.gmail.com>
References: <CABN=OSirbhaoXW_cY5aY1gk65Pf0aQO_B1sfnMZUCeO8pkibww@mail.gmail.com>
 <1416526513.9631.231.camel@infradead.org>
 <CABN=OShcQBVpUeYEtfCMG0CGAtA6ZVSq=np4ZWyqDdYXYTZpRg@mail.gmail.com>
Message-ID: <1416571928.9631.235.camel@infradead.org>

Please always remember to hit 'reply to all' to keep the mailing list in
Cc. And remember to quote *only* what is absolutely needed for context
from the previous mail, and put your own response *below* the relevant
citation.

On Fri, 2014-11-21 at 01:25 +0100, Iv Njrc wrote:
> 
> Thanks for answering!
> Here are my answers:
> 1) Ok. I checked with ip addr and ip route that the VPN was not
> established. =c(

That's not surprising, if the script hasn't run and set up the
networking for you.

> 2) "Can you run /etc/vpnc/vpnc-script directly?" No, I can't run it
> directly. It says that "this script must be called from vpnc"

OK, so you *can* run it and the script itself gives you an error. That's
precisely the output I expected when you run it. Not the 'No such file
or directory' and failing even to run the script which you reported in
your original mail.

But Kevin spotted something I didn't ? it is /etc/vpnc/vpnc-script.sh
or /etc/vpnc/vpnc-script ? It looks like you have one, and you asked for
the other.

> Should I "install" any vpnc tool? I just created the directory and add
> the script, which seems weird for me.

No, I suspect you just need to stop typing and start using cut/paste or
tab-completion so you don't get filenames wrong :)

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

From shouldbeq931 at gmail.com  Fri Nov 21 12:33:47 2014
From: shouldbeq931 at gmail.com (shouldbe q931)
Date: Fri, 21 Nov 2014 20:33:47 +0000
Subject: how can I convert from a .pcf config file?
In-Reply-To: <alpine.DEB.2.02.1411201908540.12576@nftneq.ynat.uz>
References: <alpine.DEB.2.02.1411201908540.12576@nftneq.ynat.uz>
Message-ID: <CAP1_MOC+B5ROB7cWfYVqtYYY6yPP2cycbWbNqtKTGdMHiy8whg@mail.gmail.com>

On Fri, Nov 21, 2014 at 3:13 AM, David Lang <david at lang.hm> wrote:
> My Corp IT team has provided me with a .pcf file that looks like a windows
> .ini file ([main] followed by name=value pairs)
>
> I'm trying to figure out if there's a way to use it with openconnect.
>
> The base VPN connection works with no parameters, but we're trying to test
> an alternate config, and they setup a different group for testing, adding -g
> groupname to the openconnect command line results in the error:
>
> XML POST enabled
> Invalid host entry. Please re-enter.
> Failed to obtain WebVPN cookie
>
>
> sanitized version of the config file:
>
> [main]
> Description=
> Host=vpn1.company.com
> AuthType=1
> GroupName=vpn3
> GroupPwd=
> enc_GroupPwd=<hex data>
> EnableISPConnect=0
> ISPConnectType=0
> ISPConnect=
> ISPPhonebook=
> ISPCommand=
> Username=
> SaveUserPassword=0
> UserPassword=
> enc_UserPassword=
> NTDomain=
> EnableBackup=0
> BackupServer=
> EnableMSLogon=1
> MSLogonType=0
> EnableNat=1
> TunnelingMode=0
> TcpTunnelingPort=10000
> CertStore=0
> CertName=
> CertPath=
> CertSubjectName=
> CertSerialHash=00000000000000000000000000000000
> SendCertChain=0
> PeerTimeout=90
> EnableLocalLAN=0
>
>

That looks like IPSec not AnyConnect, the key part being
"TcpTunnelingPort=10000"

Cheers


From lyre2005 at gmail.com  Tue Nov 25 06:26:49 2014
From: lyre2005 at gmail.com (Eric Lai)
Date: Tue, 25 Nov 2014 08:26:49 -0600
Subject: Split Tunnel in Windows 8.1
Message-ID: <CAJ4SLpsE8tr_5vFY4WwQoxpYxLO9iqQLG0aObcxGKtfDBJKQjw@mail.gmail.com>

Hi,
    I have one Ubuntu laptop and Windows 8.1 laptop. Have great
success configuring Ubuntu one to setup Openconnect to use split
tunnel, i.e. connect to Cisco VPN network for specific resource but
still maintain internet connectivity locally, i.e. not through the VPN
network.
    Trying to setup the same thing on Windows 8.1 laptop and have been
trying to modify vpnc-script-win.js included in the openconnect-gui
0.8 package without much success.
    Just want to ask if this is even possible under Windows 8.1 in
general before I devote more time and effort on it. If someone manage
to get it working, please share your tips or vpnc script.

Thanks,

Eric


From yjzqzu at 163.com  Thu Nov 27 07:05:48 2014
From: yjzqzu at 163.com (leo)
Date: Thu, 27 Nov 2014 15:05:48 +0000 (UTC)
Subject: ocserv cannot auth with pam radius
Message-ID: <loom.20141127T160158-929@post.gmane.org>

I was trying to connect my ocserv with radius pam auth.

in /etc/pam.d/ocserv

I have

auth    required        /lib/security/pam_radius_auth.so

When I connect to the server it shows
 ocserv[2623]:PAM-auth pam_auth_pass: Authentication service cannot 
retrieve authentication info

What should I do?

If addtional information is needed.Please let me know.



From dwmw2 at infradead.org  Thu Nov 27 08:37:51 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 27 Nov 2014 16:37:51 +0000
Subject: OpenConnect 7.00 release
Message-ID: <1417106271.5525.40.camel@infradead.org>

Lots of fun stuff here, especially on Windows. We now support keys from
the Windows certificate store, and the new NDIS6 TAP-Windows driver. And
should run on systems as far back as Windows XP.

In order to simplify string ownership rules and reduce the likelihood of
bugs, and to cope with restrictions that Windows 'DLL Hell' imposes, the
API has been completely changed so that strings do not change ownership
when they are passed into the library. API functions take 'const char *'
and will take a *copy* of the string if appropriate. The soname of the
library is bumped accordingly.

This release adds full Unicode handling for both Windows and legacy
non-UTF-8 POSIX platforms. All strings passed into, or out of, the
libopenconnect library should now be UTF-8 and it is the responsibility
of the application if running in a legacy environment to do any
conversions that are necessary.

The utun driver on OS X is now supported, so it's no longer necessary to
install a third-party unsigned kernel module.

OATH HOTP/TOTP keys stored in a Yubikey NEO using the ykneo-oath applet
are also now supported. Tested on OSX, Windows and Linux. Software HOTP
token support is now capable of using a token from a PSKC file and
updating the token counter therein, thus making it actually *useful*.

Thread-safety issues caused by using setenv()/putenv() within the
library have now been fixed.

A --no-system-trust option has been added, to prevent OpenConnect from
trusting any certificate authorities apart from those explicitly passed
to it with the --cafile option. Corresponding library APIs also exist.

Thanks to Nikos Mavrogiannopoulos and Kevin Cernekee in particular for
their significant contributions to this release. Their Android and
Windows clients are a major factor in continued improvements.


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

Chad Catlett (1):
      Check to avoid calling iconv_close(-1) in openconnect_vpninfo_free

David Woodhouse (204):
      Fix crash on invocation with --token-mode but no --token-secret
      Slightly optimise Proxy-Authenticate: header parsing
      Improve reporting when GSSAPI auth requested but not compiled in
      Fix off-by-one in xmlnode_msg() handling of error messages
      Solaris 10 *still* doesn't have 'grep -q'
      Revamp GSSAPI detection
      Avoid retrying without XML POST when we didn't even manage to connect
      Fix openconnect_base64_decode() to return the buffer
      Cosmetic fix in cleanup_ntlm_auth()
      Honour Proxy-Connection: close during authentication
      Import translations from GNOME
      Fix potential memory leak on GSSAPI failure
      Improve GSSAPI error reporting
      Don't force a reconnect if GSSAPI fails without trying
      Use RegQueryValueEx() instead of RegGetValue() to support 32-bit Windows XP
      Import translations from GNOME
      Resync translations with sources
      Sort openconnect.pot by file to avoid spurious changes
      Fix signedness in url-encoding for legacy auth postings
      Clean up return paths in openconnect_obtain_cookie()
      Use oc_text_buf for auth postings
      Return body from process_http_response() in oc_text_buf
      Dynamically find GetVolumeInformationByHandleW(); old Windows lacks it
      Add inet_pton() compatibility for Windows
      Make buf_append_urlencoded() more conservative about non-ASCII chars.
      Move buf_append_utf16le() to http.c and make it non-static
      Use "Unicode" versions of SSPI functions
      Add buf_append_from_utf16le() which appends UTF-8 to the buffer
      Handle non-ASCII tun device names under Windows
      Print name of Windows tun device not devname
      Use read_stdin() instead of fgets() in certificate validation
      Export asprintf() and vasprintf() compatibility functions
      Refactor read_stdin() a little to prepare for charset conversion
      Attempt to convert output to locale charset from UTF-8
      Convert to UTF-8 when reading from stdin
      Separate read_stdin() implementations for Windows vs. POSIX
      Handle UTF-8 input on Windows
      Handle UTF-8 output on Windows too
      Fixes for buf_append_utf16le()
      Use _wputenv() for Windows environment
      Fix tun device matching with --interface on Windows
      Move Windows UTF-8 stdio functions up to live with POSIX ones
      Introduce dup_config_arg() macro
      Add conversion to UTF-8 of command-line arguments
      Add missing 'Proxy CONNECT request failed: %d' translation back
      Use setlocale() unconditionally, complain if non-UTF8 locale and no iconv
      Take a copy of the string that nl_langinfo() returns
      Fix some arguments missing dup_config_arg()
      Add openconnect_utf8_to_legacy() helper function for charset conversion
      Add open_utf8() and fopen_utf8() functions for opening files
      Use open_utf8() in GnuTLS load_datum()
      Convert vpninfo->ifname to legacy charset for $TUNDEV and configuration
      Convert $CISCO_BANNER environment variable to legacy charset
      Convert vpnc_script to legacy charset (or UTF-16 for Windows)
      Factor out OpenSSL install_extra_certs() from load_pkcs12_certificate()
      Extend reload_pem_cert() to become load_cert_chain_file()
      Avoid SSL_CTX_use_RSAPrivateKey_file() because it doesn't handle UTF-8.
      Convert cafile to legacy charset for OpenSSL
      Convert last remaining OpenSSL code to open_utf8()
      Add web page about charset handling
      Update changelog
      Handle UTF-8 sslkey in BSD openconnect_passphrase_from_fsid
      Handle UTF-8 sslkey in Linux openconnect_passphrase_from_fsid
      Handle UTF-8 sslkey in Windows openconnect_passphrase_from_fsid
      Fix asprintf() handling in openconnect_passphrase_from_fsid()
      Remove static out_pkt
      Fix buf_append_utf16le() error handling harder
      Make buf_append_utf16le() suitable for validation-only
      Check inputs for invalid UTF-8
      Fix csd_wrapper handling for non-UTF8 locales
      Wrap ifreq_set_ifname() in #ifndef __sun__ to shut the compiler up there
      Remove stray perror() in convert_str()
      Update GUI page
      Fix NetBSD compile warnings with isspace()
      Fix UTF-8 handling of config file name
      Use O_BINARY for xmlconfig file
      Silence iconv() compiler warnings on systems which expect (const char **)
      Update translations from GNOME
      Fix SOCKS GSSAPI auth to send final token client->server if needed
      Fix SOCKS SSPI auth to send final token client->server if needed
      Fix SSPI SOCKS auth crash on double-cleanup
      Fix endless loop when automatic NTLM auth fails
      Fix ntlm_auth handling to accept AF in auth reply
      Minor SSPI fixes
      Update translations from GNOME
      Convert all args using GetCommandLineW() on Windows
      Be consistent about spelling of cancel{l,}ed
      Update changelog
      For HOTP tokens increment vpninfo->token_time in do_gen_hotp_code()
      Allow whitespace at end of HOTP and TOTP tokens
      Allow HOTP/TOTP secrets to be specified in hex form
      Remember what form we got the HOTP secret in
      Add openconnect_set_token_callbacks() API
      Support writing back to token files from openconnect(8) itself
      Actually lock and unlock/write back HOTP tokens when counter updates
      Update changelog
      Add token lock/unlock callbacks to Java bindings
      Add PSKC support
      Shift TOTP/HOTP functions in auth.c under a single #ifdef HAVE_LIBOATH
      Shift TOTP/HOTP functions in library.c under a single #ifdef HAVE_LIBOATH
      Move HOTP/TOTP code to oath.c
      Move stoken code to stoken.c
      Add software token documentation
      Disable soft token on failure
      Reread token file in lock_token()
      Resync translations with sources
      Use BIO_CLOSE when importing PEM private key with OpenSSL
      Stop using obsolete vpninfo->cert_type in GnuTLS code
      Stop using obsolete vpninfo->cert_type in OpenSSL code
      Remove cert_type field from struct openconnect_info
      Clean up OpenSSL key loading
      Merge branch 'hotp-java-v1' of git://github.com/cernekee/openconnect
      Fix DeviceIoControl() calls to make NDIS6 TAP-Windows driver happy
      Use inet_pton() to provide inet_aton() functionality
      Import translations from GNOME
      Stop internal_parse_url() mangling its input
      Stop openconnect_set_proxy_auth() mangling its input.
      Remove _BSD_SOURCE for Linux builds
      Bump library soname and add 'const' to lots of char * arguments
      Fix up Java code for string handling changes
      Rename 'value' field of struct oc_form_opt to discourage direct access
      Update changelog
      Fix build with OpenSSL
      Add openconnect_free_cert_info()
      Fix cancel_fd handling under non-Windows
      Fix JNI code to use openconnect_free_cert_info()
      Add getCSTPCipher() and getDTLSCipher() methods to Java bindings
      Cache cstp_cipher string for GnuTLS only
      Add openconnect_set_system_trust() to library API
      Import translations from GNOME
      Resync translations with sources
      Print error message strings on Windows
      Trivial translation update for Windows error output
      Resync translations with sources
      Strip trailing \r\n from Windows error messages
      Fix incompatible-pointer-types-discards-qualifiers warning on GhostBSD/clang
      Fix some clang format-nonliteral warnings
      Include stdlib.h in GSSAPI test to fix detection on GhostBSD
      Fix FreeBSD with devfs_cloning off. Harder.
      Add utun support for OS X
      Allow 'utun0' device name on OSX
      Make openconnect_init_ssl() return success/failure code
      Add vpn_perror() macro and use it instead of perror()
      Make GNUTLS_E_PUSH_ERROR reporting for DTLS slightly more helpful
      Handle ERROR_OPERATION_ABORTED on Windows TAP device
      Switch to using AM_ICONV
      Import AM_ICONV implementation
      Fix mingw32 build where libtool was failing to check for egrep
      Use ICONV_CONST now that we have it
      Detect libintl in $prefix too, like we to do libiconv
      Fix Solaris build
      Avoid writing directly to stderr on OpenSSL UI error
      Avoid writing directly to stderr on Solaris tun error
      Start to clean up #ifdef mess in tun.c
      Clean up Linux and BSD/OSX functionality in tun.c
      Fix thread-unsafe setenv() usage
      Allow console output from vpnc-script on Windows
      Stop calling setenv() from JNI code
      Update changelog
      Do not call vpn_progress() after forking
      Kill OPENCONNECT_X509, let certain functions only operate on peer_cert
      Provide openconnect_check_peer_cert_hash() function
      Add --no-system-trust command line option
      Switch to using SHA1 of server public key
      Update changelog
      Fix error handling for --servercert mismatch
      Do not allow Darwin to autoallocate utun devices
      Fix lifetime of cstp_cipher and peer_cert_hash strings
      Avoid leaking vpninfo->platname
      Fix up some more memory leaks
      Make set_peer_cert_hash() static
      Fix libintl linkage in pkg-config
      Fix GnuTLS openconnect_local_cert_md5() to give text output not binary
      Handle gnutls_certificate_get_ours() only returning the cert if it's used
      Update Java bindings for peer certificate handling changes
      Fix double-free in gnutls_pkcs12_simple_parse()
      Build for Java 1.5 to avoid compatibility issues
      Add initial support for TOTP/HOTP keys in Yubikey NEO
      Free PC/SC contexts in openconnect_vpninfo_free()
      SCard API cleanups
      Make Yubikey support build on Windows
      Improve error message when yubikey applet select fails
      Make Yubikey support build on OS X
      Document YubiOATH support
      Add openconnect_yubikey_challenge()
      Factor out select_yubioath_applet() function and make it do authentication
      Implement password request for Yubikey
      Avoid keeping the real Yubikey PIN around
      Add comment about Yubikey password charset brain-damage
      Rename --token-mode=yubikey to --token-mode=yubioath
      Use SCardListReadersW()/SCardConnectW() in Windows
      Fix GnuTLS 2.12 build
      Use native GnuTLS PIN callback instead of p11-kit where possible
      Remove vpninfo->servercert
      Sort linker script
      Admit Yubioath support in header comments
      Print YubiOATH support status in test Java app
      Fix Windows documentation for --script argument
      Documentation updates
      Add support for GnuTLS system keys
      Update changelog
      Add openconnect_has_system_key_support()
      Resync translations with sources
      Tag version 7.00

Joe Hu (1):
      Fix incorrect return value of inet_aton() shim

Kevin Cernekee (18):
      http: Fix memory leak in do_https_request()
      http: Call buf_truncate() before appending XML POST data
      http: Don't leak orig_host or orig_path
      http: Fix CSD https requests
      xml: Make a generic function to read a file into a string
      xml: Trim whitespace from xmlconfig entries
      xml: Call openconnect_parse_url() on <HostAddress> entries
      main: Restore tty state if password prompt is aborted
      main: Allow reading --token-secret from a file
      auth: Rearrange stoken support code
      auth: Refactor stoken form handling
      Rename and export open_utf8(), fopen_utf8()
      ssl: Allow openconnect_open_utf8() to be used with O_CREAT
      ssl: Support more read/write modes in openconnect_fopen_utf8()
      Use openconnect_[f]open_utf8() for xmlconfig, pidfile, config_file
      java: Add constant for OC_TOKEN_MODE_HOTP
      jni: Fix onTokenLock() invocation from native code
      www: Add notes on SecurID PIN usage

Nikos Mavrogiannopoulos (16):
      Added a default timeout value in CSTP handshake using gnutls
      use windows types and return codes for socket errors
      use recv() and closesocket() on the cmd_fd on windows
      use CreateProcess instead of system to run scripts.
      define _GNU_SOURCE to get asprintf's definition in mingw32
      mention openconnect-gui
      do not take ownership of any of the provided strings
      define openconnect_set_option_value() to set the value in oc_form_opt
      clear all cookies when doing a reset SSL
      remove the disable safe renegotiation flag from DTLS
      corrected gnutls version number check
      Added API to read the ciphersuites used for CSTP and DTLS
      Make the cipher strings consistent based on which library is in use
      Added openconnect_set_system_trust()
      Add setSystemTrust() to Java bindings
      force DTLS reconnect if the session ID we get from TLS changes

Paul Donohue (1):
      Fix invalid/double free if PKCS#11 token does not include CA certs

Stuart Henderson (1):
      GNUism in www/Makefile

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

From n.mavrogiannopoulos at gmail.com  Fri Nov 28 00:59:09 2014
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 28 Nov 2014 09:59:09 +0100
Subject: OpenConnect 7.00 release
In-Reply-To: <1417106271.5525.40.camel@infradead.org>
References: <1417106271.5525.40.camel@infradead.org>
Message-ID: <CAJU7zaJFB99yArzBTj6APc382ZzDDmxAbUTKvUsDMjK6oJvPoQ@mail.gmail.com>

A small patch over 7.00. I realized that the cipher name got after
setup_dtls() is the NULL cipher because handshake isn't complete. I
think it is better to return NULL at that point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-when-DTLS-is-not-connected-do-not-return-a-bogus-cip.patch
Type: text/plain-diff
Size: 928 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141128/2b591b46/attachment.bin>

From nmav at gnutls.org  Fri Nov 28 23:29:15 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Nov 2014 08:29:15 +0100
Subject: connecting to dynamic dns
Message-ID: <1417246155.2022.1.camel@gnutls.org>

When connecting to an IP which is dynamic, it may often change and
require a reconnection. However, cstp_reconnect() will attempt to
connect to the cached IP and never fallback. The attached patch fixes
the issue for me, but what would be the best approach?
1. Don't cache the IP at all
2. Add an openconnect flag and API call for dynamic IPs

The second sounds like more generic but I think it complicates the API
and the application quite a lot.

regards,
Nikos

-------------- next part --------------
diff --git a/cstp.c b/cstp.c
index b1235ef..05c3444 100644
--- a/cstp.c
+++ b/cstp.c
@@ -591,6 +591,8 @@ static int cstp_reconnect(struct openconnect_info *vpninfo)
 	timeout = vpninfo->reconnect_timeout;
 	interval = vpninfo->reconnect_interval;
 
+	free(vpninfo->peer_addr); 
+	vpninfo->peer_addr = NULL;
 	while ((ret = openconnect_make_cstp_connection(vpninfo))) {
 		if (timeout <= 0)
 			return ret;
@@ -611,6 +613,8 @@ static int cstp_reconnect(struct openconnect_info *vpninfo)
 		interval += vpninfo->reconnect_interval;
 		if (interval > RECONNECT_INTERVAL_MAX)
 			interval = RECONNECT_INTERVAL_MAX;
+		free(vpninfo->peer_addr); 
+		vpninfo->peer_addr = NULL;
 	}
 	script_config_tun(vpninfo, "reconnect");
 	return 0;

From dwmw2 at infradead.org  Sat Nov 29 05:54:48 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 29 Nov 2014 13:54:48 +0000
Subject: connecting to dynamic dns
In-Reply-To: <1417246155.2022.1.camel@gnutls.org>
References: <1417246155.2022.1.camel@gnutls.org>
Message-ID: <1417269288.5525.43.camel@infradead.org>

On Sat, 2014-11-29 at 08:29 +0100, Nikos Mavrogiannopoulos wrote:
> When connecting to an IP which is dynamic, it may often change and
> require a reconnection. However, cstp_reconnect() will attempt to
> connect to the cached IP and never fallback. The attached patch fixes
> the issue for me, but what would be the best approach?
> 1. Don't cache the IP at all

Hm, the problem with this is that you may now be using a DNS server *on*
the VPN. So it's unlikely that the DNS lookup will succeed. And even if
it *does* work because you still have a live DTLS connection, if you
have schizoDNS you might find that the hostname either doesn't exist in
the internal view or resolves to something different.

And then if you have full tunnel routing you're going to need to change
the routes so that the new server IP address isn't routed through the
VPN...

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

From nmav at gnutls.org  Sat Nov 29 06:26:22 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Nov 2014 15:26:22 +0100
Subject: connecting to dynamic dns
In-Reply-To: <1417269288.5525.43.camel@infradead.org>
References: <1417246155.2022.1.camel@gnutls.org>
 <1417269288.5525.43.camel@infradead.org>
Message-ID: <1417271182.24664.1.camel@gnutls.org>

On Sat, 2014-11-29 at 13:54 +0000, David Woodhouse wrote:
> On Sat, 2014-11-29 at 08:29 +0100, Nikos Mavrogiannopoulos wrote:
> > When connecting to an IP which is dynamic, it may often change and
> > require a reconnection. However, cstp_reconnect() will attempt to
> > connect to the cached IP and never fallback. The attached patch fixes
> > the issue for me, but what would be the best approach?
> > 1. Don't cache the IP at all
> 
> Hm, the problem with this is that you may now be using a DNS server *on*
> the VPN. So it's unlikely that the DNS lookup will succeed. And even if
> it *does* work because you still have a live DTLS connection, if you
> have schizoDNS you might find that the hostname either doesn't exist in
> the internal view or resolves to something different.

Well, at that point I don't have VPN. The CSTP reconnection occurs when
the TCP connection part of the VPN is closed. That can only occur if the
server is down, thus the UDP part is also off. Are there servers which
forcefully close the CSTP connection but expect the DTLS connection to
remain active?

regards,
Nikos




From dwmw2 at infradead.org  Sat Nov 29 07:03:16 2014
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 29 Nov 2014 15:03:16 -0000
Subject: connecting to dynamic dns
In-Reply-To: <1417271182.24664.1.camel@gnutls.org>
References: <1417246155.2022.1.camel@gnutls.org>
 <1417269288.5525.43.camel@infradead.org>
 <1417271182.24664.1.camel@gnutls.org>
Message-ID: <4ebe183821d6711b6f036ca97bc8f5a6.squirrel@twosheds.infradead.org>


> Well, at that point I don't have VPN. The CSTP reconnection occurs when
> the TCP connection part of the VPN is closed. That can only occur if the
> server is down, thus the UDP part is also off. Are there servers which
> forcefully close the CSTP connection but expect the DTLS connection to
> remain active?

Well, I'm not sure about 'forcefully close' but it's certainly possible to
lose the TCP connection for various reasons (packet loss, NAT brokenness,
etc.) while DTLS is still running.

Either way, the point is that surely DNS is unlikely to work right. And
even if it does you may need to run the vpnc-script to set up routes
correctly for the new server.

I wonder if the better solution here is a wrapper which will restart the
connection from scratch... it can keep the same cookie.

Let the reconnect (to the old IP address) fail. Run vpnc-script to tear
down the network config. Then where appropriate, do tje DNS lookup again.
If there's a new address, try to connect to that using the existing
cookie. Can that work?

-- 
dwmw2



From nmav at gnutls.org  Sat Nov 29 09:11:49 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Nov 2014 18:11:49 +0100
Subject: connecting to dynamic dns
In-Reply-To: <4ebe183821d6711b6f036ca97bc8f5a6.squirrel@twosheds.infradead.org>
References: <1417246155.2022.1.camel@gnutls.org>
 <1417269288.5525.43.camel@infradead.org>
 <1417271182.24664.1.camel@gnutls.org>
 <4ebe183821d6711b6f036ca97bc8f5a6.squirrel@twosheds.infradead.org>
Message-ID: <1417281109.26990.1.camel@gnutls.org>

On Sat, 2014-11-29 at 15:03 +0000, David Woodhouse wrote:
> > Well, at that point I don't have VPN. The CSTP reconnection occurs when
> > the TCP connection part of the VPN is closed. That can only occur if the
> > server is down, thus the UDP part is also off. Are there servers which
> > forcefully close the CSTP connection but expect the DTLS connection to
> > remain active?
> 
> Well, I'm not sure about 'forcefully close' but it's certainly possible to
> lose the TCP connection for various reasons (packet loss, NAT brokenness,
> etc.) while DTLS is still running.

I find that such a corner case to even bother to handle. Packet loss
would affect both TCP and UDP, and if NAT brokenness would terminate TCP
sessions, I'd expect to affect primarility UDP too.

> Either way, the point is that surely DNS is unlikely to work right. And
> even if it does you may need to run the vpnc-script to set up routes
> correctly for the new server.

As I mentioned before it works :)

> I wonder if the better solution here is a wrapper which will restart the
> connection from scratch... it can keep the same cookie.
> Let the reconnect (to the old IP address) fail. Run vpnc-script to tear
> down the network config. Then where appropriate, do tje DNS lookup again.
> If there's a new address, try to connect to that using the existing
> cookie. Can that work?

I think the openconnect mainloop is the responsible to handle that, but
anyway that's similar to what openwrt is currently doing (without
reusing the cookies). It means however, a very long downtime when the
peer changes IP, since it has have to wait for the timeout of
openconnect which retries for 5 minutes on the same IP, and in addition
termination of the vpn connections (because openconnect has teared down
the network and routes).

I believe a reasonable approach to be to not strive for zero downtime in
the corner cases you mention above (losing the TCP session due to NAT
brokenness, packet loss etc), and handle that use-case. That is, if a
reconnection is prompted by the server terminating the TCP session, it
would mean re-resolving of dns and reconnection.
Now the issues you mentioned:
1. "The new DNS is routed through the VPN": That is a configuration
issue, nothing openconnect can solve.
2. "The name cannot be resolved at all": Fallback to the old one.
3. About the corner cases: the disruption would be insignificant and
temporary (not something like 5 min downtime as it is now).

What do you think of something like the above?

regards,
Nikos




From nmav at gnutls.org  Sat Nov 29 10:02:06 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Nov 2014 19:02:06 +0100
Subject: connecting to dynamic dns
In-Reply-To: <1417281109.26990.1.camel@gnutls.org>
References: <1417246155.2022.1.camel@gnutls.org>
 <1417269288.5525.43.camel@infradead.org>
 <1417271182.24664.1.camel@gnutls.org>
 <4ebe183821d6711b6f036ca97bc8f5a6.squirrel@twosheds.infradead.org>
 <1417281109.26990.1.camel@gnutls.org>
Message-ID: <1417284126.26990.3.camel@gnutls.org>

On Sat, 2014-11-29 at 18:11 +0100, Nikos Mavrogiannopoulos wrote:

> What do you think of something like the above?

Something like the attached patch. It will try resolving again in case
the CSTP session was broken due to server error, and if that fails it
will fallback to the original IP used.

regards,
Nikos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Re-resolve-when-reconnecting-CSTP.patch
Type: text/x-patch
Size: 6011 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141129/bc8f2271/attachment.bin>

From cernekee at gmail.com  Sat Nov 29 15:26:32 2014
From: cernekee at gmail.com (Kevin Cernekee)
Date: Sat, 29 Nov 2014 15:26:32 -0800
Subject: connecting to dynamic dns
In-Reply-To: <1417269288.5525.43.camel@infradead.org>
References: <1417246155.2022.1.camel@gnutls.org>
 <1417269288.5525.43.camel@infradead.org>
Message-ID: <CAJiQ=7AahXndWmfgts2ynV=iHFGkKaeXnOiFSooS09FBTAH3nQ@mail.gmail.com>

On Sat, Nov 29, 2014 at 5:54 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Sat, 2014-11-29 at 08:29 +0100, Nikos Mavrogiannopoulos wrote:
>> When connecting to an IP which is dynamic, it may often change and
>> require a reconnection. However, cstp_reconnect() will attempt to
>> connect to the cached IP and never fallback. The attached patch fixes
>> the issue for me, but what would be the best approach?
>> 1. Don't cache the IP at all
>
> Hm, the problem with this is that you may now be using a DNS server *on*
> the VPN. So it's unlikely that the DNS lookup will succeed. And even if
> it *does* work because you still have a live DTLS connection, if you
> have schizoDNS you might find that the hostname either doesn't exist in
> the internal view or resolves to something different.
>
> And then if you have full tunnel routing you're going to need to change
> the routes so that the new server IP address isn't routed through the
> VPN...

For the special case of Android, you can ask the OS to route traffic
over the "primary" network connection (bypassing the VPN) on a per-fd
basis.  We already do this through the protect_socket() callback for
CSTP/DTLS reconnections.  DNS might be a bigger challenge, unless you
wanted to bypass the resolver built into libc.

Not sure if there is a clean, portable way to make this work with
vpnc-script though.

Nikos:
> 1. "The new DNS is routed through the VPN": That is a configuration issue, nothing openconnect can solve.

Well, in a corporate installation, that is pretty much the norm
because you'll want people to be able to look up internal hostnames.
And the schizoDNS setup that David referred to is more likely.

But on a dyndns installation (presumably somebody's home cable/DSL
line) maybe the goals are different.  The various "bypass GFW"
tutorials I've seen online have often instructed the ocserv
administrator to configure DNS using a public server like 8.8.8.8 and
to push a long list of split tunnel routes allowing access to specific
blocked services.  Likewise, if somebody is using ocserv to provide
access to their home LAN, they might push a route for 192.168.1.0/24
and allow other traffic to use the primary network connection.

If somebody is using ocserv to circumvent e.g. OpenDNS parental
controls or as a full tunnel to avoid workplace snooping, then
(currently) they would want to be using a static IP.

Do you think it makes sense for ocserv to pass a hint to the client
that the server's IP is dynamic?


From imhorsley at gmail.com  Sat Nov 29 20:37:39 2014
From: imhorsley at gmail.com (horsley)
Date: Sun, 30 Nov 2014 04:37:39 +0000 (UTC)
Subject: about  AUTHENTICATION mode plain 
Message-ID: <loom.20141130T051927-641@post.gmane.org>

I want to ask why ocserv using plain authentication response the auth xml in two 
step?

first is Please enter your username

<?xml version="1.0" encoding="UTF-8"?>
<config-auth client="vpn" type="auth-request">
<version who="sg">0.1(1)</version>
<auth id="main">
<message>Please enter your username</message>
<form method="post" action="/auth">
<input type="text" name="username" label="Username:" />
</form></auth>
</config-auth>

and then the password

That's make the client prompt twice, and while I use an url to control 
the client externally like 
anyconnect:connect?name=vpn&host=abc.com
&prefill_username=user&prefill_password=pass

it's still prompt for password.(username is prefill ok but password are not)

so why not send the complete auth request including user and password in 
the xml form together?



From nmav at gnutls.org  Sun Nov 30 01:18:57 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 30 Nov 2014 10:18:57 +0100
Subject: connecting to dynamic dns
In-Reply-To: <CAJiQ=7AahXndWmfgts2ynV=iHFGkKaeXnOiFSooS09FBTAH3nQ@mail.gmail.com>
References: <1417246155.2022.1.camel@gnutls.org>
 <1417269288.5525.43.camel@infradead.org>
 <CAJiQ=7AahXndWmfgts2ynV=iHFGkKaeXnOiFSooS09FBTAH3nQ@mail.gmail.com>
Message-ID: <1417339137.2024.2.camel@gnutls.org>

On Sat, 2014-11-29 at 15:26 -0800, Kevin Cernekee wrote:

> But on a dyndns installation (presumably somebody's home cable/DSL
> line) maybe the goals are different.  The various "bypass GFW"
> tutorials I've seen online have often instructed the ocserv
> administrator to configure DNS using a public server like 8.8.8.8 and
> to push a long list of split tunnel routes allowing access to specific
> blocked services.  Likewise, if somebody is using ocserv to provide
> access to their home LAN, they might push a route for 192.168.1.0/24
> and allow other traffic to use the primary network connection.
> [...]
> Do you think it makes sense for ocserv to pass a hint to the client
> that the server's IP is dynamic?

It would. I could send a patch if David agrees too.

regards,
Nikos





From nmav at gnutls.org  Sun Nov 30 01:21:45 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 30 Nov 2014 10:21:45 +0100
Subject: about  AUTHENTICATION mode plain
In-Reply-To: <loom.20141130T051927-641@post.gmane.org>
References: <loom.20141130T051927-641@post.gmane.org>
Message-ID: <1417339305.2024.4.camel@gnutls.org>

On Sun, 2014-11-30 at 04:37 +0000, horsley wrote:
> I want to ask why ocserv using plain authentication response the auth xml in two 
> step?
> 
> first is Please enter your username
[...]
> it's still prompt for password.(username is prefill ok but password are not)
> so why not send the complete auth request including user and password in 
> the xml form together?

Hi,
 If I understand what you are describing correctly, that was done in
early versions of ocserv. However, that does not tie well with PAM which
has its own prompts, which may even prompt to change a password. So the
short answer, is so that it can be integrated with PAM.

regards,
Nikos




From nuxx at hot.ee  Sun Nov 30 02:23:23 2014
From: nuxx at hot.ee (Nuxx)
Date: Sun, 30 Nov 2014 12:23:23 +0200
Subject: ubuntu 14.10,networkmanager and openconnect
Message-ID: <547AF01B.5020107@hot.ee>

Hello,

Ubuntu 14.10 Lenovo X240.
network-manager-openconnect 0.9.8.6-1ubuntu2
openconnect                                          6.00-1

over Wifi, networkmanager manages okay openconnect vpn, but using build 
in 4G internet, it wont add default route anymore.
using USB tongle 3/4G works fine.
using command line openconnect vpn.myserver.com works fine.

i think there a problem with interface name wwan0 what internal 4G 
creates. usb tongle uses ppp0





From imhorsley at gmail.com  Sun Nov 30 03:53:15 2014
From: imhorsley at gmail.com (lee horsley)
Date: Sun, 30 Nov 2014 19:53:15 +0800
Subject: about AUTHENTICATION mode plain
In-Reply-To: <1417339305.2024.4.camel@gnutls.org>
References: <loom.20141130T051927-641@post.gmane.org>
 <1417339305.2024.4.camel@gnutls.org>
Message-ID: <CAJ4i3skA9ZPkHkiYu6M-n7g-fXv0B07CL7+n5wNx1U4Rg_Yd=Q@mail.gmail.com>

Hi,
I am using another vpn which is powered by offical Cisco ASA Firewall,
That's prompt the username and password  together. The client config was
the same as the one using ocserv, plain username and password.

Actually, that's service was using an one-time password and the password
was transfered through the connect url, so end-user just open a website and
do login stuff and finally the website redirect to the connect url as
I mentioned
above. The connect url contained pre-fill username and password so end-user
neither need to care about the password nor input the password.

But while using ocserv with plain auth mode, the connect url was not working
and end-user must input the password manually. And I found the username was
pre-fill ok, it becomes prompt one time for password only instead of two prompt,
username and password. So I am thinking about if we send the auth form
including username and password field together, the client will act
pre-fill well.

As I was not using the certificate auth mode, end-user need to input
the password
manually, that's quite annoying

2014-11-30 17:21 GMT+08:00 Nikos Mavrogiannopoulos <nmav at gnutls.org>:
> On Sun, 2014-11-30 at 04:37 +0000, horsley wrote:
>> I want to ask why ocserv using plain authentication response the auth xml in two
>> step?
>>
>> first is Please enter your username
> [...]
>> it's still prompt for password.(username is prefill ok but password are not)
>> so why not send the complete auth request including user and password in
>> the xml form together?
>
> Hi,
>  If I understand what you are describing correctly, that was done in
> early versions of ocserv. However, that does not tie well with PAM which
> has its own prompts, which may even prompt to change a password. So the
> short answer, is so that it can be integrated with PAM.
>
> regards,
> Nikos
>
>


From azuisalpha at gmail.com  Sun Nov 30 16:41:13 2014
From: azuisalpha at gmail.com (Claud)
Date: Mon, 1 Dec 2014 11:41:13 +1100
Subject: cserv doesn't call script-disconnect when client roaming through
 different network
Message-ID: <CAJnXRTTDzLrkiRoWL4N-MH5=BwoodzJhynJZGG2m6XZ5RfdBbg@mail.gmail.com>

Hi,

When I use ocserv as VPN server, I found that if the client pause the
connection and resume on the same network (same IP address), ocserv
will call script-disconnect before script-connect executed. But when
the same client roaming between netwok (IP address changed).  Ocserv
was only call script-connect and script-disconnect never called. Will
it be fixed?

ocserv version 0.8.8


Best Regards,
Xi,


