[Openvpn-devel] Topics for the community meeting (Wed, 21st Mar 2018)

[Openvpn-devel] Topics for the community meeting (Wed, 21st Mar 2018)

[@ 2018-03-21 8:04 UTC (permalink / raw)]

Hi,

We're going to have an IRC meeting starting at 11:30 CET
(10:30 UTC) on #openvpn-meeting <at> irc.freenode.net. You do not have
to be logged in to Freenode to join the channel.

Current topic list along with basic information is here:

<https://community.openvpn.net/openvpn/wiki/Topics-2018-03-21>

If you have any other things you'd like to bring up, respond to this
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments
on the topics by responding to this email or to the summary email sent
after the meeting. Whenever possible, we'll also respond to existing,
related email threads.

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

irc freenode net: mattock

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

[@ 2018-03-21 11:45 UTC (permalink / raw)]

[-- Attachment #1.1.1: Type: text/plain, Size: 2979 bytes --]

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.

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

irc freenode net: mattock

[-- Attachment #1.1.2: openvpn_irc_meeting_chatlog_2018-03-21.txt --]
[-- Type: text/plain, Size: 27112 bytes --]

(12:31:27) dazo: hey!
(12:31:36) janjust: hi dazo
(12:31:50) dazo: nice that you could join, janjust :)
(12:32:23) ordex: hi!
(12:32:43) janjust: just don't get used to it, dazo ;)
(12:32:48) dazo: hehehe ;-)
(12:32:49) ordex: syzzer: here too?
(12:32:52) ordex: mattock: ?
(12:33:06) dazo: janjust: nah, that wouldn't make it so special!  We need to protect this special feeling ;-)
(12:33:14) janjust: lol
(12:33:14) mattock: good day
(12:33:20) ordex: we have some topics pending from last week that we did not really go through (nothing major I think): https://community.openvpn.net/openvpn/wiki/Topics-2018-03-14
(12:33:21) vpnHelper: Title: Topics-2018-03-14 – OpenVPN Community (at community.openvpn.net)
(12:33:22) cron2: grouphugs!
(12:33:26) ordex: :D
(12:33:30) ***janjust hugs cron2
(12:33:30) dazo: lol
(12:33:49) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2018-03-21
(12:33:51) vpnHelper: Title: Topics-2018-03-21 – OpenVPN Community (at community.openvpn.net)
(12:33:54) mattock: enough hugging already :D
(12:34:02) ***janjust hugs mattock 
(12:34:04) janjust: :P
(12:34:08) mattock: oh that was so nice :D
(12:34:10) ***dazo had to check which channel he joined
(12:34:13) cron2: ordex: can you just move over the agenda items from -14 to -21?
(12:34:22) ordex: yup
(12:34:26) cron2: (so we have *one* agenda to work, and put stuff to -28 then)
(12:35:12) ordex: done, refresh
(12:35:18) ***syzzer here now
(12:35:21) syzzer: sorry for the delay
(12:35:26) syzzer: reading backlog...
(12:35:30) dazo: btw ... There's one more topic regarding openvpn 3 development which needs to be added .... mostly FYI on what's happening
(12:35:30) cron2: pretty full agenda now :-)
(12:35:36) ordex: it's mostly about hugs, syzzer 
(12:35:37) ordex: :P
(12:35:41) cron2: syzzer: except lots of enjoyment, nothing missed :)
(12:35:44) mattock: dazo: sounds good
(12:35:48) janjust: yeah... I'm pretty interested in the tap-win part for today
(12:35:57) janjust: need a hug , syzzer ?
(12:36:08) syzzer: always :D
(12:36:28) cron2: *hugs*
(12:36:34) syzzer: \o/
(12:36:43) ordex: lol
(12:36:45) janjust: let's rename this channel to #openvpn-grouphug
(12:37:11) mattock: let's hug tap-windows6 for a while
(12:37:15) dazo: +1
(12:37:17) dazo: :-D
(12:37:38) mattock: so a problem was reported to security list
(12:37:46) janjust: good plan; I have a "tangent" question on it (later)
(12:37:48) mattock: not critical but needs to be fixed
(12:37:58) mattock: we have a patch from cron2, but afaik it has not gotten any review
(12:38:02) mattock: correct?
(12:38:17) cron2: mattock: correct.  You wanted to build a test installer with it :)
(12:38:30) cron2: I don't even know if it compiles, but it "looks reasonable"
(12:39:16) mattock: ah yes
(12:39:23) mattock: I was waiting for a formal review :)
(12:39:25) mattock: then build
(12:39:29) syzzer: hm, I should really fire up my tap-windows build env again too
(12:39:29) mattock: but we can reverse that
(12:39:47) cron2: is there documentation how to build tap-windows/tap-windows6?
(12:40:24) dazo: 1. Ask mattock
(12:40:25) dazo: 2. Profit
(12:40:56) mattock: cron2: yes, check the tap-windows6 repo in GitHub
(12:41:01) mattock: the instructions are fairly thorough
(12:41:11) cron2: the "how to build windows snapshots" installation is nice (just to mention it) :)
(12:42:09) mattock: cron2: you will need to play some tricks to use a pre-built tapinstall.exe (haven't been able to build it in years)
(12:42:09) cron2: well... the instructions are not dummy-level enough for me... "you need python 2.7, windows 7 wdk, windows code signing certificate, git".  So, yes, and how do I get those? :)
(12:42:24) mattock: well you don't need the code signing certificate
(12:42:34) cron2: it says "required"... :)
(12:42:44) mattock: I suggest "python windows", "git windows" for starters :)
(12:42:51) mattock: those will lead you to correct page
(12:42:52) mattock: s
(12:43:17) ordex: mattock: does tap-windows need to be re-signed with some special key that is accepted by Windows everytime?
(12:43:20) cron2: yeah, but anyway, like "Win 7 WDK" - does that mean "it has to be a windows 7 machine" or "the WDK has a version number, 7.x", ...
(12:43:24) cron2: ordex: yes
(12:43:28) ordex: k
(12:43:40) mattock: cron2: I build on Windows 2012r2 so no
(12:43:43) cron2: (you can tell windows to ignore driver signing requirements, but that is not a generally good idea)
(12:44:02) mattock: lemme check the WDK verison
(12:44:03) mattock: version
(12:44:06) cron2: ((and it's a boot-time selection...))
(12:44:33) ordex: (I see, so it has to be signed every time - ok)
(12:44:43) mattock: WinDDK 7600 is supposed to work
(12:44:46) syzzer: cron2: you can build on newer windows
(12:44:47) cron2: while a major PITA, it's generally speaking a good idea
(12:44:54) mattock: how to get it: don't know
(12:45:10) syzzer: probably even with newer WDK - there is some compat version thingy defined somewhere iirc...
(12:45:16) mattock: download a version of WinDDK for your OS and hope it is not too recent
(12:45:17) cron2: I see me send a PR with "for dummies, click here, click there" :-)
(12:45:32) mattock: cron2: I will gladly merge that kind of PR
(12:45:37) cron2: anyway: next steps - test installer or review?
(12:45:38) janjust: https://www.microsoft.com/en-us/download/details.aspx?id=11800
(12:45:39) vpnHelper: Title: Download Windows Driver Kit Version 7.1.0 from Official Microsoft Download Center (at www.microsoft.com)
(12:46:09) janjust: https://tortoisegit.org/download/
(12:46:12) vpnHelper: Title: Download – TortoiseGit – Windows Shell Interface to Git (at tortoisegit.org)
(12:46:21) mattock: janjust: that WinDDK link looks promising
(12:46:27) mattock: 7600 in the ISO filename and all
(12:46:50) janjust: https://www.python.org/downloads/release/python-2714/
(12:46:52) vpnHelper: Title: Python Release Python 2.7.14 | Python.org (at www.python.org)
(12:46:55) cron2: 7.1.0 has 7600 in the filename.  Yay :)
(12:47:14) cron2: janjust: thanks - I'll do the searching and testing and send mattock a PR
(12:48:44) mattock: I can build a new tap-windows6 installer later today
(12:49:00) mattock: I happened to test the build system a few weeks ago and it was not horribly broken
(12:49:12) mattock: then we can do the code review
(12:49:26) mattock: then make an installer release for 2.4.5
(12:49:35) cron2: cool.  Then I can clone a VM and try to generate a "bad packet" and see if I can actually break the old tap driver, and see if that does not break anymore afterwards (and nothing else breaks)
(12:49:44) cron2: dazo: can you get us the CVE?
(12:50:13) dazo: cron2: sure! ... Now I might even be able to do it directly with MITRE as well
(12:50:24) cron2: good :)
(12:53:02) dazo: I might need some help to draft the contents of the vulnerability, but will let you know when I've prepared a draft
(12:53:11) cron2: ack
(12:53:55) syzzer: sounds good
(12:54:05) dazo: mattock: [off-topic] .... would it be possible and a good idea to get a openvpn community etherpad, restricted with LDAP auth from community LDAP?
(12:54:16) cron2: yes
(12:54:22) dazo: would be a better place to collaborate on such security notes
(12:54:29) mattock: dazo: definitely (next month, too busy this month)
(12:54:35) dazo: sure
(12:54:40) mattock: I will add a ticket for myself
(12:54:43) dazo: thx!
(12:55:17) dazo: next topic?
(12:55:23) mattock: +1
(12:55:33) mattock: "Security list GPG key expiry policies"
(12:55:40) cron2: mattock: reload :)
(12:55:40) mattock: something we touched briefly elsewhere
(12:55:56) mattock: oh some nasty person added stuff there :P
(12:55:57) mattock: ok
(12:55:59) ordex: :P
(12:56:01) mattock: topic #1
(12:56:09) ordex: but we can finish the gpg thing first if we want
(12:56:13) mattock: ​https://patchwork.openvpn.net/patch/263/
(12:56:14) cron2: we skip that one, I'd say, since it's plaisthos'
(12:56:15) vpnHelper: Title: [Openvpn-devel,v2] Rework OpenVPN auth-token support - Patchwork (at patchwork.openvpn.net)
(12:56:17) ordex: plaisthos: is not here apparently - he "owns" topic #1
(12:56:19) ordex: yeah
(12:56:22) mattock: next then
(12:56:28) cron2: ordex: yours
(12:56:31) mattock: multi-port/multi-ip listening support: config format 
(12:56:34) ordex: yeah
(12:56:49) ordex: I just wanted to quickly hear your opinion about how to re-arrange the config options once introducing the multiport feature
(12:57:01) ordex: basically a server will be able to listen on multiple ports
(12:57:13) ordex: so it will be possible to define "port xxx" multiple times with different xxx each time
(12:57:16) cron2: my thoughts on that: while apache generally stinks, the "Listen" directive from there ("Listen <port>" or "Listen <ip>:<port>") generally seems to be easy to understand
(12:57:35) ordex: mh yeah that's a good idea
(12:57:50) cron2: what we have now with "bind", "port", "lport" is confusing at best - but if you all tell me "multiple lport statements are good", fine with me :)
(12:58:22) ordex: well multiple lport is equivalent to multiple Listen <port> no ?
(12:58:30) cron2: ye
(12:58:31) cron2: s
(12:58:41) ordex: the problem is: if we have multiple IPs to listen to, and 2 ports
(12:58:48) ordex: does the user need to list all the combinations ?
(12:59:02) ordex: Listen ip1:port1 Listen ip1:port2, etcc
(12:59:20) cron2: the socket API needs this explicitly
(12:59:37) ordex: sure, but the config does not need to be 1:1 with the API :P it's for people after all
(12:59:44) cron2: you can either bind *:port or *-v4:port or *-v6:port or "one fixed IP":port
(12:59:50) cron2: understood
(13:00:35) cron2: so you'd prose to do multiple "local" and "lport" statements, and then combine them?
(13:00:38) cron2: local 1.2.3.4
(13:00:44) cron2: local 2001:db8::5
(13:00:49) cron2: lport 80 udp
(13:00:51) cron2: lport 443 tcp
(13:00:52) cron2: ?
(13:00:54) ordex: right
(13:00:57) ordex: this is one way
(13:01:02) ordex: even though I am not fully convinced
(13:01:15) ordex: probably the listen ip:port is just simpler to understand and avoid ambiguity
(13:01:20) cron2: we need to expand "lport" in any case to add udp/tcp
(13:01:26) ordex: yap
(13:02:05) dazo: I'm wondering of "Listen" + "lport" will confuse users even more though .... as they essentially do almost the same .... the difference though, lport can also be used on client side as well
(13:02:31) dazo: but the "listen" semantic is simpler
(13:03:10) ordex: we can still support "lport" but document the clear mapping in behaviour. i.e. if you specify lport X, this is just an alias for "listen :X" check --listen in manpage
(13:03:13) cron2: if you want to do stuff like "listen on 1.2.3.4:80 and 4.5.6.7:443", you cannot specify this with two individual options
(13:03:15) dazo: since we have --remote which can be used multiple times, and have support for ports and protocols ... wouldn't it be better to have the same syntax approach for 'local' instead?
(13:03:22) ordex: cron2: right
(13:03:35) cron2: I would not mind extending local into "local $ip:$port $proto"
(13:03:36) dazo: cron2: yeah
(13:03:41) cron2: does not have to be called "listen"
(13:03:56) ordex: listen is good because it does not exist for now :D and matches other server configs
(13:03:59) dazo: I think that's a better approach ... no new option, just a natural expansion
(13:04:03) cron2: lol
(13:04:12) ordex: ah "local"
(13:04:14) ordex: sorry I misread
(13:04:15) dazo: yeah
(13:04:22) cron2: you do agree beforehand on who agrees and who disagrees, simultaneously, do you?
(13:04:26) ordex: hmmm but we have to keep it backward compatible
(13:04:28) dazo: :-P
(13:04:36) dazo: IRC latency is tricky some times :-P
(13:04:49) dazo: ordex: yeah
(13:05:07) ordex: so if somebody specifies "local ip:port proto" and *also* lport we trigger an error?
(13:05:08) dazo: ordex: but lets aim for the same argument order as --remote
(13:05:21) dazo:        --remote host [port] [proto]
(13:05:31) cron2: works for me
(13:05:40) ordex: the error or the order?
(13:05:40) dazo: so for --local, it would be   --local IP [port] [proto]
(13:06:02) ordex: --local IP [port] [proto] << sounds good
(13:06:21) cron2: dazo: how to specify "I do not care about the IP address (=ANY) but I want 1194/udp + 443/tcp"?
(13:06:27) cron2: local * 1194 udp
(13:06:31) cron2: local * 443 tcp
(13:06:31) cron2: ?
(13:06:33) dazo: I was just pondering on that ..... 0.0.0.0 as IP?
(13:06:40) dazo: oh ipv5
(13:06:42) dazo: ipv6*
(13:06:45) ordex: yeah
(13:06:46) cron2: that is legacy IP only, which you might want, or not
(13:06:47) dazo: yeah *
(13:06:51) ordex: * is better
(13:06:54) dazo: agreed
(13:07:08) cron2: so 0.0.0.0 is "any v4", :: is "any v6", * is "do a dual-stack v6 socket"
(13:07:09) dazo: * or ANY ... I don't care :)
(13:07:20) dazo: agreed
(13:07:25) ordex: cron2: waitttttt don't let new features sneak in :P
(13:07:26) mattock: that sounds reasonable
(13:07:33) dazo: :-P
(13:07:38) ***cron2 sees an incoming patch from ordex with "we do DNS resolution on this" with a special case for "ANY" :)
(13:07:44) ordex: LOL
(13:07:45) cron2: ordex: mmmh?
(13:07:45) mattock: many daemons do 0.0.0.0 / :: / * thingy
(13:08:06) ordex: cron2: the dual socket thing is currently not addressed by all this
(13:08:20) ordex: this reminds me: protocol udp6/4 are not required anymore then ?
(13:08:30) ordex: because 0.0.0.0 will imply udp/tcp4 ?
(13:08:31) cron2: ordex: it actually is - if you throw 0.0.0.0 or :: at getaddrinfo(), you get back "v4" or "v6" ANY chunks
(13:08:39) ordex: yeah true
(13:09:07) ordex: it's the * case that is not well defined (unless you meant that openvpn will open two sockets)
(13:09:12) cron2: ordex: indeed, if you do multi-socket, the old "proto" thing is not generic enough - so it would still be there for single-socket, and maybe lport/proto should trigger an error if multiple "local" are there
(13:09:33) ordex: ok
(13:09:37) dazo: yeah, that makes sense ... multiple local with lport/proto should bail out
(13:09:39) cron2: ordex: well, "*" could mean what "bind !ipv6only" does today: do a v6-socket with dual-stacking enabled
(13:09:40) ordex: so if proto exist -> allow only 1 local
(13:09:52) ordex: cron2: that works on every platform?
(13:09:54) dazo: yeah
(13:10:15) cron2: ot works on everything but OpenBSD (who removed v4-mapped v6 sockets)
(13:10:24) dazo: hmmm .... server side, that should be how it is today .... client side ... might be different
(13:10:36) cron2: but "just do two binds with v6only=1" might be more explicit plus also OpenBSD-portable
(13:11:02) ordex: yap
(13:11:13) cron2: dazo: client side *if you do not bind* is basically "we do not need to care".  If the client wants to bind to multiple addresses, things will be interesting, but we can just disallow it
(13:11:32) ***cron2 tends to "show me a good use case for a multi-bind client"
(13:11:34) dazo: yeah, agreed ... I think that makes sense, at least for now
(13:11:42) ordex: client and multiple addresses? guys please, no smoking :D
(13:11:46) ordex: hehe
(13:11:47) ordex: yeah
(13:11:55) dazo: We just need to tackle users doing that without exploding ;-)
(13:12:04) mattock: :P
(13:12:16) ordex: < cron2> but "just do two binds with v6only=1" might be more explicit plus also OpenBSD-portable << cron2 so this means 2 sockets, one bound to 0.0.0.0 and one to :: ?
(13:12:17) cron2: ordex: someone, somewhere will have a setup that would benefit from it :-) - and then do load-sharing between both sockets
(13:12:19) dazo: and failing with a M_FATAL when users try to do that is very fine for me
(13:12:21) mattock: if it explodes we will get email to openvpn-devel list sooner or later
(13:12:21) ordex: (or with v6only)
(13:12:59) cron2: ordex: wrt "one or two sockets", I do not care much either way - both works everywhere but OpenBSD, and on OpenBSD one could always do "local 0.0.0.0 1194" + "local :: 1194"
(13:13:19) ordex: cron2: right
(13:13:26) dazo: mattock: uncontrolled explosions are bad - they might trigger security issues ... failing controlled (like M_FATAL) is a controlled behaviour with not risks
(13:13:43) dazo: s/not /no /
(13:13:47) mattock: I was not implying that we should blow up thing in uncontrolled fashion :)
(13:13:53) dazo: :)
(13:14:06) mattock: just that somebody _will_ complain if we break a highly esoteric use-case
(13:14:14) cron2: always
(13:14:24) ordex: do we agree that "local" will support only udp/tcp (without any 6 or 4 at the end)
(13:14:26) ordex: ?
(13:14:28) dazo: as long as it is documented, we can do the RTFM
(13:14:34) cron2: 5 years later, in CAPITAL LETTERS, in trac :)
(13:14:39) ordex: lol
(13:14:51) cron2: ordex: yes, because 4/6 is explicit from the address
(13:14:55) dazo: ordex: yeah, that makes sense to me .... IPv4/IPv6 is given by the IP address
(13:15:01) cron2: first!
(13:15:10) dazo: heh :-D
(13:16:03) ordex: good
(13:16:08) ordex: :)
(13:16:34) ordex: i think this closes the topic. it seems we pretty much covered all the cases for the next 10 years
(13:16:46) cron2: .oO(what about sctp...)
(13:16:51) ***cron2 hides
(13:16:54) dazo: heh
(13:16:58) cron2: and no, it does not make sense
(13:17:08) janjust: you forget openvpn-over-icmp ;)
(13:17:11) ordex: we might have other protocols coming from plugin
(13:17:18) ordex: but those might need to be "registered" somehow
(13:17:18) ordex: :P
(13:17:25) dazo: but that's tackled by the plugins ;-)
(13:17:29) ordex: yeah
(13:17:56) janjust: before this meeting is closed I have a question on tap-windows and the windows version of Viscosity
(13:18:31) cron2: go ahead :)
(13:19:04) janjust: I've got access to the win version of viscosity; it seems those guys patched openvpn itself and even provide their own tap adapter
(13:19:18) janjust: that adapter performs *BETTER* than the tap-win adapter
(13:19:28) mattock: hmm
(13:19:31) dazo: hmmmm
(13:19:36) janjust: question is: has anyone else seen this?  question 2:  should we go "after them" to release their patches?
(13:19:41) mattock: we need to check if they version's code is available somewhere
(13:19:46) mattock: no and yes
(13:20:07) mattock: what is the performance difference?
(13:20:10) dazo: first we need to dissect it, to see if it is plausible it contains tap-windows code
(13:20:31) ordex: but they should definitely publish the openvpn changes, I think
(13:20:36) dazo: they could have written something from scratch ... "white reverse engineered" or something like that
(13:20:41) mattock: yes, and also tap-windows6 changes as both are GPLv2
(13:20:46) cron2: janjust: is that adapter compatible with us?  So, if viscosity is installed, and you fire up openvpn.exe, what does it see?
(13:21:09) cron2: (and of course, publish changes to GPLed code)
(13:21:11) janjust: hmm I haven't tested that, cron2, will do so after this meeting (I need to reboot into win7)
(13:21:58) janjust:  but AFAICT viscosity uses a patched version of openvpn.exe so I wouldn't be surprised if you can mix&match
(13:23:11) mattock: I can start bugging them for their changes once we have more info
(13:23:22) janjust: alright, I will send feedback to you mattock 
(13:23:26) mattock: thanks!
(13:23:58) mattock: next topic?
(13:24:04) mattock: 54 minutes in
(13:24:15) ordex: quickie about netlink?
(13:24:16) cron2: netlink: quick recap, 5 minutes?
(13:24:19) cron2: :)
(13:24:20) ordex: yeah
(13:24:20) mattock: sounds good
(13:24:21) dazo: https://www.sparklabs.com/blog/ ... They definitely use openvpn 2.x
(13:24:23) vpnHelper: Title: Blog - SparkLabs (at www.sparklabs.com)
(13:24:30) mattock: yeah they do
(13:24:38) mattock: and they did use tap-windows6 in the past at least
(13:24:52) mattock: they actually reported a bug in it, maybe even provided a patch early on
(13:24:55) ordex: we should definitely ask to publish the patches
(13:25:18) mattock: yep, I've done that in the past with them and they've been responsive
(13:25:37) mattock: anyhow, netlink
(13:25:41) ordex: ok
(13:25:48) ordex: so the code has been used by a couple of users so far for quite some time
(13:25:54) ordex: and it seems to work[tm]
(13:26:15) ordex: we agreed on providing unit tests to check the output of netlink with what is expected from using ip/route/ifconfig
(13:26:24) ordex: now, the unit tests are not there yet and may require quite some time
(13:26:39) ordex: however, how about we move on and try to review/merge the netlink code already?
(13:26:43) ordex: so people testing master can get it ?
(13:26:51) dazo: I'll create a Fedora Copr repo for Fedora/RHEL environments ... I'll use that for testing in my servers at least
(13:26:52) ordex: unit-tests are expected to come before the release
(13:27:07) cron2: unit-tests are expected to come together with merging
(13:27:12) ordex: :D
(13:27:18) ordex: I tried!
(13:27:19) cron2: (otherwise unit-tests will never arrive...)
(13:27:20) mattock: cron2: +1
(13:27:32) ordex: yeah, I have to say you're right :P
(13:27:34) cron2: I've done too much software development :-)
(13:27:37) dazo: :)
(13:27:44) ordex: ok, so I'll publish the patches to the ml
(13:27:55) cron2: but looking at the stuff for a first round of feedback is certainly a good idea
(13:27:56) ordex: and hopefully I'll run them through buildbot, now that mattock has pointed it to the other repo
(13:28:17) ordex: ok. then work on the unit tests
(13:28:19) ordex: good!
(13:28:25) dazo: cool, and I'll use them for the Copr repo .... mattock, can we have a separate openvpn-netlink repo for testing for Deb/Ubu?
(13:28:25) ordex: I'll send them soon then
(13:28:39) cron2: we need to work on the patch queue already out there :-( - because the more patches are pending, the more merge clashes we end up with
(13:28:40) mattock: hmm
(13:28:46) ordex: yeah :/
(13:28:47) mattock: technically yes
(13:28:56) ***ordex will work on tls-crypt-v2
(13:29:19) dazo: mattock: perhaps we should try to make something automated .... would benefit openvpn3 too
(13:29:34) mattock: dazo: I fully agree, but time is a scarse resource
(13:29:39) dazo: yeah, I know
(13:29:49) mattock: I would like to just take a commit and push out various "things" built from that commit
(13:29:49) syzzer: whee, my build bot claims to have built both tap-windows and tap-windows6 :)
(13:29:50) ordex: mattock: dazo: we could create a new openvpn-testing repo and have packages in there built from different branches? (only some)
(13:30:03) dazo: yeah, that's my thought
(13:30:04) cron2: mattock: so to be sure I understand the setup - the buildslaves are fetching from your new repo on "build" now, and "we" can all push to branches there?
(13:30:13) mattock: cron2: that is correct
(13:30:14) syzzer: ordex: oh, I should do that too...
(13:30:16) cron2: ("we" being "people that have mailed you their ssh key and are trusted")
(13:30:24) mattock: and have VPN access
(13:30:27) mattock: so double trusted
(13:30:32) cron2: build is not in vpn
(13:30:35) dazo: btw ... openvpn3 development ... quick words here .... we're going to start pushing openvpn3 patches to the public mailing list in not too far future
(13:30:40) mattock: oh yes, it is also accessible without VPN
(13:30:45) mattock: I can definitely fix that though :P
(13:30:50) cron2: ah, "click on buildmaster", that needs VPN
(13:30:51) ordex: (even via ipv6!)
(13:30:53) cron2: no, the other part is good
(13:31:10) mattock: ok
(13:31:15) dazo: We will have done internal review on those patches coming from @openvpn.net addresses .... so they should all carry a "Approved-by:" line in the commit messages
(13:31:41) cron2: dazo: I'm curious how that is going to work out with patchwork :-)
(13:32:05) dazo: so they will be pushed to the git repo directly .... but copies patches to the ML for distributed archive purpose
(13:32:35) dazo: cron2: that's going to be interesting as well ... we might need to "tag" openvpn3 patches differently, as patchwork has this "project" reference
(13:32:53) ordex: i think one project = one mailing list ?
(13:32:54) cron2: something like that would be good, otherwise the "openvpn2" view would be confusing
(13:33:10) dazo: but I'd like to see these patches arrive in patchwork too ... but under a different project
(13:33:40) dazo: it might be a little bit noise in the beginning as we figure out these details ... the intention is not to make things worse than it is :)
(13:33:40) cron2: +1
(13:33:41) mattock: yeah, definitely have 1:1 mapping between a project and a mailing list
(13:33:54) mattock: patchwork can filter the emails, but I think that gets tricky
(13:34:12) cron2: I need to leave this discussion now, as $wife is biting other people already - time for lunch
(13:34:14) dazo: mattock: lets see how we can tackle this filtering
(13:34:15) mattock: it needs to have a clue as to where a patch belongs to
(13:34:25) mattock: let's stop here
(13:34:28) mattock: I need to eat also
(13:34:28) ordex: oky
(13:34:32) ***ordex too
(13:34:39) ordex: and the laptop does not taste good today
(13:34:46) ***syzzer too, before the canteen closes (which is about now :p )
(13:34:50) ordex: :D
(13:34:52) dazo: we discussed briefly earlier to have separate mailing lists for openvpn2 and openvpn3 ... but consensus was to have a unified one .... okay, lets eat :)
(13:34:52) ordex: run!
(13:35:05) mattock: ok bye guys!
(13:35:07) ordex: bye!
(13:35:11) syzzer: bye! :)
(13:35:15) mattock: let me know if this is accurate:
(13:35:16) janjust: hehe , bye everyone
(13:35:18) mattock: iscussed "multi-port/multi-ip listening support: config format". The format agreed upon in the meeting was this:
(13:35:18) mattock:   local IP [port] [proto]
(13:35:18) mattock: Where IP can be an IPv4 address, and IPv6 address, or * which means dual-stack 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.
(13:35:46) dazo: " which means dual-stack IPv6" --> " which means dual-stack IPv4/IPv6"
(13:35:55) mattock: ah yes
(13:36:18) ordex: yap
(13:36:25) dazo: yeah, that's a good summary
(13:36:27) mattock: will openbsd just break if "local *" is defined?
(13:36:36) mattock: that would worthy of mention
(13:36:43) ordex: nope, it will do the same as today with udp6
(13:36:47) ordex: which is not really dual-stack
(13:36:47) mattock: ok
(13:36:53) mattock: so IPv6 only
(13:36:59) ordex: yap
(13:37:01) mattock: ok
(13:37:14) ordex: we can have some define in the code to error out and suggest to use 2 local statements
(13:37:20) dazo: that could be improved later on though, to actually do dual sockets on OpenBSD ... but that's for later
(13:37:27) ordex: right
(13:38:41) janjust ha abbandonato la stanza (quit: Quit: Leaving).

