Re: [Openvpn-devel] Help with testing OpenVPN 2.3.3 installers with tap-windows6? (Openvpn-devel Digest, Vol 95, Issue 44)

2014-04-30 Thread Christian Rank
On 04/30/2014 02:15 PM, Samuli Seppänen wrote:
> 
>> On 04/29/2014 10:02 PM, Samuli Sepp?nen wrote:
>>> Hi all,
>>>
>>> I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers:
>>>
>>> 
>>>
>>> Note the build number, "605", where the first digit ("6") means "comes
>>> with an NDIS 6 driver".
>>>
>>> I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but
>>> my testing was anything but extensive.  So, if [some of] you happen to
>>> have a non-critical Windows box(es) lying around it'd be great if you
>>> could test whether the new driver works ok in your environment. I
>>> suggest removing any previous OpenVPN installations, installing the new
>>> package and then verifying the driver version using the Device Manager;
>>> the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0
>>>
>>> Note that as tap-windows6 is still an unproven driver it can BSOD. We
>>> haven't experienced any problems with it, but it's best too keep that
>>> possibility in mind.
>>>
>>> We will soon start offering the OpenVPN installer with NDIS 6-driver as
>>> an option and hopefully soon afterwards make them the default option for
>>> Windows Vista and above.
>>>
>> Hello,
>>
>> I've just done some testing on Win7 64-bit (german localization) and
>> didn't notice any problems. However, driver assembly version is
>> indicated as "9.0.0.21", not "9.21.0". (?)
>>
>> Regards,
>>  Christian
>>
> Thanks for testing, Christian!
> 
> I believe that odd version number is to be expected, and really boils
> down to formatting differences. Similarly the old tap-windows (NDIS 5)
> driver will report 9.0.0.9 as it's version - in our parlance that
> translates to 9.9.x.
> 

Hello Samuli,

thanks for clarification. I've now tested successfully on Win 8.1 64-bit
(german localization). Version numbers are the same as on Win 7.

Regards,
Christian

-- 
Dr. Christian Rank
Rechenzentrum Universität Passau
Bereich Netzwerk und Telekommunikation
IT-Sicherheitsbeauftragter der Universität
Innstr. 33
D-94032 Passau
GERMANY
Tel.: 0851/509-1838
Fax:  0851/509-1802



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Openvpn-devel] Help with testing OpenVPN 2.3.3 installers with tap-windows6? (Openvpn-devel Digest, Vol 95, Issue 44)

2014-04-30 Thread Christian Rank
On 04/29/2014 10:02 PM, Samuli Sepp?nen wrote:
> Hi all,
> 
> I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers:
> 
> 
> 
> Note the build number, "605", where the first digit ("6") means "comes
> with an NDIS 6 driver".
> 
> I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but
> my testing was anything but extensive.  So, if [some of] you happen to
> have a non-critical Windows box(es) lying around it'd be great if you
> could test whether the new driver works ok in your environment. I
> suggest removing any previous OpenVPN installations, installing the new
> package and then verifying the driver version using the Device Manager;
> the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0
> 
> Note that as tap-windows6 is still an unproven driver it can BSOD. We
> haven't experienced any problems with it, but it's best too keep that
> possibility in mind.
> 
> We will soon start offering the OpenVPN installer with NDIS 6-driver as
> an option and hopefully soon afterwards make them the default option for
> Windows Vista and above.
> 

Hello,

I've just done some testing on Win7 64-bit (german localization) and
didn't notice any problems. However, driver assembly version is
indicated as "9.0.0.21", not "9.21.0". (?)

Regards,
Christian

-- 
Dr. Christian Rank
Rechenzentrum Universität Passau
Bereich Netzwerk und Telekommunikation
IT-Sicherheitsbeauftragter der Universität
Innstr. 33
D-94032 Passau
GERMANY
Tel.: 0851/509-1838
Fax:  0851/509-1802



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Openvpn-devel] Help with testing OpenVPN 2.3.3 installers with tap-windows6? (Openvpn-devel Digest, Vol 95, Issue 44)

2014-04-30 Thread Samuli Seppänen

> On 04/29/2014 10:02 PM, Samuli Sepp?nen wrote:
>> Hi all,
>>
>> I built OpenVPN 2.3.3 installers that contain tap-windows6 (NDIS 6) drivers:
>>
>> 
>>
>> Note the build number, "605", where the first digit ("6") means "comes
>> with an NDIS 6 driver".
>>
>> I tested the 64-bit version on Win7 64-bit and it seemed to work ok, but
>> my testing was anything but extensive.  So, if [some of] you happen to
>> have a non-critical Windows box(es) lying around it'd be great if you
>> could test whether the new driver works ok in your environment. I
>> suggest removing any previous OpenVPN installations, installing the new
>> package and then verifying the driver version using the Device Manager;
>> the NDIS 5 driver version is 9.9.2, whereas this new driver is 9.21.0
>>
>> Note that as tap-windows6 is still an unproven driver it can BSOD. We
>> haven't experienced any problems with it, but it's best too keep that
>> possibility in mind.
>>
>> We will soon start offering the OpenVPN installer with NDIS 6-driver as
>> an option and hopefully soon afterwards make them the default option for
>> Windows Vista and above.
>>
> Hello,
>
> I've just done some testing on Win7 64-bit (german localization) and
> didn't notice any problems. However, driver assembly version is
> indicated as "9.0.0.21", not "9.21.0". (?)
>
> Regards,
>   Christian
>
Thanks for testing, Christian!

