Re: [Openvpn-devel] Summary of the community meeting (24th June 2020)

[Gert Doering]

Hi,

On Thu, Jun 25, 2020 at 12:52:30AM +0500,  ?? wrote:
> there's quite an interesting patchset
> https://patchwork.openvpn.net/project/openvpn2/list/?series=230
> is it scheduled for 2.5 release ?

No.  Too late, too incomplete.

> or I've missed something and all patches are scheduled for 2.5 ?

This: 

  https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25 

is what will go in, and what not.  Things not listed on the page 
will not (the "multi socket" patch is listed, but in the "won't make
it" section).

Yes, it would be great to have this all, but it's even greater to
actually *reach* 2.5 - and then work on the remaining patchsets towards
2.6 (which is planned to take less than umpteen years :-) )

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 g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of the community meeting (24th June 2020)

[Илья Шипицин]

there's quite an interesting patchset
https://patchwork.openvpn.net/project/openvpn2/list/?series=230
is it scheduled for 2.5 release ?

or I've missed something and all patches are scheduled for 2.5 ?

ср, 24 июн. 2020 г. в 16:11, Samuli Seppänen :

> Hi,
>
> Here's the summary of the IRC meeting.
>
> ---
>
> COMMUNITY MEETING
>
> Place: #openvpn-meeting on irc.freenode.net
> Date: Wed 24th June 2020
> Time: 11:30 CEST (9:30 UTC)
>
> Planned meeting topics for this meeting were here:
>
> 
>
> Your local meeting time is easy to check from services such as
>
> 
>
> SUMMARY
>
> cron2, dazo, lev, mattock, plaisthos and uip participated in this meeting.
>
> ---
>
> Talked about the status of OpenVPN 2.5:
>
> 
>
> Ordex promised to have a look at the async-cc patches this week.
> Plaisthos, dazo and cron2 will follow-up on the review comments to get
> them resolved quickly.
>
> OpenVPN 2.5 MSI looks surprisingly good. Mattock was able to produce
> tap-windows6 MSM ("merge module") which he then used to produce OpenVPN
> 2.5-based MSI installer. The only significant challenge is adding
> code-signing support to openvpn-build/generic.
>
> Automating MSI builds also seems easier than expected, given that the
> existing openvpn-build buildslave can perform the actual build and push
> the artifacts to the Windows packager, which can then build and push the
> results to build.openvpn.net.
>
> Code-vise 2.5-alpha1 is in a good shape, mainly missing
>
> - compression
> - async cc
> - VRF (which is quite trivial)
>
> The auth-token fixes are corner-cases and it was agreed that that can be
> resolved between 2.5-alpha1 and 2.5-beta1.
>
> ---
>
> Talked about moving 2.3 into "oldstable" support mode. Previously we had
> agreed to do that when 2.3.19 was released. However, 2.3.18 was released
> a long while ago and there's nothing queued for 2.3.19. So it was
> decided to move 2.3 to "oldstable" now instead of later.
>
> ---
>
> Talked about starting the deprecation of "--ncp-disable". The idea is
> that --ncp-disable has been mostly a debug feature and as we move
> forward and want to be able to manage VPN security more from server
> side, we want to abandon the possibility to ignore NCP.
>
> This is tied with deprecation of --cipher for everything except p2p:
>
>
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20062.html
>
> Uip will bring these topics up with syzzer a.s.a.p.
>
> ---
>
> Talked about OpenVPN 2.6. There are several things that are 2.6 material:
>
> - Kernel acceleration module (client-side only beta ~next week)
> - Work related to "making DNS handling nice"
>
> It is possible that we'd also need to postpone the --ncp-disable and
> --cipher changes.
>
> However, it was agreed that doing a "quick" 2.6 release in, say, early
> 2021 is doable. It was also agreed that supporting both 2.5 and 2.6 as
> "stable" for a while would be acceptable, as the changes would be mostly
> in OpenVPN and the same release and automation tooling could be used for
> both.
>
> ---
>
> Talked about our use of IV_*. Agreed that rather than having tons of
> IV_FOO=1 options IV_PROTO should be considered a wire-protocol-only
> 64-bit mask field and IV_FEAT would be a new 64-bit mask field
> indicating which features the local side supports.
>
> OpenVPN will need to handle a remote side not providing IV_FEAT.
> Default behaviour when this field is missing must be documented.
> IV_FEAT should be sent by OpenVPN 2.6 and newer. This approach allows
> easier deprecation of features as well.
>
> --
>
> Full chatlog attached
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 00/11] man-page overhaul project

[David Sommerseth]

On 24/06/2020 20:07, David Sommerseth wrote:
> Hi,
> 
> This is the first real review round of the man-page overhaul project.
> Since the n/groff based openvpn.8 format is fairly cumbersome to edit,
> we agreed at the 2019 Hackathon in Trento to move the man page into
> something more editing and management friendly.
> 
> This set of patches converts the openvpn.8 file into the
> ReStructuredText format (.rst) which can easily be converted into both
> man and html files using python-docutils.  The advantage of this format
> is that it is easy to edit in any plain text editors and displays
> reasonably well in any terminals.  And it will be easier to review
> patches man page updates sent to the mailing list.
> 
> To avoid everyone building the OpenVPN source tarball to have the full
> python stack available, the doc/Makefile.am file has been adopted to
> generate the man and html files when we create the source tarball
> we distribute in releases.  Only users only pulling down the source
> directly from git will need to have python-docutils available.
> 
> As I worked my way through the man page, there were several things
> which was less good.  Lots of options where misplaced in not related
> sections, a few options where documented several places.  And lots
> of the sections overlapped quite a bit.  From patch 5/11 splits
> the whole man page into several smaller files; one file per section.
> This is all tied into a single man-page/html file when running the
> rst2man/rst2html tools.  The following patches just cleans up and
> moves some options into more suitable sections.
> 
> 
> I will continue to update my own git branch containing this work as
> review comments come in until this is merged into master.  You can
> find it here:
> 
>   https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting/doc
> 

So sf.net mailing list is grumpy at me for sending a large mail, patch 5/11 is
currently waiting to be unlocked by the list admin.  In the mean time, here's
the patch:




-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 07/11] doc/man: Move --dhcp-option from client to vpn-network section

[David Sommerseth]

Even though the --dhcp-option is only useful in a client context, it is
more related to configuration of the VPN network interface and the
related settings.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/client-options.rst  | 69 
 doc/man-sections/vpn-network-options.rst | 69 
 2 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index d6f9e6aa..966ede1e 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -146,75 +146,6 @@ configuration.
 --connect-timeout n
   See ``--server-poll-timeout``.
 
