From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN no more --client-(dis)connect scripts can be executed Date: Mon, 12 Oct 2020 15:23:23 +0100 Message-ID: <54805E1E-A21B-4F1F-B390-4021709842E0@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9040004655072811842==" List-Id: --===============9040004655072811842== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Has OpenVPN finally been integrated into stock Android, or is this a custom v= ersion (like Lineage) or a userspace application? Best, -Michael > On 12 Oct 2020, at 12:28, Adolf Belka wrote: >=20 > Hi >=20 > On 12/10/2020 12:45, Michael Tremer wrote: >> Hi, >>> On 11 Oct 2020, at 15:16, ummeegge wrote: >>>=20 >>> Hi all, >>> sorry for the late replay but things are going to be a little chaotic >>> this days :-) . >>>=20 >>> Am Donnerstag, den 08.10.2020, 19:18 +0200 schrieb Adolf Belka: >>>> Hi Michael, >>>>=20 >>>> 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 rou= nds :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 a= ll 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. >>>>=20 >>>>=20 >>>> Regards, >>>> Adolf. >>>>=20 >>>>=20 >>>> On 08/10/2020 16:26, Michael Tremer wrote: >>>>> Hello boys, >>>>>=20 >>>>> Great conversation here, but unfortunately this is going to be >>>>> messy... >>>>>=20 >>>>>> On 8 Oct 2020, at 14:23, Adolf Belka >>>>>> wrote: >>>>>>=20 >>>>>> Hi Erik, >>>>>>=20 >>>>>> On 08/10/2020 10:11, ummeegge wrote: >>>>>>> Good morning Michael, >>>>>>>=20 >>>>>>> Am Mittwoch, den 07.10.2020, 13:38 +0100 schrieb Michael >>>>>>> Tremer: >>>>>>>=20 >>>>>>>> Hello, >>>>>>>>=20 >>>>>>>> That reads awful. >>>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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". >>>>>=20 >>>>> 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 bo= x 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. >>>>>=20 >>>>> We should then be able to support a maximum of clients according to >>>>> this >>>>> https://community.openvpn.net/openvpn/wiki/CipherNegotiation#Serververs= ion2.5 >>>=20 >>> 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. >=20 >=20 > I use OpenVPN on my Samsung phone. I am using the OpenVPN for Android app a= nd that seems to work very well for me. So I would be happy to test out my mo= bile link on any updates to OpenVPN that reach the appropriate testing stage. >=20 >=20 >> I think we should start dropping old crypto now. This is an easy change an= d 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 pe= ople to move away from BF, DES, SEED, etc. And then remove these in around Ma= rch-April time for good. We have already marked those ciphers as weak and I w= ould propose to remove all of them. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>> 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. >>>=20 >>> 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 wil= l be released earlier. >> Changing ns-cert-type on the server side should still allow clients to con= nect that use an older version, am I right? >>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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.. >>>=20 >>>>>=20 >>>>>> 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... >>>=20 >>>>>>=20 >>>>>> 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 co= uld not test when posting patches. Then, somebody else can fill in the gaps. >>>=20 >>>>>>=20 >>>>>> 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... >>>=20 >>>>>>=20 >>>>>> 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 a= s default. >> We can add them after we got rid of the legacy ones and finished the NCP m= igration. Tackle one problem at a time. If we change too many things, we won= =E2=80=99t be able to test things easily. >>>>>>=20 >>>>>> 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. >>>=20 >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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 ca= nnot simply change the cipher unless you can update all your clients at the s= ame time. People=E2=80=99s hands are tied. >>>=20 >>>>>>=20 >>>>>> Please let me have your feedback, especially if I have made an >>>>>> error in my analysis and interpretation. >>>>>=20 >>>>> No, I think you are just a little bit more optimistic than I am :) >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> , 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: >>>>>>>=20 >>>>>>> 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 >>>>>=20 >>>>> This seems to be broken. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> ifconfig-push 10.191.0.2 10.191.0.1 >>>>>=20 >>>>> 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? >>>=20 >>>>>=20 >>>>> The documentation says that the second part has to be replaced by >>>>> the subnet mask. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>>>=20 >>>>>>> which seems to be a kernel or an iproute problem on the client >>>>>>> system >>>>>>> --> >>>>>>> https://community.openvpn.net/openvpn/ticket/1086 >>>>>>>=20 >>>>>>> even it connects. >>>>>>>=20 >>>>>>> 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 . >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> 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). >>>>>>>>=20 >>>>>>>=20 >>>>>>> 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 ? >>>>>=20 >>>>> Yes, it is a good idea to reach out to him as soon as we have a >>>>> plan. >>>>>=20 >>>>>>>> We need to coordinate this and future-proof OpenVPN as best >>>>>>>> as we >>>>>>>> can, but it looks like we will break client configuration - >>>>>>>> again. >>>>>>>>=20 >>>>>>>=20 >>>>>>> As far as i can see it now, yes we will break client >>>>>>> configurations >>>>>>> finally with OpenVPN version 2.6 . >>>>>=20 >>>>> We probably won=E2=80=99t 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=C2=B4t tested Smartphones since i do not use them... >>>=20 >>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>=20 >>>>>>> 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... >>>>>=20 >>>>> Questions from me: >>>>>=20 >>>>> 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 --> >>>=20 >>> https://community.ipfire.org/t/solved-manual-repair-pki-on-openvpn-rfc328= 0-issue/2326 >>> which i haven=C2=B4t 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=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 opin= ion. >>>=20 >>>>>=20 >>>>> 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__=3D= c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4l= hhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEV= JvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHn= aLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4= ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q >> We cannot change this, because it is not being negotiated between the clie= nt and server. So we have to keep it enabled for users where it is currently = enabled. >> Again, we have no choice. >>>=20 >>>>>=20 >>>>> We should be fine for the rest. >>> :-) >>>=20 >>>>>=20 >>>>> How do we get rid of this ugly certificate warning? >>> Which one you mean ? >> The RFC something one at the top. >>>=20 >>>>>=20 >>>>> 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 si= nce 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 th= em a own openvpn-functions.pl like it was done with ids-functions.pl, this cl= eaned up the cgi also a little and is already available... >>>>>=20 >>>=20 >>>=20 >>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> I cannot even say how annoying this is - again. But we must >>>>>>>> try our >>>>>>>> best. >>>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>=20 >>>>> Together we will get it done :) >>> Great :-) . >>>>>=20 >>>>> -Michael >>>>>=20 >>>>>>>> -Michael >>>>>>>>=20 >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Erik >>>>>>>=20 >>>>>>>=20 >>>>>>>>> On 7 Oct 2020, at 11:37, ummeegge >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> Am Mittwoch, den 07.10.2020, 10:22 +0100 schrieb Michael >>>>>>>>> Tremer: >>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 7 Oct 2020, at 10:21, ummeegge >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Michael, >>>>>>>>>>>=20 >>>>>>>>>>> Am Mittwoch, den 07.10.2020, 09:20 +0100 schrieb >>>>>>>>>>> Michael >>>>>>>>>>> Tremer: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> Oh so this is a custom thing? >>>>>>>>>>>>=20 >>>>>>>>>>>> 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/). >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> OK, will give it a try. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> Another great example how OpenVPN breaks running >>>>>>>>>>>> installations. >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Yes, and there are comming some exiting new examples >>>>>>>>>>> with the >>>>>>>>>>> upcoming >>>>>>>>>>> releases 8-| ... >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Like what? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> e.g. this >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/2 >>>>>>>>> or >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173/8 >>>>>>>>> checkout the deprecated options :-\ >>>>>>>>>=20 >>>>>>>>>> -Michael >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>> -Michael >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 6 Oct 2020, at 14:26, ummeegge < >>>>>>>>>>>>> ummeegge(a)ipfire.org> >>>>>>>>>>>>>=20 >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Am Dienstag, den 06.10.2020, 12:58 +0100 schrieb >>>>>>>>>>>>> Michael >>>>>>>>>>>>> Tremer: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Why do you have more than one client- >>>>>>>>>>>>>> connnect/disconnect >>>>>>>>>>>>>> script >>>>>>>>>>>>>> in >>>>>>>>>>>>>> your configuration? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Best, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Erik >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -Michael >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 5 Oct 2020, at 16:59, ummeegge < >>>>>>>>>>>>>>> ummeegge(a)ipfire.org> >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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 --> >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D708f2b7368cc8fb= d54a06ca66337ebdcc26b58b4 >>>>>>>>>>>>>>> the new OpenVPN version lined out that only one >>>>>>>>>>>>>>> script >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> be >>>>>>>>>>>>>>> executed. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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 ? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Erik --===============9040004655072811842==--