[-- Attachment #1.1.3: 0x40864578.asc --]
[-- Type: application/pgp-keys, Size: 2217 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Sommerseth]

[-- Attachment #1.1: Type: text/plain, Size: 4854 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Eric Thorpe]

[-- Attachment #1.1: Type: text/plain, Size: 4394 bytes --]

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.

Regards,
Eric

--
Eric Thorpe
SparkLabs Developer
https://www.sparklabs.com
https://twitter.com/sparklabs
support@...1918...

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



[-- Attachment #1.2: Type: text/html, Size: 5817 bytes --]

[-- Attachment #2: tap_constants.h.patch --]
[-- Type: text/plain, Size: 801 bytes --]

--- constants.h	Thu Mar 22 12:30:50 2018
+++ constants.h	Mon Oct 26 14:25:14 2015
@@ -38,7 +38,7 @@
 #ifndef TAP_DRIVER_MAJOR_VERSION
 
 #define TAP_DRIVER_MAJOR_VERSION           0x04
-#define TAP_DRIVER_MINOR_VERSION           0x02
+#define TAP_DRIVER_MINOR_VERSION           0x03
 
 #endif
 
@@ -102,8 +102,8 @@
 // If you have physical hardware on 802.3, use NdisPhysicalMedium802_3.
 #define TAP_PHYSICAL_MEDIUM         NdisPhysicalMediumUnspecified
 
-// Claim to be 100mbps duplex
-#define MEGABITS_PER_SECOND                1000000ULL
+// Claim to be 100mbps duplex - VISC update to 1gbit
+#define MEGABITS_PER_SECOND                10000000ULL
 #define TAP_XMIT_SPEED                     (100ULL*MEGABITS_PER_SECOND)
 #define TAP_RECV_SPEED                     (100ULL*MEGABITS_PER_SECOND)
 

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

[Jan Just Keijser]

[-- Attachment #1: Type: text/plain, Size: 5959 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 8242 bytes --]

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 <janjust@...1147...> 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

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 <janjust@...1147...> 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

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 <janjust@...1147...> 
>> 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/1111902c1f1c71ac+] 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)
------------------------------------------------------------


* Linux client (vpn and iperf)

[  4] local 10.56.101.238 port 5001 connected with 10.56.101.226 port 40284
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.2 sec   708 MBytes   197 Mbits/sec
------------------------------------------------------------
Client connecting to 10.56.101.226, TCP port 5001
TCP window size:  416 KByte (WARNING: requested  867 MByte)
------------------------------------------------------------
[  4] local 10.56.101.238 port 36629 connected with 10.56.101.226 port 5001
[  4]  0.0-30.3 sec   728 MBytes   201 Mbits/sec





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

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 51345
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.2 sec   528 MBytes   147 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 48864 connected with 10.56.101.110 port 5001
[  4]  0.0-30.5 sec   548 MBytes   151 Mbits/sec


* Linux client (vpn and iperf)

[  5] local 10.56.101.238 port 5001 connected with 10.56.101.226 port 40280
[  5]  0.0-30.2 sec   812 MBytes   226 Mbits/sec
------------------------------------------------------------
Client connecting to 10.56.101.226, TCP port 5001
TCP window size:  416 KByte (WARNING: requested  867 MByte)
------------------------------------------------------------
[  5] local 10.56.101.238 port 36626 connected with 10.56.101.226 port 5001
[  5]  0.0-30.3 sec   844 MBytes   234 Mbits/sec



For clarity, my network is a little unusual.

The Windows vpn/iperf client is real hardware running Hyper-V
The debian and Arch Linux are Hyper-V clients on the Win10 host above.

eth0 IPs for these machines:
Win10 : 10.10.201.110/24 (Gb ethernet net binding to Hyper-V Switch)
Deb8  : 10.10.201.238/24 (Hyper-V Switch above)
Arch  : 10.10.201.226/24 (Hyper-V Switch above)

I don't know to what extent that will effect the results.

Note for JJK, you asked if maybe you had done something wrong .. well ..

When I first ran the tests I did find a huge asymmetry but I found the
cause, in my case.  Initially the Win10 machine was in subnet 
10.10.101.0/24 not .201.0/24 (that is a little quirk I had setup to test
routing (and some other odds and ends), the router supports multiple IPs
per interface, so i was tempted away from the true path but I restored
all machines to the .201.0/24 subnet and found my asymmetry had gone.
Aping your favourite sig. "HTH" somehow :-)


Best regards
fragmentux (aka tincantech)

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 
>>> <janjust@...1147...> 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/1111902c1f1c71ac+] 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)
> ------------------------------------------------------------
> 
> 
> * Linux client (vpn and iperf)
> 
> [  4] local 10.56.101.238 port 5001 connected with 10.56.101.226 port 40284
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-30.2 sec   708 MBytes   197 Mbits/sec
> ------------------------------------------------------------
> Client connecting to 10.56.101.226, TCP port 5001
> TCP window size:  416 KByte (WARNING: requested  867 MByte)
> ------------------------------------------------------------
> [  4] local 10.56.101.238 port 36629 connected with 10.56.101.226 port 5001
> [  4]  0.0-30.3 sec   728 MBytes   201 Mbits/sec
> 
> 
> 
> 
> 
> * Linux server (vpn and iperf) -- AES-256-GCM **
> 
> 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 51345
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-30.2 sec   528 MBytes   147 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 48864 connected with 10.56.101.110 port 5001
> [  4]  0.0-30.5 sec   548 MBytes   151 Mbits/sec
> 
> 
> * Linux client (vpn and iperf)
> 
> [  5] local 10.56.101.238 port 5001 connected with 10.56.101.226 port 40280
> [  5]  0.0-30.2 sec   812 MBytes   226 Mbits/sec
> ------------------------------------------------------------
> Client connecting to 10.56.101.226, TCP port 5001
> TCP window size:  416 KByte (WARNING: requested  867 MByte)
> ------------------------------------------------------------
> [  5] local 10.56.101.238 port 36626 connected with 10.56.101.226 port 5001
> [  5]  0.0-30.3 sec   844 MBytes   234 Mbits/sec
> 
> 
> 
> For clarity, my network is a little unusual.
> 
> The Windows vpn/iperf client is real hardware running Hyper-V
> The debian and Arch Linux are Hyper-V clients on the Win10 host above.
> 
> eth0 IPs for these machines:
> Win10 : 10.10.201.110/24 (Gb ethernet net binding to Hyper-V Switch)
> Deb8  : 10.10.201.238/24 (Hyper-V Switch above)
> Arch  : 10.10.201.226/24 (Hyper-V Switch above)
> 
> I don't know to what extent that will effect the results.
> 
> Note for JJK, you asked if maybe you had done something wrong .. well ..
> 
> When I first ran the tests I did find a huge asymmetry but I found the
> cause, in my case.  Initially the Win10 machine was in subnet 
> 10.10.101.0/24 not .201.0/24 (that is a little quirk I had setup to test
> routing (and some other odds and ends), the router supports multiple IPs
> per interface, so i was tempted away from the true path but I restored
> all machines to the .201.0/24 subnet and found my asymmetry had gone.
> Aping your favourite sig. "HTH" somehow :-)
> 

Just for clarity, the vpn server had a direct route for the client, due
to how I had it setup, where as the client routed via the gateway.
So I removed that issue.

cheers

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

Re: [Openvpn-devel] aes-gcm and iperf on Windows

[Jan Just Keijser]

Hi,

(renamed the topic to reflect what it's about)

On 27/03/18 01:09, fragmentux wrote:
> 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 ..
>
I've measured it with 'iperf -s' on Win7 and get the same results.
Important difference: with the Cygwin version of iperf I get a 240 Mbps 
/ 50 Mbps
With the Win32 version (v2.0.8) i get 330 / 100 Mbps (plus or minus 5 %)

The asymmetry is caused by the hardware used - if I use two Linux 
servers I also see asymmetry, as I am pushing the CPU of one of the 
Linux boxen a bit. The difference of my laptop running Linux vs running 
Win 7 is quite huge, however: on Linux I am getting well above 600 Mbps 
both ways.

cheers,

JJK

Re: [Openvpn-devel] Viscosity patch to TAP driver (was: Summary of the community meeting) 2018)

[Gert Doering]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Hi Eric,

On Thu, Mar 22, 2018 at 02:25:56PM +1100, Eric Thorpe wrote:
> 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.

I think it would make sense for us to merge that patch - for two reasons,
one is "the change could indeed help performance in high-bandwidth
situtions", and the more important one is "another patch to tap-windows6
is forthcoming, and that way we can keep the version numbers aligned
so people can know what is inside".

Do you have the patch in git?  If yes, could you please do the commit
with "-s" (so the signed-off-by: line is added) and send it as regular
git commit (git-send-email)?  Alternatively a PR against tap-windows6
on github should do as well.

Thanks in advance,

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert@...1296...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 630 bytes --]

Re: [Openvpn-devel] Viscosity patch to TAP driver (was: Summary of the community meeting) 2018)

