OpenVPN Community Meetup 2026

Dates

Previous nuudel poll about the date for the Meetup:

https://nuudel.digitalcourage.de/VnbRxE6iKdWECLbW

Planned date: October Sat. 17 - Sun. 18, 2026 (with October 16 and 19 as travel days) Pre-meeting-social-outing-activity: https://www.hnf.de/en/home.html old computer museum, on the friday before.

Venue

Paderborn, Germany.

Meeting room: Potentially https://www.welcome-hotels.com/en/hotels/paderborn/events/ - Arne will enquire for details.

Accommodation

Welcome Hotel (same as the meeting room)

Price per night should be around 90EUR/night including breakfast.

Currently, for all people that have indicated that they want to come rooms have been reserved. If you do not want to stay in the hotel or want to stay longer etc, please contact Arne.

How to get there

Paderborn has a small local airport, but it's hard to get there from outside Germany.

Closest airports: Frankfurt and Dusseldorf.

Alternatively you can arrive by train.

Who is coming?

If someone is unable to edit this page please reach out to any developer with the travel/topics informations.

Schedule

Friday 16.10.: visit computer museum

Saturday 17/10:

Sunday 18/10:

Meeting notes

1. Gert: 2.8 release planning

   1. Gert wants to release 2.8 sooner, compared to older releases, because the code diverged a lot already from 2.7 and backporting patches is beginning to be annoying.

   2. ideally 2.8 can be released early 2027 (february), on time for the next stable Debian release

   3. 2.8 would be a cleanup release, with a few new features

   4. SHOULD HAVE ("patches need to be in gerrit in the next few weeks"):

      1. TLS cleanups (Arne)

      2. string and integer cleanups (Frank)

      3. server probe (Lev)

      4. windows cleanup: remove network interface code from openvpn.exe (Heiko), split up monolithic iservice code into smaller compile units (Heiko), merge openvpnserv2 code back to iservice (Heiko/Lev/Gert).  Please do not break debuggability ("press F5 from IDE") - "openvpn.exe --pretend-to-be-gui-talk-to-iservice-yourself"

      5. remove --static (Arne? Antonio? Steffan?)

      6. Push-Update and Iroutes support for DCO (needs review)

      7. DCO capability negotiation (on gerrit already) - userspace can query kernel (tx-peer-id, epoch)

      8. windows installer: stop building x86 installers (Lev: check microsoft telemetry if they give us numbers on 32/64 bit distribution) - Win11 only exists as 64bit version, so this would only affect win10/x86 and older versions.

      9. release notes for 2.8 must contain a list of features that "will not survive in the long term" (so *we* need to agree on this first...)

      10. deprecate / remove "small block" cipher support for real?  3DES, blowfish?  -> drop support, except if you add `--really-really-insecure-I-will-change-this-soon` shame flag?  (Arne)

   5. NICE TO HAVE;

      1. Modernize Windows installer

         1. Upgrade WiX
         2. Replace JScript with CMake (there is PR already from Frank)

      2. Multisocket support for dco-win

      3. TCP server support for dco-win

      4. improved VRF support for FreeBSD (Gert) and Linux (patches in Gerrit)

      5. multi-pool patchset from Antonio

   6. all features should be in before christmas 2026, so we can release in february

   7. Features that might not make it (from the list agreed upon in Naples)

      1. full multipeer server-to-server etc.

      2. pluggable transport API - "it's a bit large, and has not seen much use" - Gianmarco has kept it updated, so it's "just a matter of doing it" (-> Antonio/Gianmarco: please ping Arne) - there is a use case for "have it in master for the client side" (OpenVPN for Android), which would give more experience

      3. "peer session restoring" (upgrade userspace while kernel space is keeping the tunnel active, and reattach to kernel peer)

      4. route monitoring to make openvpn react to "changes in network attachment" (wifi/wired roaming, etc.) in a more nice way than "time out and reconnect"

      5. user space DCO (Antonio has this all running...?)

      6. "ip rule" based VPN setup on Linux (nobody working on this right now, no patch set to review)

2. - Yuriy: Gerrit private instance setup?

   1. "yes, please" :-)

   2. Gert ("whoever pushes to the normal public repos") is responsible for pushing "public" master + release/X branches to the "private" instance as well, so push-to-private has the correct commits to base on

