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: Thu, 08 Oct 2020 19:18:00 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5562636272910205190==" List-Id: --===============5562636272910205190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, I suspect you are right about my optimism but that is my nature :) Regards, Adolf. 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: >> >> 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 c= ould 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 a= ny date. It does not show up yet in the Deprecated options page (https://comm= unity.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 w= ill be removed, the new alternative approach and the reasoning behind removin= g the option". >=20 > So, I suppose we will have to re-implement the whole cipher selection on ou= r side then. We will have to remove --ncp-disable and =E2=80=94cipher and sta= rt adding =E2=80=94data-ciphers. A select box where multiple algorithms can b= e 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 ht= tps://community.openvpn.net/openvpn/wiki/CipherNegotiation#Serverversion2.5 >=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. >=20 > Potentially, but we need to prepare ourselves and our users before that. Wh= enever we release 2.7, it will simply be too late, because then the deprecate= d 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 deprecati= on of one option. Although I agree with the cipher negotiation, there has to = be a migration path. >=20 >> Secondly https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/c= ipher-negotiation.rst states "OpenVPN 2.5 will only allow the ciphers specifi= ed in --data-ciphers. To ensure backwards compatibility also if a ciphe= r is specified using the --cipher option it is automatically added to this li= st. If both options are unset the default is AES-256-GCM:AES-128-GCM." >> >> In my OpenVPN for Android client this is what happens. --cipher has AES-25= 6-GCM from my client config that I transferred from IPFire but also has --dat= a-ciphers with AES-256-GCM:AES-128-GCM:AES-256-GCM, so the contents of my --c= ipher have been copied across to the end of --data-ciphers. >> >> If users are using a strong encryption, such as AES-256-GCM then this is t= he 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-ci= phers but from OpenVPN v2.6 those encryptions will not be copied across as th= ey have been deprecated as too weak for some time. The other encryptions will= still be copied across from --cipher to --data-cipher. >> >> Eventually, when --cipher is removed (timing still to be defined) then use= rs 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 th= e IPFire OpenVPN server. >> >> 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 c= iphers any more. >> >> 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 timin= g 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. >> >> 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 >> >> 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 broadcas= t 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 exite= d 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 >=20 > This seems to be broken. >=20 > If we change to =E2=80=9Csubnet=E2=80=9D, we would simply lease one IP addr= ess 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 a= nd the second one is the one that is getting assigned to the server. >=20 > The documentation says that the second part has to be replaced by the subne= t mask. >=20 > So that means we will have to migrate all those files manually when the upd= ate is being applied. This can all be done on the server and therefore won=E2= =80=99t break the client configuration. Phew. >=20 >>> >>> 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 ? >=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. >>>> >>> 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 Up= date 1. But I suppose we need to try and prepare the currently issued configu= ration files so that clients will work when they update soon. >=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. >>>> >>> 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? >=20 > How do we migrate comp-lzo/compress? >=20 > We should be fine for the rest. >=20 > How do we get rid of this ugly certificate warning? >=20 > Before we start hacking the CGI, should we try to clean up some code? For e= xample does the whole page not take the /24 format for subnets. That is a bit= annoying. >=20 >>> >>> >>>> 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. >=20 > Together we will get it done :) >=20 > -Michael >=20 >>>> -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 >>>>>>>>> >>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> 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=3D708f2b7368cc8fb= d54a06ca66337ebdcc26b58b4 >>>>>>>>>>> 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 --===============5562636272910205190==--