Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[fragmentux]

I am not convinced 'iperf -r' is reliable (bold claim maybe .. )

iperf3 have dropped -r in favour of -R "reverse mode"
server sends and client receives. but not both on the same run ..

After numerous hangs and some bazaar results with iperf2
i opted to upgrade to iperf3 .. still some slightly odd results
but no hangs so far ..

regards


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[fragmentux]

On 26/03/18 22:21, fragmentux wrote:



On 22/03/18 19:33, Jan Just Keijser wrote:

Hi Selva,

On 22/03/18 18:12, Selva Nair wrote:
On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser 
 wrote:

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:

Hi All,

One of the Viscosity developers here. The TAP driver used by 
Viscosity is

based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
performance differences, as the changes we've made are very minimal.

Besides a name and version number change, the only other 
modification is a
change to the reported network adapter speed, which has Windows 
report the

driver as 1000 Mbit instead of 100 Mbit.

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries 
to QoS

the adapter based on its reported adapter speed, which is of course a
problem if the VPN connection is capable of more than 100 Mbit.

Please find a patch file of the changes attached.


first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 
based)

compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
gigabit test setup.  Strangely enough, it turns out that it's the 
*absence

of* AES256-GCM that makes my Viscosity client faster.
My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
   99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
  240 Mbps +/- 8 Mbps to server
   55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows
clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?


thanks for the confirmation; as for the assymmetry: that can be due to 
many factors, including hardware differences (there is asymmetry on 
Linux as well). It could also be due to the way the tap driver works, 
but I have never been able to get my finger on that , and I don't use 
Windows often enough to bother.





Thought I would have a look at this and I do not find this asymmetry ..


vpn & iperf server = Linux debian 8
iperf version 2.0.5 (08 Jul 2010) pthreads

Mon Mar 26 12:39:03 2018 us=287116 OpenVPN 2.5_git+ipv6pf 
[git:master/902c1f1c71ac+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan  1 2018
Mon Mar 26 12:39:03 2018 us=287135 library versions: OpenSSL 1.0.1t  3 
May 2016, LZO 2.08



vpn & iperf client (1) = Windows 10
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:25:46 2018 us=107859 OpenVPN 2.4.5 
[git:2.4/161afbebdc2b7e24+] x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] 
[LZ4] [PKCS11] [AEAD] built on Mar  1 2018


Mon Mar 26 21:25:46 2018 us=107859 Windows version 6.2 (Windows 8 or 
greater) 64bit


Mon Mar 26 21:25:46 2018 us=107859 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10



vpn & iperf client (2) = Linux Arch
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:36:17 2018 us=258243 OpenVPN 2.4.4 
x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
[MH/PKTINFO] [AEAD] built on Sep 26 2017
Mon Mar 26 21:36:17 2018 us=258256 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10





*** Output from server iperf:


client: iperf -c 10.56.101.238 -r -l 4M -t 30

* Linux server (vpn and iperf) -- AES-256-CBC **

iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)



* Windows client (vpn and iperf)

[  4] local 10.56.101.238 port 5001 connected with 10.56.101.110 port 51370
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-30.1 sec   480 MBytes   134 Mbits/sec

Client connecting to 10.56.101.110, TCP port 5001
TCP window size:  416 KByte (WARNING: requested  867 MByte)

[  4] local 10.56.101.238 port 48867 connected with 10.56.101.110 port 5001
[  4]  0.0-30.3 sec   568 MBytes   157 Mbits/sec


iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[fragmentux]

On 22/03/18 19:33, Jan Just Keijser wrote:

Hi Selva,

On 22/03/18 18:12, Selva Nair wrote:
On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser  
wrote:

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:

Hi All,

One of the Viscosity developers here. The TAP driver used by 
Viscosity is

based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
performance differences, as the changes we've made are very minimal.

Besides a name and version number change, the only other modification 
is a
change to the reported network adapter speed, which has Windows 
report the

driver as 1000 Mbit instead of 100 Mbit.

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries to 
QoS

the adapter based on its reported adapter speed, which is of course a
problem if the VPN connection is capable of more than 100 Mbit.

Please find a patch file of the changes attached.


first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 
based)

compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
gigabit test setup.  Strangely enough, it turns out that it's the 
*absence

of* AES256-GCM that makes my Viscosity client faster.
My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
   99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
  240 Mbps +/- 8 Mbps to server
   55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows
clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?