---dhcp-option args
-  Set additional network settings via DHCP.  On Windows, this is parsed by
-  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
-  options can be picked up by a ``--up`` script or plug-in if it has been
-  pushed by the OpenVPN server.  The option will then be saved in the
-  client's environment before the ``--up`` script is called, under the name
-  :code:`foreign_option_{n}`.
-
-  Valid syntax:
-  ::
-
- dhcp-options type [parm]
-
-  :code:`DOMAIN` ``name``
-Set Connection-specific DNS Suffix to :code:`name`.
-
-  :code:`DNS` ``address``
-Set primary domain name server IPv4 or IPv6 address.
-Repeat this option to set secondary DNS server addresses.
-
-Note: DNS IPv6 servers are currently set using netsh (the existing
-DHCP code can only do IPv4 DHCP, and that protocol only permits
-IPv4 addresses anywhere). The option will be put into the
-environment, so an ``--up`` script could act upon it if needed.
-
-  :code:`WINS` ``address``
-Set primary WINS server address (NetBIOS over TCP/IP Name Server).
-Repeat this option to set secondary WINS server addresses.
-
-  :code:`NBDD` ``address``
-Set primary NBDD server address (NetBIOS over TCP/IP Datagram
-Distribution Server). Repeat this option to set secondary NBDD
-server addresses.
-
-  :code:`NTP` ``address``
-Set primary NTP server address (Network Time Protocol).
-Repeat this option to set secondary NTP server addresses.
-
-  :code:`NBT` ``type``
-Set NetBIOS over TCP/IP Node type. Possible options:
-
-:code:`1`
-  b-node (broadcasts)
-
-:code:`2`
-  p-node (point-to-point name queries to a WINS server)
-
-:code:`4`
-  m-node (broadcast then query name server)
-
-:code:`8`
-  h-node (query name server, then broadcast).
-
-  :code:`NBS` ``scope-id``
-Set NetBIOS over TCP/IP Scope. A NetBIOS Scope ID provides an
-extended naming service for the NetBIOS over TCP/IP (Known as NBT)
-module. The primary purpose of a NetBIOS scope ID is to isolate
-NetBIOS traffic on a single network to only those nodes with the
-same NetBIOS scope ID. The NetBIOS scope ID is a character string
-that is appended to the NetBIOS name. The NetBIOS scope ID on two
-hosts must match, or the two hosts will not be able to communicate.
-The NetBIOS Scope ID also allows computers to use the same computer
-name, as they have different scope IDs. The Scope ID becomes a part
-of the NetBIOS name, making the name unique. (This description of
-NetBIOS scopes courtesy of neonsu...@abyss.com)
-
-  :code:`DISABLE-NBT`
-Disable Netbios-over-TCP/IP.
-
 --explicit-exit-notify n
   In UDP client mode or point-to-point mode, send server/peer an exit
   notification if tunnel is restarted or OpenVPN process is exited. In
diff --git a/doc/man-sections/vpn-network-options.rst 
b/doc/man-sections/vpn-network-options.rst
index fc18676e..d75cf540 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -88,6 +88,75 @@ routing.
   the TUN/TAP device used with ``--dev`` does not begin with :code:`tun`
   or :code:`tap`.
 
+--dhcp-option args
+  Set additional network settings via DHCP.  On Windows, this is parsed by
+  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
+  options can be picked up by a ``--up`` script or plug-in if it has been
+  pushed by the OpenVPN server.  The option will then be saved in the
+  client's environment before the ``--up`` script is called, under the name
+  :code:`foreign_option_{n}`.
+
+  Valid syntax:
+  ::
+
+ dhcp-options type [parm]
+
+  :code:`DOMAIN` ``name``
+Set Connection-specific DNS Suffix to :code:`name`.
+
+  :code:`DNS` ``address``
+Set primary domain name server IPv4 or IPv6 address.
+Repeat this option to set secondary DNS server addresses.
+
+Note: DNS IPv6 servers are currently set using netsh (the existing
+DHCP code can only do IPv4 DHCP, and that protocol only permits
+IPv4 addresses anywhere). The option will be put into the

[Openvpn-devel] [PATCH 11/11] doc/man: Cleaned up the examples

[David Sommerseth]

Removed a lot of outdated information.  The loading of the tun module is
not needed on current Linux distributions; it is automatically loaded
when needed.

Also removed all the iptables references and rather refer the reader to
figure out how firewalling is configured on their system.  The reason is
that iptables is moving towards being deprecated in faviour of
nftables/nft.  In addition many Linux distributions provide their own
wrappers around it (ufw, firewalld, to mention a couple).  In addition
it makes the man page less Linux-centric.

The only Linux specific reference left is configuration of IP
forwarding.  But extended the text to ask the reader to find the
preferred way of configuring IP forwarding in a persistent way.  Many
Linux distributions uses their own set of network configuration tools as
well (NetworkManager, systemd-networkd, netplan, to mention a few).

The rest of the instructions should be fairly OS neutral and is a quick
introduction how to get tunnels configured and gradually expand the
configuration and improve the security along the way.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/examples.rst | 105 --
 1 file changed, 11 insertions(+), 94 deletions(-)

diff --git a/doc/man-sections/examples.rst b/doc/man-sections/examples.rst
index 0bea7f5a..ecc2a29f 100644
--- a/doc/man-sections/examples.rst
+++ b/doc/man-sections/examples.rst
@@ -7,32 +7,12 @@ installed OpenVPN, consult the INSTALL file included in the 
OpenVPN
 distribution.
 
 
-TUN/TAP Setup:
---
-
-If you are using Linux 2.4 or higher, make the tun device node and load
-the tun module:
-
-::
-
-mknod /dev/net/tun c 10 200
-modprobe tun
-
-If you installed from RPM, the ``mknod`` step may be omitted, because
-the RPM install does that for you.
-
-Only Linux 2.4 and newer are supported.
-
-For other platforms, consult the INSTALL file at
-https://openvpn.net/community-resources/the-standard-install-file-included-in-the-source-distribution/
-for more information.
-
-
 Firewall Setup:
 ---
 
 If firewalls exist between the two machines, they should be set to
-forward UDP port 1194 in both directions. If you do not have control
+forward the port OpenVPN is configured to use, in both directions.
+The default for OpenVPN is 1194/udp.  If you do not have control
 over the firewalls between the two machines, you may still be able to
 use OpenVPN by adding ``--ping 15`` to each of the ``openvpn`` commands
 used below in the examples (this will cause each peer to send out a UDP
@@ -40,13 +20,8 @@ ping to its remote peer once every 15 seconds which will 
cause many
 stateful firewalls to forward packets in both directions without an
 explicit firewall rule).
 
