OpenVPN no more --client-(dis)connect scripts can be executed

OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

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=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
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

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Why do you have more than one client-connnect/disconnect script in your configuration?

-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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> 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
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> > 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
> > 
> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

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/).

Another great example how OpenVPN breaks running installations.

-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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>> 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
>>> 
>> 
>> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

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-| ...

> 
> -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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> > > > 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
> > > > 
> > > 
> > > 
> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

Hi,

> On 7 Oct 2020, at 10:21, ummeegge <ummeegge(a)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?

-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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>> 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
>>>>> 
>>>> 
>>>> 
>> 
>> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 3176 bytes --]

Am Mittwoch, den 07.10.2020, 10:22 +0100 schrieb Michael Tremer:
> Hi,
> 
> > On 7 Oct 2020, at 10:21, ummeegge <ummeegge(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> > > > > > 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
> > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]

Hello,

That reads awful.

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).

We need to coordinate this and future-proof OpenVPN as best as we can, but it looks like we will break client configuration - again.

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.

I cannot even say how annoying this is - again. But we must try our best.

-Michael

> On 7 Oct 2020, at 11:37, ummeegge <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>> 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
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 7119 bytes --]

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.

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

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 ?

> 
> 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 .

> 
> 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...

> 
> 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.

> 
> -Michael

Best,

Erik

> 
> > On 7 Oct 2020, at 11:37, ummeegge <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> > > > > > > > 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
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 13004 bytes --]

Hello boys,

Great conversation here, but unfortunately this is going to be messy...

> On 8 Oct 2020, at 14:23, Adolf Belka <ahb.ipfire(a)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.5

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-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."
> 
> 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(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 13433 bytes --]

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,
> 
> Great conversation here, but unfortunately this is going to be messy...
> 
>> On 8 Oct 2020, at 14:23, Adolf Belka <ahb.ipfire(a)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.5
> 
> 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-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."
>>
>> 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(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 20587 bytes --]

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´s great :-) , would you like to step into some more testing rounds :D --> 
https://community.ipfire.org/t/openvpn-2-5-development-version/2173
?

> 
> 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 <ahb.ipfire(a)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.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.


> > 
> > 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
?

> > 
> > 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/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...

> > > 
> > > 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...

> > > 
> > > 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 ?!

> > > 
> > > 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 ?!

> > > 
> > > 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.
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 ?

> > 
> > 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.
2.5 was working with RC2 also with the conventional configs as far as i
can see but i haven´t 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´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?
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-rfc3280-issue/2326
which i haven´t 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´t we expand the actual values
2048/4096 may too ?

> > 
> > 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__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q

> > 
> > We should be fine for the rest.
:-) 

> > 
> > How do we get rid of this ugly certificate warning?
Which one you mean ?

> > 
> > 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 since 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 them a own openvpn-functions.pl like it was done with ids-functions.pl, this cleaned 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 <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> > > > > > > > > > > > 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

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 21695 bytes --]

Hi,

> On 11 Oct 2020, at 15:16, ummeegge <ummeegge(a)ipfire.org> 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´s great :-) , would you like to step into some more testing rounds :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 some 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 <ahb.ipfire(a)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.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 think we should start dropping old crypto now. This is an easy change and 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 people to move away from BF, DES, SEED, etc. And then remove these in around March-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’s start with the ciphers/NCP ones first, because that will be released earlier.

Changing ns-cert-type on the server side should still allow clients to connect 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/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...
> 
>>>> 
>>>> 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 could 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’t 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’t always possible. In this case: You cannot simply change the cipher unless you can update all your clients at the same time. People’s 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 “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.
> 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’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.
> 2.5 was working with RC2 also with the conventional configs as far as i
> can see but i haven´t 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´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?
> 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-rfc3280-issue/2326
> which i haven´t 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´t we expand the actual values
> 2048/4096 may too ?

Oh. This is bad. We need to script the changes then. Otherwise we won’t be able to encourage users to update.

Having shorter key lengths is a compromise that we have to make in my opinion.

> 
>>> 
>>> 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__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q

