From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Status update on openvpn work Date: Thu, 19 Oct 2023 12:28:27 +0200 Message-ID: <2625fb81-1ea7-4f6a-9c20-ea0f4a1278c8@ipfire.org> In-Reply-To: <407ac20a2d62aaa028d0aedd2a0e14494ce28fde.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8491191653882714149==" List-Id: --===============8491191653882714149== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On 19/10/2023 10:02, ummeegge wrote: > Hi all, >=20 > Am Mittwoch, dem 18.10.2023 um 21:39 +0200 schrieb Adolf Belka: >> Hi all, >> >> On 18/10/2023 20:48, Michael Tremer wrote: >>> Hello, >>> >>>> On 18 Oct 2023, at 10:05, ummeegge wrote: >>>> >>>> Hi all, >>>> >>>> Am Freitag, dem 13.10.2023 um 14:52 +0200 schrieb Adolf Belka: >>>>> Hi Erik, >>>>> >>>>> On 12/10/2023 13:30, ummeegge wrote: >>>>>> Your welcome. >>>>>> If you are in state of completing the blog post you can send >>>>>> it >>>>>> again >>>>>> to overread it so we all can speak about it, as an offer from >>>>>> me. >>>>>> >>>>>> I would really also recommend to make the cipher >>>>>> renegotiation >>>>>> configurable via WUI. Since the release of 2FA it has been >>>>>> hardcoded >>>>>> --> >>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dhtml/cgi-bin/o= vpnmain.cgi;h=3Deb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=3Drefs/heads/next= #l368 >>>>>> to 48 hours which in a practical way or in fact disables the >>>>>> PFS >>>>>> also >>>>>> for users which do not use 2FA whereby the OpenVPN default, >>>>>> also >>>>>> with >>>>>> potential secure ciphers, are configured to 1 hour to >>>>>> renegotiate a >>>>>> new >>>>>> session key. >>>>> The problem with making it configurable from the WUI is that >>>>> there is >>>>> only one value that the server can have so users that have >>>>> client >>>>> connections with and without OTP would have to make a choice >>>>> between >>>>> one >>>>> or the other. >>>> Client and server can have different '--reneg-sec' values but it >>>> makes >>>> no sense to configure it in such way since the earlier value >>>> triggers >>>> the renegotiation of the session key and will never reach the >>>> later one >>>> cause it starts then again with 0. >>> >>> Ah okay, I think I overlooked the aspect here that the default >>> comes even for the client. >>> >>> It is potentially a bad design choice then that the protocol cannot >>> rekey without reauthentication. >>> >>> We could try to push this from the server side maybe? That would at >>> least indicate some SHOULD value. If the client does not honour it, >>> we cannot do anything about that. >> >> I disagree that this will not work as I have tested it and it worked. > This statement above was according the server have not the capabilities > to trigger different reneg-sec values via CCD or push option for > different clients. If the server is e.g. configured with 'reneg-sec 0' > (disabled) you can configure all clients with different values that=C2=B4s > no problem but i would say more then 90% of all IPFire Roadwarriors out > there does not have a reneg-sec configuration in client.ovpn cause it > was simply not given by the server before 2FA so they use the time > values from the server. To change the client configuration afterwards > are only possible from user side so we run in the same problems to > communicate this but also stresses admins with several hundreds may > thousands of clients. >=20 Looking at the ref manual on the reneg-sec, I get the impression that if=20 the client does not have reneg-sec defined then the default value is=20 applied. If this is the case then I would expect that the client would=20 renegotiate first as the default reneg-sec value is 3600 secs, even if=20 the server has 86400 secs set. Some clients look like they defined=20 reneg-secs to 0 by default, such as network-manager with the openvpn=20 plugin, so those would take the server value. I haven't tested the above with a client with no reneg-sec defined and=20 see if the renegotiation takes place at an hour or not. I will try and=20 find some time to do this later. You are right that users that have large numbers of clients won't want=20 to go and change all their client settings, if they have reneg-sec=20 defined already at 0 or if the client as standard turns off reneg-sec by=20 setting at 0 but if their clients are working okay then there will be no=20 requirement to make them change their client. My suggestion for the change to reneg-sec was for all new connections=20 made. All existing connections would continue running as they have been. Adolf. >> >> I had a standard system with the server set to 86400 secs. >> >> I then added into the client profile for my laptop reneg-sec 30. >> >> So server with 86400 >> client with 30 >> >> Result the server renegotiated every 30 secs. I had the reneg occur 5 >> times. >> This is what is wanted. >> >> Alternative would be another client with reneg-sec set to 86400 to be >> used for OTP connection. >> >> So server with 86400 >> client set to 86400 >> This should result in renegotiation somewhere between 77760 secs (90% >> 86400 secs) and 86400 secs, randomly selected. >> >> I didn't test this as I didn't have a spare 48 hours to test and also >> I >> have not found an openvpn client that I use that works with OTP. >> >> Regards, >> >> Adolf. >> >>> >>>>> I have looked through the OpenVPN info on reneg-sec and found >>>>> that it >>>>> can be specified on both the server but also on each client and >>>>> for a >>>>> specific client the timer that will time out first is the lower >>>>> value >>>>> of >>>>> the one in both ends. >>>> Yes, and the counter starts then from the beginning. >>>> >>>>> >>>>> I have tested this out on my laptop with a direct openvpn cli >>>>> connection >>>>> and via the network manager openvpn plugin and also on my >>>>> android >>>>> phone >>>>> via the OpenVPN for Android app. >>>>> >>>>> In all three cases I added reneg-sec 30 to the .ovpn profile >>>>> and then >>>>> installed it. >>>>> >>>>> I then was able to successfully make a connection and every 30 >>>>> secs I >>>>> saw in the logs that the connection was renegotiated in all >>>>> three >>>>> cases. >>>> It can also be used with pkts [n] and bytes [n] which OpenVPN is >>>> using >>>> if 64 bit block ciphers are configured and renegotiates after 64 >>>> MB of >>>> transfered data. This was the consequences after the SWEET32 >>>> birthday >>>> attacks --> https://sweet32.info=C2=A0. But if '--reneg-*' has been >>>> configured the internal OpenVPN defaults won=C2=B4t be used. >>> >>> I am not aware that anyone has ever reported that they need to re- >>> enter the OTP after hitting a certain amount of data. >>> >>> If so, we need to disable this for OTP-enabled clients. The >>> rationale would be that because we have stronger authentication, we >>> can afford to have fewer rekeys - which I personally disagree with. >>> >>>> >>>>> >>>>> So the current server value can be left as it is and for >>>>> clients with >>>>> the OTP option checked they can have the same reneg-sec as >>>>> currently >>>>> in >>>>> the server and for clients without the OTP checked they can >>>>> have a >>>>> reneg-sec value of one hour, which will trigger before the >>>>> server >>>>> value. >>>> I think this won=C2=B4t work since whichever (server or client) uses >>>> the >>>> lower value will be the one who triggers the renegotiation and >>>> the >>>> counter starts then by 0 again. So this is a kind of a global >>>> setting >>>> and can not be triggered ealier for some and ater for others in >>>> my >>>> opinion --> >>>> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ >>>> . >>> >>> That is a correct statement. >>> >>>> >>>>> >>>>> It could already be that in some cases this is happening anyway >>>>> as >>>>> the >>>>> default value for reneg-sec if not specified is 3600 so it >>>>> depends >>>>> what >>>>> the clients are doing with that default value. I would need to >>>>> run a >>>>> test with the three above options where I leave the systems >>>>> connected >>>>> via OpenVPN and see what happens after one hour (the default >>>>> value >>>>> for >>>>> reneg-sec) but I am not sure when I will have time for that. >>>> Adolf, i would test also the '--auth-(gen-)token' directive --> >>>> https://github.com/OpenVPN/openvpn3/blob/master/doc/webauth.md#auth-toke= n-usage >>>> (very old discussion!) may this can be a solution to bypass the >>>> whole >>>> reneg-sec discussion around 2FA and leave the server to 3600 >>>> sec=C2=B4s or >>>> make it even configuerable cause 2FA users uses it, i think, for >>>> mostly >>>> clients. >>>> I can not test this sinec 2FA on IPFire never works for me! >>> >>> Why not? >>> >>>>> >>>>> I think it will be good to explicitly specify the reneg-sec on >>>>> both >>>>> OTP >>>>> and non-OTP clients so that the default value doesn't cause >>>>> unexpected >>>>> consequences. >>>> Please check also the OpenVPN manpage -- >>>>> =20 >>>>> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-= 6/ >>>> in section "Data Channel Renegotiation" according the above >>>> questions >>>> and potential testing scenarios. >>>> >>>>> >>>>> Regards, >>>>> Adolf. >>>>>> >>>>>> Best, >>>>>> >>>>>> Erik >>>> >>>> Best, >>>> >>>> Erik >>>> >>>>>> >>>>>> Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf >>>>>> Belka: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On 12/10/2023 08:06, ummeegge wrote: >>>>>>>> Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb >>>>>>>> ummeegge: >>>>>>>>>> OpenVPN plan to remove those weak ciphers completely >>>>>>>>>> in >>>>>>>>>> version >>>>>>>>>> 2.7 >>>>>>>>>> If a user at that time still had a client with say >>>>>>>>>> BF-CBC >>>>>>>>>> would >>>>>>>>>> the >>>>>>>>>> negotiation still work then or would it fail because >>>>>>>>>> OpenVPN no >>>>>>>>>> longer >>>>>>>>>> recognises the old weak cipher? >>>>>>>>> This is true according to the OpenVPN 'Deprecated >>>>>>>>> Option' >>>>>>>>> wiki -- >>>>>>>>>> >>>>>>>>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy= :Migrateawayfromdeprecatedciphers.Status:Inprogress >>>>>>> I had seen that overall page before but obviously not read >>>>>>> the >>>>>>> details >>>>>>> well enough of that specific entry. The entry makes it >>>>>>> clear that >>>>>>> from >>>>>>> openvpn-2.7 onwards the 64 bit ciphers will no longer be >>>>>>> accepted >>>>>>> even >>>>>>> as data-fallback ones. >>>>>>>>> that=C2=B4s causes, beneath the OpenSSL-3.x decision, to >>>>>>>>> leave the >>>>>>>>> deprecated ciphers out of the Roadwarrior list (N2N is >>>>>>>>> another >>>>>>>>> thing >>>>>>>>> since it do no understands cipher negotiation) but >>>>>>>>> pushed at >>>>>>>>> that >>>>>>>>> time >>>>>>>>> an idea to bring on some warnings for the users before >>>>>>>>> the >>>>>>>>> IPFire >>>>>>>>> decision to leave the broken ciphers out of any list >>>>>>>>> since >>>>>>>>> the >>>>>>>>> server >>>>>>>>> can not see what client configuration is in place. >>>>>>>> To correct this statement, mostly users do not >>>>>>>> see/recognize >>>>>>>> such >>>>>>>> warnings in the=C2=A0 OpenVPN logs, the server does see it! >>>>>>> I see what you are saying. The users tend not to look at >>>>>>> their >>>>>>> logs >>>>>>> and >>>>>>> so will miss the message about the 64 bit BF-CBC etc being >>>>>>> removed >>>>>>> from >>>>>>> 2.7 onwards. >>>>>>> >>>>>>> So having the 64 bit ciphers in the data-fallback table but >>>>>>> not >>>>>>> allowing >>>>>>> them to be used and instead giving a warning message about >>>>>>> the >>>>>>> cipher >>>>>>> being removed in the future is a way to make the changes >>>>>>> more >>>>>>> visible >>>>>>> that the user needs to do and the potential timing >>>>>>> scenario. >>>>>>> >>>>>>> I think I will also need to put together a supporting info >>>>>>> blog >>>>>>> post >>>>>>> on >>>>>>> the openvpn changes that will come with the IPFire updates >>>>>>> being >>>>>>> worked >>>>>>> on and the future ones with openvpn-2.7 >>>>>>>>> This patch can be found in here --> >>>>>>>>> https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcomm= it;h=3Ddd11f42776f1b60660f4e862d6e847e746b9411b >>>>>>> Thanks for the clarification. >>>>>>> >>>>>>> Regards, >>>>>>> Adolf. >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Adolf. >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Erik >>>>>>>>> >>>>>>>>>>>> Then pressed Start OpenVPN Server and nothing >>>>>>>>>>>> happened. >>>>>>>>>>>> Checked >>>>>>>>>>>> the >>>>>>>>>>>> logs and there is the openssl error >>>>>>>>>>>> >>>>>>>>>>>> OpenSSL: error:0308010C:digital envelope >>>>>>>>>>>> routines::unsupported >>>>>>>>>>>> >>>>>>>>>>>> which occurs because Openssl-3.x doesn't support >>>>>>>>>>>> the >>>>>>>>>>>> older >>>>>>>>>>>> ciphers >>>>>>>>>>>> like BF unless legacy is selected. In this case I >>>>>>>>>>>> think >>>>>>>>>>>> it >>>>>>>>>>>> is >>>>>>>>>>>> the >>>>>>>>>>>> OpenVPN server conf file that requires the >>>>>>>>>>>> >>>>>>>>>>>> providers legacy default >>>>>>>>>>>> >>>>>>>>>>>> to be included, rather than the client conf file. >>>>>>>>>>>> >>>>>>>>>>>> Still it does feel like two steps forward and one >>>>>>>>>>>> backwards >>>>>>>>>>>> so >>>>>>>>>>>> overall still making progress. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Adolf. >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Erik >>>>>>>>>>>> On 09/10/2023 14:05, Adolf Belka wrote: >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Over the last week I have been working on the >>>>>>>>>>>>> openvpn >>>>>>>>>>>>> update >>>>>>>>>>>>> using >>>>>>>>>>>>> Erik's previous patches as my starting point. >>>>>>>>>>>>> >>>>>>>>>>>>> My first attempt to try and be able to >>>>>>>>>>>>> understand the >>>>>>>>>>>>> changes >>>>>>>>>>>>> from >>>>>>>>>>>>> each patch to figure out what I needed to do >>>>>>>>>>>>> proved >>>>>>>>>>>>> difficult >>>>>>>>>>>>> for >>>>>>>>>>>>> me to work with. >>>>>>>>>>>>> >>>>>>>>>>>>> What I then did was take the current >>>>>>>>>>>>> ovpnmain.cgi and >>>>>>>>>>>>> apply >>>>>>>>>>>>> all >>>>>>>>>>>>> of >>>>>>>>>>>>> Erik's patches to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Then I have gone through that new version of >>>>>>>>>>>>> ovpnmain.cgi >>>>>>>>>>>>> and >>>>>>>>>>>>> made >>>>>>>>>>>>> the changes based on previous discussions with >>>>>>>>>>>>> Michael. >>>>>>>>>>>>> >>>>>>>>>>>>> So I have removed the b2sum options that were >>>>>>>>>>>>> present >>>>>>>>>>>>> for >>>>>>>>>>>>> the >>>>>>>>>>>>> Data >>>>>>>>>>>>> and Channel Authentication. >>>>>>>>>>>>> >>>>>>>>>>>>> I also moved all the cryptographic options from >>>>>>>>>>>>> an >>>>>>>>>>>>> additional >>>>>>>>>>>>> advanced cryptographic options button into the >>>>>>>>>>>>> Advanced >>>>>>>>>>>>> Server >>>>>>>>>>>>> options button. >>>>>>>>>>>>> >>>>>>>>>>>>> I was successful in doing all the above and >>>>>>>>>>>>> then >>>>>>>>>>>>> tested >>>>>>>>>>>>> the >>>>>>>>>>>>> ovpnmain.cgi out with a vm using the existing >>>>>>>>>>>>> openvpn- >>>>>>>>>>>>> 2.5.9 >>>>>>>>>>>>> version >>>>>>>>>>>>> for openvpn. >>>>>>>>>>>>> >>>>>>>>>>>>> My old profile for my laptop which had a >>>>>>>>>>>>> ciphers >>>>>>>>>>>>> entry >>>>>>>>>>>>> worked >>>>>>>>>>>>> without any problem. My laptop was working >>>>>>>>>>>>> withy >>>>>>>>>>>>> openvpn- >>>>>>>>>>>>> 2.6.6 >>>>>>>>>>>>> >>>>>>>>>>>>> I then created a new profile using the new >>>>>>>>>>>>> ovpnmain.cgi >>>>>>>>>>>>> using >>>>>>>>>>>>> the >>>>>>>>>>>>> negotiation option which ended up with a data- >>>>>>>>>>>>> ciphers >>>>>>>>>>>>> line. >>>>>>>>>>>>> That >>>>>>>>>>>>> also worked in making a successful openvpn >>>>>>>>>>>>> tunnel >>>>>>>>>>>>> with my >>>>>>>>>>>>> laptop >>>>>>>>>>>>> without any issues. >>>>>>>>>>>>> >>>>>>>>>>>>> I then downgraded my laptop to openvpn-2.4.8 >>>>>>>>>>>>> and had >>>>>>>>>>>>> to >>>>>>>>>>>>> install >>>>>>>>>>>>> openvpn-1.1.1 to make that work. >>>>>>>>>>>>> >>>>>>>>>>>>> With that client version on my laptop both the >>>>>>>>>>>>> old >>>>>>>>>>>>> and >>>>>>>>>>>>> new >>>>>>>>>>>>> profiles >>>>>>>>>>>>> connected with a tunnel with no problems. >>>>>>>>>>>>> >>>>>>>>>>>>> I then tried downgrading my laptop to openvpn- >>>>>>>>>>>>> 2.3.14 >>>>>>>>>>>>> but >>>>>>>>>>>>> to >>>>>>>>>>>>> make >>>>>>>>>>>>> this work I would have had to downgrade the >>>>>>>>>>>>> laptop to >>>>>>>>>>>>> openssl- >>>>>>>>>>>>> 1.0.0 >>>>>>>>>>>>> which I was not willing to do as that is very >>>>>>>>>>>>> old and >>>>>>>>>>>>> very >>>>>>>>>>>>> insecure. >>>>>>>>>>>>> >>>>>>>>>>>>> The oldest openvpn version working with >>>>>>>>>>>>> openssl-1.1.1 >>>>>>>>>>>>> is >>>>>>>>>>>>> 2.4.0 >>>>>>>>>>>>> which is nearly 7 years old. >>>>>>>>>>>>> >>>>>>>>>>>>> That version also worked with both the old and >>>>>>>>>>>>> new >>>>>>>>>>>>> laptop >>>>>>>>>>>>> profiles. >>>>>>>>>>>>> >>>>>>>>>>>>> I then tested out the openvpn server on my >>>>>>>>>>>>> IPFire vm >>>>>>>>>>>>> with >>>>>>>>>>>>> a >>>>>>>>>>>>> 2.6.0 >>>>>>>>>>>>> and 2.6.6 version of openvpn. >>>>>>>>>>>>> >>>>>>>>>>>>> Both these openvpn versions worked with both >>>>>>>>>>>>> the old >>>>>>>>>>>>> and >>>>>>>>>>>>> new >>>>>>>>>>>>> laptop >>>>>>>>>>>>> connection profiles with my laptop on version >>>>>>>>>>>>> 2.4.0 >>>>>>>>>>>>> and >>>>>>>>>>>>> on >>>>>>>>>>>>> 2.6.6 >>>>>>>>>>>>> >>>>>>>>>>>>> All the above was using network manager with >>>>>>>>>>>>> its >>>>>>>>>>>>> openvpn >>>>>>>>>>>>> plugin >>>>>>>>>>>>> option on the laptop for making the openvpn >>>>>>>>>>>>> tunnel >>>>>>>>>>>>> connections. >>>>>>>>>>>>> >>>>>>>>>>>>> As far as I can tell everything is working fine >>>>>>>>>>>>> when >>>>>>>>>>>>> negotiation is >>>>>>>>>>>>> specified on the server. Old profiles that just >>>>>>>>>>>>> use >>>>>>>>>>>>> the >>>>>>>>>>>>> cipher >>>>>>>>>>>>> option also work fine. Therefore my plan is to >>>>>>>>>>>>> only >>>>>>>>>>>>> use >>>>>>>>>>>>> the >>>>>>>>>>>>> negotiation option and not make it selectable >>>>>>>>>>>>> for >>>>>>>>>>>>> older >>>>>>>>>>>>> clients. >>>>>>>>>>>>> The data-ciphers-fallback option in the server >>>>>>>>>>>>> seems >>>>>>>>>>>>> to >>>>>>>>>>>>> be >>>>>>>>>>>>> doing >>>>>>>>>>>>> its job. >>>>>>>>>>>>> >>>>>>>>>>>>> The negotiation option on the server was able >>>>>>>>>>>>> to >>>>>>>>>>>>> connect >>>>>>>>>>>>> to a >>>>>>>>>>>>> 2.4.0 >>>>>>>>>>>>> client on my laptop. >>>>>>>>>>>>> >>>>>>>>>>>>> According to the OpenVPN wiki on cipher >>>>>>>>>>>>> negotiation >>>>>>>>>>>>> the >>>>>>>>>>>>> data- >>>>>>>>>>>>> ciphers-fallback option will work with 2.4.x >>>>>>>>>>>>> and >>>>>>>>>>>>> 2.3.x >>>>>>>>>>>>> clients. >>>>>>>>>>>>> As >>>>>>>>>>>>> the 2.3.x clients need to be using openssl- >>>>>>>>>>>>> 1.0.0 then >>>>>>>>>>>>> I >>>>>>>>>>>>> think >>>>>>>>>>>>> if >>>>>>>>>>>>> those clients work then fine but nothing >>>>>>>>>>>>> further >>>>>>>>>>>>> back. >>>>>>>>>>>>> >>>>>>>>>>>>> Overall, I am very happy with what I have >>>>>>>>>>>>> succeeded >>>>>>>>>>>>> in >>>>>>>>>>>>> doing >>>>>>>>>>>>> so >>>>>>>>>>>>> far. I achieved things much quicker than I had >>>>>>>>>>>>> expected. >>>>>>>>>>>>> >>>>>>>>>>>>> I will now try and see about creating a profile >>>>>>>>>>>>> on a >>>>>>>>>>>>> CU >>>>>>>>>>>>> 179 >>>>>>>>>>>>> based >>>>>>>>>>>>> system that uses one of the old insecure >>>>>>>>>>>>> ciphers such >>>>>>>>>>>>> as >>>>>>>>>>>>> Blow >>>>>>>>>>>>> Fish >>>>>>>>>>>>> and restore that into my evaluation vm and see >>>>>>>>>>>>> how >>>>>>>>>>>>> that >>>>>>>>>>>>> works >>>>>>>>>>>>> with >>>>>>>>>>>>> my laptop when I have it downgraded to openvpn- >>>>>>>>>>>>> 2.4.0 >>>>>>>>>>>>> >>>>>>>>>>>>> I already know that if the laptop is at >>>>>>>>>>>>> openvpn-2.6.6 >>>>>>>>>>>>> then it >>>>>>>>>>>>> will >>>>>>>>>>>>> not accept a blowfish cipher (or another weak >>>>>>>>>>>>> cipher >>>>>>>>>>>>> such >>>>>>>>>>>>> as >>>>>>>>>>>>> DES) >>>>>>>>>>>>> as that is something I tested in the past. >>>>>>>>>>>>> >>>>>>>>>>>>> If that also works then my plan will be to take >>>>>>>>>>>>> the >>>>>>>>>>>>> updated >>>>>>>>>>>>> ovpnmain.cgi and split the changes into a new >>>>>>>>>>>>> range >>>>>>>>>>>>> of >>>>>>>>>>>>> patches >>>>>>>>>>>>> and >>>>>>>>>>>>> then submit them for consideration. >>>>>>>>>>>>> >>>>>>>>>>>>> That will probably end up later in November as >>>>>>>>>>>>> I will >>>>>>>>>>>>> be >>>>>>>>>>>>> busy >>>>>>>>>>>>> with >>>>>>>>>>>>> personal things at the end of October / >>>>>>>>>>>>> beginning of >>>>>>>>>>>>> November. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Adolf. >>> >>> >> >=20 --=20 Sent from my laptop --===============8491191653882714149==--