-If you are using a Linux iptables-based firewall, you may need to enter
-the following command to allow incoming packets on the TUN device:
-
-:code:`iptables -A INPUT -i tun+ -j ACCEPT`
-
-See the firewalls section below for more information on configuring
-firewalls for use with OpenVPN.
+Please see your operating system guides for how to configure the firewall
+on your systems.
 
 
 VPN Address Setup:
@@ -239,10 +214,14 @@ enable routing:
 
 echo 1 > /proc/sys/net/ipv4/ip_forward
 
-and enable TUN packet forwarding through the firewall:
-::
+This setting is not persistent.  Please see your operating systems
+documentation how to properly configure IP forwarding, which is also
+persistent through system boots.
 
-   iptables -A FORWARD -i tun+ -j ACCEPT
+If you system is configured with a firewall.  Please see your operating
+systems guide on how to configure the firewall.  You typically want to
+allow traffic coming from and going to the tun/tap adapter OpenVPN is
+configured to use.
 
 On bob:
 ::
@@ -260,65 +239,3 @@ Now any machine on the *10.0.0.0/24* subnet can access any 
machine on the
 In a production environment, you could put the route command(s) in a
 script and execute with the ``--up`` option.
 
-
-FIREWALLS
-=
-
-OpenVPN's usage of a single UDP port makes it fairly firewall-friendly.
-You should add an entry to your firewall rules to allow incoming OpenVPN
-packets. On Linux 2.4+:
-::
-
-   iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT
-
-This will allow incoming packets on UDP port :code:`1194` (OpenVPN's
-default UDP port) from an OpenVPN peer at :code:`1.2.3.4`.
-
-If you are using HMAC-based packet authentication (the default in any of
-OpenVPN's secure modes), having the firewall filter on source address
-can be considered optional, since HMAC packet authentication is a much
-more secure method of verifying the authenticity of a packet source. In
-that case:
-::
-
-   iptables -A INPUT -p udp --dport 1194 -j ACCEPT
-
-would be adequate and would not render the host inflexible with respect
-to its peer having a dynamic IP address.
-
-OpenVPN also works well on stateful firewalls. In some cases, you may
-not need to add any static rules to the firewall list 

[Openvpn-devel] [PATCH 10/11] doc/man: Moved --reneg-* options to its own section

[David Sommerseth]

The options related to renegotiation of the data channel encryption key
is not really a link option.  As the renegotiation is encryption
related but doesn't really fit into the generic, tls or pkcs11 sections,
add it into its own section.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/encryption-options.rst |  1 +
 doc/man-sections/link-options.rst   | 47 --
 doc/man-sections/renegotiation.rst  | 53 +
 3 files changed, 54 insertions(+), 47 deletions(-)
 create mode 100644 doc/man-sections/renegotiation.rst

diff --git a/doc/man-sections/encryption-options.rst 
b/doc/man-sections/encryption-options.rst
index 5e99c52f..42c80eb8 100644
--- a/doc/man-sections/encryption-options.rst
+++ b/doc/man-sections/encryption-options.rst
@@ -130,6 +130,7 @@ Generating key material
access to this file will be to generate auth tokens that the OpenVPN
server will accept as valid.
 
+.. include:: renegotiation.rst
 .. include:: tls-options.rst
 .. include:: pkcs11-options.rst
 
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index 5f75c5f3..43e33176 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -284,53 +284,6 @@ the local and the remote host.
   and has been used since version 2.0-beta17. Previous versions used port
   5000 as the default.
 
---reneg-bytes n
-  Renegotiate data channel key after ``n`` bytes sent or received
-  (disabled by default with an exception, see below). OpenVPN allows the
-  lifetime of a key to be expressed as a number of bytes
-  encrypted/decrypted, a number of packets, or a number of seconds. A key
-  renegotiation will be forced if any of these three criteria are met by
-  either peer.
-
-  If using ciphers with cipher block sizes less than 128-bits,
-  ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly
-  disabled by setting the value to :code:`0`, but this is
-  **HIGHLY DISCOURAGED** as this is designed to add some protection against
-  the SWEET32 attack vector. For more information see the ``--cipher``
-  option.
-
---reneg-pkts n
-  Renegotiate data channel key after **n** packets sent and received
-  (disabled by default).
-
---reneg-sec args
-  Renegotiate data channel key after at most ``max`` seconds
-  (default :code:`3600`) and at least ``min`` seconds (default is 90% of
-  ``max`` for servers, and equal to ``max`` for clients).
-  ::
-
- reneg-sec max [min]
-
-  The effective ``--reneg-sec`` value used is per session
-  pseudo-uniform-randomized between ``min`` and ``max``.
-
-  With the default value of :code:`3600` this results in an effective per
-  session value in the range of :code:`3240`..:code:`3600` seconds for
-  servers, or just 3600 for clients.
-
-  When using dual-factor authentication, note that this default value may
-  cause the end user to be challenged to reauthorize once per hour.
-
-  Also, keep in mind that this option can be used on both the client and
-  server, and whichever uses the lower value will be the one to trigger
-  the renegotiation. A common mistake is to set ``--reneg-sec`` to a
-  higher value on either the client or server, while the other side of the
-  connection is still using the default value of :code:`3600` seconds,
-  meaning that the renegotiation will still occur once per :code:`3600`
-  seconds. The solution is to increase --reneg-sec on both the client and
-  server, or set it to :code:`0` on one side of the connection (to
-  disable), and to your chosen value on the other side.
-
 --rport port
   Set TCP/UDP port number or name used by the ``--remote`` option. The
   port can also be set directly using the ``--remote`` option.
diff --git a/doc/man-sections/renegotiation.rst 
b/doc/man-sections/renegotiation.rst
new file mode 100644
index ..aaede4eb
--- /dev/null
+++ b/doc/man-sections/renegotiation.rst
@@ -0,0 +1,53 @@
+Data Channel Renegotiation
+--
+
+When running OpenVPN in client/server mode, the data channel will use a
+separate ephemeral encryption key which is rotated at regular intervals.
+
+--reneg-bytes n
+  Renegotiate data channel key after ``n`` bytes sent or received
+  (disabled by default with an exception, see below). OpenVPN allows the
+  lifetime of a key to be expressed as a number of bytes
+  encrypted/decrypted, a number of packets, or a number of seconds. A key
+  renegotiation will be forced if any of these three criteria are met by
+  either peer.
+
+  If using ciphers with cipher block sizes less than 128-bits,
+  ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly
+  disabled by setting the value to :code:`0`, but this is
+  **HIGHLY DISCOURAGED** as this is designed to add some protection against
+  the SWEET32 attack vector. For more information see the ``--cipher``
+  option.
+
+--reneg-pkts n
+  Renegotiate data channel key after **n** packets sent and received
+  (disabled by 

[Openvpn-devel] [PATCH 04/11] doc/man: Remove unsupported options in OpenVPN 2.5

[David Sommerseth]

This removes the options from the man page which is enlisted as
deprecated options in OpenVPN 2.5.  To provide some history, a short
summary of why they were removed has been put into a new file which is
included into its own "UNSUPPORTED OPTIONS" section in the man page.

Signed-off-by: David Sommerseth 
---
 doc/openvpn.8.rst   | 144 +---
 doc/unsupported-options.rst |  33 +
 2 files changed, 35 insertions(+), 142 deletions(-)
 create mode 100644 doc/unsupported-options.rst

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index fc3ecdb8..713cd309 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -454,9 +454,7 @@ Tunnel Options:
 the client's tun interface always points to the local endpoint of the
 server's tun interface. This mode allocates a single IP address per
 connecting client. Only use when none of the connecting clients are
-Windows systems. This mode is functionally equivalent to the
-``--ifconfig-pool-linear`` directive which is available in OpenVPN 2.0,
-is deprecated and will be removed in OpenVPN 2.5
+Windows systems.
 
   :code:`subnet`
 Use a subnet rather than a point-to-point topology by
@@ -2184,17 +2182,6 @@ fast hardware. SSL/TLS authentication must be used in 
this mode.
   receive the given IP address. If you want guaranteed assignment, use
   ``--ifconfig-push``
 
---ifconfig-pool-linear
-  **DEPRECATED** This option will be removed in OpenVPN 2.5
-
-  Modifies the ``--ifconfig-pool`` directive to allocate individual TUN
-  interface addresses for clients rather than /30 subnets.
-
-  *NOTE:*   This option is incompatible with Windows clients.
-
-  This option is deprecated, and should be replaced with ``--topology
-  p2p`` which is functionally equivalent.
-
 --ifconfig-push args
   Push virtual IP endpoints for client tunnel, overriding the
   ``--ifconfig-pool`` dynamic allocation.
@@ -2668,17 +2655,6 @@ fast hardware. SSL/TLS authentication must be used in 
this mode.
   authentication module/script MUST have logic to detect this condition
   and respond accordingly.
 
---client-cert-not-required
-  **DEPRECATED** This option will be removed in OpenVPN 2.5
-
-  Don't require client certificate, client will authenticate using
-  username/password only. Be aware that using this directive is less
-  secure than requiring certificates from all clients.
-
-  **Please note:** This is replaced by ``--verify-client-cert`` which
-  allows for more flexibility. The option ``--verify-client-cert none`` is
-  functionally equivalent to ``--client-cert-not-required``
-
 --verify-client-cert mode
   Specify whether the client is required to supply a valid certificate.
 
@@ -3178,41 +3154,6 @@ These options are meaningful for both Static & 
TLS-negotiated key modes
   ``--show-engines`` standalone option to list the crypto engines which
   are supported by OpenSSL.
 
---no-replay
-  **DEPRECATED** This option will be removed in OpenVPN 2.5.
-
-  (Advanced) Disable OpenVPN's protection against replay attacks. Don't
-  use this option unless you are prepared to make a tradeoff of greater
-  efficiency in exchange for less security.
-
-  OpenVPN provides datagram replay protection by default.
-
-  Replay protection is accomplished by tagging each outgoing datagram with
-  an identifier that is guaranteed to be unique for the key being used.
-  The peer that receives the datagram will check for the uniqueness of the
-  identifier. If the identifier was already received in a previous
-  datagram, OpenVPN will drop the packet. Replay protection is important
-  to defeat attacks such as a SYN flood attack, where the attacker listens
-  in the wire, intercepts a TCP SYN packet (identifying it by the context
-  in which it occurs in relation to other packets), then floods the
-  receiving peer with copies of this packet.
-
-  OpenVPN's replay protection is implemented in slightly different ways,
-  depending on the key management mode you have selected.
-
-  In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses
-  a 64 bit unique identifier that combines a time stamp with an
-  incrementing sequence number.
-
-  When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses
-  only a 32 bit sequence number without a time stamp, since OpenVPN can
-  guarantee the uniqueness of this value for each key. As in IPSec, if the
-  sequence number is close to wrapping back to zero, OpenVPN will trigger
-  a new key exchange.
-
-  To check for replays, OpenVPN uses the *sliding window* algorithm used
-  by IPSec.
-
 --replay-window args
   Modify the replay protection sliding-window size and time window.
 
@@ -3311,27 +3252,6 @@ These options are meaningful for both Static & 
TLS-negotiated key modes
   default) and you are using either ``--secret`` (shared-secret key mode)
   or TLS mode with ``--tls-auth``.
 
---no-iv
-  **DEPRECATED** This option will be removed in OpenVPN 2.5.
-
-  

[Openvpn-devel] [PATCH 03/11] doc/man: Move profiles section

[David Sommerseth]

The  profile documentation has been enlisted in between all
the other OpenVPN options.  As  is not strictly an option by
itself but a grouping mechanism, move it into its own section in the man
page.  This also makes the HTML rendering look much nicer and better
structured.

Signed-off-by: David Sommerseth 
---
 doc/openvpn.8.rst | 149 --
 1 file changed, 78 insertions(+), 71 deletions(-)

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index 4627a7d3..fc3ecdb8 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -204,77 +204,6 @@ Tunnel Options:
   prevent DNS caching. For example, "foo.bar.gov" would be modified to
   ".foo.bar.gov".
 
-
-  Define a client connection profile. Client connection profiles are
-  groups of OpenVPN options that describe how to connect to a given
-  OpenVPN server. Client connection profiles are specified within an
-  OpenVPN configuration file, and each profile is bracketed by
-   and .
-
-  An OpenVPN client will try each connection profile sequentially until it
-  achieves a successful connection.
-
-  ``--remote-random`` can be used to initially "scramble" the connection
-  list.
-
-  Here is an example of connection profile usage:
-  ::
-
- client
- dev tun
-
- 
- remote 198.19.34.56 1194 udp
- 
-
- 
- remote 198.19.34.56 443 tcp
- 
-
- 
- remote 198.19.34.56 443 tcp
- http-proxy 192.168.0.8 8080
- 
-
- 
- remote 198.19.36.99 443 tcp
- http-proxy 192.168.0.8 8080
- 
-
- persist-key
- persist-tun
- pkcs12 client.p12
- remote-cert-tls server
- verb 3
-
-  First we try to connect to a server at 198.19.34.56:1194 using UDP. If
-  that fails, we then try to connect to 198.19.34.56:443 using TCP. If
-  that also fails, then try connecting through an HTTP proxy at
-  192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect
-  through the same proxy to a server at 198.19.36.99:443 using TCP.
-
-  The following OpenVPN options may be used inside of a 
-  block:
-
-  ``bind``, ``connect-retry``, ``connect-retry-max``, ``connect-timeout``,
-  ``explicit-exit-notify``, ``float``, ``fragment``, ``http-proxy``,
-  ``http-proxy-option``, ``key-direction``, ``link-mtu``, ``local``,
-  ``lport``, ``mssfix``, ``mtu-disc``, ``nobind``, ``port``, ``proto``,
-  ``remote``, ``rport``, ``socks-proxy``, ``tls-auth``, ``tls-crypt``,
-  ``tun-mtu and``, ``tun-mtu-extra``.
-
-  A defaulting mechanism exists for specifying options to apply to all
-   profiles. If any of the above options (with the
-  exception of ``remote`` ) appear outside of a  block,
-  but in a configuration file which has one or more 
-  blocks, the option setting will be used as a default for
-   blocks which follow it in the configuration file.
-
-  For example, suppose the ``nobind`` option were placed in the sample
-  configuration file above, near the top of the file, before the first
-   block. The effect would be as if ``nobind`` were
-  declared in all  blocks below it.
-
 --proto-force p
   When iterating through connection profiles, only consider profiles using
   protocol ``p`` (:code:`tcp` \| :code:`udp`).
@@ -5400,6 +5329,84 @@ instances.
 
 
 
+CONNECTION PROFILES
+===
+
+Client configuration files may contain multiple remote servers which
+it will attempt to connect against.  But there are some configuration
+options which are related to specific ``--remote`` options.  For these
+use cases, connection profiles is the solution.
+
+By enacpulating the ``--remote`` option and related options within
+ and , these options are handled as a
+group.
+
+An OpenVPN client will try each connection profile sequentially until it
+achieves a successful connection.
+
+``--remote-random`` can be used to initially "scramble" the connection
+list.
+
+Here is an example of connection profile usage:
+::
+
+   client
+   dev tun
+
+   
+   remote 198.19.34.56 1194 udp
+   
+
+   
+   remote 198.19.34.56 443 tcp
+   
+
+   
+   remote 198.19.34.56 443 tcp
+   http-proxy 192.168.0.8 8080
+   
+
+   
+   remote 198.19.36.99 443 tcp
+   http-proxy 192.168.0.8 8080
+   
+
+   persist-key
+   persist-tun
+   pkcs12 client.p12
+   remote-cert-tls server
+   verb 3
+
+First we try to connect to a server at 198.19.34.56:1194 using UDP. If
+that fails, we then try to connect to 198.19.34.56:443 using TCP. If
+that also fails, then try connecting through an HTTP proxy at
+192.168.0.8:8080 to 198.19.34.56:443 using TCP. Finally, try to connect
+through the same proxy to a server at 198.19.36.99:443 using TCP.
+
+The following OpenVPN options may be used inside of a 
+block:
+
+``bind``, ``connect-retry``, ``connect-retry-max``, ``connect-timeout``,
+``explicit-exit-notify``, ``float``, ``fragment``, ``http-proxy``,
+``http-proxy-option``, ``key-direction``, ``link-mtu``, ``local``,
+``lport``, ``mssfix``, ``mtu-disc``, 

[Openvpn-devel] [PATCH 09/11] doc/man: Move some options from link to advanced section

[David Sommerseth]

Moved --persist-local-ip, --persist-remote-ip, --rcvbuf, --sndbuf
and --shaper from the link options section to the advanced section.

The rationale is that these options are not common to use and is for
more advanced use cases where special tweaking is required.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/advanced-options.rst | 40 +++
 doc/man-sections/link-options.rst | 40 ---
 2 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/doc/man-sections/advanced-options.rst 
b/doc/man-sections/advanced-options.rst
index 9e59677d..262e568c 100644
--- a/doc/man-sections/advanced-options.rst
+++ b/doc/man-sections/advanced-options.rst
@@ -34,6 +34,14 @@ used when debugging or testing out special usage scenarios.
 --bcast-buffers n
   Allocate ``n`` buffers for broadcast datagrams (default :code:`256`).
 
+--persist-local-ip
+  Preserve initially resolved local IP address and port number across
+  ``SIGUSR1`` or ``--ping-restart`` restarts.
+
+--persist-remote-ip
+  Preserve most recently authenticated remote IP address and port number
+  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
+
 --prng args
   *(Advanced)* Change the PRNG (Pseudo-random number generator) parameters
 
@@ -51,6 +59,38 @@ used when debugging or testing out special usage scenarios.
   RAND\_bytes function instead for all of OpenVPN's pseudo-random number
   needs.
 
+--rcvbuf size
+  Set the TCP/UDP socket receive buffer size. Defaults to operation system
+  default.
+
+--shaper n
+  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
+  TCP/UDP port. Note that this will only work if mode is set to
+  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
+  this option on both peers.
+
+  OpenVPN uses the following algorithm to implement traffic shaping: Given
+  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
+  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
+  seconds before queuing the next write.
+
+  It should be noted that OpenVPN supports multiple tunnels between the
+  same two peers, allowing you to construct full-speed and reduced
+  bandwidth tunnels at the same time, routing low-priority data such as
+  off-site backups over the reduced bandwidth tunnel, and other data over
+  the full-speed tunnel.
+
+  Also note that for low bandwidth tunnels (under 1000 bytes per second),
+  you should probably use lower MTU values as well (see above), otherwise
+  the packet latency will grow so large as to trigger timeouts in the TLS
+  layer and TCP connections running over the tunnel.
+
+  OpenVPN allows ``n`` to be between 100 bytes/sec and 100 Mbytes/sec.
+
+--sndbuf size
+  Set the TCP/UDP socket send buffer size. Defaults to operation system
+  default.
+
 --tcp-queue-limit n
   Maximum number of output packets queued before TCP (default :code:`64`).
 
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index ca719c75..5f75c5f3 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -173,14 +173,6 @@ the local and the remote host.
 --passtos
   Set the TOS field of the tunnel packet to what the payload's TOS is.
 
---persist-local-ip
-  Preserve initially resolved local IP address and port number across
-  ``SIGUSR1`` or ``--ping-restart`` restarts.
-
---persist-remote-ip
-  Preserve most recently authenticated remote IP address and port number
-  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
-
 --ping n
   Ping remote over the TCP/UDP control channel if no packets have been
   sent for at least ``n`` seconds (specify ``--ping`` on both peers to
@@ -292,10 +284,6 @@ the local and the remote host.
   and has been used since version 2.0-beta17. Previous versions used port
   5000 as the default.
 
---rcvbuf size
-  Set the TCP/UDP socket receive buffer size. Defaults to operation system
-  default.
-
 --reneg-bytes n
   Renegotiate data channel key after ``n`` bytes sent or received
   (disabled by default with an exception, see below). OpenVPN allows the
@@ -439,34 +427,6 @@ the local and the remote host.
   default) and you are using either ``--secret`` (shared-secret key mode)
   or TLS mode with ``--tls-auth``.
 
---shaper n
-  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
-  TCP/UDP port. Note that this will only work if mode is set to
-  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
-  this option on both peers.
-
-  OpenVPN uses the following algorithm to implement traffic shaping: Given
-  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
-  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
-  seconds before queuing the next write.
-
-  It should be noted that OpenVPN supports multiple tunnels between the
-  same two peers, allowing you to construct full-speed and reduced
-  bandwidth tunnels at the 

[Openvpn-devel] [PATCH 08/11] doc/man: Mark compression options as deprecated

[David Sommerseth]

Due to the VORACLE attack vector, compression in general is deprecated.
Make this clear in the man page.

Also remove an incorrect statement claiming --compress lzo is compatible
with --comp-lzo.  It is not, as --compress lzo uses a different
compression framing than --comp-lzo.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/protocol-options.rst | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index 37e55eb7..5bc072af 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -54,13 +54,13 @@ configured in a compatible way between both the local and 
remote side.
   Set ``alg`` to :code:`none` to disable encryption.
 
 --compress algorithm
-  Enable a compression algorithm.
+  **DEPRECATED** Enable a compression algorithm.  Compression is generally
+  not recommended.  VPN tunnels which uses compression are suspectible to
+  the VORALCE attack vector.
 
   The ``algorithm`` parameter may be :code:`lzo`, :code:`lz4`, or empty.
   LZO and LZ4 are different compression algorithms, with LZ4 generally
-  offering the best performance with least CPU usage. For backwards
-  compatibility with OpenVPN versions before v2.4, use :code:`lzo` (which
-  is identical to the older option ``--comp-lzo yes``).
+  offering the best performance with least CPU usage.
 
   If the ``algorithm`` parameter is empty, compression will be turned off,
   but the packet framing for compression will still be enabled, allowing a
@@ -77,8 +77,9 @@ configured in a compatible way between both the local and 
remote side.
   *not* enable compression.
 
 --comp-lzo mode
-  *DEPRECATED* This option will be removed in a future OpenVPN release.
-  Use the newer ``--compress`` instead.
+  **DEPRECATED** Enable LZO compression algorithm.  Compression is
+  generally not recommended.  VPN tunnels which uses compression are
+  suspectible to the VORALCE attack vector.
 
   Use LZO compression -- may add up to 1 byte per packet for incompressible
   data. ``mode`` may be :code:`yes`, :code:`no`, or :code:`adaptive`
@@ -104,9 +105,9 @@ configured in a compatible way between both the local and 
remote side.
   link, the second sets the client side.
 
 --comp-noadapt
-  When used in conjunction with ``--comp-lzo``, this option will disable
-  OpenVPN's adaptive compression algorithm. Normally, adaptive compression
-  is enabled with ``--comp-lzo``.
+  **DEPRECATED** When used in conjunction with ``--comp-lzo``, this option
+  will disable OpenVPN's adaptive compression algorithm. Normally, adaptive
+  compression is enabled with ``--comp-lzo``.
 
   Adaptive compression tries to optimize the case where you have
   compression enabled, but you are sending predominantly incompressible
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 06/11] doc/man: Move --bind from generic to link section