[Selva Nair]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

Hi,

On Thu, Apr 12, 2018 at 4:26 AM, Gert Doering <gert@...1296...> wrote:

> Hi Eric,
>
> On Thu, Mar 22, 2018 at 02:25:56PM +1100, Eric Thorpe wrote:
> > 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.
>
> I think it would make sense for us to merge that patch - for two reasons,
> one is "the change could indeed help performance in high-bandwidth
> situtions", and the more important one is "another patch to tap-windows6
> is forthcoming, and that way we can keep the version numbers aligned
> so people can know what is inside".
>

One can get > 100 Mbits/s from the stock TAP driver, so that parameter does
not appear to affect the actual "speed". With 100Mbit setting, Windows will
classify the device as fast ethernet for heuristics like choosing the
default metric. But now we do have code for setting a custom metric isn't
it? Or is it only used when --block-outside-dns is in use?

Or am I mistaken -- does this setting really affect the max throughput?

Selva

[-- Attachment #2: Type: text/html, Size: 2228 bytes --]

Re: [Openvpn-devel] Viscosity patch to TAP driver (was: Summary of the community meeting) 2018)

[Gert Doering]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

Hi,

On Thu, Apr 12, 2018 at 10:27:08AM -0400, Selva Nair wrote:
> > > 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.
[..]
> Or am I mistaken -- does this setting really affect the max throughput?