thanks for the confirmation; as for the assymmetry: that can be due to 
many factors, including hardware differences (there is asymmetry on 
Linux as well). It could also be due to the way the tap driver works, 
but I have never been able to get my finger on that , and I don't use 
Windows often enough to bother.





Thought I would have a look at this and I do not find this asymmetry ..


vpn & iperf server = Linux debian 8
iperf version 2.0.5 (08 Jul 2010) pthreads

Mon Mar 26 12:39:03 2018 us=287116 OpenVPN 2.5_git+ipv6pf 
[git:master/902c1f1c71ac+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan  1 2018
Mon Mar 26 12:39:03 2018 us=287135 library versions: OpenSSL 1.0.1t  3 
May 2016, LZO 2.08



vpn & iperf client (1) = Windows 10
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:25:46 2018 us=107859 OpenVPN 2.4.5 
[git:2.4/161afbebdc2b7e24+] x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] 
[LZ4] [PKCS11] [AEAD] built on Mar  1 2018


Mon Mar 26 21:25:46 2018 us=107859 Windows version 6.2 (Windows 8 or 
greater) 64bit


Mon Mar 26 21:25:46 2018 us=107859 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10



vpn & iperf client (2) = Linux Arch
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:36:17 2018 us=258243 OpenVPN 2.4.4 
x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
[MH/PKTINFO] [AEAD] built on Sep 26 2017
Mon Mar 26 21:36:17 2018 us=258256 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10





*** Output from server iperf:


client: iperf -c 10.56.101.238 -r -l 4M -t 30

* Linux server (vpn and iperf) -- AES-256-CBC **

iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)



* Windows client (vpn and iperf)

[  4] local 10.56.101.238 port 5001 connected with 10.56.101.110 port 51370
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-30.1 sec   480 MBytes   134 Mbits/sec

Client connecting to 10.56.101.110, TCP port 5001
TCP window size:  416 KByte (WARNING: requested  867 MByte)

[  4] local 10.56.101.238 port 48867 connected with 10.56.101.110 port 5001
[  4]  0.0-30.3 sec   568 MBytes   157 Mbits/sec


iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[Jan Just Keijser]

Hi Selva,

On 22/03/18 18:12, Selva Nair wrote:

On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser  wrote:

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:

Hi All,

One of the Viscosity developers here. The TAP driver used by Viscosity is
based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
performance differences, as the changes we've made are very minimal.

Besides a name and version number change, the only other modification is a
change to the reported network adapter speed, which has Windows report the
driver as 1000 Mbit instead of 100 Mbit.

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries to QoS
the adapter based on its reported adapter speed, which is of course a
problem if the VPN connection is capable of more than 100 Mbit.

Please find a patch file of the changes attached.


first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 based)
compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
gigabit test setup.  Strangely enough, it turns out that it's the *absence
of* AES256-GCM that makes my Viscosity client faster.
My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
   99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
  240 Mbps +/- 8 Mbps to server
   55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows
clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?


thanks for the confirmation; as for the assymmetry: that can be due to 
many factors, including hardware differences (there is asymmetry on 
Linux as well). It could also be due to the way the tap driver works, 
but I have never been able to get my finger on that , and I don't use 
Windows often enough to bother.


HTH,

JJK


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[Selva Nair]

Hi,

On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser  wrote:
> Hi Eric, all,
>
> On 22/03/18 04:25, Eric Thorpe wrote:
>
> Hi All,
>
> One of the Viscosity developers here. The TAP driver used by Viscosity is
> based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
> performance differences, as the changes we've made are very minimal.
>
> Besides a name and version number change, the only other modification is a
> change to the reported network adapter speed, which has Windows report the
> driver as 1000 Mbit instead of 100 Mbit.
>
> This change was made not because of any actual performance gains, but
> because of user reports that certain firewall or AV software tries to QoS
> the adapter based on its reported adapter speed, which is of course a
> problem if the VPN connection is capable of more than 100 Mbit.
>
> Please find a patch file of the changes attached.
>
>
> first of all, thanks for responding so quickly.
> I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 based)
> compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
> gigabit test setup.  Strangely enough, it turns out that it's the *absence
> of* AES256-GCM that makes my Viscosity client faster.
> My test setup is as follows:
>
> - server: CentOS 7, openvpn 2.4.4, gigabit ethernet
> - client: Win7 Pro, gigabit ethernet:
>
> Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):
>
> viscosity:
> 380 Mbps +/- 10 Mbps to server
> 100 Mbps +/- 5 Mpbs from server
>
> Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
> 377 Mbps +/- 10 Mbps to server
>   99 Mbps +/- 5 Mpbs from server
>
> Openvpn 2.4.5 (aes256-gcm)
>  240 Mbps +/- 8 Mbps to server
>   55 Mbps +/- 5 Mpbs from server
>
> So strangely enough it seems that AES-256-GCM is **slower** for Windows
> clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[David Sommerseth]