[David Sommerseth]

This is more related to the configuration of the link, plus --nobind is
already placed in the link section.

Signed-off-by: David Sommerseth 
---
 doc/man-sections/generic-options.rst | 7 ---
 doc/man-sections/link-options.rst| 7 +++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/man-sections/generic-options.rst 
b/doc/man-sections/generic-options.rst
index cd048fa5..35985afc 100644
--- a/doc/man-sections/generic-options.rst
+++ b/doc/man-sections/generic-options.rst
@@ -22,13 +22,6 @@ which mode OpenVPN is configured as.
   This directive does not affect the ``--http-proxy`` username/password.
   It is always cached.
 
---bind keywords
-  Bind to local address and port. This is the default unless any of
-  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
-
-  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
-  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
-
 --cd dir
   Change directory to ``dir`` prior to reading any files such as
   configuration files, key files, scripts, etc. ``dir`` should be an
diff --git a/doc/man-sections/link-options.rst 
b/doc/man-sections/link-options.rst
index 595f7f69..ca719c75 100644
--- a/doc/man-sections/link-options.rst
+++ b/doc/man-sections/link-options.rst
@@ -3,6 +3,13 @@ Link Options
 This link options section covers options related to the connection between
 the local and the remote host.
 
+--bind keywords
+  Bind to local address and port. This is the default unless any of
+  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
+
+  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
+  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
+
 --float
   Allow remote peer to change its IP address and/or port number, such as
   due to DHCP (this is the default if ``--remote`` is not used).
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 00/11] man-page overhaul project

