From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: OpenVPN no more --client-(dis)connect scripts can be executed Date: Mon, 12 Oct 2020 17:46:47 +0200 Message-ID: <96d003e3-cbc3-8467-8fc8-933f8bf9f099@gmail.com> In-Reply-To: <54805E1E-A21B-4F1F-B390-4021709842E0@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1194829708494662061==" List-Id: --===============1194829708494662061== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=3Dde.blinkt.openvpn&hl=3Den_US&gl=3DUS Regards, Adolf. On 12/10/2020 16:23, Michael Tremer wrote: > Hello, >=20 > Has OpenVPN finally been integrated into stock Android, or is this a custom= version (like Lineage) or a userspace application? >=20 > Best, > -Michael >=20 >> On 12 Oct 2020, at 12:28, Adolf Belka wrote: >> >> Hi >> >> On 12/10/2020 12:45, Michael Tremer wrote: >>> Hi, >>>> On 11 Oct 2020, at 15:16, ummeegge 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=C2=B4s great :-) , would you like to step into some more testing ro= unds :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 som= e 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 >>>>>>> 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 =E2=80=94cipher and start adding =E2=80=94data-ciphers. A select b= ox 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#Serverver= sion2.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 m= obile 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 a= nd 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 p= eople to move away from BF, DES, SEED, etc. And then remove these in around M= arch-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=E2=80=99s start with the ciphers/NCP ones first, because that wi= ll be released earlier. >>> Changing ns-cert-type on the server side should still allow clients to co= nnect 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/ciphe= r-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 c= ould 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= =E2=80=99t 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=E2=80=99t always possible. In this case: You c= annot simply change the cipher unless you can update all your clients at the = same time. People=E2=80=99s 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 =E2=80=9Csubnet=E2=80=9D, 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 =E2=80=9Cifconfig-push=E2= =80=9D won=E2=80=99t >>>>>> 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=E2=80=99t 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=E2=80=99t be able to support it all the way back to Co= re >>>>>> 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=C2=B4t 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=C2=B4t 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-rfc32= 80-issue/2326 >>>> which i haven=C2=B4t test and i am also not a friend of it since it most= ly >>>> includes also the old values of keylengths 1024 bit host and 2048 bit >>>> for the root certificate --> shouldn=C2=B4t we expand the actual values >>>> 2048/4096 may too ? >>> Oh. This is bad. We need to script the changes then. Otherwise we won=E2= =80=99t be able to encourage users to update. >>> Having shorter key lengths is a compromise that we have to make in my opi= nion. >>>> >>>>>> >>>>>> 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__= =3Dc269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkL= W4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karw= sEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDS= rHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZ= Sg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q >>> We cannot change this, because it is not being negotiated between the cli= ent 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 s= ince 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 t= hem a own openvpn-functions.pl like it was done with ids-functions.pl, this c= leaned 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 >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Am Mittwoch, den 07.10.2020, 10:22 +0100 schrieb Michael >>>>>>>>>> Tremer: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 7 Oct 2020, at 10:21, ummeegge >>>>>>>>>>>> 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=E2=80=99t 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=3Dipfire-2.x.git;a=3Dcommit;h=3D708f2b7368cc8f= bd54a06ca66337ebdcc26b58b4 >>>>>>>>>>>>>>>> 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=C2=B4s 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 >=20 --===============1194829708494662061==--