Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on libera.chat
Date: Wed 6th April 2022
Time: 10:30 CEST (9:30 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2022-04-06>
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
cron2, dazo, d12fk, lev, mattock, MaxF, ordex and plaisthos participated
in this meeting.
---
Talked about OpenVPN 2.6:
<https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26>
Noted that tls-cryptv2 will need client support and some tricks to do
signalling there (packet id starts at magic number instead 1). This is
on the "must have" list for 2.6.
Lev has discovered an issue with tap-windows6 driver and Windows Server
2022 / Windows 11 which in some cases breaks TCP streams. It manifests
itself by, for example, iperf3 -R via VPN on Windows not working at all.
Lev has a workaround (fix?) for it already, but he'll do some further
looking into the problem to see if there's a cleaner solution. This also
required changes to the build configuration to differentiate between
Windows 10 and 11.
Noted that there's a Windows GUI bug that breaks escaping of ' in
passwords. We need a new Windows installer release to fix this.
Noted that OpenSSL 3.0.1 Windows build are working fine.
Mattock is fixing the auth-user-pass docs.
---
Noted that new production buildbot spams the hell out of us with "Build
successful" emails. Mattock (hopefully) made it send mails only on failure.
--
Full chatlog attached
(11.27.16) dazo: w00t!?! topic URL is already correct!
(11.27.28) cron2: I got prepared :-)
(11.27.47) dazo: :)
(11.31.13) plaisthos: moin
(11.32.05) cron2: hi
(11.33.42) plaisthos: so on update for 2.6
(11.34.01) plaisthos: syn cookie like 3way handshake works for
tls-auth/tls-crypt/none
(11.34.34) ordex: here
(11.34.42) MaxF [~m...@cust-95-128-91-242.breedbanddelft.nl] è entrato nella
stanza.
(11.34.42) ordex: 2.6?
(11.34.44) plaisthos: tls-cryptv2 will need client support and I also doing
some tricks to do signalling there (packet id starts at magic number instead 1)
(11.34.46) cron2: very nice
(11.34.51) ordex: isn't it a bit rushed to go in 2.6?
(11.34.59) cron2: it's much too late
(11.35.32) cron2: this is one of our weak spots, allowing reflection and state
exhaustion attacks
(11.35.59) ordex: yap
(11.36.10) ordex: still in a limited manner though
(11.36.14) MaxF ha abbandonato la stanza (quit: Client Quit).
(11.36.44) ordex: but regardless, isn't it late for such a big thing to go into
2.6?
(11.36.56) cron2: ordex: it's on the MUST HAVE list
(11.37.08) MaxF [~m...@cust-95-128-91-242.breedbanddelft.nl] è entrato nella
stanza.
(11.37.21) cron2: and it should have been in 2.5 :-)
(11.37.55) ordex: oh
(11.38.10) plaisthos: ordex: what do you mean with lmited manner?
(11.38.39) plaisthos: I updated a few bits in the RFC that I touched during
that stuff
(11.38.48) cron2: *like*
(11.38.54) ordex: plaisthos: that it's not like we can be used in a DDoS attack
as amplifier
(11.39.07) ordex: (I think?)
(11.39.17) cron2: we can
(11.39.37) ordex: oh ok
(11.40.48) cron2: with tls-auth/tls-crypt, you need to have that key, of course
- but if you have a big VPN provider, all clients have the same tls-* key, so
if one of them is lazy or malicious, it's no perfect protection
(11.41.04) cron2: also, state exhaustion in the server, and attacks against
ongoing sessions
(11.42.29) plaisthos: you don't need the key
(11.42.39) plaisthos: replay attacks work fine
(11.43.12) cron2: if you can sniff a packet, yes, but "to abuse a random
openvpn server for reflection", you need to see at least one handshake packet
(11.45.05) mattock: hi
(11.45.07) mattock: time flew
(11.46.01) lev__: hello
(11.46.01) MaxF22 [~m...@27-73-177-143.ftth.glasoperator.nl] è entrato nella
stanza.
(11.46.46) MaxF22: libera webchat really hates me today
(11.47.49) plaisthos: :P
(11.47.58) MaxF ha abbandonato la stanza (quit: Ping timeout: 250 seconds).
(11.48.09) ordex: IT REALLY DOES
(11.48.11) ordex: ops
(11.48.25) dazo: !!
(11.48.26) vpnHelper: dazo: temper, temper!
(11.48.29) cron2: haha
(11.48.38) mattock: well somebody here has good manners
(11.48.59) plaisthos: vpnHelper in here, is new
(11.49.00) vpnHelper: plaisthos: Error: "in" is not a valid command.
(11.49.12) dazo: :-D
(11.49.14) cron2: mattock: MAKE IT STOP
(11.49.40) cron2: I am not pushing anything, and the buildbot keeps spamming me
with "BUILD SUCCESS!" mails
(11.50.00) mattock: cron2: lol yes
(11.50.03) mattock: there are so many builds
(11.50.14) mattock: I'll make it stop for successful builds, just a sec
(11.50.19) lev__: I discovered an issue with tap-windows6 driver and windows
server 2022 which in some cases breaks TCP streams, it manifests itself in
iperf3 -R via vpn on windows not working at all
(11.50.24) plaisthos: anyway. Basically something I am doing to indicate to
indicate from the client really really early protocol support is to modify the
replay id that is part of client reset v3 packet
(11.50.50) plaisthos: nromally that is (32bit timestamp)00000001 on the first
packet
(11.50.54) cron2: lev__: interesting. Did you find the cause already?
(11.51.26) cron2: plaisthos: this is for tls-crypt v2 support?
(11.51.33) plaisthos: and new clients will instead use (32 bit
timestamp)0x0f010001 in their v3 packet
(11.52.19) plaisthos: to indicate that they support resending the wrapped
tls-cryptv2 key in the 3rd packet of the handshake, so the server does not need
to store the wrapped key from the initial packet (and therefore can be
stateless)
(11.52.44) plaisthos: cron2: client reset v3 is the intiial packet of
tls-crypt-v2, yes
(11.52.48) lev__: I made some changes to tap-windows6 and problem went away (we
process "tun write" requests synchronously and tell ndis to copy buffers and
then immediately free those instead of indicating to userspace that request is
pending, wait for ndis callback "now all packes are digested, you can free
buffers" and then indicate to userspace that write is complete)
(11.53.16) cron2: plaisthos: sounds good
(11.53.45) lev__: cron2: there is a delay (up to second) inside NDIS between
indicating packet to OS and receiving callback "packet is digested", and during
that delay we don't do any tun writes
(11.54.10) lev__: and this is windows server 2022 specific - I couldn
(11.54.36) lev__: * couldn't reproduce it with windows 10
(11.55.09) cron2: lev__: mmmh. 1 second no writes sounds quite a lot. But
"wait for the callback before freeing the buffer" sounds like the correct thing
to do
(11.56.33) lev__: NDIS has a flag which tells it to copy the buffer, which
enables us to complete write immediately and not care about "in-flight" packets
(11.57.05) cron2: or such
(11.57.31) lev__: this is something wintun did in earlier versions before they
switched to ring buffers
https://github.com/WireGuard/wintun/blob/0.1/wintun.c#L647
(12.02.52) lev__: anyway, I'll try to figure out what causes that delay inside
ndis and if I won't find an answer in reasonable timeframe I'll do this
workaround/fix (I have working PoC, need to finalize it)
(12.05.21) cron2: I haven't reached windows DCO review/testing yet... still on
Linux
(12.06.53) lev__: for dco windows I added RX checksum offload support - we
indicate that RX checksums are good and no need to calculate those
(12.08.33) lev__: this works starting from Windows Server 2022/Windows 11, so I
had to create additional build configuration and will have to change installer
script a bit (if new kernel -> copy driver from this path, else from that path)
(12.14.40) cron2: nice
(12.15.02) mattock: ok, now buildbot _might_ not be sending "build successful"
emails anymore
(12.15.16) ***cron2 sighs with relief
(12.15.19) mattock: the code has been restructured so the old easy way of doing
that no longer worked
(12.15.24) dazo: Anything else on 2.6? What needs attention and from whom?
(12.15.48) mattock: if there's no email from "debian-10-factory-package"
builder then things should be ok
(12.16.14) cron2: I have two patches out on the list that I'd like review on -
--mtu-disc for IPv6, and multi-deferred-auth-plugin
(12.16.38) dazo: I can give the multi-deferred-auth-plugin a go
(12.19.08) dazo: I presume it's this one:
https://patchwork.openvpn.net/patch/2327/
(12.19.09) vpnHelper: Title: [Openvpn-devel] Enable deferred auth for multiple
plugins (RFC). - Patchwork (at patchwork.openvpn.net)
(12.19.42) dazo: And for reference, the mtu-disc:
https://patchwork.openvpn.net/patch/2318/
(12.19.43) vpnHelper: Title: [Openvpn-devel] Implement --mtu-disc for IPv6 UDP
sockets. - Patchwork (at patchwork.openvpn.net)
(12.20.47) cron2: yes. As it says, this is not ready to go - it's working, and
should be correct "authentication wise", but but not be correct code-wise or
style-wise
(12.20.55) cron2: and yes, that is the other one
(12.37.09) mattock: ok, meeting over?
(12.37.11) mattock: summary is done
(12.37.19) cron2: seems like it :)
(12.37.25) mattock: I think buildbot stopped spamming
(12.37.30) cron2: oh, noes, you ignored my 2.5 item on the agenda...
(12.37.34) cron2: we need a I602 re-release
(12.37.36) mattock: not me
(12.37.43) mattock: I saw it and got scared already
(12.37.50) mattock: but yeah, new Windows installers are doable
(12.37.59) mattock: not a full-blown release unless absolutely necessary
(12.38.23) cron2: well, new GUI version, because of GUI bug
(12.38.33) cron2: no changes in openvpn itself
(12.38.46) dazo: Should we do a quick recap on the "must have" items here?
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26
(12.39.10) dazo: "DNS option rework" ... what was slated for 2.6 has been
merged, right?
(12.39.16) mattock: cron2: +1
(12.39.54) dazo: "sort out multiple-plugin mess" ... that's patchwork 2327
(12.40.22) dazo: "update auth-user-pass docs" .... mattock, that's on your
plate
(12.41.57) dazo: and we should update our estimated schedule
(12.42.59) plaisthos: the auth-token corner case patch is still sitting on the
mailing list
(12.43.42) dazo: plaisthos: got a patchwork ID for it?
(12.44.44) plaisthos: https://patchwork.openvpn.net/patch/2303/
(12.44.45) vpnHelper: Title: [Openvpn-devel,v3] Fix OpenVPN querying
user/password if auth-token with user expires - Patchwork (at
patchwork.openvpn.net)
(12.47.49) Pippin_ ha abbandonato la stanza (quit: Remote host closed the
connection).
(12.48.15) Pippin_ [Pippin_@openvpn/community/Pippin] è entrato nella stanza.
(12.48.57) dazo: plaisthos: frame/buffer size patches .... didn't we merge them?
(12.49.10) cron2: dazo: yes
(12.49.22) cron2: all in, all tested, all followup comments addressed \o/
(12.49.25) ***dazo updates status page
(12.52.19) Pippin__ [Pippin_@openvpn/community/Pippin] è entrato nella stanza.
(12.52.19) Pippin_ è ora conosciuto come Guest8609
(12.52.19) Pippin__ è ora conosciuto come Pippin_
(12.52.23) cron2: dazo: the "DNS options" patch is in and should do the right
thing for windows + env for everything else
(12.52.40) dazo: good, I'll mark it done
(12.53.22) Guest8609 ha abbandonato la stanza (quit: Ping timeout: 260 seconds).
(12.56.26) dazo: mattock: can you decide the fate of "update auth-user-pass
docs" ... that's been lingering for years now
(12.56.42) mattock: dazo: yeah, I know
(12.56.45) mattock: I'll check it out now
(12.57.05) mattock: only four years!
(12.57.10) mattock: no, six
(12.58.18) dazo: mattock lev__ How is it with openssl 3.0.1 in Windows builds?
no status here
(12.59.08) dazo: ordex cron2: What about "do not push route-ipv6 entries that
are also in the iroute-ipv6 list", it says "pending review"
(12.59.09) mattock: openssl 3.0.1 windows build work
(12.59.17) dazo: mattock: okay, so we can close that off as done
(12.59.20) mattock: I know because my builds broke badly because of openssl
3.0.x
(12.59.24) cron2: there's a couple of dangling patches that nobody had time for
yet
(12.59.34) mattock: plus I needed to make the builds work for both 1.1.1 and
3.0.x
(12.59.43) dazo: cron2: alright, got a patchwork pointer for it?
(12.59.45) mattock: required two separate builder vms unfortunately
(13.00.03) cron2: dazo: "somewhere down", from ordex
(13.00.12) dazo: I'll try to dig it up
(13.01.01) dazo: cron2: this one? Or we got a newer one?
https://patchwork.openvpn.net/patch/332/
(13.01.02) vpnHelper: Title: [Openvpn-devel] do not push route-ipv6 entries
that are also in the iroute-ipv6 list - Patchwork (at patchwork.openvpn.net)
(13.01.10) cron2: that would be the one
(13.01.28) dazo: thx!
(13.02.51) dazo: cron2 plaisthos "DDoS reflection hardening (rate-limiting)"
... it says "wip", but don't recall discussions lately here
(13.03.12) cron2: scroll up 50 lines :-)
(13.03.36) dazo: hahaha ... okay, *that* one .... I thought that was the "TLS
handshake replay protection"
(13.04.04) cron2: it's related
(13.04.08) mattock: I'll do a PR that modifies the man-page
(13.04.18) dazo: mattock: thx!
(13.04.21) mattock: now
(13.04.21) cron2: my own rate-limit patches might be dropped (also, fairly down
in patchwork)
(13.04.50) plaisthos: dazo: the second one also includes the "switch to a new
tls-crypt key on reneog" to fully fix it
(13.04.56) dazo:
https://patchwork.openvpn.net/project/openvpn2/list/?series=&submitter=5&state=&q=&archive=&delegate=
... yeah, there's a few old ones here
(13.04.57) vpnHelper: Title: OpenVPN 2 - Patchwork (at patchwork.openvpn.net)
(13.09.07) dazo: plaisthos: alright, I'll just mark them as "wip" for now
(13.09.37) dazo: Updated!
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn26
(13.09.39) MaxF22 ha abbandonato la stanza (quit: Quit: Client closed).
(13.10.38) MaxF [~m...@27-73-177-143.ftth.glasoperator.nl] è entrato nella
stanza.
(13.12.22) mattock: https://github.com/OpenVPN/openvpn/pull/172/files
(13.14.22) mattock: meeting ended _now_ I hope :)
(13.18.33) dazo: mattock: yeah, I think we can wrap it up now
(13.18.51) dazo: mattock: commented on your pull-req ... just as an idea.
(13.20.13) mattock: dazo: I'll have a look
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