[David Sommerseth]

Hi,

This is the first real review round of the man-page overhaul project.
Since the n/groff based openvpn.8 format is fairly cumbersome to edit,
we agreed at the 2019 Hackathon in Trento to move the man page into
something more editing and management friendly.

This set of patches converts the openvpn.8 file into the
ReStructuredText format (.rst) which can easily be converted into both
man and html files using python-docutils.  The advantage of this format
is that it is easy to edit in any plain text editors and displays
reasonably well in any terminals.  And it will be easier to review
patches man page updates sent to the mailing list.

To avoid everyone building the OpenVPN source tarball to have the full
python stack available, the doc/Makefile.am file has been adopted to
generate the man and html files when we create the source tarball
we distribute in releases.  Only users only pulling down the source
directly from git will need to have python-docutils available.

As I worked my way through the man page, there were several things
which was less good.  Lots of options where misplaced in not related
sections, a few options where documented several places.  And lots
of the sections overlapped quite a bit.  From patch 5/11 splits
the whole man page into several smaller files; one file per section.
This is all tied into a single man-page/html file when running the
rst2man/rst2html tools.  The following patches just cleans up and
moves some options into more suitable sections.


I will continue to update my own git branch containing this work as
review comments come in until this is merged into master.  You can
find it here:

  https://gitlab.com/dazo/openvpn/-/tree/dev/man-reformatting/doc



