Hello boys,
Great conversation here, but unfortunately this is going to be messy...
On 8 Oct 2020, at 14:23, Adolf Belka ahb.ipfire@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....
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.
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.
Secondly https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negot... 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."
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.
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.
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.
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.
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.
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.
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.
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?
How do we migrate comp-lzo/compress?
We should be fine for the rest.
How do we get rid of this ugly certificate warning?
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.
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 :)
-Michael
-Michael
Best,
Erik
On 7 Oct 2020, at 11:37, ummeegge ummeegge@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@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@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@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=708f2b7368cc8fbd54a06ca6...
>>>> 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 >>>> >>>> >>> >