On 21/03/18 12:45, Samuli Seppänen wrote:
> 
> Dazo informed that OpenVPN 3 developers will start using openvpn-devel
> for their patches. We will need to figure out how to make patchwork
> detech whether a patch belongs to openvpn2 or openvpn3.

Just to elaborate a bit more on this topic.  I will try to explain a bit more
in detail how OpenVPN Inc staffers will contribute to the development more
openly and in a publicly, auditable approach.

Current situation: OpenVPN Inc developers push changes to a private git
repository for peer-review, and at random intervals these changes are pushed
out to the public.  This is not considered a good long-term approach when
wanting to have the community involved in the further development.  So we are
adjusting our own processes to be far more community friendly.

This is our current proposal:

Patches submitted with the patch author carrying an @openvpn.net address will
in most cases have been through internal peer-review before being accepted.
These patches will thus have at minimum one "Approved-By:" tag line.  This is
similar to the Acked-by: tag-line used in OpenVPN 2 patches.  The reason
"Approved-by:" is used is simply due to the internal tools used by OpenVPN Inc
for peer-review - which adds this automatically.  But seeing an "Approved-by:"
line means the commit has been through peer-review by OpenVPN Inc developers
and was ACKed.

It is also preferred that OpenVPN Inc developers which have their patches
reviewed internally to make patches available in a publicly available git
repository (like GitHub, GitLab, Bitbucket, etc) - at any time.  This enables
the use of a git feature we've not used before for OpenVPN - git request-pull.
 This combined with git format-patch with the --cover-letter option will
generate a e-mail template where it is possible to validate the authenticity
of the patches on the ML against an external git repository.

Patches sent through the git request-pull approach can then be merged directly
into the official openvpn3 git repository.  We also try to ensure that as many
 commits as possible added to the openvpn3 git repository are PGP signed.  But
we have to find a good way to tackle this as automated as possible.

The community may, of course, dispute commits post-merge, where after a
discussion with the OpenVPN Inc developers will figure out if this needs to be
reverted or if it can be improved by adding another patch fixing issues.  But
we are open and happy to take those discussions whenever needed.


The rest of the OpenVPN community may also use the 'git request-pull'
approach, or take the approach used for OpenVPN 2.x patches over many years.
But all patches from the community [1] need to receive a public "Acked-by:"
response, sent explicitly to the mailing list.  We do not restrict the
Acked-by to be by OpenVPN Inc developers only; we use the same approach as
with OpenVPN 2 patches - contributors who have built up credibility among the
core developers over time will have their Acked-by responses handled easier
and quicker.  But any Acked-by: responses are valuable.


And even though a lot of the process is pretty much laid out - nothing is set
in stone yet.  But we (OpenVPN Inc) needed to find an approach which works
well for us and at the same time encourage the community to participate in the
development.  We do a lot of work on the OpenVPN 3 code base but also want
this development to happen in the open and public space as well.  But as we
gain experience, we will adopt this process to what works best for both the
community and OpenVPN Inc.  The main goal is to make OpenVPN 3 as attractive
for contribution as what we have managed with OpenVPN 2.

But see this mail as an early heads-up.  OpenVPN Inc is still adjusting the
internal tooling and processes.  But we expect to be ready internally in not
too long (a few weeks, not months - unless we hit some nasty challenges).  And
if there are ideas how to make things better, please let us know asap!

All this said ... In todays community meeting concerns about Patchwork was
raised.  We will need to ensure that OpenVPN 3 related patches won't affect
and make a big mess of the OpenVPN 2.x development and the Patchwork
integration used there.  And we (OpenVPN Inc) would like to make Patchwork
work well with OpenVPN 3 patches as well.  So this is something needed to be
handled properly before we start for real.  But we will do a few tests and see
what happens.


[1] With "the community" it is meant: Patch from a sender _not_ carrying an
@openvpn.net address with at least one "Approved-by: " tag-line with an
@openvpn.net address.  Both addresses needs to be well known OpenVPN Inc
employees.



-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!