kind regards,

David Sommerseth
OpenVPN Inc.



David Sommerseth (11):
  doc/man: Add an .rst formatted version of the man page
  doc/man: Replace old man page with generated man page
  doc/man: Move  profiles section
  doc/man: Remove unsupported options in OpenVPN 2.5
  doc/man: Split up and reorganize main man page
  doc/man: Move --bind from generic to link section
  doc/man: Move --dhcp-option from client to vpn-network section
  doc/man: Mark compression options as deprecated
  doc/man: Move some options from link to advanced section
  doc/man: Moved --reneg-* options to its own section
  doc/man: Cleaned up the examples

 .gitignore   |1 +
 INSTALL  |3 +-
 configure.ac |   15 +-
 doc/Makefile.am  |   56 +-
 doc/README.man   |   23 +
 doc/man-sections/advanced-options.rst|  107 +
 doc/man-sections/client-options.rst  |  355 +
 doc/man-sections/connection-profiles.rst |   75 +
 doc/man-sections/encryption-options.rst  |  136 +
 doc/man-sections/examples.rst|  241 +
 doc/man-sections/generic-options.rst |  436 ++
 doc/man-sections/inline-files.rst|   25 +
 doc/man-sections/link-options.rst|  410 ++
 doc/man-sections/log-options.rst |   74 +
 doc/man-sections/management-options.rst  |  136 +
 doc/man-sections/network-config.rst  |9 +
 doc/man-sections/pkcs11-options.rst  |   81 +
 doc/man-sections/plugin-options.rst  |   52 +
 doc/man-sections/protocol-options.rst|  228 +
 doc/man-sections/proxy-options.rst   |   66 +
 doc/man-sections/renegotiation.rst   |   53 +
 doc/man-sections/script-options.rst  |  807 +++
 doc/man-sections/server-options.rst  |  769 +++
 doc/man-sections/signals.rst |   30 +
 doc/man-sections/tls-options.rst |  643 ++
 doc/man-sections/unsupported-options.rst |   33 +
 doc/man-sections/vpn-network-options.rst |  531 ++
 doc/man-sections/windows-options.rst |  245 +
 doc/openvpn.8| 7631 --
 doc/openvpn.8.rst|  169 +
 30 files changed, 5794 insertions(+), 7646 deletions(-)
 create mode 100644 doc/README.man
 create mode 100644 doc/man-sections/advanced-options.rst
 create mode 100644 doc/man-sections/client-options.rst
 create mode 100644 doc/man-sections/connection-profiles.rst
 create mode 100644 doc/man-sections/encryption-options.rst
 create mode 100644 doc/man-sections/examples.rst
 create mode 100644 doc/man-sections/generic-options.rst
 create mode 100644 doc/man-sections/inline-files.rst
 create mode 100644 doc/man-sections/link-options.rst
 create mode 100644 doc/man-sections/log-options.rst
 create mode 100644 doc/man-sections/management-options.rst
 create mode 100644 doc/man-sections/network-config.rst
 create mode 100644 doc/man-sections/pkcs11-options.rst
 create mode 100644 doc/man-sections/plugin-options.rst
 create mode 100644 doc/man-sections/protocol-options.rst
 create mode 100644 doc/man-sections/proxy-options.rst
 create mode 100644 doc/man-sections/renegotiation.rst
 create mode 100644 doc/man-sections/script-options.rst
 create mode 100644 