I believe that odd version number is to be expected, and really boils
down to formatting differences. Similarly the old tap-windows (NDIS 5)
driver will report 9.0.0.9 as it's version - in our parlance that
translates to 9.9.x.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock




[Openvpn-devel] [PATCH applied] Re: Make serial env exporting consistent amongst OpenSSL and PolarSSL builds.

2014-04-30 Thread Gert Doering
ACK.

Patch is slightly bigger than f80a52b09eed8e5e0cad ("the same thing for 
master") as it also backports the renaming of x509_get_serial() to
backend_x509_get_serial() - which is purely cosmetic, but now the code
is better aligned.

Your patch has been applied to the release/2.3 branch.

commit 142d4dd2e98317a03ca9827f03fc4643fe922834 (release/2.3)

Author: Steffan Karger
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 28 21:50:22 2014 +0200

 Make serial env exporting consistent amongst OpenSSL and PolarSSL builds.

 Signed-off-by: Steffan Karger 
 Acked-by: Gert Doering 
 Message-Id: <535eb49e.5090...@karger.me>
 URL: http://article.gmane.org/gmane.network.openvpn.devel/8664
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering




[Openvpn-devel] [PATCH applied] Re: When tls-version-min is unspecified, revert to original versioning approach.

2014-04-30 Thread Gert Doering
Latest iteration of this patch has been applied to the release/2.3 branch,
thanks to all who helped.

commit a291825f7145679e6d1806029290402d0430b465 (release/2.3)

Author: James Yonan
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Apr 28 22:52:11 2014 +0200

 When tls-version-min is unspecified, revert to original versioning 
approach.

 Signed-off-by: James Yonan 
 Signed-off-by: Gert Doering 
 Signed-off-by: Steffan Karger 
 Acked-by: James Yonan 
 Message-Id: <535ec5fe.6060...@karger.me>
 URL: http://article.gmane.org/gmane.network.openvpn.devel/8665
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering




Re: [Openvpn-devel] [PATCH 4/4] When tls-version-min is unspecified, revert to original versioning approach.

2014-04-30 Thread James Yonan

On 28/04/2014 15:19, Steffan Karger wrote:

Hi,

On 27-04-14 22:10, Steffan Karger wrote:

On 27-04-14 19:53, Gert Doering wrote:

On Mon, Apr 21, 2014 at 01:10:04AM -0600, James Yonan wrote: The
attached patch is what I intend to commit to release/2.3 *only*,
not to master - as agreed at the IRC meeting.  "Please ACK" :-)


Sorry, but NAK.


On a more constructive note: attached a new proposal for this patch.


The OpenSSL bits look fine


On a closer look, the wrapping "if (tls_version_min > TLS_VER_UNSPEC)"
in tls_ctx_set_options() seems redundant, because TLS_VER_UNSPEC <
TLS_VER_1_0 < TLS_VER_1_1 < TLS_VER_1_2 and the ifs are checking for
"tls_version_min > TLS_VER_1_x". I've removed these changes in the
attached patch proposal.


the PolarSSL bits
would also allow for SSL_MINOR_VERSION_0, which is SSLv3 and thus a
reduction in security (and actually increases the handshake complexity).


To elaborate a bit: The naming is a bit confusing, but
SSL_MAJOR_VERSION_3 + SSL_MINOR_VERSION_O means SSLv3, ... +
SSL_MINOR_VERSION_1 means TLSv1.0, ... + SSL_MINOR_VERSION_2 means
TLSv1.1, etc. If none are given (what would happen in the previous
version of the patch), PolarSSL defaults the minimum version to SSLv3
and maximum to TLSv1.2. The attached patch thus removes the wrapping "if
(tls_version_min > TLS_VER_UNSPEC)" and sets the default to TLSv1.0 to
TLSv1.2 again. That is equal to the behaviour prior to the TLS
versioning patch.

-Steffan


This is fine.  I can ACK this.

Thanks,
James




[Openvpn-devel] [PATCH applied] Re: Conditionalize calls to print_default_gateway on !ENABLE_SMALL

2014-04-30 Thread Gert Doering
Patch has been applied to the master and release/2.3 branches.

commit c29e08a2f33234fb705a8323c0d9e1e07b0773fd (master)
commit d08a6a94e14a73b62603500b9a1a89cb9ec5cb2f (release/2.3)

Author: Gert Doering
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Tue Apr 29 23:09:39 2014 +0200

 Conditionalize calls to print_default_gateway on !ENABLE_SMALL

 Signed-off-by: Gert Doering 
 Acked-by: Steffan Karger 
 Message-Id: <1398805779-29376-1-git-send-email-g...@greenie.muc.de>
 URL: http://article.gmane.org/gmane.network.openvpn.devel/8670


--
kind regards,

Gert Doering