Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Adolf Belka <ahb.ipfire@gmail.com>]

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

Hi Michael,

No this is not integrated into stock android.

It is an app from the Google Store https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=en_US&gl=US


Regards,
Adolf.

On 12/10/2020 16:23, Michael Tremer wrote:
> Hello,
> 
> Has OpenVPN finally been integrated into stock Android, or is this a custom version (like Lineage) or a userspace application?
> 
> Best,
> -Michael
> 
>> On 12 Oct 2020, at 12:28, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>
>> Hi
>>
>> On 12/10/2020 12:45, Michael Tremer wrote:
>>> Hi,
>>>> On 11 Oct 2020, at 15:16, ummeegge <ummeegge(a)ipfire.org> wrote:
>>>>
>>>> Hi all,
>>>> sorry for the late replay but things are going to be a little chaotic
>>>> this days :-) .
>>>>
>>>> Am Donnerstag, den 08.10.2020, 19:18 +0200 schrieb Adolf Belka:
>>>>> Hi Michael,
>>>>>
>>>>> I suspect you are right about my optimism but that is my nature :)
>>>> That´s great :-) , would you like to step into some more testing rounds :D -->
>>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173
>>>> ?
>>> Can we not keep development stuff on the development list please?
>>> community.ipfire.org is a support portal and loads of people download all sorts of things and crash their systems with it, or never update them. I am all for having people involved in testing, but only after we have reached some sort of standard that is good enough for a larger group of testers.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Adolf.
>>>>>
>>>>>
>>>>> On 08/10/2020 16:26, Michael Tremer wrote:
>>>>>> Hello boys,
>>>>>>
>>>>>> Great conversation here, but unfortunately this is going to be
>>>>>> messy...
>>>>>>
>>>>>>> On 8 Oct 2020, at 14:23, Adolf Belka <ahb.ipfire(a)gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> On 08/10/2020 10:11, ummeegge wrote:
>>>>>>>> Good morning Michael,
>>>>>>>>
>>>>>>>> Am Mittwoch, den 07.10.2020, 13:38 +0100 schrieb Michael
>>>>>>>> Tremer:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> That reads awful.
>>>>>>>>>
>>>>>>>>
>>>>>>>> yes indeed it also feels exactly like this if there is the need
>>>>>>>> to
>>>>>>>> handle it for the community in a good proper way.
>>>>>>>> I really can not understand why directives like --cipher needs
>>>>>>>> to be
>>>>>>>> changed to --data-ciphers, from the OpenVPN perspective it
>>>>>>>> might be a
>>>>>>>> better understanding if there is a difference between control
>>>>>>>> channel
>>>>>>>> and data channel encryption but from the users point of view
>>>>>>>> with
>>>>>>>> several hundreds clients it is overkill since every client
>>>>>>>> config needs
>>>>>>>> then to be changed.
>>>>>>>>
>>>>>>>
>>>>>>> I am not sure that this is as major an issue as you indicate,
>>>>>>> although I could very easily be wrong, so I thought it was
>>>>>>> worthwhile to give my input.
>>>>>>>
>>>>>>> Firstly, the --cipher option has been indicated that it will be
>>>>>>> deprecated (
>>>>>>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation) but
>>>>>>> without any date. It does not show up yet in the Deprecated
>>>>>>> options page (
>>>>>>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions)
>>>>>>> This states "we will try to keep an up-to-date list of all
>>>>>>> options       we have deprecated, when they will be removed, the
>>>>>>> new alternative approach and the reasoning behind removing the
>>>>>>> option".
>>>>>>
>>>>>> So, I suppose we will have to re-implement the whole cipher
>>>>>> selection on our side then. We will have to remove --ncp-disable
>>>>>> and —cipher and start adding —data-ciphers. A select box where
>>>>>> multiple algorithms can be chosen (like in IPsec) is probably the
>>>>>> best option, and we can select AES-{256,128}-{GCM,CBC} and
>>>>>> potentially BF if we find a user that is still on it. We would have
>>>>>> to deprecate the latter already though.
>>>>>>
>>>>>> We should then be able to support a maximum of clients according to
>>>>>> this
>>>>>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation#Serverversion2.5
>>>>
>>>> As far as i can see now with the testing results from RC2, we can run
>>>> the old configurations like before which includes a lot of deprecation
>>>> warnings in the logs but it should nevertheless work... The rest, like
>>>> Michael mentioned it, should be done better earlier than later.
>>>> But besides of that i am really really not sure what happens with the
>>>> actual version on Smartphones since i do not uses such.
>>> I do not think that too many people use OpenVPN on mobile devices because it does not provide a native client and all clients that I have tried were a little fiddly.
>>
>>
>> I use OpenVPN on my Samsung phone. I am using the OpenVPN for Android app and that seems to work very well for me. So I would be happy to test out my mobile link on any updates to OpenVPN that reach the appropriate testing stage.
>>
>>
>>> I think we should start dropping old crypto now. This is an easy change and we can get people on AES. That will be with us for the foreseeable future.
>>> I am happy to either show a warning for about 6 months and to encourage people to move away from BF, DES, SEED, etc. And then remove these in around March-April time for good. We have already marked those ciphers as weak and I would propose to remove all of them.
>>>>>>
>>>>>> Under no circumstances is it feasible that we require the client to
>>>>>> change. We have users out there with hundreds and hundreds of
>>>>>> connections. It simply is not possible for them to change them. It
>>>>>> will take years. OpenVPN simply seems to be forgetting this.
>>>>>>
>>>>>>> I think that means that it will likely not be removed till
>>>>>>> OpenVPN v2.7 at earliest.
>>>> It was a fast way from 2.3 to 2.4 and am sure the way to 2.7 will be
>>>> done faster and there are indeed a lot of configurations out there
>>>> which uses --ns-cert-type even there are warnings findable in the WUI.
>>>>
>>>> Apart from that according to the log messages i think we have also some
>>>> stuff to solve until 2.6 like the --ncp-disable deprecation -->
>>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2
>>>> ?
>>> Yes, let’s start with the ciphers/NCP ones first, because that will be released earlier.
>>> Changing ns-cert-type on the server side should still allow clients to connect that use an older version, am I right?
>>>>
>>>>>>
>>>>>> Potentially, but we need to prepare ourselves and our users before
>>>>>> that. Whenever we release 2.7, it will simply be too late, because
>>>>>> then the deprecated options have already gone. We need to act now,
>>>>>> and make sure that a client with a modern configuration can connect
>>>>>> to a server - now and in the future.
>>>>>>
>>>>>> I find it brilliant that OpenVPN has a whole page to describe the
>>>>>> deprecation of one option. Although I agree with the cipher
>>>>>> negotiation, there has to be a migration path.
>>>> Yes, me too..
>>>>
>>>>>>
>>>>>>> Secondly
>>>>>>> https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst
>>>>>>> states "OpenVPN 2.5 will only allow the ciphers specified in --
>>>>>>> data-ciphers.       To ensure backwards compatibility also if a
>>>>>>> cipher is specified using the --cipher option it is automatically
>>>>>>> added to this list. If both options are unset the default is AES-
>>>>>>> 256-GCM:AES-128-GCM."
>>>> Like above explained, The last tests here (RC2) did not have problems
>>>> with the --cipher directive even the log fires the warning that it is
>>>> deprecated... but am not sure how the 2.5.0 release behavior is since
>>>> the beta releases do have noticable changes to the RC ones and again i
>>>> have no experiences with Smartphones and the new version...
>>>>
>>>>>>>
>>>>>>> In my OpenVPN for Android client this is what happens. --cipher
>>>>>>> has AES-256-GCM from my client config that I transferred from
>>>>>>> IPFire but also has --data-ciphers with AES-256-GCM:AES-128-
>>>>>>> GCM:AES-256-GCM, so the contents of my --cipher have been copied
>>>>>>> across to the end of --data-ciphers.
>>>> That might be interessting if the server do not reflects this ? My
>>>> testings involves only PCs/laptops which uses the config files without
>>>> own interactions/enhancements...
>>> That is not a big problem. Just make clear what you tested and what you could not test when posting patches. Then, somebody else can fill in the gaps.
>>>>
>>>>>>>
>>>>>>> If users are using a strong encryption, such as AES-256-GCM then
>>>>>>> this is the default anyway. If people have a weaker encryption in
>>>>>>> --cipher such as BF-CBC, CAST or RC2, then currently that will
>>>>>>> also be copied across to --data-ciphers but from OpenVPN v2.6
>>>>>>> those encryptions will not be copied across as they have been
>>>>>>> deprecated as too weak for some time. The other encryptions will
>>>>>>> still be copied across from --cipher to --data-cipher.
>>>> If someone uses those algorithms they do not care really about
>>>> security, IPFire lined that out as "(weak)" but in fact they are
>>>> broken, but the differences between Smartphones and regular clients are
>>>> may important to focus on...
>>>>
>>>>>>>
>>>>>>> Eventually, when --cipher is removed (timing still to be defined)
>>>>>>> then users may need to ensure that --data-ciphers contains the
>>>>>>> encryptions they want to use if they are not using the default of
>>>>>>> AES-256-GCM and AES-128-GCM on the IPFire OpenVPN server.
>>>> There is meanwhile more, 2.5 offers also CHACHA20-POLY1305 for the data
>>>> channel but also BLAKE2 and SHA3 for the controll channel which are
>>>> potential candiates for a future default ?!
>>> To be honest, I do not care about them. AES has the advantage of hardware acceleration on all platforms and it is probably too early to roll out SHA3 as default.
>>> We can add them after we got rid of the legacy ones and finished the NCP migration. Tackle one problem at a time. If we change too many things, we won’t be able to test things easily.
>>>>>>>
>>>>>>> Having a blog post about the removal of BF-CBC and CAST5-CBC with
>>>>>>> OpenVPN v2.6 and the need for anyone using those ciphers would be
>>>>>>> a good idea because anyone concerned about their VPN security
>>>>>>> would not want to be using those ciphers any more.
>>>> May a good idea even this has been meanwhile longer time ago announced
>>>> but also outlined in the WUI.
>>>>
>>>>>>>
>>>>>>> So, yes the deprecation of --cipher will eventually give a need
>>>>>>> to update client configs if the default strong ciphers are not
>>>>>>> being used but the timing is not yet critical. We need to keep an
>>>>>>> eye on the Deprecated Options page on the OpenVPN Wiki.
>>>>>>
>>>>>> Not critical, but clients are normally not being updated. And if,
>>>>>> very very slowly.
>>>> Exactly! Or in other words, who read the documentation/blog_posts and
>>>> acts like recommended ?!
>>> Some people do, but it isn’t always possible. In this case: You cannot simply change the cipher unless you can update all your clients at the same time. People’s hands are tied.
>>>>
>>>>>>>
>>>>>>> Please let me have your feedback, especially if I have made an
>>>>>>> error in my analysis and interpretation.
>>>>>>
>>>>>> No, I think you are just a little bit more optimistic than I am :)
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Adolf.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Also, if --topology net30 will be dropped by OpenVPN we need to
>>>>>>>> modify
>>>>>>>> every CCD configuration which uses --ifconfig-push out there
>>>>>>>> otherwise
>>>>>>>> we get an
>>>>>>>>
>>>>>>>> Wed Oct  7 17:14:29 2020 /sbin/ip addr add dev tun0 10.18.5.2/-
>>>>>>>> 1 broadcast 255.255.255.254
>>>>>>>> Error: any valid prefix is expected rather than "10.18.5.2/-1".
>>>>>>>> Wed Oct  7 17:14:29 2020 Linux ip addr add failed: external
>>>>>>>> program exited with error status: 1
>>>>>>>> Wed Oct  7 17:14:29 2020 Exiting due to fatal error
>>>>>>>>
>>>>>>>> , which logic should we use to distribute the IPs?! Did some
>>>>>>>> tests with
>>>>>>>> new CCD configs and topology subnet but run in other currently
>>>>>>>> not
>>>>>>>> identifiable problems like:
>>>>>>>>
>>>>>>>> Wed Oct  7 17:19:44 2020 /sbin/ip route add 192.168.5.0/24 via
>>>>>>>> 10.25.18.1
>>>>>>>> Error: Nexthop has invalid gateway.
>>>>>>>> Wed Oct  7 17:19:44 2020 ERROR: Linux route add command failed:
>>>>>>>> external program exited with error status: 2
>>>>>>>> Wed Oct  7 17:19:44 2020 Initialization Sequence Completed
>>>>>>
>>>>>> This seems to be broken.
>>>>>>
>>>>>> If we change to “subnet”, we would simply lease one IP address from
>>>>>> the allocated subnet to this client and that is it.
>>>>>>
>>>>>> I could not find anything that tells us that “ifconfig-push” won’t
>>>>>> work any more. However, it currently looks like this for a client:
>>>>>>
>>>>>> ifconfig-push 10.191.0.2 10.191.0.1
>>>>>>
>>>>>> The first IP address is the one that the user has selected for the
>>>>>> client and the second one is the one that is getting assigned to
>>>>>> the server.
>>>> I think there is more but we should deliver that one may to bugzilla
>>>> then and may it is possibly also a good idea to wait until the release
>>>> and check for potential changes ?
>>> We should start now on what we can do now. Why wait?
>>>>
>>>>>>
>>>>>> The documentation says that the second part has to be replaced by
>>>>>> the subnet mask.
>>>>>>
>>>>>> So that means we will have to migrate all those files manually when
>>>>>> the update is being applied. This can all be done on the server and
>>>>>> therefore won’t break the client configuration. Phew.
>>>>>>
>>>>>>>>
>>>>>>>> which seems to be a kernel or an iproute problem on the client
>>>>>>>> system
>>>>>>>> -->
>>>>>>>> https://community.openvpn.net/openvpn/ticket/1086
>>>>>>>>
>>>>>>>> even it connects.
>>>>>>>>
>>>>>>>> There is a little time for the most stuff left cause this will
>>>>>>>> be
>>>>>>>> initially a problem with OpenVPN version 2.6 , also, the tested
>>>>>>>> 2.5
>>>>>>>> versions are RCs and so may some changes can happen too but
>>>>>>>> there is
>>>>>>>> currently not much to say from my side except arrgh .
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Can we please create individual tickets for the individual
>>>>>>>>> problems
>>>>>>>>> and assign someone to work on those (I assume that would be
>>>>>>>>> you Erik
>>>>>>>>> :D).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Will go for it but as far as i can see we would need possibly
>>>>>>>> some more
>>>>>>>> help, may Alexander is around for the CCD section ?
>>>>>>
>>>>>> Yes, it is a good idea to reach out to him as soon as we have a
>>>>>> plan.
>>>>>>
>>>>>>>>> We need to coordinate this and future-proof OpenVPN as best
>>>>>>>>> as we
>>>>>>>>> can, but it looks like we will break client configuration -
>>>>>>>>> again.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As far as i can see it now, yes we will break client
>>>>>>>> configurations
>>>>>>>> finally with OpenVPN version 2.6 .
>>>>>>
>>>>>> We probably won’t be able to support it all the way back to Core
>>>>>> Update 1. But I suppose we need to try and prepare the currently
>>>>>> issued configuration files so that clients will work when they
>>>>>> update soon.
>>>> 2.5 was working with RC2 also with the conventional configs as far as i
>>>> can see but i haven´t tested Smartphones since i do not use them...
>>>>
>>>>>>
>>>>>>>>> If we have to do that and there is no way to avoid it, we
>>>>>>>>> need to
>>>>>>>>> make our users aware of that of course and give the enough
>>>>>>>>> time to
>>>>>>>>> prepare for this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, we did that before and i hate it to say but probably we
>>>>>>>> need to
>>>>>>>> make this again if the OpenVPN update politics go this way. But
>>>>>>>> may
>>>>>>>> someone here have another idea or i haven´t interpret the
>>>>>>>> upcoming
>>>>>>>> changes incorrectly since there is already no manpage/wiki for
>>>>>>>> OpenVPN
>>>>>>>> 2.5 around...
>>>>>>
>>>>>> Questions from me:
>>>>>>
>>>>>> How do we migrate ns-cert-type?
>>>> Create a new PKI with the approrpiate openssl.cnf entries.
>>>> But there was also an idea to manually repair the PKI -->
>>>>
>>>> https://community.ipfire.org/t/solved-manual-repair-pki-on-openvpn-rfc3280-issue/2326
>>>> which i haven´t test and i am also not a friend of it since it mostly
>>>> includes also the old values of keylengths 1024 bit host and 2048 bit
>>>> for the root certificate --> shouldn´t we expand the actual values
>>>> 2048/4096 may too ?
>>> Oh. This is bad. We need to script the changes then. Otherwise we won’t be able to encourage users to update.
>>> Having shorter key lengths is a compromise that we have to make in my opinion.
>>>>
>>>>>>
>>>>>> How do we migrate comp-lzo/compress?
>>>> Should we really do this ? Since Voracle OpenVPN disables compression by default -->
>>>> https://community.openvpn.net/openvpn/wiki/VORACLE?__cf_chl_jschl_tk__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q
>>> We cannot change this, because it is not being negotiated between the client and server. So we have to keep it enabled for users where it is currently enabled.
>>> Again, we have no choice.
>>>>
>>>>>>
>>>>>> We should be fine for the rest.
>>>> :-)
>>>>
>>>>>>
>>>>>> How do we get rid of this ugly certificate warning?
>>>> Which one you mean ?
>>> The RFC something one at the top.
>>>>
>>>>>>
>>>>>> Before we start hacking the CGI, should we try to clean up some
>>>>>> code? For example does the whole page not take the /24 format for
>>>>>> subnets. That is a bit annoying.
>>>> Pretty much, am happy if someone comes around with some help with this since there has been also some work been made, same with the RRD stuff...
>>>> Have also for example outsorted the functions in ovpnmain.cgi and gave them a own openvpn-functions.pl like it was done with ids-functions.pl, this cleaned up the cgi also a little and is already available...
>>>>>>
>>>>
>>>>
>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I cannot even say how annoying this is - again. But we must
>>>>>>>>> try our
>>>>>>>>> best.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I feel you very good am not sure how to handle this without
>>>>>>>> hassle the
>>>>>>>> users around... sad to say but this is not a glorious job.
>>>>>>
>>>>>> Together we will get it done :)
>>>> Great :-) .
>>>>>>
>>>>>> -Michael
>>>>>>
>>>>>>>>> -Michael
>>>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Erik
>>>>>>>>
>>>>>>>>
>>>>>>>>>> On 7 Oct 2020, at 11:37, ummeegge <ummeegge(a)ipfire.org>
>>>>>>>>>>   wrote:
>>>>>>>>>>
>>>>>>>>>> Am Mittwoch, den 07.10.2020, 10:22 +0100 schrieb Michael
>>>>>>>>>> Tremer:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 7 Oct 2020, at 10:21, ummeegge <ummeegge(a)ipfire.org>
>>>>>>>>>>>>   wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Michael,
>>>>>>>>>>>>
>>>>>>>>>>>> Am Mittwoch, den 07.10.2020, 09:20 +0100 schrieb
>>>>>>>>>>>> Michael
>>>>>>>>>>>> Tremer:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oh so this is a custom thing?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously most users won’t use this. If you care much
>>>>>>>>>>>>> about
>>>>>>>>>>>>> your
>>>>>>>>>>>>> custom script, you can write a script that searches a
>>>>>>>>>>>>> directory
>>>>>>>>>>>>> and
>>>>>>>>>>>>> calls all scripts in it (like
>>>>>>>>>>>>> /etc/init.d/networking/red.up/
>>>>>>>>>>>>> and
>>>>>>>>>>>>> /etc/init.d/networking/red.down/).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> OK, will give it a try.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Another great example how OpenVPN breaks running
>>>>>>>>>>>>> installations.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, and there are comming some exiting new examples
>>>>>>>>>>>> with the
>>>>>>>>>>>> upcoming
>>>>>>>>>>>> releases 8-| ...
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Like what?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> e.g. this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2
>>>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/8
>>>>>>>>>> checkout the deprecated options :-\
>>>>>>>>>>
>>>>>>>>>>> -Michael
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> -Michael
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6 Oct 2020, at 14:26, ummeegge <
>>>>>>>>>>>>>> ummeegge(a)ipfire.org>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am Dienstag, den 06.10.2020, 12:58 +0100 schrieb
>>>>>>>>>>>>>> Michael
>>>>>>>>>>>>>> Tremer:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why do you have more than one client-
>>>>>>>>>>>>>>> connnect/disconnect
>>>>>>>>>>>>>>> script
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> your configuration?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In this case it is a email which will be fired if
>>>>>>>>>>>>>> someone
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> (dis)connected but there are plenty of potential
>>>>>>>>>>>>>> possibilities.
>>>>>>>>>>>>>> This
>>>>>>>>>>>>>> one is not specified for my use case but may for
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> OpenVPN
>>>>>>>>>>>>>> scripting
>>>>>>>>>>>>>> architecture in IPFire in general.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Erik
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Michael
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 5 Oct 2020, at 16:59, ummeegge <
>>>>>>>>>>>>>>>> ummeegge(a)ipfire.org>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>> am currently in testing scenario with the new
>>>>>>>>>>>>>>>> OpenVPN-
>>>>>>>>>>>>>>>> 2.5_rc2
>>>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>>>> additional --client-connect/--client-disconnect
>>>>>>>>>>>>>>>> script.
>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> release of OpenVPN metrics -->
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>>>>>>>> the new OpenVPN version lined out that only one
>>>>>>>>>>>>>>>> script
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> executed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> openvpnserver[15373]: Multiple --client-connect
>>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>>> defined.  The
>>>>>>>>>>>>>>>> previously configured script is overridden.
>>>>>>>>>>>>>>>> openvpnserver[15373]: Multiple --client-
>>>>>>>>>>>>>>>> disconnect
>>>>>>>>>>>>>>>> scripts
>>>>>>>>>>>>>>>> defined.  The previously configured script is
>>>>>>>>>>>>>>>> overridden.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> so a question arises (beneath a lot´s others
>>>>>>>>>>>>>>>> which are
>>>>>>>>>>>>>>>> here
>>>>>>>>>>>>>>>> OT),
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>> we make it possible to execute more then one --
>>>>>>>>>>>>>>>> (dis)connect
>>>>>>>>>>>>>>>> script
>>>>>>>>>>>>>>>> ? If
>>>>>>>>>>>>>>>> so, are there may some ideas for this ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Erik
>