Re: [Openvpn-devel] Summary of the community meeting (24th June 2020)

[David Sommerseth]

On 24/06/2020 13:10, Samuli Seppänen wrote:
[...snip...]
> Talked about the status of OpenVPN 2.5:
> 
> 
> 
> Ordex promised to have a look at the async-cc patches this week.
> Plaisthos, dazo and cron2 will follow-up on the review comments to get
> them resolved quickly.
> 
> OpenVPN 2.5 MSI looks surprisingly good. Mattock was able to produce
> tap-windows6 MSM ("merge module") which he then used to produce OpenVPN
> 2.5-based MSI installer. The only significant challenge is adding
> code-signing support to openvpn-build/generic.
> 
> Automating MSI builds also seems easier than expected, given that the
> existing openvpn-build buildslave can perform the actual build and push
> the artifacts to the Windows packager, which can then build and push the
> results to build.openvpn.net.
> 
> Code-vise 2.5-alpha1 is in a good shape, mainly missing

Just a nit-pick; we have not considered an alpha cycle for 2.5.  The first
beta will be released early July according to:


> - compression
> - async cc
> - VRF (which is quite trivial)
> 
> The auth-token fixes are corner-cases and it was agreed that that can be
> resolved between 2.5-alpha1 and 2.5-beta1.

That's also incorrect.  We will resolve these issues between the beta1 and rc1
releases.


-- 
kind regards,