We cannot change this, because it is not being negotiated between the client 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 since 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 them a own openvpn-functions.pl like it was done with ids-functions.pl, this cleaned 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 <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>>>>> 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

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 22441 bytes --]

Hi

On 12/10/2020 12:45, Michael Tremer wrote:
> Hi,
> 
>> On 11 Oct 2020, at 15:16, ummeegge <ummeegge(a)ipfire.org> 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´s great :-) , would you like to step into some more testing rounds :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 some 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 <ahb.ipfire(a)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.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 mobile 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 and 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 people to move away from BF, DES, SEED, etc. And then remove these in around March-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’s start with the ciphers/NCP ones first, because that will be released earlier.
> 
> Changing ns-cert-type on the server side should still allow clients to connect 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/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...
>>
>>>>>
>>>>> 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 could 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’t 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’t always possible. In this case: You cannot simply change the cipher unless you can update all your clients at the same time. People’s 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 “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.
>> 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’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.
>> 2.5 was working with RC2 also with the conventional configs as far as i
>> can see but i haven´t 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´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?
>> 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-rfc3280-issue/2326
>> which i haven´t 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´t we expand the actual values
>> 2048/4096 may too ?
> 
> Oh. This is bad. We need to script the changes then. Otherwise we won’t be able to encourage users to update.
> 
> Having shorter key lengths is a compromise that we have to make in my opinion.
> 
>>
>>>>
>>>> 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__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q
> 
> We cannot change this, because it is not being negotiated between the client 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 since 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 them a own openvpn-functions.pl like it was done with ids-functions.pl, this cleaned 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 <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>>>>>> 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
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 23290 bytes --]

Hello,

Has OpenVPN finally been integrated into stock Android, or is this a custom version (like Lineage) or a userspace application?

Best,
-Michael

> On 12 Oct 2020, at 12:28, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
> 
> Hi
> 
> On 12/10/2020 12:45, Michael Tremer wrote:
>> Hi,
>>> On 11 Oct 2020, at 15:16, ummeegge <ummeegge(a)ipfire.org> 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´s great :-) , would you like to step into some more testing rounds :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 some 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 <ahb.ipfire(a)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.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 mobile 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 and 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 people to move away from BF, DES, SEED, etc. And then remove these in around March-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’s start with the ciphers/NCP ones first, because that will be released earlier.
>> Changing ns-cert-type on the server side should still allow clients to connect 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/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...
>>> 
>>>>>> 
>>>>>> 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 could 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’t 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’t always possible. In this case: You cannot simply change the cipher unless you can update all your clients at the same time. People’s 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 “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.
>>> 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’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.
>>> 2.5 was working with RC2 also with the conventional configs as far as i
>>> can see but i haven´t 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´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?
>>> 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-rfc3280-issue/2326
>>> which i haven´t 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´t we expand the actual values
>>> 2048/4096 may too ?
>> Oh. This is bad. We need to script the changes then. Otherwise we won’t be able to encourage users to update.
>> Having shorter key lengths is a compromise that we have to make in my opinion.
>>> 
>>>>> 
>>>>> 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__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q
>> We cannot change this, because it is not being negotiated between the client 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 since 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 them a own openvpn-functions.pl like it was done with ids-functions.pl, this cleaned 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 <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>>>>>>> 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

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 23948 bytes --]

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=de.blinkt.openvpn&hl=en_US&gl=US


Regards,
Adolf.

