openvpn (2.6.0~git20221201-1) unstable; urgency=medium

    OpenVPN 2.6 has changed several defaults that might lead to connection
    problems, especially when the remote side runs an old OpenVPN version
    or cipher negotiations (NCP) are not in effect. This especially affects
    connecting to OpenVPN 2.3.x or earlier, and several limitations around
    old cryptographic algorithms and keys, mostly caused by the switch to
    OpenSSL 3.0

    These include but are not limited to

    - weak SHA1 or MD5 signature on certificates
    - 1024 bit RSA certificates, 1024 bit DH parameters, other weak keys
    - Use of a legacy or deprecated cipher (e.g. 64bit block ciphers)
    - remote OpenVPN version not supporting TLS 1.2 or later

    Please read the release notes installed as
    /usr/share/doc/openvpn/changelog.gz.

    With an optional kernel module (available as package openvpn-dco-dkms)
    the data plane encryption/decryption is performed in kernel space,
    reducing page copy overhead and increasing the throughput significantly.
    DCO (Data Channel Offload) should work with most configurations. In
    case of issues, please try running OpenVPN with --disable-dco first.

 -- Bernhard Schmidt <berni@debian.org>  Mon, 23 May 2022 11:04:30 +0200

openvpn (2.4.9-3) unstable; urgency=medium

    To ensure the functionality of OpenVPN connections during an update,
    OpenVPN is not restarted after the update since this version.

    Please restart OpenVPN or reboot the computer manually after the update.

 -- Jörg Frings-Fürst <debian@jff.email>  Sat, 02 May 2020 18:14:36 +0200

openvpn (2.4.0-4) unstable; urgency=medium

    If you're upgrading a previous OpenVPN installation, you should check your
    current CRL file expiraton date. "crl-verify" option now also checks that.
    Regenerate your CRL file if the expiration date is in the past or your
    clients won't be able to connect.

    OpenVPN 2.4 will try to connect using IPv6 first if you're using a hostname
    with both A and AAAA entries, if your VPN server is still running a
    previous (<2.4) version a long wait may occur until your 2.4 client tries
    with the IPv4 address.

 -- Alberto Gonzalez Iniesta <agi@inittab.org>  Thu, 02 Feb 2017 14:15:42 +0100

openvpn (2.4.0-1) unstable; urgency=medium
    
    OpenVPN 2.4 removed tls-remote option. Current setups using that option
    will fail to work. Update your configuration to use verify-x509-name
    instead.

 -- Alberto Gonzalez Iniesta <agi@inittab.org>  Tue, 27 Dec 2016 22:50:20 +0100

openvpn (2.3~rc1-1) experimental; urgency=low
    
    auth-pam and down-root plugins renamed to:
    openvpn-plugin-auth-pam.so
    openvpn-plugin-down-root.so

 -- Alberto Gonzalez Iniesta <agi@inittab.org>  Tue, 06 Nov 2012 13:22:13 +0100

openvpn (2.1~rc15-1) unstable; urgency=low

    The openvpn utility changed its handling of pkcs11 certificates when it
    switched from built-in code to the pkcs11-helper library (package
    libpkcs11-helper1 on Debian). This means that you will have to update your
    openvpn configuration files if you are using such certificates. For
    example, a stanza in a configuration file might previously have referred to
    a given pkcs11 certificate like this:

      pkcs11-providers /usr/lib/opensc-pkcs11.so
      pkcs11-slot-type id
      pkcs11-slot 0
      pkcs11-id-type label
      pkcs11-id "YOUR_LABEL"

    This stanza has to be rewritten now in the following way:

      pkcs11-providers /usr/lib/opensc-pkcs11.so
      pkcs11-id 'YOUR_PKCS11_SERIALIZED_ID'

    The pkcs11-slot, pkcs11-slot-type, pkcs11-id-type options are obsolete;
    a long ID string that is unique for each certificate is now used as the
    only identifier. Note that YOUR_PKCS11_SERIALIZED_ID will almost
    certainly be different from YOUR_LABEL that you used previously with the
    pkcs11-id option. To find out the correct serialized ID(s) for your
    certificate(s), you have to query the pkcs11-provider library:

      $ openvpn --show-pkcs11-ids /usr/lib/opensc-pkcs11.so 
    
    The following objects are available for use.
    Each object shown below may be used as parameter to --pkcs11-id option
    please remember to use single quote mark.
    
      Certificate
           DN:             /CN=YOUR_USER
           Serial:         SERIAL_NUMBER
           Serialized id:  YOUR_PKCS11_SERIALIZED_ID

    You have to paste YOUR_PKCS11_SERIALIZED_ID as seen in this output into
    your openvpn configuration file and make sure that the string is enclosed
    in single quotation marks.

    The example above assumes that your cryptographic token can be accessed
    via the opensc-pkcs11.so library from libopensc2. If you have to use
    another library, for example a proprietary driver from the vendor of your
    token, then you have to adapt both the stanza in the configuration file
    and the path given on the command line accordingly.

    Florian Kulzer

 -- Alberto Gonzalez Iniesta <agi@inittab.org>  Thu, 30 Apr 2009 12:35:05 +0200

openvpn (2.1~rc9-3) unstable; urgency=low

    Calling of external commands/scripts 

    Starting with version 2.1~rc9, openvpn has a new option to control the
    ability to execute external commands (--script-security).

    By default (script-security 1) it will only allow the execution of
    built-in commands (ip, ifconfig, route,...). If you require the execution
    of external commands, such as /etc/openvpn/update-resolv-conf, you'll have
    to include the following option in your configuration file:
    script-security 2

 -- Alberto Gonzalez Iniesta <agi@inittab.org>  Sat, 16 Aug 2008 13:34:24 +0200