3. Arne: FOOD!

   1. Steak house is out -> plan with the "ghetto Norma fusion asian place" instead (13:00)

   2. reservation for Saturday night is "italian place" (20:00, https://maps.app.goo.gl/yqtSCdQK7nmuXwFK8)

   3. Sunday lunch:

   4. Sunday evening: Steakhouse

4. Frank: Release Management

   1. Gert: current point release handling works quite well - 4 week fixed and plannable schedule, good quality patches in the release/ branches, so "make a release" is just version.m4 / Changes.md / ChangeLog editing, and pushing to buildbot host - 30 minutes, unless there is "writing up Changes.md" is hard because of too many patches.  BB will test-build release, so there is an assurance the version.m4 commit didn't break anything.

   2. we do not formally inform distros of dooming releases (informal heads up to debian and freebsd given) - do we want that?

   3. Frank/Yuriy side: improvements?

      1. remove debian/ubuntu package builds from build-openvpn -> build via build.opensuse.org (because SuSE supports "all the distros")

      2. currently "t_client" tests for Windows are not done on gerrit pushes, but on "push to openvpn-build" repo -> this could be improved --> "Lev has super-super comprehensive windows test framework now!" -> please integrate ;-)

5. Lev: dco-win (and dco?) CI test rig https://lstipakov.github.io/dco-rig/

   • very impressive coverage, 90.000 packets between clients, 20.000 sessions per run, iperf, misbehaving userspace, ...

   • 4 pairs "stay connected all the time, run iperf", 16 "swarm" clients, 800 "flood" peers (gremlins)

   • 7 EC2 instances, "a few EUR" per test <-> maybe not run this for every gerrit push?

   • run this as nightly tests?

6. Merge handling

   1. right now, Gert handles all the "merge final patches and push to sf/github/gitlab/gerrit/buildbot"

      • with the review support from Razvan & the financial support from OpenVPN Inc, this works out reasonably well, and we've reduced the gerrit backlog quite a bit over the last 2 months

   2. it would be useful to have at least one backup person in case of unavailability

      • sf.net - who has access?  David, Samuli, James?
      • github, gitlab - who has access?
      • tooling (git ack-am) to be shared Gert -> dev-tools/
      • commit/tag signing is currently only done for release commits, using gert@ personal key

7. Heiko: Anthropic Mythos Access for OpenVPN?

   • Option 1: "Claude for OSS" - maximum plan for free for 6 months, then pay for it
   • Option 2: "Project Glasswing" - sounds like "security researchers" and "red teams" and such - we could apply?
   • Option 3: "OSS Scanner" - dedicated repository on GitHub where you can file PRs that explain attack vector, etc., and how the scanner should behave, and results are mailed "to a mailing list" -> looks useful.  Heiko plans to check with them how "different OS" builds are covered (Linux, Windows, ...) --> go for this one!  (Help with Docker -> Frank)
   • there is a paid version of "OSS Scanner" which might be used for "Corp stuff" eventually

8. Max: Signal group - "how trusted is it?"

   • create a new group with "core developers" (at least: Frank, Gert, Arne, David, Antonio, Max, Steffan, Lev, Heiko + X) - "those in the room right now + David + Johan" sounds like a plan ;-)
   • group clearly marked as "confidential for active core developers"
   • existing group is re-chartered to be more loose "people involved in OpenVPN"
   • memes and volcanoes to be posted to the "community group"

9. Ralf: UDP source port entropy

   • inbound high-bandwidth crypto stream between "just two" entities can not be properly fanned-out to multiple CPUs because "same source+destination port" gets hashed to 1 CPU, 1 Queue

   • idea: modulate UDP source port (bind not needed from within kernel, just set the source port)

     • calculate inner hash, map to outer UDP source port
     • get spread inner flows to multiple receive queues on the other side
     • this is what VXLAN/GENEVE do "in data centers"
     • can't use this for all scenarios ("if you are behind a stateful engine, state will explode")
     • might cause issues with ECMP routing / LACP balancing
     • will cause issues for packet-id / replay window checks, differential delay between flows, proportional to packet-per-second
     • is incompatible with floating (= must not float on source port "change")
     • "ignoring all this for first experiment" -> "it works, and gives a huuuge performance boost"
     • on the receiving side -> replay-window shared between CPUs -> read-modify-write -> cache contention

   • idea: every "lane" has its own receive window = no cache contention

   • 3rd version...

     • IPSEC draft: https://datatracker.ietf.org/doc/html/draft-antony-ipsecme-muse-00

     • "quite complex"

     • different crypto space for "sub-channels" (child SA), negotiated, derived from main

     • assign child SA "to hardware resource", bounded to source port, nicer bidirectionality and NAT behaviour (= symmetric flow)

     • inner flows mapped bidirectional to same "child SA" = helps with cache locality etc

     • localized cryptographic state

   • Question to the room...?

     • "what makes sense? what do we want to adopt?"
     • if "child SA" -> we need to do control-channel signalling

   • Arne: #1 is very hacky, #2 is problematic with packet ID space limits (48 bit, but only 29 can be used due to AEAD limits) - "same key, IV space partitioned" - very small per-lane IV space (it would work with ChaCha or AEGIS)

   • Steffan: "there is no good option with AEAD except do multiple keys"

   • (discussion about technical details, bit length, data format, ...)

   • rough result how an implementation could look like:

     • server has multiple active sockets, set up by the admin, firewall ports openend ("it is known beforehand that these ports work")
     • client connects
     • server signals "I can do multi-channel, I would be willing to accept extra connections on ip:port1, ip:port2, ip:port3"
     • client sends a CONTROL_AUX packet to additional socket (= new "userland control-data channel" stuff, authenticated by peer-id + crypto")
     • server acknowledges this, assigns a new peer-id for the subchannel (?)
     • client sends a 3-way "let's do this!" CONTROL_AUX PACKET
     • data channel key is derived from original TLS session ("do not re-use the same identifier!")
     • both ends instantiate a kernel peer (master peer-id, sub-channel peer-id) <<-- needs new kernel messages
     • open question: what peer-id to use in which packets?
       • identity of "what"?
       • floating of subchannels?
       • asymmetric peer-id?
     • possibly de-couple "client id" (identifier between userspace and DCO) and "peer-id" (what is in the packet)
       • "client id" can have "1..N" peer-id associated to it
     • also rx-peer-id/tx-peer-id

10. Steffan: control channel test suite "it has been on the list since 2022! go merge it!"
     --> new patchset on Gerrit, go review!

11. Arne: testing management/testing in general

    • App-Custom-Control: client and server can exchange "custom" messages over openvpn transport, using management-interface on both ends

    • two demo scripts for this available in gerrit

    • needs management interface patch to actively run scripts "connected to mgmt-if"

    • python scripts with python module (omi.py) to excercise management interface

    • Question to the room: what do we want and what do we need?

      • Frank: yes! test! all of it!

      • Gert: extend t_client to use management interface to drive client side (connect, disconnect, reconnect, test signal handling, counters, 2FA, --management-query-user-pass, --management-external-key...)

        • run openvpn --management-script $driver

      • Gert: extend t_server tests to test management functionality (permit/reject clients, do delayed auth, IP assignment, PUSH_UPDATE, ...)

      • Steffan: this could nicely integrate with the TLS test suite Steffan is currently building (for "make check")

    • TODO: review and merge patches in gerrit, then enhance t_client, t_server, .. tests

    • ACC examples is master, but the "python framework handling things" should be in 2.7

    • Arne: grab one of the AS python developers to help review

12. Arne/Steffan/Lev/Max: CONTROL_V2/probe protocol

    • everbody agrees on the concepts and the naming (PMH!)
    • Arne and Steffan will write it down next week

13. Gert: agree on server-probe architecture ("which bit of the code gets to do what"), before going into individual patch review

    • Lev: "this is mostly client side and I need to rewrite everything now"
    • please update the highlevel document :-) and we look very closely at this next week

14. Heiko: can we have automated testing for the windows services?

    • Frank: "we have some windows infrastructure" (AWS), we also have t_client "alike" windows tests
    • not run on every commit to openvpn main repo, just on push to openvpn-build repo
    • Lev: "will fix my test rig to use latest-master .msi"
    • how to test from gerrit?
    • *what* to test from gerrit?
    • for windows: split-dns, block-outside-dns testing looks interesting
    • reference server ("phillip") has UDP, TCP, v4, v6 server instances that can push DNS if requested, etc. ("setenv IV_WANT_DNS=dns|dhcp" on the client side)
    • Heiko: this looks good, but it's not testing the automatic service yet --> add work on this
    • gui (-cli) can be used to monitor / restart / stop instances (if automatic configs have --management in them) -> Selva understands all the details

15. Lev: streamline dco-win releases (we now have EV/Authenticode signing automated, need to move builds from Lev machine to some AWS instance?)

    • signing is done on Lev's laptop plus some machine in Community VPN today, and it's complicated with copying files and signed files back and forth 6 times

    • improved scripting already - "one click!", but still built & signed on Lev's laptop

    • it would need "Windows VM with right version of enterprise driver kit + community VPN access for signing"

      • -> Ball is with Frank and Yuriy to use the "windows installer building + signing" AMI for dco-win too, "we just need to do this"

16. Antonio: libdco, synchronize across linux/windows/freebsd?

17. next meeting?  location and time?

    • Oulu (July/August)
    • Tallinn?
    • Berlin?
    • Istanbul?
    • Zagreb? --> east-west-trajectory being followed
    • Belgrade?

18. multipeer support?

    • will we have something in 2.8?  (no)
    • Arne has proof of concept code, but it's "very rough"
    • not being worked on righ