On 12/10/2020 16:23, Michael Tremer wrote:
> Hello,
> 
> Has OpenVPN finally been integrated into stock Android, or is this a custom version (like Lineage) or a userspace application?
> 
> Best,
> -Michael
> 
>> On 12 Oct 2020, at 12:28, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>
>> Hi
>>
>> On 12/10/2020 12:45, Michael Tremer wrote:
>>> Hi,
>>>> On 11 Oct 2020, at 15:16, ummeegge <ummeegge(a)ipfire.org> 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´s great :-) , would you like to step into some more testing rounds :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 some 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 <ahb.ipfire(a)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.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 mobile 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 and 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 people to move away from BF, DES, SEED, etc. And then remove these in around March-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’s start with the ciphers/NCP ones first, because that will be released earlier.
>>> Changing ns-cert-type on the server side should still allow clients to connect 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/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...
>>>>
>>>>>>>
>>>>>>> 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 could 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’t 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’t always possible. In this case: You cannot simply change the cipher unless you can update all your clients at the same time. People’s 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 “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.
>>>> 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’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.
>>>> 2.5 was working with RC2 also with the conventional configs as far as i
>>>> can see but i haven´t 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´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?
>>>> 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-rfc3280-issue/2326
>>>> which i haven´t 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´t we expand the actual values
>>>> 2048/4096 may too ?
>>> Oh. This is bad. We need to script the changes then. Otherwise we won’t be able to encourage users to update.
>>> Having shorter key lengths is a compromise that we have to make in my opinion.
>>>>
>>>>>>
>>>>>> 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__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q
>>> We cannot change this, because it is not being negotiated between the client 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 since 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 them a own openvpn-functions.pl like it was done with ids-functions.pl, this cleaned 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 <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
>>>>>>>>>>>>>>>> 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
> 

Re: OpenVPN no more --client-(dis)connect scripts can be executed

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 29643 bytes --]

Hi all,
am a little sorry that we wenthave so much OT here :-), am some steps
further with some things and will push them may one by one to the list
if the release is out and the RC time is over.

Am Montag, den 12.10.2020, 11:45 +0100 schrieb Michael Tremer:
> Hi,
> 
> > On 11 Oct 2020, at 15:16, ummeegge <ummeegge(a)ipfire.org> 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´s great :-) , would you like to step into some more testing
> > rounds :D --> 
> > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> > ?
> 
> Can we not keep development stuff on the development list please?
Did that long time in the forum which was also a collector for my
testings and a reference for the list if it gets more interesting but
OK we can try it in here only, there is also no downloadable stuff in
this community topic.

> 
> 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 some sort of standard that is good enough for a
> larger group of testers.
As mentioned, no downloadable stuff in there ;-).

> 
> > 
> > > 
> > > 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 <ahb.ipfire(a)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.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.
IPSec might be there the harder one, am not sure about that.

> 
> I think we should start dropping old crypto now. This is an easy
> change and 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 people to move away from BF, DES, SEED, etc. And then
> remove these in around March-April time for good. We have already
> marked those ciphers as weak and I would propose to remove all of
> them.
OK, can do it e.g. via --> 
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;h=e7bc505e744aaae5e6a07727c3d2f40d3fc0976f;hb=refs/heads/core150#l216
.

> 
> > > > 
> > > > 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’s start with the ciphers/NCP ones first, because that will
> be released earlier.
Have tested it with RC2 and it should be for the first enought to
simply delete --ncp-disable from server.conf to start him succesfully.

> 
> Changing ns-cert-type on the server side should still allow clients
> to connect that use an older version, am I right?
Meanwhile it seems you are right -->
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?__cf_chl_jschl_tk__=cfe4647137b5d7cdf024d64a6c60ed393b353fc5-1602588623-0-AUfvmWoY1fRGVDHRV7x_O9LhQAkW5kWj19wGaiAn1puvr7Xex6HQUFHOlWXgynCy6QNdrViLT0Y-t8_JugwWLZofASgZyLIp8TDVjWq-kTVq3rX_4BTejsyVRjwpp7XDOj9rYp_AiBgBFJIO2Qsft7izLKcNl0XL_ISYkelzAp6yC_tEZNsSwvuMdmtAlneN2gE9wFFQwo4z30Cfy1bVexhDOidH0SaDhqmHE1XaDd_buNjER0gGzVmhu2hBMSynXKnhS5hHL5v26MoI1TF9a1clfwobq1POYUkeTueUNI9uBWf2RNvWz_2mDKpqln1xVA#Option:--ns-cert-type
by the release of 2.4 they announced it to be replaced with 2.5 (which
means now !) but they changed their opinion as far as i can see.

> 
> > 
> > > > 
> > > > 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/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...
> > 
> > > > > 
> > > > > 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 could not test when posting patches. Then, somebody else can fill
> in the gaps.
OK.

> 
> > 
> > > > > 
> > > > > 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’t be able to test things easily.
You mean in March April ? Really 8-| .

> 
> > > > > 
> > > > > 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’t always possible. In this case: You
> cannot simply change the cipher unless you can update all your
> clients at the same time. People’s 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 “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.
> > 
> > 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?
Am waiting of the release to get all in. Since e.g. Beta2 and RC2 has
been changed a lot. The *.0 version can also bring sometimes some
problems with, may an IPFire update with 2.5.1 might be an idea ? 

> 
> > 
> > > > 
> > > > 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.
> > 
> > 2.5 was working with RC2 also with the conventional configs as far
> > as i
> > can see but i haven´t 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´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?
> > 
> > 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-rfc3280-issue/2326
> > which i haven´t 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´t we expand the actual values
> > 2048/4096 may too ?
> 
> Oh. This is bad. We need to script the changes then. Otherwise we
> won’t be able to encourage users to update.
> 
> Having shorter key lengths is a compromise that we have to make in my
> opinion.
> 
> > 
> > > > 
> > > > 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__=c269b344bb1a46a9d9ad40cdbca2fa7250a49634-1602424768-0-AZ_zX1wAAsx6JM0SGLkLW4lhhlE1I77NRrWVdljRXGvS1ijBw5O8mHtjNvPWfPbvr3ruH2YMtPO-Fc8GPgphkW2dQ2NX0karwsEVJvusnUcZXdc9rYkLiyuqsfrmfJxOPds9BXCoxPb2jA-6ElbmVE-Hyyp0FwLpa7xw_nw3gOMTDSrHnaLO9uT5_rHdSwn7Z0NhRKtzgf2eSHyNyqSu3Nd_YKk0YKvuLKqEARvIA9TBQlBKwMn6AtiUpUZSg4ghQutd-u8H4KAI8NKb-N6R0PbV_aNz7MPGTo5nl1Kczx_q
> 
> We cannot change this, because it is not being negotiated between the
> client and server. So we have to keep it enabled for users where it
> is currently enabled.
> 
> Again, we have no choice.
The sound in here -->
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?__cf_chl_jschl_tk__=cfe4647137b5d7cdf024d64a6c60ed393b353fc5-1602588623-0-AUfvmWoY1fRGVDHRV7x_O9LhQAkW5kWj19wGaiAn1puvr7Xex6HQUFHOlWXgynCy6QNdrViLT0Y-t8_JugwWLZofASgZyLIp8TDVjWq-kTVq3rX_4BTejsyVRjwpp7XDOj9rYp_AiBgBFJIO2Qsft7izLKcNl0XL_ISYkelzAp6yC_tEZNsSwvuMdmtAlneN2gE9wFFQwo4z30Cfy1bVexhDOidH0SaDhqmHE1XaDd_buNjER0gGzVmhu2hBMSynXKnhS5hHL5v26MoI1TF9a1clfwobq1POYUkeTueUNI9uBWf2RNvWz_2mDKpqln1xVA#Option:--comp-lzo
is not pretty clear if or when they will remove it :-| .

> 
> > 
> > > > 
> > > > 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.
Is the same which we talked about above. Have therefor currently no
testing scenario since the PKI here do have all changes since 2017 -->
https://forum.ipfire.org/viewtopic.php?f=50&t=18852&p=108144&hilit=rfc3280#p108144
, if there is someone who would like to give it a try, in here -->
https://community.ipfire.org/t/solved-manual-repair-pki-on-openvpn-rfc3280-issue/2326
is the topic.


> 
> > 
> > > > 
> > > > 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 since 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 them a own openvpn-functions.pl like it was done with ids-
> > functions.pl, this cleaned 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 <ummeegge(a)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(a)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(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=ipfire-2.x.git;a=commit;h=708f2b7368cc8fbd54a06ca66337ebdcc26b58b4
> > > > > > > > > > > > > > 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
> 
>