Not normally, but when certain 'helpful' software is around...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert@...1296...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 630 bytes --]

Re: [Openvpn-devel] Viscosity patch to TAP driver (was: Summary of the community meeting) 2018)

[Selva Nair]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

Hi,

On Thu, Apr 12, 2018 at 10:50 AM, Gert Doering <gert@...1296...> wrote:

> Hi,
>
> On Thu, Apr 12, 2018 at 10:27:08AM -0400, Selva Nair wrote:
> > > > 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.
> [..]
> > Or am I mistaken -- does this setting really affect the max throughput?
>
> Not normally, but when certain 'helpful' software is around...
>

Aha, my bad not reading carefully..

Thanks,

Selva

[-- Attachment #2: Type: text/html, Size: 1136 bytes --]

Re: [Openvpn-devel] Viscosity patch to TAP driver

[Jan Just Keijser]

Hi,

On 12/04/18 16:50, Gert Doering wrote:
> Hi,
>
> On Thu, Apr 12, 2018 at 10:27:08AM -0400, Selva Nair wrote:
>>>> 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.
> [..]
>> Or am I mistaken -- does this setting really affect the max throughput?
> Not normally, but when certain 'helpful' software is around...
>
>
as a side note: there is one thing to keep in mind when changing this:
Windows calculates its automatic routing metrics based on the adapter 
speed. So if we increase the speed then there are scenarios possible 
where the tun adapter route will take precedence over a lan route : in 
most cases that is what a user would want, but there are (rare) 
scenarios where that could have nasty side effects (including the 
"biting your own tail" problem)

JM2CW,

JJK

Re: [Openvpn-devel] Viscosity patch to TAP driver

[Antonio Quartulli]

[-- Attachment #1.1: Type: text/plain, Size: 1367 bytes --]



On 13/04/18 04:22, Jan Just Keijser wrote:
> Hi,
> 
> On 12/04/18 16:50, Gert Doering wrote:
>> Hi,
>>
>> On Thu, Apr 12, 2018 at 10:27:08AM -0400, Selva Nair wrote:
>>>>> 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.
>> [..]
>>> Or am I mistaken -- does this setting really affect the max throughput?
>> Not normally, but when certain 'helpful' software is around...
>>
>>
> as a side note: there is one thing to keep in mind when changing this:
> Windows calculates its automatic routing metrics based on the adapter
> speed. So if we increase the speed then there are scenarios possible
> where the tun adapter route will take precedence over a lan route : in
> most cases that is what a user would want, but there are (rare)
> scenarios where that could have nasty side effects (including the
> "biting your own tail" problem)

Can't we come up with a reasonable default that works for 99.9% of the
users (i.e. 1Gbps) and allow experts to tweak that? or tweak the metric
(I think this is already possible, given what Selva said)?


Cheers,



-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Openvpn-devel] Viscosity patch to TAP driver

[Eric Thorpe]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

Hi Gert,

PR #47 has been submitted to tap-windows6 on github.

Regards,
Eric

--
Eric Thorpe
SparkLabs Developer
https://www.sparklabs.com
https://twitter.com/sparklabs
support@...1918...

On 12/04/2018 6:26 PM, Gert Doering wrote:
> Hi Eric,
>
> On Thu, Mar 22, 2018 at 02:25:56PM +1100, Eric Thorpe wrote:
>> 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.
> I think it would make sense for us to merge that patch - for two reasons,
> one is "the change could indeed help performance in high-bandwidth
> situtions", and the more important one is "another patch to tap-windows6
> is forthcoming, and that way we can keep the version numbers aligned
> so people can know what is inside".
>
> Do you have the patch in git?  If yes, could you please do the commit
> with "-s" (so the signed-off-by: line is added) and send it as regular
> git commit (git-send-email)?  Alternatively a PR against tap-windows6
> on github should do as well.
>
> Thanks in advance,
>
> gert
>



[-- Attachment #2: Type: text/html, Size: 2519 bytes --]