David Sommerseth
OpenVPN Inc



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of the community meeting (24th June 2020)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 24th June 2020
Time: 11:30 CEST (9:30 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

cron2, dazo, lev, mattock, plaisthos and uip participated in this meeting.

---

Talked about the status of OpenVPN 2.5:



Ordex promised to have a look at the async-cc patches this week.
Plaisthos, dazo and cron2 will follow-up on the review comments to get
them resolved quickly.

OpenVPN 2.5 MSI looks surprisingly good. Mattock was able to produce
tap-windows6 MSM ("merge module") which he then used to produce OpenVPN
2.5-based MSI installer. The only significant challenge is adding
code-signing support to openvpn-build/generic.

Automating MSI builds also seems easier than expected, given that the
existing openvpn-build buildslave can perform the actual build and push
the artifacts to the Windows packager, which can then build and push the
results to build.openvpn.net.

Code-vise 2.5-alpha1 is in a good shape, mainly missing

- compression
- async cc
- VRF (which is quite trivial)

The auth-token fixes are corner-cases and it was agreed that that can be
resolved between 2.5-alpha1 and 2.5-beta1.

---

Talked about moving 2.3 into "oldstable" support mode. Previously we had
agreed to do that when 2.3.19 was released. However, 2.3.18 was released
a long while ago and there's nothing queued for 2.3.19. So it was
decided to move 2.3 to "oldstable" now instead of later.

---

Talked about starting the deprecation of "--ncp-disable". The idea is
that --ncp-disable has been mostly a debug feature and as we move
forward and want to be able to manage VPN security more from server
side, we want to abandon the possibility to ignore NCP.

This is tied with deprecation of --cipher for everything except p2p:

https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20062.html

Uip will bring these topics up with syzzer a.s.a.p.

---

Talked about OpenVPN 2.6. There are several things that are 2.6 material:

- Kernel acceleration module (client-side only beta ~next week)
- Work related to "making DNS handling nice"

It is possible that we'd also need to postpone the --ncp-disable and
--cipher changes.

However, it was agreed that doing a "quick" 2.6 release in, say, early
2021 is doable. It was also agreed that supporting both 2.5 and 2.6 as
"stable" for a while would be acceptable, as the changes would be mostly
in OpenVPN and the same release and automation tooling could be used for
both.

---

Talked about our use of IV_*. Agreed that rather than having tons of
IV_FOO=1 options IV_PROTO should be considered a wire-protocol-only
64-bit mask field and IV_FEAT would be a new 64-bit mask field
indicating which features the local side supports.

OpenVPN will need to handle a remote side not providing IV_FEAT.
Default behaviour when this field is missing must be documented.
IV_FEAT should be sent by OpenVPN 2.6 and newer. This approach allows
easier deprecation of features as well.

--

Full chatlog attached
(12:29:37) cron2: oh, a rare guest :-) - good morning uipko
(12:30:10) uip: morning
(12:30:21) dazo: hey!
(12:30:46) uip: trying to join the meetings more often
(12:31:59) dazo: that's great!
(12:32:34) plaisthos: hey
(12:32:39) lev__: hello
(12:32:52) uip: probably mainly reading/listening most of teh time ;)
(12:33:56) cron2: oh, feel free to take over and tell us what to do :-)  
(poking ordex and looking for lev__ ever so often starts to get boring)
(12:34:46) cron2: where is ordex anyway? :)
(12:35:09) dazo: Good question! :)
(12:35:36) mattock: hi!
(12:36:39) mattock: 2.5 updates first?
(12:37:11) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2020-06-24
(12:37:13) vpnHelper: Title: Topics-2020-06-24 – OpenVPN Community (at 
community.openvpn.net)
(12:37:32) cron2: first things first, and that's topic #1 :-)
(12:37:54) dazo: :)
(12:38:07) lev__: I will reply to plaisthos mail about optional compression, 
rebase my "fix some warnings" patch and write a test script/suite for testing 
async-cc (with the help of openvpn inc qa guy)
(12:38:24) dazo: So #1 means 
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25  :)
(12:38:25) vpnHelper: Title: StatusOfOpenvpn25 – OpenVPN Community (at 
community.openvpn.net)
(12:38:32) lev__: sorry, was busy lately with corp stuff and midsommer 
celebration
(12:38:58) dazo: corp/kernel module stuff ;-)
(12:39:25) cron2: lev__: happy dance :-)
(12:40:32) dazo: ordex promised to have a look at the async-cc patches this 
week.  plaisthos and I can follow-up on review comments, to get them resolved 
quickly
(12:41:20) cron2: I expect that this will be somewhat more work than "just 
review comments" 

Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs

[Dmitry Melekhov]

24.06.2020 14:12, Arne Schwabe пишет:

There are openvpn 2.3 clients in 3g routers which  are built without
ability to inform server about cipher, so server uses default cipher for
them,

in case you need to change default cipher on server you can't do this ,
because clients will not work, it is also impossible to change default
cipher on all clients at once,

so this is where ability to set default cipher on ccd helps.  All these
are explained in ticket.

Thanks to patch author we were able to change default cipher without
downtime.

btw, we still run such routers but can't do the same procedure because
patch is not compatible with 2.4.9 if for some reason current cipher
will became nonsecure as blowfish.


Allowing to be able to specify ncp-fallback-cipher from my proposal per
ccd if no NCP could be performed would also fix your use case, right?



Yes, sure!

Thank you!



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Gert Doering]

Hi,

On Tue, Jun 23, 2020 at 03:53:52PM -0400, Selva Nair wrote:
> > So what option do we want?
> >
> > --dhcp-option SEARCH
> > --dhcp-option DOMAIN-SEARCH
> > --dhcp-option SEARCH-DOMAIN
> 
> RFC 3397 calls it "Domain Search" so it has to be DOMAIN-SEARCH, in my
> view.  Platform scripts accepting other forms in foreign_option is up
> to them. We don't have to officially support that.

I like that argument.

(I do not care too much which string it is, in the end, but if we have
an RFC which has a name for it, and that name maps directly to one of
the candidates, this is a strong argument :-) )


On the "shall it be a single occurrance with multiple domains in it" or
"shall it be multiple occurances that are concatenated into a single DHCP
option which then has multiple domains in it", I do not have a truly
strong opinion.  So I'd go with "what Tunnelblick has", which is
"multiple occurances, a single string each".

He who goes first wins :-)

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 g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs

[Arne Schwabe]

> There are openvpn 2.3 clients in 3g routers which  are built without
> ability to inform server about cipher, so server uses default cipher for
> them,
> 
> in case you need to change default cipher on server you can't do this ,
> because clients will not work, it is also impossible to change default
> cipher on all clients at once,
> 
> so this is where ability to set default cipher on ccd helps.  All these
> are explained in ticket.
> 
> Thanks to patch author we were able to change default cipher without
> downtime.
> 
> btw, we still run such routers but can't do the same procedure because
> patch is not compatible with 2.4.9 if for some reason current cipher
> will became nonsecure as blowfish.
> 

Allowing to be able to specify ncp-fallback-cipher from my proposal per
ccd if no NCP could be performed would also fix your use case, right?

Arne



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] engine-key tests: make check_engine_keys.sh work with --enable-small

[Gert Doering]

Acked-by: Gert Doering 

Looks reasonable and does not break anything that already worked.

I could reproduce the --enable-small breakage with FreeBSD / 1.0.2s
here (interesting enough, not with Linux and 1.1.1*), and can confirm
that the patch fixes things.

Your patch has been applied to the master branch.

commit 013498ddfe0a2b7f8986e9edac2b9f062bdd5fd7 (HEAD -> master)
Author: James Bottomley 
Date:   Tue Jun 23 16:02:34 2020 -0700

engine-key tests: make check_engine_keys.sh work with --enable-small

Signed-off-by: James Bottomley 
Acked-by: Gert Doering 
Message-Id: <1592953354.2103.3.ca...@hansenpartnership.com>
URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20102.html
Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] engine-test on FreeBSD still not working

[Gert Doering]

Hi,

On Mon, Jun 22, 2020 at 08:40:15PM +0200, Gert Doering wrote:
> so
> 
> $(builddir)/openvpn.cnf: $(srcdir)/openvpn.cnf.in
>   sed "s|ABSBUILDDIR|$(abs_builddir)|" < $< > $@
> 
> should work.

It doesn't :-(

It worked for my tests of that patch, because the openssl.cnf generated
with "gmake test" was still in that directory - but today I created new
build directories to test --enable-small, and it doesn't - seems it
is not understanding $(builddir)/openvpn.cnf: as destination, nor does
"< $<" work.

What works is this:

openssl.cnf: $(srcdir)/openssl.cnf.in
sed "s|ABSBUILDDIR|$(abs_builddir)|" < $(srcdir)/openssl.cnf.in > $@

(tested both for clean in-tree and out-of-tree builds)

Can we have a new (LAST!!!) patch, please...

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 g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel