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 hope someone else can verify these results (or refute them and tell me
what I am doing wrong ;))
HTH,
JJK
On 21/03/2018 10:45 PM, Samuli Seppänen wrote:
Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 21st Mar 2018
Time: 11:30 CET (10:30 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2018-03-21>
The next meeting has not been scheduled yet.
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
cron2, dazo, janjust, mattock, ordex and syzzer participated in
this meeting.
--
Janjust initialized the meeting with virtual group hug.
--
Discussed the security issue in tap-windows6 reported to the security
mailing list. While the issue is not critical it needs to be fixed.
Mattock will produce an installer with the fix. Cron2 will compare
unfixed and fixed versions to verify that the problem is gone. Dazo will
get us a CVE for the problem. Once this is done we will release new
Windows installers for OpenVPN 2.4.5.
--
Discussed "multi-port/multi-ip listening support: config format". The
format agreed upon in the meeting was this:
local IP [port] [proto]
Where IP can be an IPv4 address, and IPv6 address, or * which means
dual-stack IPv4/IPv6. Proto can be either udp or tcp; the udp6 and tcp6
variants are not needed as they can be deduced from the IP address.
Note that on OpenBSD "local *" will bind to IPv6 addresses only. This is
because v4-mapped v6 sockets are not available on that platform.
--
Discussed Viscosity's patches to OpenVPN and their tap-windows adapter.
According to janjust Viscosity's tap-windows6 adapter performs
significantly better than our tap-windows6 adapter. Agreed that we
should first verify that they're using tap-windows6 and not something
they wrote themselves. If yes, we should check if their source code is
available. And if not, we should ask them to publish it according
GPLv2's requirements.
Janjust will do more testing with Viscosity's driver and report the
results to mattock who will start bugging Viscosity as necessary.
--
Discussed the "netlink support: quick roadmap recap" topic. Previously
we have agreed on providing unit tests to check the output of netlink
with what is expected from using ip/route/ifconfig. Agreed that we
should have unit tests in place at merge time. Otherwise we fear the
unit tests will never arrive.
Also agreed that we should try to provide testing Debian/Ubuntu package
for this. While that is doable right now, it requires manual work. It
would thus make more sense to automate the package creation process.
--
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.
---
Full chatlog attached.
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
