OpenVPN-2.5.0 update procedure and idea collector

OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi all,
i am currently in the update process of the already realeased OpenVPN-
2.5.0 --> https://openvpn.net/community-downloads-2/ . The update has
been tested and worked so far also with the old default client
configuration (tested with 2.4.9 client). There are two warnings -->

1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
is a deprecated debug feature that will be removed in OpenVPN 2.6

2) WARNING: --topology net30 support for server configs with IPv4 pools
will be removed in a future release. Please migrate to --topology
subnet as soon as possible.

in the server log but it nevertheless works flawlessly.

Am working currently on an "Advanced Encryption Settings" page which
includes currently four new directives --data-ciphers (data channel
encryption), --data-ciphers-fallback (data-channel encryption for
clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only)
and --tls-ciphersuites (control channel >= TLSv3) all options are
explained in here --> 
https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
, which works here currently and looks like this:

Button to belong to this page:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png

And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png


You can see also the default settings, were i need also your ideas and
comments for may better defaults.
On the page itself is also more planned but to not overload this here
now, i wanted to go now a two step procedure with this update.

1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for regukar
global settings for RW and N2N. A overview of the new crypto can be
found in here -->
https://community.ipfire.org/t/openvpn-2-5-development-version/2173 .
2) I would push the "Advanced Encryption settings" development as seen
above then as one patch <-- this would also eliminate the first warning
causing --ncp-disable since we can delete this option then.

Everything else would come detached from this.

Some feedback might be nice.

Best,

Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Some additions and WUI restructure ideas after some more testings.

'--cipher' is no longer needed if '--data-cipher-fallback' is in usage,
there is also no need for '--data-ciphers' for the first if '--data-
cipher-fallback' is active. The client can still uses the '--cipher
alg' directive and the 2.5.0 server responds with '--data-ciphers-
fallback alg' .

The idea: Remove the cipher section from the global area from the WUI,
rename simply '--cipher' to '--data-ciphers-fallback' in server.conf
and keep the index, include the 'DCIPHER' (also 'DAUTH' and 'TLSAUTH')
variable(s) to the advanced encryption section with the related indexes
to keep the old configuration but set also new defaults for new
configurations.

If '--data-ciphers' is active, all old clients have the chance with
e.g. an old CBC cipher to migrate also to newer clients step-by-step so
we can get rid of the old broken algorithms like CAST, DES and BF since
they won´t appear in the new advanced encryption section...


As an idea !?

Best,

Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi Erik,

Thanks for all your work on OpenVPN. Much appreciated, especially in these challenging times of many changes.

Am I correct in my presumption that in the advanced encryption settings GUI we will be able to select multiple entries, which will then be made into a list in order that the entries are in the tables.

 From the advanced encryption settings page I see that you have removed the old insecure options, which is good.
For the Data-Channel fallback do you have to have a default or can you unselect everything. There could be people who only want to connect to systems that have the strongest ciphers and just refuse to connect with weaker ones.

For the Control-Channel sections I would suggest swapping the order of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most secure to least secure from left to right. I think that the Control-Channel should do the same.

I don't have any comments about the defaults. They seem reasonable to me.

Excellent work, it's looking very nice.

Regards,
Adolf.


On 22/11/2020 17:30, ummeegge wrote:
> Hi all,
> i am currently in the update process of the already realeased OpenVPN-
> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update has
> been tested and worked so far also with the old default client
> configuration (tested with 2.4.9 client). There are two warnings -->
> 
> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
> is a deprecated debug feature that will be removed in OpenVPN 2.6
> 
> 2) WARNING: --topology net30 support for server configs with IPv4 pools
> will be removed in a future release. Please migrate to --topology
> subnet as soon as possible.
> 
> in the server log but it nevertheless works flawlessly.
> 
> Am working currently on an "Advanced Encryption Settings" page which
> includes currently four new directives --data-ciphers (data channel
> encryption), --data-ciphers-fallback (data-channel encryption for
> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only)
> and --tls-ciphersuites (control channel >= TLSv3) all options are
> explained in here -->
> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> , which works here currently and looks like this:
> 
> Button to belong to this page:
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> 
> And the page itself:
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> 
> 
> You can see also the default settings, were i need also your ideas and
> comments for may better defaults.
> On the page itself is also more planned but to not overload this here
> now, i wanted to go now a two step procedure with this update.
> 
> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for regukar
> global settings for RW and N2N. A overview of the new crypto can be
> found in here -->
> https://community.ipfire.org/t/openvpn-2-5-development-version/2173 .
> 2) I would push the "Advanced Encryption settings" development as seen
> above then as one patch <-- this would also eliminate the first warning
> causing --ncp-disable since we can delete this option then.
> 
> Everything else would come detached from this.
> 
> Some feedback might be nice.
> 
> Best,
> 
> Erik
> 

RE: OpenVPN-2.5.0 update procedure and idea collector

[Kienker, Fred]

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

Eric:

The idea of putting all of the encryption settings on one page is a good 
one. There are now so many encryption settings and choices that they 
really need their own page.

The settings changes, at first look, should work but sometimes these 
backwards compatibility settings don't always work as advertised.. 
Testing with a variety of clients and both the current and reasonable 
legacy versions would be recommended, even if it is hard to get people 
to assist. With OpenVPN people have a tendency to set it up, get it 
working and leave it alone until it stops working so there are always a 
lot of old clients out there. 

Best regards, 
Fred

Please note: Although we may sometimes respond to email, text and phone 
calls instantly at all hours of the day, our regular business hours are 
9:00 AM - 6:00 PM ET, Monday thru Friday.

-----Original Message-----
From: ummeegge <ummeegge(a)ipfire.org> 
Sent: Monday, November 23, 2020 4:15 AM
To: development(a)lists.ipfire.org
Subject: Re: OpenVPN-2.5.0 update procedure and idea collector

Some additions and WUI restructure ideas after some more testings.

'--cipher' is no longer needed if '--data-cipher-fallback' is in usage, 
there is also no need for '--data-ciphers' for the first if '--data- 
cipher-fallback' is active. The client can still uses the '--cipher alg' 
directive and the 2.5.0 server responds with '--data-ciphers- fallback 
alg' .

The idea: Remove the cipher section from the global area from the WUI, 
rename simply '--cipher' to '--data-ciphers-fallback' in server.conf and 
keep the index, include the 'DCIPHER' (also 'DAUTH' and 'TLSAUTH')
variable(s) to the advanced encryption section with the related indexes 
to keep the old configuration but set also new defaults for new 
configurations.

If '--data-ciphers' is active, all old clients have the chance with e.g. 
an old CBC cipher to migrate also to newer clients step-by-step so we 
can get rid of the old broken algorithms like CAST, DES and BF since 
they won´t appear in the new advanced encryption section...


As an idea !?

Best,

Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi Adolf,
and thanks for your feedback.

Am Montag, den 23.11.2020, 12:41 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> Thanks for all your work on OpenVPN. Much appreciated, especially in
> these challenging times of many changes.
thank you too.

> 
> Am I correct in my presumption that in the advanced encryption
> settings GUI we will be able to select multiple entries, which will
> then be made into a list in order that the entries are in the tables.
Yes, the negotiation was already introduced in 2.4. The server check
via 'IV_NCP=2' if and then which ciphers the client does support and
uses the first in place then e.g. AES-256-GCM:AES-256-CBC . Same with -
-tls-ciphers and tls-ciphersuites. Every client above 2.4.0 does not
recognize the renegotiation, therefor --data-ciphers-fallback .

> 
>  From the advanced encryption settings page I see that you have
> removed the old insecure options, which is good.
Yes i would really love to do this as soon as possible but since we
introduce the negotiation not before, older configurations does not
have had the possibility to migrate. My idea is now to leave the old
ciphers for the first in --data-ciphers-fallback, but give the user a
message in the WUI and may also in IPFire blog that he should change as
soon as possible since those (64 bit block ciphers) will be removed
very soon. We can handle this via &pkiconfigcheck function e.g. . 

> For the Data-Channel fallback do you have to have a default or can
> you unselect everything. There could be people who only want to
> connect to systems that have the strongest ciphers and just refuse to
> connect with weaker ones.
We can make there a checkbox to disable data-channel-fallback but for
the first time it might be better to leave it there in my opinion for
the above described migration possiblity. It is the substitute for --
cipher.
Nevertheless, if you use --data-ciphers and the clients are OpenVPN >=
2.4.0 or if system library >= OpenSSL-1.1.0 they will use the --data-
ciphers algorithm before --data-cipher-fallback.

> 
> For the Control-Channel sections I would suggest swapping the order
> of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most
> secure to least secure from left to right. I think that the
> Control-Channel should do the same.
Gret, good idea. Done.

> 
> I don't have any comments about the defaults. They seem reasonable to
> me.
Yes, the cipher listing takes also care of the order i think.

> 
> Excellent work, it's looking very nice.
Thanks for the flowers always good to hear :-) .

> 
> Regards,
> Adolf.

Best,

Erik

P.S. Short update. I moved now the --cipher and --auth part from the
global to the advanced encryption page. I think the defaults should
handle it for not so experience users so they do not need to bother
around with all that. Am not sure if the layout looks good, for a short
look -->
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_enc_hmac.png 
or should we leave it as a flip menu ?

> 
> 
> On 22/11/2020 17:30, ummeegge wrote:
> > Hi all,
> > i am currently in the update process of the already realeased
> > OpenVPN-
> > 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update
> > has
> > been tested and worked so far also with the old default client
> > configuration (tested with 2.4.9 client). There are two warnings
> > -->
> > 
> > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
> > negotiation
> > is a deprecated debug feature that will be removed in OpenVPN 2.6
> > 
> > 2) WARNING: --topology net30 support for server configs with IPv4
> > pools
> > will be removed in a future release. Please migrate to --topology
> > subnet as soon as possible.
> > 
> > in the server log but it nevertheless works flawlessly.
> > 
> > Am working currently on an "Advanced Encryption Settings" page
> > which
> > includes currently four new directives --data-ciphers (data channel
> > encryption), --data-ciphers-fallback (data-channel encryption for
> > clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
> > only)
> > and --tls-ciphersuites (control channel >= TLSv3) all options are
> > explained in here -->
> > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> > , which works here currently and looks like this:
> > 
> > Button to belong to this page:
> >
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> > 
> > And the page itself:
> >
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> > 
> > 
> > You can see also the default settings, were i need also your ideas
> > and
> > comments for may better defaults.
> > On the page itself is also more planned but to not overload this
> > here
> > now, i wanted to go now a two step procedure with this update.
> > 
> > 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
> > regukar
> > global settings for RW and N2N. A overview of the new crypto can be
> > found in here -->
> > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
.
> > 2) I would push the "Advanced Encryption settings" development as
> > seen
> > above then as one patch <-- this would also eliminate the first
> > warning
> > causing --ncp-disable since we can delete this option then.
> > 
> > Everything else would come detached from this.
> > 
> > Some feedback might be nice.
> > 
> > Best,
> > 
> > Erik
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Am Montag, den 23.11.2020, 09:28 -0500 schrieb Kienker, Fred:
> Eric:
> 
> The idea of putting all of the encryption settings on one page is a
> good 
> one. There are now so many encryption settings and choices that they 
> really need their own page.
Yes, and there are even more may also good directives ;-) .

> 
> The settings changes, at first look, should work but sometimes these 
> backwards compatibility settings don't always work as advertised.. 
> Testing with a variety of clients and both the current and reasonable
> legacy versions would be recommended, even if it is hard to get
> people 
> to assist. With OpenVPN people have a tendency to set it up, get it 
> working and leave it alone until it stops working so there are always
> a 
> lot of old clients out there. 
Exactly, the --data-cipher-fallback uses the index of the already
configured --cipher, in that case no interaction is needed from the
user to run the old system. To enable the new --data-ciphers option the
user would need to interact (at least press the save button in the
advanced section) which is not needed in that case... So was my
implementation idea...

> 
> Best regards, 
> Fred

Best,

Erik

> 
> Please note: Although we may sometimes respond to email, text and
> phone 
> calls instantly at all hours of the day, our regular business hours
> are 
> 9:00 AM - 6:00 PM ET, Monday thru Friday.
> 
> -----Original Message-----
> From: ummeegge <ummeegge(a)ipfire.org> 
> Sent: Monday, November 23, 2020 4:15 AM
> To: development(a)lists.ipfire.org
> Subject: Re: OpenVPN-2.5.0 update procedure and idea collector
> 
> Some additions and WUI restructure ideas after some more testings.
> 
> '--cipher' is no longer needed if '--data-cipher-fallback' is in
> usage, 
> there is also no need for '--data-ciphers' for the first if '--data- 
> cipher-fallback' is active. The client can still uses the '--cipher
> alg' 
> directive and the 2.5.0 server responds with '--data-ciphers-
> fallback 
> alg' .
> 
> The idea: Remove the cipher section from the global area from the
> WUI, 
> rename simply '--cipher' to '--data-ciphers-fallback' in server.conf
> and 
> keep the index, include the 'DCIPHER' (also 'DAUTH' and 'TLSAUTH')
> variable(s) to the advanced encryption section with the related
> indexes 
> to keep the old configuration but set also new defaults for new 
> configurations.
> 
> If '--data-ciphers' is active, all old clients have the chance with
> e.g. 
> an old CBC cipher to migrate also to newer clients step-by-step so we
> can get rid of the old broken algorithms like CAST, DES and BF since 
> they won´t appear in the new advanced encryption section...
> 
> 
> As an idea !?
> 
> Best,
> 
> Erik
> 
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer]

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

Hello everyone,

Good to see that we are moving forward on making OpenVPN on IPFire better.

To avoid that the conversation is getting stuck again, can we split the problems into many smaller ones instead of having one massive thread again? I think I suggested that some time before and it would really help us to stay on track with things and ideally merge everything that is done already so that we do not end up with one massive patchset that is getting really difficult to work with later on.

> On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi all,
> i am currently in the update process of the already realeased OpenVPN-
> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update has
> been tested and worked so far also with the old default client
> configuration (tested with 2.4.9 client). There are two warnings -->

Which clients to we want to support?

Is it possible and do we want to support OpenVPN 2.3, too?

Depending on when the last release has been, it might not be worth it.

> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
> is a deprecated debug feature that will be removed in OpenVPN 2.6

I think we have a good way to migrate cryptography.

> 2) WARNING: --topology net30 support for server configs with IPv4 pools
> will be removed in a future release. Please migrate to --topology
> subnet as soon as possible.

This seems to be much trickier.

> in the server log but it nevertheless works flawlessly.
> 
> Am working currently on an "Advanced Encryption Settings" page which
> includes currently four new directives --data-ciphers (data channel
> encryption), --data-ciphers-fallback (data-channel encryption for
> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only)
> and --tls-ciphersuites (control channel >= TLSv3) all options are
> explained in here --> 
> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> , which works here currently and looks like this:
> 
> Button to belong to this page:
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> 
> And the page itself:
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png

In order to keep things like this archived for later, you can simply attach them to the email that you send to the list :)

Then I have some questions:

1) Does this need to be an extra page? Why didn’t you put this on the advanced server options page?

2) What is the use-case for choosing different things for the data/control channel?

I am asking this because I find this really confusing. Why does OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2? Should we not hide this from the user, because otherwise editing the configuration file is easier?

I assume that clients <= version 2.3 cannot use cipher negotiation? How is it possible to select multiple options here and this still works?

> You can see also the default settings, were i need also your ideas and
> comments for may better defaults.

I am sure we have talked about this somewhere and we even came up with a decision…

It must be here on the list somewhere...

> On the page itself is also more planned but to not overload this here
> now, i wanted to go now a two step procedure with this update.
> 
> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for regukar
> global settings for RW and N2N. A overview of the new crypto can be
> found in here -->
> https://community.ipfire.org/t/openvpn-2-5-development-version/2173 .
> 2) I would push the "Advanced Encryption settings" development as seen
> above then as one patch <-- this would also eliminate the first warning
> causing --ncp-disable since we can delete this option then.

I do not understand how we can split this into two steps because I thought OpenVPN 2.5 won’t work with the current settings?!

-Michael

> Everything else would come detached from this.
> 
> Some feedback might be nice.
> 
> Best,
> 
> Erik
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer]

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

Hi,

> On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
> 
> Hi Erik,
> 
> Thanks for all your work on OpenVPN. Much appreciated, especially in these challenging times of many changes.
> 
> Am I correct in my presumption that in the advanced encryption settings GUI we will be able to select multiple entries, which will then be made into a list in order that the entries are in the tables.
> 
> From the advanced encryption settings page I see that you have removed the old insecure options, which is good.

It is good to encourage people to use modern cryptography, but I would like to raise the point that if we want to support older clients, we will have to support the old crypto, too. Otherwise it is not worth to add the extra work if it is virtually unusable.

> For the Data-Channel fallback do you have to have a default or can you unselect everything. There could be people who only want to connect to systems that have the strongest ciphers and just refuse to connect with weaker ones.
> 
> For the Control-Channel sections I would suggest swapping the order of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most secure to least secure from left to right. I think that the Control-Channel should do the same.
> 
> I don't have any comments about the defaults. They seem reasonable to me.
> 
> Excellent work, it's looking very nice.
> 
> Regards,
> Adolf.
> 
> 
> On 22/11/2020 17:30, ummeegge wrote:
>> Hi all,
>> i am currently in the update process of the already realeased OpenVPN-
>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update has
>> been tested and worked so far also with the old default client
>> configuration (tested with 2.4.9 client). There are two warnings -->
>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>> 2) WARNING: --topology net30 support for server configs with IPv4 pools
>> will be removed in a future release. Please migrate to --topology
>> subnet as soon as possible.
>> in the server log but it nevertheless works flawlessly.
>> Am working currently on an "Advanced Encryption Settings" page which
>> includes currently four new directives --data-ciphers (data channel
>> encryption), --data-ciphers-fallback (data-channel encryption for
>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only)
>> and --tls-ciphersuites (control channel >= TLSv3) all options are
>> explained in here -->
>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>> , which works here currently and looks like this:
>> Button to belong to this page:
>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>> And the page itself:
>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>> You can see also the default settings, were i need also your ideas and
>> comments for may better defaults.
>> On the page itself is also more planned but to not overload this here
>> now, i wanted to go now a two step procedure with this update.
>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for regukar
>> global settings for RW and N2N. A overview of the new crypto can be
>> found in here -->
>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173 .
>> 2) I would push the "Advanced Encryption settings" development as seen
>> above then as one patch <-- this would also eliminate the first warning
>> causing --ncp-disable since we can delete this option then.
>> Everything else would come detached from this.
>> Some feedback might be nice.
>> Best,
>> Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer]

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

Hi,

> On 23 Nov 2020, at 14:28, Kienker, Fred <fkienker(a)at4b.com> wrote:
> 
> Eric:
> 
> The idea of putting all of the encryption settings on one page is a good 
> one. There are now so many encryption settings and choices that they 
> really need their own page.

If we need an extra page, I would say we have done our job wrong.

We need to make sure that this is easy to use. If we have a whole page full of cryptography options that are very dangerous to change (because that is how OpenVPN works) then we will only have people with broken setups.

> The settings changes, at first look, should work but sometimes these 
> backwards compatibility settings don't always work as advertised.. 
> Testing with a variety of clients and both the current and reasonable 
> legacy versions would be recommended, even if it is hard to get people 
> to assist. With OpenVPN people have a tendency to set it up, get it 
> working and leave it alone until it stops working so there are always a 
> lot of old clients out there. 
> 
> Best regards, 
> Fred
> 
> Please note: Although we may sometimes respond to email, text and phone 
> calls instantly at all hours of the day, our regular business hours are 
> 9:00 AM - 6:00 PM ET, Monday thru Friday.
> 
> -----Original Message-----
> From: ummeegge <ummeegge(a)ipfire.org> 
> Sent: Monday, November 23, 2020 4:15 AM
> To: development(a)lists.ipfire.org
> Subject: Re: OpenVPN-2.5.0 update procedure and idea collector
> 
> Some additions and WUI restructure ideas after some more testings.
> 
> '--cipher' is no longer needed if '--data-cipher-fallback' is in usage, 
> there is also no need for '--data-ciphers' for the first if '--data- 
> cipher-fallback' is active. The client can still uses the '--cipher alg' 
> directive and the 2.5.0 server responds with '--data-ciphers- fallback 
> alg' .
> 
> The idea: Remove the cipher section from the global area from the WUI, 
> rename simply '--cipher' to '--data-ciphers-fallback' in server.conf and 
> keep the index, include the 'DCIPHER' (also 'DAUTH' and 'TLSAUTH')
> variable(s) to the advanced encryption section with the related indexes 
> to keep the old configuration but set also new defaults for new 
> configurations.
> 
> If '--data-ciphers' is active, all old clients have the chance with e.g. 
> an old CBC cipher to migrate also to newer clients step-by-step so we 
> can get rid of the old broken algorithms like CAST, DES and BF since 
> they won´t appear in the new advanced encryption section...
> 
> 
> As an idea !?
> 
> Best,
> 
> Erik
> 
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi Michael,

Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
> Hello everyone,
> 
> Good to see that we are moving forward on making OpenVPN on IPFire
> better.
Bigger hurdles at this time ;-).

> 
> To avoid that the conversation is getting stuck again, can we split
> the problems into many smaller ones instead of having one massive
> thread again? I think I suggested that some time before and it would
> really help us to stay on track with things and ideally merge
> everything that is done already so that we do not end up with one
> massive patchset that is getting really difficult to work with later
> on.
Might it be an idea to go for the initial post, with the update to
2.5.0 new crypto for N2N, nothing changed for RW. In the same or may
the next core update a "Advanced Cyrpto Section" delivers data-cipher,
data-cipher-fallback, can but must not be tls-cipher, tls-ciphersuite -
-> both are new ?

> 
> > On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi all,
> > i am currently in the update process of the already realeased
> > OpenVPN-
> > 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update
> > has
> > been tested and worked so far also with the old default client
> > configuration (tested with 2.4.9 client). There are two warnings
> > -->
> 
> Which clients to we want to support?
> 
> Is it possible and do we want to support OpenVPN 2.3, too?
Yes it is posible to support <= 2.3.x . Every client needs to be aware
of the Galois-Counte-Mode otherwise we would need --> '--data-ciper-
fallback' which is equal to the current --cipher directive in 2.5.0 ...
Try to sort it in that way...

> 
> Depending on when the last release has been, it might not be worth
> it.
It´s possible but also practical to deliver the chance to migrate via -
-data-cipher-fallback (only one cipher, taken the already existing
'DCIPHER' in that case).

> 
> > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
> > negotiation
> > is a deprecated debug feature that will be removed in OpenVPN 2.6
> 
> I think we have a good way to migrate cryptography.
Me too, question is how.

> 
> > 2) WARNING: --topology net30 support for server configs with IPv4
> > pools
> > will be removed in a future release. Please migrate to --topology
> > subnet as soon as possible.
> 
> This seems to be much trickier.
Haven´t been there more than one hour ;-) but there seems to be more
time with that (no 2.6 hint to change it)...

> 
> > in the server log but it nevertheless works flawlessly.
> > 
> > Am working currently on an "Advanced Encryption Settings" page
> > which
> > includes currently four new directives --data-ciphers (data channel
> > encryption), --data-ciphers-fallback (data-channel encryption for
> > clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
> > only)
> > and --tls-ciphersuites (control channel >= TLSv3) all options are
> > explained in here --> 
> > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> > , which works here currently and looks like this:
> > 
> > Button to belong to this page:
> >
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> > 
> > And the page itself:
> >
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> 
> In order to keep things like this archived for later, you can simply
> attach them to the email that you send to the list :)
Ohh didn´t see that :D hope i do not forget it until the next time...
Best is i deliver the code and more people can go for a checkout ?

> 
> Then I have some questions:
> 
> 1) Does this need to be an extra page? Why didn’t you put this on the
> advanced server options page?
Simply too much, i thought the IPSec workflow is the best one i could
choose.

> 
> 2) What is the use-case for choosing different things for the
> data/control channel?
More possibilites equal to IPSec but also more flexibility to the
existing infrastructure/features. Nevertheless a default can be
existant like it is in IPsec advanced crypto page. Should we
enable/disable/delete the control channel crypto section ?

> 
> I am asking this because I find this really confusing. Why does
> OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2?
> Should we not hide this from the user, because otherwise editing the
> configuration file is easier?
Yeah this is confusing. TLSv3 for the control channel is another
dierctive (--tls-ciphersuites), the channel control with TLSv2 uses the
--tls-cipher directive. May also not that bad, fututre sound of music,
TLSv2 will sooner or later go and there is than --tls-ciphersuites ?!

> 
> I assume that clients <= version 2.3 cannot use cipher negotiation?
> How is it possible to select multiple options here and this still
> works?
That´s true. 2.3 have no plan how to use the NegotiationCipherProtocol
. In that case the new directive '--data-ciphers-fallback algo' which
is simply '--cipher alg' , as we know it, handles this.

> 
> > You can see also the default settings, were i need also your ideas
> > and
> > comments for may better defaults.
> 
> I am sure we have talked about this somewhere and we even came up
> with a decision…
Yes i know it too but we didn´t go into depth in there ;-) .

> 
> It must be here on the list somewhere...
1000% :-) .

> 
> > On the page itself is also more planned but to not overload this
> > here
> > now, i wanted to go now a two step procedure with this update.
> > 
> > 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
> > regukar
> > global settings for RW and N2N. A overview of the new crypto can be
> > found in here -->
> > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
.
> > 2) I would push the "Advanced Encryption settings" development as
> > seen
> > above then as one patch <-- this would also eliminate the first
> > warning
> > causing --ncp-disable since we can delete this option then.
> 
> I do not understand how we can split this into two steps because I
> thought OpenVPN 2.5 won’t work with the current settings?!
For RW are only two warnings (NCP, topology) but it works here, which
is for N2N not that hard since N2N do not understands
'push|SENT_CONTROL' and it works also not with --topology net30. I
would give N2N all that new stuff for ciphers and HMACs but the RW runs
for the first without modifications. This could be the second patch ?! 
Ater that let´s check the warnings, one is here already more or less
for me comfortably solved :D .

> 
> -Michael

Great feedback thanks Michael...

> 
> > Everything else would come detached from this.
> > 
> > Some feedback might be nice.
> > 
> > Best,
> > 
> > Erik
> > 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi Michael,


On 23/11/2020 19:00, Michael Tremer wrote:
> Hi,
> 
>> On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>
>> Hi Erik,
>>
>> Thanks for all your work on OpenVPN. Much appreciated, especially in these challenging times of many changes.
>>
>> Am I correct in my presumption that in the advanced encryption settings GUI we will be able to select multiple entries, which will then be made into a list in order that the entries are in the tables.
>>
>>  From the advanced encryption settings page I see that you have removed the old insecure options, which is good.
> 
> It is good to encourage people to use modern cryptography, but I would like to raise the point that if we want to support older clients, we will have to support the old crypto, too. Otherwise it is not worth to add the extra work if it is virtually unusable.

I understand the need/desire to support older clients but I just wonder how old we should be supporting. Erik's previous page picture showed the older crypto (BF-CBC, CAST etc) which were marked Data-Channel fallback (insecure). If those are going to be left in then I think they should be labelled Data-Channel fallback (insecure/deprecated) so people know they are not secure and/or likely to disappear before too long.

I also want to be sure that if these unsecure algorithms are listed and selected for fallback I want to be sure that there is no way for my system to fallback to using them by accident or whatever. That is why I would then like to have the ability to not have any fallback algorithm selected. The default can be to have one or more selected but I would like to be able to unselect all fallback algorithms if they are of this type of security.

> 
>> For the Data-Channel fallback do you have to have a default or can you unselect everything. There could be people who only want to connect to systems that have the strongest ciphers and just refuse to connect with weaker ones.
>>
>> For the Control-Channel sections I would suggest swapping the order of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most secure to least secure from left to right. I think that the Control-Channel should do the same.
>>
>> I don't have any comments about the defaults. They seem reasonable to me.
>>
>> Excellent work, it's looking very nice.
>>
>> Regards,
>> Adolf.
>>
>>
>> On 22/11/2020 17:30, ummeegge wrote:
>>> Hi all,
>>> i am currently in the update process of the already realeased OpenVPN-
>>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update has
>>> been tested and worked so far also with the old default client
>>> configuration (tested with 2.4.9 client). There are two warnings -->
>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>>> 2) WARNING: --topology net30 support for server configs with IPv4 pools
>>> will be removed in a future release. Please migrate to --topology
>>> subnet as soon as possible.
>>> in the server log but it nevertheless works flawlessly.
>>> Am working currently on an "Advanced Encryption Settings" page which
>>> includes currently four new directives --data-ciphers (data channel
>>> encryption), --data-ciphers-fallback (data-channel encryption for
>>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only)
>>> and --tls-ciphersuites (control channel >= TLSv3) all options are
>>> explained in here -->
>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>> , which works here currently and looks like this:
>>> Button to belong to this page:
>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>>> And the page itself:
>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>>> You can see also the default settings, were i need also your ideas and
>>> comments for may better defaults.
>>> On the page itself is also more planned but to not overload this here
>>> now, i wanted to go now a two step procedure with this update.
>>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for regukar
>>> global settings for RW and N2N. A overview of the new crypto can be
>>> found in here -->
>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173 .
>>> 2) I would push the "Advanced Encryption settings" development as seen
>>> above then as one patch <-- this would also eliminate the first warning
>>> causing --ncp-disable since we can delete this option then.
>>> Everything else would come detached from this.
>>> Some feedback might be nice.
>>> Best,
>>> Erik
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi Erik,


On 23/11/2020 20:49, ummeegge wrote:
> Hi Michael,
> 
> Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
>> Hello everyone,
>>
>> Good to see that we are moving forward on making OpenVPN on IPFire
>> better.
> Bigger hurdles at this time ;-).
> 
>>
>> To avoid that the conversation is getting stuck again, can we split
>> the problems into many smaller ones instead of having one massive
>> thread again? I think I suggested that some time before and it would
>> really help us to stay on track with things and ideally merge
>> everything that is done already so that we do not end up with one
>> massive patchset that is getting really difficult to work with later
>> on.
> Might it be an idea to go for the initial post, with the update to
> 2.5.0 new crypto for N2N, nothing changed for RW. In the same or may
> the next core update a "Advanced Cyrpto Section" delivers data-cipher,
> data-cipher-fallback, can but must not be tls-cipher, tls-ciphersuite -
> -> both are new ?
> 

All of my experience to date is with RW. If you will use N2N initially I will have to see if I am able to set an N2N system up in my Virtual test bed. I will only be able to test out any OpenVPN changes in N2N if I am successful in setting that up. I will give it a go.

>>
>>> On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
>>>
>>> Hi all,
>>> i am currently in the update process of the already realeased
>>> OpenVPN-
>>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update
>>> has
>>> been tested and worked so far also with the old default client
>>> configuration (tested with 2.4.9 client). There are two warnings
>>> -->
>>
>> Which clients to we want to support?
>>
>> Is it possible and do we want to support OpenVPN 2.3, too?
> Yes it is posible to support <= 2.3.x . Every client needs to be aware
> of the Galois-Counte-Mode otherwise we would need --> '--data-ciper-
> fallback' which is equal to the current --cipher directive in 2.5.0 ...
> Try to sort it in that way...
> 
>>
>> Depending on when the last release has been, it might not be worth
>> it.
> It´s possible but also practical to deliver the chance to migrate via -
> -data-cipher-fallback (only one cipher, taken the already existing
> 'DCIPHER' in that case).
> 
>>
>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
>>> negotiation
>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>>
>> I think we have a good way to migrate cryptography.
> Me too, question is how.
> 
>>
>>> 2) WARNING: --topology net30 support for server configs with IPv4
>>> pools
>>> will be removed in a future release. Please migrate to --topology
>>> subnet as soon as possible.
>>
>> This seems to be much trickier.
> Haven´t been there more than one hour ;-) but there seems to be more
> time with that (no 2.6 hint to change it)...
> 
>>
>>> in the server log but it nevertheless works flawlessly.
>>>
>>> Am working currently on an "Advanced Encryption Settings" page
>>> which
>>> includes currently four new directives --data-ciphers (data channel
>>> encryption), --data-ciphers-fallback (data-channel encryption for
>>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
>>> only)
>>> and --tls-ciphersuites (control channel >= TLSv3) all options are
>>> explained in here -->
>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>> , which works here currently and looks like this:
>>>
>>> Button to belong to this page:
>>>
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>>>
>>> And the page itself:
>>>
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>>
>> In order to keep things like this archived for later, you can simply
>> attach them to the email that you send to the list :)
> Ohh didn´t see that :D hope i do not forget it until the next time...
> Best is i deliver the code and more people can go for a checkout ?
> 
>>
>> Then I have some questions:
>>
>> 1) Does this need to be an extra page? Why didn’t you put this on the
>> advanced server options page?
> Simply too much, i thought the IPSec workflow is the best one i could
> choose.
> 
>>
>> 2) What is the use-case for choosing different things for the
>> data/control channel?
> More possibilites equal to IPSec but also more flexibility to the
> existing infrastructure/features. Nevertheless a default can be
> existant like it is in IPsec advanced crypto page. Should we
> enable/disable/delete the control channel crypto section ?
> 
>>
>> I am asking this because I find this really confusing. Why does
>> OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2?
>> Should we not hide this from the user, because otherwise editing the
>> configuration file is easier?
> Yeah this is confusing. TLSv3 for the control channel is another
> dierctive (--tls-ciphersuites), the channel control with TLSv2 uses the
> --tls-cipher directive. May also not that bad, fututre sound of music,
> TLSv2 will sooner or later go and there is than --tls-ciphersuites ?!
> 
>>
>> I assume that clients <= version 2.3 cannot use cipher negotiation?
>> How is it possible to select multiple options here and this still
>> works?
> That´s true. 2.3 have no plan how to use the NegotiationCipherProtocol
> . In that case the new directive '--data-ciphers-fallback algo' which
> is simply '--cipher alg' , as we know it, handles this.
> 
>>
>>> You can see also the default settings, were i need also your ideas
>>> and
>>> comments for may better defaults.
>>
>> I am sure we have talked about this somewhere and we even came up
>> with a decision…
> Yes i know it too but we didn´t go into depth in there ;-) .
> 
>>
>> It must be here on the list somewhere...
> 1000% :-) .
> 
>>
>>> On the page itself is also more planned but to not overload this
>>> here
>>> now, i wanted to go now a two step procedure with this update.
>>>
>>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
>>> regukar
>>> global settings for RW and N2N. A overview of the new crypto can be
>>> found in here -->
>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> .
>>> 2) I would push the "Advanced Encryption settings" development as
>>> seen
>>> above then as one patch <-- this would also eliminate the first
>>> warning
>>> causing --ncp-disable since we can delete this option then.
>>
>> I do not understand how we can split this into two steps because I
>> thought OpenVPN 2.5 won’t work with the current settings?!
> For RW are only two warnings (NCP, topology) but it works here, which
> is for N2N not that hard since N2N do not understands
> 'push|SENT_CONTROL' and it works also not with --topology net30. I
> would give N2N all that new stuff for ciphers and HMACs but the RW runs
> for the first without modifications. This could be the second patch ?!
> Ater that let´s check the warnings, one is here already more or less
> for me comfortably solved :D .
> 
>>
>> -Michael
> 
> Great feedback thanks Michael...
> 
>>
>>> Everything else would come detached from this.
>>>
>>> Some feedback might be nice.
>>>
>>> Best,
>>>
>>> Erik
>>>
>>
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi all,

Am Montag, den 23.11.2020, 23:29 +0100 schrieb Adolf Belka:
> Hi Michael,
> 
> 
> On 23/11/2020 19:00, Michael Tremer wrote:
> > Hi,
> > 
> > > On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com>
> > > wrote:
> > > 
> > > Hi Erik,
> > > 
> > > Thanks for all your work on OpenVPN. Much appreciated, especially
> > > in these challenging times of many changes.
> > > 
> > > Am I correct in my presumption that in the advanced encryption
> > > settings GUI we will be able to select multiple entries, which
> > > will then be made into a list in order that the entries are in
> > > the tables.
> > > 
> > >  From the advanced encryption settings page I see that you have
> > > removed the old insecure options, which is good.
> > 
> > It is good to encourage people to use modern cryptography, but I
> > would like to raise the point that if we want to support older
> > clients, we will have to support the old crypto, too. Otherwise it
> > is not worth to add the extra work if it is virtually unusable.
> 
> I understand the need/desire to support older clients but I just
> wonder how old we should be supporting. Erik's previous page picture
> showed the older crypto (BF-CBC, CAST etc) which were marked Data-
> Channel fallback (insecure). If those are going to be left in then I
> think they should be labelled Data-Channel fallback
> (insecure/deprecated) so people know they are not secure and/or
> likely to disappear before too long.
Did that now in the menu 'insecure/broken' for DES, BF and Cast.
Shouldn´t we probably mark CBC in general also as 'insecure' ?

> 
> I also want to be sure that if these unsecure algorithms are listed
> and selected for fallback I want to be sure that there is no way for
> my system to fallback to using them by accident or whatever. That is
> why I would then like to have the ability to not have any fallback
> algorithm selected. The default can be to have one or more selected
> but I would like to be able to unselect all fallback algorithms if
> they are of this type of security.
Have tested this with a client (2.4.9) which have had AES-256-CBC as --
cipher configured. The server provided --data-ciphers ChaCha20-
Poly1305:AES-256-GCM but also --data-ciphers-fallback AES-256-CBC and
the connection initiated the data channel with AES-256-GCM which i
think is even better than the existing client configuration provides
it. May there are also good news :-) .

> 
> > 
> > > For the Data-Channel fallback do you have to have a default or
> > > can you unselect everything. There could be people who only want
> > > to connect to systems that have the strongest ciphers and just
> > > refuse to connect with weaker ones.
> > > 
> > > For the Control-Channel sections I would suggest swapping the
> > > order of TLSv2 and TLSv3 on the screen. The Data-Channel goes
> > > from most secure to least secure from left to right. I think that
> > > the Control-Channel should do the same.
> > > 
> > > I don't have any comments about the defaults. They seem
> > > reasonable to me.
> > > 
> > > Excellent work, it's looking very nice.
> > > 
> > > Regards,
> > > Adolf.
> > > 
> > > 
> > > On 22/11/2020 17:30, ummeegge wrote:
> > > > Hi all,
> > > > i am currently in the update process of the already realeased
> > > > OpenVPN-
> > > > 2.5.0 --> https://openvpn.net/community-downloads-2/ . The
> > > > update has
> > > > been tested and worked so far also with the old default client
> > > > configuration (tested with 2.4.9 client). There are two
> > > > warnings -->
> > > > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
> > > > negotiation
> > > > is a deprecated debug feature that will be removed in OpenVPN
> > > > 2.6
> > > > 2) WARNING: --topology net30 support for server configs with
> > > > IPv4 pools
> > > > will be removed in a future release. Please migrate to --
> > > > topology
> > > > subnet as soon as possible.
> > > > in the server log but it nevertheless works flawlessly.
> > > > Am working currently on an "Advanced Encryption Settings" page
> > > > which
> > > > includes currently four new directives --data-ciphers (data
> > > > channel
> > > > encryption), --data-ciphers-fallback (data-channel encryption
> > > > for
> > > > clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
> > > > only)
> > > > and --tls-ciphersuites (control channel >= TLSv3) all options
> > > > are
> > > > explained in here -->
> > > > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> > > > , which works here currently and looks like this:
> > > > Button to belong to this page:
> > > >   
> > > > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> > > > And the page itself:
> > > >   
> > > > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> > > > You can see also the default settings, were i need also your
> > > > ideas and
> > > > comments for may better defaults.
> > > > On the page itself is also more planned but to not overload
> > > > this here
> > > > now, i wanted to go now a two step procedure with this update.
> > > > 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
> > > > regukar
> > > > global settings for RW and N2N. A overview of the new crypto
> > > > can be
> > > > found in here -->
> > > >   
> > > > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> > > >  .
> > > > 2) I would push the "Advanced Encryption settings" development
> > > > as seen
> > > > above then as one patch <-- this would also eliminate the first
> > > > warning
> > > > causing --ncp-disable since we can delete this option then.
> > > > Everything else would come detached from this.
> > > > Some feedback might be nice.
> > > > Best,
> > > > Erik
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hello Adolf,

Am Montag, den 23.11.2020, 23:38 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> 
> On 23/11/2020 20:49, ummeegge wrote:
> > Hi Michael,
> > 
> > Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
> > > Hello everyone,
> > > 
> > > Good to see that we are moving forward on making OpenVPN on
> > > IPFire
> > > better.
> > Bigger hurdles at this time ;-).
> > 
> > > 
> > > To avoid that the conversation is getting stuck again, can we
> > > split
> > > the problems into many smaller ones instead of having one massive
> > > thread again? I think I suggested that some time before and it
> > > would
> > > really help us to stay on track with things and ideally merge
> > > everything that is done already so that we do not end up with one
> > > massive patchset that is getting really difficult to work with
> > > later
> > > on.
> > Might it be an idea to go for the initial post, with the update to
> > 2.5.0 new crypto for N2N, nothing changed for RW. In the same or
> > may
> > the next core update a "Advanced Cyrpto Section" delivers data-
> > cipher,
> > data-cipher-fallback, can but must not be tls-cipher, tls-
> > ciphersuite -
> > -> both are new ?
> > 
> 
> All of my experience to date is with RW. If you will use N2N
> initially I will have to see if I am able to set an N2N system up in
> my Virtual test bed. I will only be able to test out any OpenVPN
> changes in N2N if I am successful in setting that up. I will give it
> a go.
Great thanks for that. If i get responds from Michael i will start over
with this. I can neverthless push also the RW code changes to my Git
repo if you want to go for some testings also in there.

> 
> > > 
> > > > On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > > 
> > > > Hi all,
> > > > i am currently in the update process of the already realeased
> > > > OpenVPN-
> > > > 2.5.0 --> https://openvpn.net/community-downloads-2/ . The
> > > > update
> > > > has
> > > > been tested and worked so far also with the old default client
> > > > configuration (tested with 2.4.9 client). There are two
> > > > warnings
> > > > -->
> > > 
> > > Which clients to we want to support?
> > > 
> > > Is it possible and do we want to support OpenVPN 2.3, too?
> > Yes it is posible to support <= 2.3.x . Every client needs to be
> > aware
> > of the Galois-Counte-Mode otherwise we would need --> '--data-
> > ciper-
> > fallback' which is equal to the current --cipher directive in 2.5.0
> > ...
> > Try to sort it in that way...
> > 
> > > 
> > > Depending on when the last release has been, it might not be
> > > worth
> > > it.
> > It´s possible but also practical to deliver the chance to migrate
> > via -
> > -data-cipher-fallback (only one cipher, taken the already existing
> > 'DCIPHER' in that case).
> > 
> > > 
> > > > 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
> > > > negotiation
> > > > is a deprecated debug feature that will be removed in OpenVPN
> > > > 2.6
> > > 
> > > I think we have a good way to migrate cryptography.
> > Me too, question is how.
> > 
> > > 
> > > > 2) WARNING: --topology net30 support for server configs with
> > > > IPv4
> > > > pools
> > > > will be removed in a future release. Please migrate to --
> > > > topology
> > > > subnet as soon as possible.
> > > 
> > > This seems to be much trickier.
> > Haven´t been there more than one hour ;-) but there seems to be
> > more
> > time with that (no 2.6 hint to change it)...
> > 
> > > 
> > > > in the server log but it nevertheless works flawlessly.
> > > > 
> > > > Am working currently on an "Advanced Encryption Settings" page
> > > > which
> > > > includes currently four new directives --data-ciphers (data
> > > > channel
> > > > encryption), --data-ciphers-fallback (data-channel encryption
> > > > for
> > > > clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
> > > > only)
> > > > and --tls-ciphersuites (control channel >= TLSv3) all options
> > > > are
> > > > explained in here -->
> > > > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
> > > > , which works here currently and looks like this:
> > > > 
> > > > Button to belong to this page:
> > > > 
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
> > > > 
> > > > And the page itself:
> > > > 
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
> > > 
> > > In order to keep things like this archived for later, you can
> > > simply
> > > attach them to the email that you send to the list :)
> > Ohh didn´t see that :D hope i do not forget it until the next
> > time...
> > Best is i deliver the code and more people can go for a checkout ?
> > 
> > > 
> > > Then I have some questions:
> > > 
> > > 1) Does this need to be an extra page? Why didn’t you put this on
> > > the
> > > advanced server options page?
> > Simply too much, i thought the IPSec workflow is the best one i
> > could
> > choose.
> > 
> > > 
> > > 2) What is the use-case for choosing different things for the
> > > data/control channel?
> > More possibilites equal to IPSec but also more flexibility to the
> > existing infrastructure/features. Nevertheless a default can be
> > existant like it is in IPsec advanced crypto page. Should we
> > enable/disable/delete the control channel crypto section ?
> > 
> > > 
> > > I am asking this because I find this really confusing. Why does
> > > OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2?
> > > Should we not hide this from the user, because otherwise editing
> > > the
> > > configuration file is easier?
> > Yeah this is confusing. TLSv3 for the control channel is another
> > dierctive (--tls-ciphersuites), the channel control with TLSv2 uses
> > the
> > --tls-cipher directive. May also not that bad, fututre sound of
> > music,
> > TLSv2 will sooner or later go and there is than --tls-ciphersuites
> > ?!
> > 
> > > 
> > > I assume that clients <= version 2.3 cannot use cipher
> > > negotiation?
> > > How is it possible to select multiple options here and this still
> > > works?
> > That´s true. 2.3 have no plan how to use the
> > NegotiationCipherProtocol
> > . In that case the new directive '--data-ciphers-fallback algo'
> > which
> > is simply '--cipher alg' , as we know it, handles this.
> > 
> > > 
> > > > You can see also the default settings, were i need also your
> > > > ideas
> > > > and
> > > > comments for may better defaults.
> > > 
> > > I am sure we have talked about this somewhere and we even came up
> > > with a decision…
> > Yes i know it too but we didn´t go into depth in there ;-) .
> > 
> > > 
> > > It must be here on the list somewhere...
> > 1000% :-) .
> > 
> > > 
> > > > On the page itself is also more planned but to not overload
> > > > this
> > > > here
> > > > now, i wanted to go now a two step procedure with this update.
> > > > 
> > > > 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
> > > > regukar
> > > > global settings for RW and N2N. A overview of the new crypto
> > > > can be
> > > > found in here -->
> > > > https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> > .
> > > > 2) I would push the "Advanced Encryption settings" development
> > > > as
> > > > seen
> > > > above then as one patch <-- this would also eliminate the first
> > > > warning
> > > > causing --ncp-disable since we can delete this option then.
> > > 
> > > I do not understand how we can split this into two steps because
> > > I
> > > thought OpenVPN 2.5 won’t work with the current settings?!
> > For RW are only two warnings (NCP, topology) but it works here,
> > which
> > is for N2N not that hard since N2N do not understands
> > 'push|SENT_CONTROL' and it works also not with --topology net30. I
> > would give N2N all that new stuff for ciphers and HMACs but the RW
> > runs
> > for the first without modifications. This could be the second patch
> > ?!
> > Ater that let´s check the warnings, one is here already more or
> > less
> > for me comfortably solved :D .
> > 
> > > 
> > > -Michael
> > 
> > Great feedback thanks Michael...
> > 
> > > 
> > > > Everything else would come detached from this.
> > > > 
> > > > Some feedback might be nice.
> > > > 
> > > > Best,
> > > > 
> > > > Erik
> > > > 
> > > 
> > 
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi all,
for the interested ones, have push the current state to my repo which
can be found in here -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
feel free to test and criticize it :-) .

After integration and configuration, the 'save' button in the global
section should also be pushed since --cipher will replaced by --data-
channel-fallback. For the langs files, a update-lang-cache should be
executed via console so the changes can take affect.

Happy testing. Best,

Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi Erik,

I take it that I need to take the patch from your repo and apply it to my local repo and then build IPFire and install it, and I will then have your version. Should I use master or next as the base on which to patch it.

Thanks,

Adolf.


On 26/11/2020 19:47, ummeegge wrote:
> Hi all,
> for the interested ones, have push the current state to my repo which
> can be found in here -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> feel free to test and criticize it :-) .
> 
> After integration and configuration, the 'save' button in the global
> section should also be pushed since --cipher will replaced by --data-
> channel-fallback. For the langs files, a update-lang-cache should be
> executed via console so the changes can take affect.
> 
> Happy testing. Best,
> 
> Erik
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Good morning Adolf,

Am Donnerstag, den 26.11.2020, 23:33 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> I take it that I need to take the patch from your repo and apply it
> to my local repo and then build IPFire 
you would only need to build the OpenVPN binary 
https://patchwork.ipfire.org/patch/3679/
for those of you which can not build it by their own, in here
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/
all files can be found.

> and install it, and I will then have your version. Should I use
> master or next as the base on which to patch it.
the files from my repo can be manually installed, please backup up all
existing files, the ovpnmain.cgi state is origin/next (incl. the MTU
patch from Michael but excluding the up script line for the static-
routes for the client N2N).
After installation you need to execute 'update-lang-cache' via console
that the changes in the language files takes affect.
Hit the save button also in the global section since --cipher should be
renamed in --data-cipher-fallback...
Please check at the beginning that all your old settings are still in
place.

Thanks Adolf.

Best,

Erik

> 
> Thanks,
> 
> Adolf.
> 
> 
> On 26/11/2020 19:47, ummeegge wrote:
> > Hi all,
> > for the interested ones, have push the current state to my repo
> > which
> > can be found in here -->
> >  
> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> > feel free to test and criticize it :-) .
> > 
> > After integration and configuration, the 'save' button in the
> > global
> > section should also be pushed since --cipher will replaced by --
> > data-
> > channel-fallback. For the langs files, a update-lang-cache should
> > be
> > executed via console so the changes can take affect.
> > 
> > Happy testing. Best,
> > 
> > Erik
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Good Morning Erik,

Thanks for the information. You say that I only need to build the OpenVPN binary. I may be missing something here with my knowledge of IPFire. The only way I know to build the OpenVPN binary in IPFire is to do the ./make.sh clean followed by ./make.sh build which then builds the whole of IPFire. Are you suggesting that I build the OpenVPN binary by doing the ./configure then make then make install commands or is there some other way that I am not aware of.
I am still learning a lot about what is "under the bonnet" in IPFire programming so excuse me if my questions are a bit basic.

Regards,

Adolf.


On 27/11/2020 08:20, ummeegge wrote:
> Good morning Adolf,
> 
> Am Donnerstag, den 26.11.2020, 23:33 +0100 schrieb Adolf Belka:
>> Hi Erik,
>>
>> I take it that I need to take the patch from your repo and apply it
>> to my local repo and then build IPFire
> you would only need to build the OpenVPN binary
> https://patchwork.ipfire.org/patch/3679/
> for those of you which can not build it by their own, in here
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/
> all files can be found.
> 
>> and install it, and I will then have your version. Should I use
>> master or next as the base on which to patch it.
> the files from my repo can be manually installed, please backup up all
> existing files, the ovpnmain.cgi state is origin/next (incl. the MTU
> patch from Michael but excluding the up script line for the static-
> routes for the client N2N).
> After installation you need to execute 'update-lang-cache' via console
> that the changes in the language files takes affect.
> Hit the save button also in the global section since --cipher should be
> renamed in --data-cipher-fallback...
> Please check at the beginning that all your old settings are still in
> place.
> 
> Thanks Adolf.
> 
> Best,
> 
> Erik
> 
>>
>> Thanks,
>>
>> Adolf.
>>
>>
>> On 26/11/2020 19:47, ummeegge wrote:
>>> Hi all,
>>> for the interested ones, have push the current state to my repo
>>> which
>>> can be found in here -->
>>>   
>>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
>>> feel free to test and criticize it :-) .
>>>
>>> After integration and configuration, the 'save' button in the
>>> global
>>> section should also be pushed since --cipher will replaced by --
>>> data-
>>> channel-fallback. For the langs files, a update-lang-cache should
>>> be
>>> executed via console so the changes can take affect.
>>>
>>> Happy testing. Best,
>>>
>>> Erik
>>>
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi Erik,

I tried downloading your file where the required files are already built. However I came up with a different sha256sum to the one you had in your file. I downloaded it several times and the same difference occurred each time.
I will do the build from scratch.

Regards,

Adolf.


On 27/11/2020 08:20, ummeegge wrote:
> Good morning Adolf,
> 
> Am Donnerstag, den 26.11.2020, 23:33 +0100 schrieb Adolf Belka:
>> Hi Erik,
>>
>> I take it that I need to take the patch from your repo and apply it
>> to my local repo and then build IPFire
> you would only need to build the OpenVPN binary
> https://patchwork.ipfire.org/patch/3679/
> for those of you which can not build it by their own, in here
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/
> all files can be found.
> 
>> and install it, and I will then have your version. Should I use
>> master or next as the base on which to patch it.
> the files from my repo can be manually installed, please backup up all
> existing files, the ovpnmain.cgi state is origin/next (incl. the MTU
> patch from Michael but excluding the up script line for the static-
> routes for the client N2N).
> After installation you need to execute 'update-lang-cache' via console
> that the changes in the language files takes affect.
> Hit the save button also in the global section since --cipher should be
> renamed in --data-cipher-fallback...
> Please check at the beginning that all your old settings are still in
> place.
> 
> Thanks Adolf.
> 
> Best,
> 
> Erik
> 
>>
>> Thanks,
>>
>> Adolf.
>>
>>
>> On 26/11/2020 19:47, ummeegge wrote:
>>> Hi all,
>>> for the interested ones, have push the current state to my repo
>>> which
>>> can be found in here -->
>>>   
>>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
>>> feel free to test and criticize it :-) .
>>>
>>> After integration and configuration, the 'save' button in the
>>> global
>>> section should also be pushed since --cipher will replaced by --
>>> data-
>>> channel-fallback. For the langs files, a update-lang-cache should
>>> be
>>> executed via console so the changes can take affect.
>>>
>>> Happy testing. Best,
>>>
>>> Erik
>>>
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi Adolf

Am Freitag, den 27.11.2020, 13:19 +0100 schrieb Adolf Belka:
> Good Morning Erik,
> 
> Thanks for the information. You say that I only need to build the
> OpenVPN binary. I may be missing something here with my knowledge of
> IPFire. The only way I know to build the OpenVPN binary in IPFire is
> to do the ./make.sh clean followed by ./make.sh build which then
> builds the whole of IPFire. Are you suggesting that I build the
> OpenVPN binary by doing the ./configure then make then make install
> commands or is there some other way that I am not aware of.
> I am still learning a lot about what is "under the bonnet" in IPFire
> programming so excuse me if my questions are a bit basic.
you would need to make a clean build if the ROOTFILE is not produced.
In the patchwork link you can find the changes in the ROOTFILE which
you can adapt to the already existing under ipfire-
2.x/config/rootfiles/common/.
You would need the sources from OpenVPN community download page, move
openvpn-2.5.0.tar.xz to the cache folder, check the md5sum and change
the OpenVPN LFS file with this data.
You won´t need ./configure since all that is already in the LFS build
stage. Here https://patchwork.ipfire.org/patch/3679/
scroll to the bottom and you can find the path and diffs.

If this is done, just delete the OpenVPN log under ipfire-2.x/log and
make a ./make.sh build. After that you can find the new binary under
ipfire-2.x/build/usr/sbin .

Best,

Erik

> 
> Regards,
> 
> Adolf.
> 
> 
> On 27/11/2020 08:20, ummeegge wrote:
> > Good morning Adolf,
> > 
> > Am Donnerstag, den 26.11.2020, 23:33 +0100 schrieb Adolf Belka:
> > > Hi Erik,
> > > 
> > > I take it that I need to take the patch from your repo and apply
> > > it
> > > to my local repo and then build IPFire
> > you would only need to build the OpenVPN binary
> > https://patchwork.ipfire.org/patch/3679/
> > for those of you which can not build it by their own, in here
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/
> > all files can be found.
> > 
> > > and install it, and I will then have your version. Should I use
> > > master or next as the base on which to patch it.
> > the files from my repo can be manually installed, please backup up
> > all
> > existing files, the ovpnmain.cgi state is origin/next (incl. the
> > MTU
> > patch from Michael but excluding the up script line for the static-
> > routes for the client N2N).
> > After installation you need to execute 'update-lang-cache' via
> > console
> > that the changes in the language files takes affect.
> > Hit the save button also in the global section since --cipher
> > should be
> > renamed in --data-cipher-fallback...
> > Please check at the beginning that all your old settings are still
> > in
> > place.
> > 
> > Thanks Adolf.
> > 
> > Best,
> > 
> > Erik
> > 
> > > 
> > > Thanks,
> > > 
> > > Adolf.
> > > 
> > > 
> > > On 26/11/2020 19:47, ummeegge wrote:
> > > > Hi all,
> > > > for the interested ones, have push the current state to my repo
> > > > which
> > > > can be found in here -->
> > > >   
> > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> > > > feel free to test and criticize it :-) .
> > > > 
> > > > After integration and configuration, the 'save' button in the
> > > > global
> > > > section should also be pushed since --cipher will replaced by -
> > > > -
> > > > data-
> > > > channel-fallback. For the langs files, a update-lang-cache
> > > > should
> > > > be
> > > > executed via console so the changes can take affect.
> > > > 
> > > > Happy testing. Best,
> > > > 
> > > > Erik
> > > > 
> > 
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Am Freitag, den 27.11.2020, 13:40 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> I tried downloading your file where the required files are already
> built. However I came up with a different sha256sum to the one you
> had in your file. I downloaded it several times and the same
> difference occurred each time.
That´s strange, have had such problems more often...

> I will do the build from scratch.
This might be even better :-)

> 
> Regards,
> 
> Adolf.
> 
> 
> On 27/11/2020 08:20, ummeegge wrote:
> > Good morning Adolf,
> > 
> > Am Donnerstag, den 26.11.2020, 23:33 +0100 schrieb Adolf Belka:
> > > Hi Erik,
> > > 
> > > I take it that I need to take the patch from your repo and apply
> > > it
> > > to my local repo and then build IPFire
> > you would only need to build the OpenVPN binary
> > https://patchwork.ipfire.org/patch/3679/
> > for those of you which can not build it by their own, in here
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/
> > all files can be found.
> > 
> > > and install it, and I will then have your version. Should I use
> > > master or next as the base on which to patch it.
> > the files from my repo can be manually installed, please backup up
> > all
> > existing files, the ovpnmain.cgi state is origin/next (incl. the
> > MTU
> > patch from Michael but excluding the up script line for the static-
> > routes for the client N2N).
> > After installation you need to execute 'update-lang-cache' via
> > console
> > that the changes in the language files takes affect.
> > Hit the save button also in the global section since --cipher
> > should be
> > renamed in --data-cipher-fallback...
> > Please check at the beginning that all your old settings are still
> > in
> > place.
> > 
> > Thanks Adolf.
> > 
> > Best,
> > 
> > Erik
> > 
> > > 
> > > Thanks,
> > > 
> > > Adolf.
> > > 
> > > 
> > > On 26/11/2020 19:47, ummeegge wrote:
> > > > Hi all,
> > > > for the interested ones, have push the current state to my repo
> > > > which
> > > > can be found in here -->
> > > >   
> > > >  
> > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> > > > feel free to test and criticize it :-) .
> > > > 
> > > > After integration and configuration, the 'save' button in the
> > > > global
> > > > section should also be pushed since --cipher will replaced by -
> > > > -
> > > > data-
> > > > channel-fallback. For the langs files, a update-lang-cache
> > > > should
> > > > be
> > > > executed via console so the changes can take affect.
> > > > 
> > > > Happy testing. Best,
> > > > 
> > > > Erik
> > > > 
> > 
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Adolf, i have another request for you :-) ,
if the 2.5.0 binary has been build, can you please check first (no nnew
cgi or lang files) before all if it works with your actual clients and
report it here -->
https://lists.ipfire.org/pipermail/development/2020-November/008783.html
this might be great.

Thanks and best,

Erik


Am Freitag, den 27.11.2020, 14:23 +0100 schrieb ummeegge:
Hi Adolf

Am Freitag, den 27.11.2020, 13:19 +0100 schrieb Adolf Belka:
> Good Morning Erik,
> 
> Thanks for the information. You say that I only need to build the
> OpenVPN binary. I may be missing something here with my knowledge of
> IPFire. The only way I know to build the OpenVPN binary in IPFire is
> to do the ./make.sh clean followed by ./make.sh build which then
> builds the whole of IPFire. Are you suggesting that I build the
> OpenVPN binary by doing the ./configure then make then make install
> commands or is there some other way that I am not aware of.
> I am still learning a lot about what is "under the bonnet" in IPFire
> programming so excuse me if my questions are a bit basic.
you would need to make a clean build if the ROOTFILE is not produced.
In the patchwork link you can find the changes in the ROOTFILE which
you can adapt to the already existing under ipfire-
2.x/config/rootfiles/common/.
You would need the sources from OpenVPN community download page, move
openvpn-2.5.0.tar.xz to the cache folder, check the md5sum and change
the OpenVPN LFS file with this data.
You won´t need ./configure since all that is already in the LFS build
stage. Here https://patchwork.ipfire.org/patch/3679/
scroll to the bottom and you can find the path and diffs.

If this is done, just delete the OpenVPN log under ipfire-2.x/log and
make a ./make.sh build. After that you can find the new binary under
ipfire-2.x/build/usr/sbin .

Best,

Erik

> 
> Regards,
> 
> Adolf.
> 
> 
> On 27/11/2020 08:20, ummeegge wrote:
> > Good morning Adolf,
> > 
> > Am Donnerstag, den 26.11.2020, 23:33 +0100 schrieb Adolf Belka:
> > > Hi Erik,
> > > 
> > > I take it that I need to take the patch from your repo and apply
> > > it
> > > to my local repo and then build IPFire
> > you would only need to build the OpenVPN binary
> > https://patchwork.ipfire.org/patch/3679/
> > for those of you which can not build it by their own, in here
> > https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/
> > all files can be found.
> > 
> > > and install it, and I will then have your version. Should I use
> > > master or next as the base on which to patch it.
> > the files from my repo can be manually installed, please backup up
> > all
> > existing files, the ovpnmain.cgi state is origin/next (incl. the
> > MTU
> > patch from Michael but excluding the up script line for the static-
> > routes for the client N2N).
> > After installation you need to execute 'update-lang-cache' via
> > console
> > that the changes in the language files takes affect.
> > Hit the save button also in the global section since --cipher
> > should be
> > renamed in --data-cipher-fallback...
> > Please check at the beginning that all your old settings are still
> > in
> > place.
> > 
> > Thanks Adolf.
> > 
> > Best,
> > 
> > Erik
> > 
> > > 
> > > Thanks,
> > > 
> > > Adolf.
> > > 
> > > 
> > > On 26/11/2020 19:47, ummeegge wrote:
> > > > Hi all,
> > > > for the interested ones, have push the current state to my repo
> > > > which
> > > > can be found in here -->
> > > >   
> > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> > > > feel free to test and criticize it :-) .
> > > > 
> > > > After integration and configuration, the 'save' button in the
> > > > global
> > > > section should also be pushed since --cipher will replaced by -
> > > > -
> > > > data-
> > > > channel-fallback. For the langs files, a update-lang-cache
> > > > should
> > > > be
> > > > executed via console so the changes can take affect.
> > > > 
> > > > Happy testing. Best,
> > > > 
> > > > Erik
> > > > 
> > 
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi all,
made some fixes 

- --tls-auth will now be displayed and saved correctly.
- de.pl needed other 'save-enc-options' name since it was a double.
    Fixes tls-crypt key generation.
- Fixed comments and changed box size to prevent line break.

New version is here 

https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b

located.

Best,

Erik


Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
Hi all,
for the interested ones, have push the current state to my repo which
can be found in here -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
feel free to test and criticize it :-) .

After integration and configuration, the 'save' button in the global
section should also be pushed since --cipher will replaced by --data-
channel-fallback. For the langs files, a update-lang-cache should be
executed via console so the changes can take affect.

Happy testing. Best,

Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi All,

I am having problems getting the latest patch from Erik to apply to my local repo.

The previous version worked well. I successfully built it and was going to install it today but Erik had some fixes mentioned below. I followed the link and clicked on patch to download it to my local computer. I then did a git pull on next and then created a local branch from it and ran git am patch-name but it came back with the following error.

	git am ipfire-2.x.git-7bd13546f3c5e28fd62e25b487e440690860339b.patch
	Applying: OpenVPN: Introduce advanced encryption section
	error: patch failed: langs/de/cgi-bin/de.pl:894
	error: langs/de/cgi-bin/de.pl: patch does not apply
	Patch failed at 0001 OpenVPN: Introduce advanced encryption section
	hint: Use 'git am --show-current-patch=diff' to see the failed patch
	When you have resolved this problem, run "git am --continue".
	If you prefer to skip this patch, run "git am --skip" instead.
	To restore the original branch and stop patching, run "git am --abort".

I tried re-downloading the patch but the same thing happened.
The fail mentions line number 894 against de.pl but in the patch line 894 is still within the ovpnmain.cgi diff section.


I downloaded the diff for just ovpnmain.cgi and tried applying it but again got an error.

	git apply ovpnmain.diff
	error: patch failed: html/cgi-bin/ovpnmain.cgi:325
	error: html/cgi-bin/ovpnmain.cgi: patch does not apply

The fail location this time is in a different part of ovpnmain.cgi

I am probably doing something fundamentally wrong but I am failing to make any progress by myself so would appreciate any help on how to solve this so I can build and test the update.

Regards,

Adolf


On 28/11/2020 06:52, ummeegge wrote:
> Hi all,
> made some fixes
> 
> - --tls-auth will now be displayed and saved correctly.
> - de.pl needed other 'save-enc-options' name since it was a double.
>      Fixes tls-crypt key generation.
> - Fixed comments and changed box size to prevent line break.
> 
> New version is here
> 
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b
> 
> located.
> 
> Best,
> 
> Erik
> 
> 
> Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
> Hi all,
> for the interested ones, have push the current state to my repo which
> can be found in here -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> feel free to test and criticize it :-) .
> 
> After integration and configuration, the 'save' button in the global
> section should also be pushed since --cipher will replaced by --data-
> channel-fallback. For the langs files, a update-lang-cache should be
> executed via console so the changes can take affect.
> 
> Happy testing. Best,
> 
> Erik
> 
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi All,

I may have found a solution. I downloaded the whole files and copied them into my local repo branch copy. IPFire is building now. Will see if everything completes okay.

Regards,

Adolf


On 28/11/2020 15:12, Adolf Belka wrote:
> Hi All,
>
> I am having problems getting the latest patch from Erik to apply to my local repo.
>
> The previous version worked well. I successfully built it and was going to install it today but Erik had some fixes mentioned below. I followed the link and clicked on patch to download it to my local computer. I then did a git pull on next and then created a local branch from it and ran git am patch-name but it came back with the following error.
>
>     git am ipfire-2.x.git-7bd13546f3c5e28fd62e25b487e440690860339b.patch
>     Applying: OpenVPN: Introduce advanced encryption section
>     error: patch failed: langs/de/cgi-bin/de.pl:894
>     error: langs/de/cgi-bin/de.pl: patch does not apply
>     Patch failed at 0001 OpenVPN: Introduce advanced encryption section
>     hint: Use 'git am --show-current-patch=diff' to see the failed patch
>     When you have resolved this problem, run "git am --continue".
>     If you prefer to skip this patch, run "git am --skip" instead.
>     To restore the original branch and stop patching, run "git am --abort".
>
> I tried re-downloading the patch but the same thing happened.
> The fail mentions line number 894 against de.pl but in the patch line 894 is still within the ovpnmain.cgi diff section.
>
>
> I downloaded the diff for just ovpnmain.cgi and tried applying it but again got an error.
>
>     git apply ovpnmain.diff
>     error: patch failed: html/cgi-bin/ovpnmain.cgi:325
>     error: html/cgi-bin/ovpnmain.cgi: patch does not apply
>
> The fail location this time is in a different part of ovpnmain.cgi
>
> I am probably doing something fundamentally wrong but I am failing to make any progress by myself so would appreciate any help on how to solve this so I can build and test the update.
>
> Regards,
>
> Adolf
>
>
> On 28/11/2020 06:52, ummeegge wrote:
>> Hi all,
>> made some fixes
>>
>> - --tls-auth will now be displayed and saved correctly.
>> - de.pl needed other 'save-enc-options' name since it was a double.
>>      Fixes tls-crypt key generation.
>> - Fixed comments and changed box size to prevent line break.
>>
>> New version is here
>>
>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b
>>
>> located.
>>
>> Best,
>>
>> Erik
>>
>>
>> Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
>> Hi all,
>> for the interested ones, have push the current state to my repo which
>> can be found in here -->
>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
>> feel free to test and criticize it :-) .
>>
>> After integration and configuration, the 'save' button in the global
>> section should also be pushed since --cipher will replaced by --data-
>> channel-fallback. For the langs files, a update-lang-cache should be
>> executed via console so the changes can take affect.
>>
>> Happy testing. Best,
>>
>> Erik
>>
>>
>>

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi all,
another bug has been fixed -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=211bce2dc6f9a3c0fcdee61f3afc0d3c2283f375
. If the save button in the global section is used, it deletes the --auth parameter, this diff fixes it.
for manual changes:

--- /srv/web/ipfire/cgi-bin/ovpnmain.cgi_advanced_encryption	2020-
11-27 10:37:47.405168037 +0100
+++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi	2020-11-29
11:59:02.846338304 +0100
@@ -1303,7 +1303,6 @@
     $vpnsettings{'DDEST_PORT'} = $cgiparams{'DDEST_PORT'};
     $vpnsettings{'DMTU'} = $cgiparams{'DMTU'};
     $vpnsettings{'DCOMPLZO'} = $cgiparams{'DCOMPLZO'};
-    $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
 #wrtie enable
 
   if ( $vpnsettings{'ENABLED_BLUE'} eq 'on' ) {system("touch
${General::swroot}/ovpn/enable_blue 2>/dev/null");}else{system("unlink
${General::swroot}/ovpn/enable_blue 2>/dev/null");}


Am Samstag, den 28.11.2020, 06:52 +0100 schrieb ummeegge:
Hi all,
made some fixes 

- --tls-auth will now be displayed and saved correctly.
- de.pl needed other 'save-enc-options' name since it was a double.
    Fixes tls-crypt key generation.
- Fixed comments and changed box size to prevent line break.

New version is here 

https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b

located.

Best,

Erik


Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
Hi all,
for the interested ones, have push the current state to my repo which
can be found in here -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
feel free to test and criticize it :-) .

After integration and configuration, the 'save' button in the global
section should also be pushed since --cipher will replaced by --data-
channel-fallback. For the langs files, a update-lang-cache should be
executed via console so the changes can take affect.

Happy testing. Best,

Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Adolf Belka]

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

Hi Erik,

I have successfully installed OpenVPN-2.5.0 and the new ovpnmain.cgi and language files onto my system. Everything is working fine. I can see the new tab for encryption options. All my existing settings were maintained. All three of my clients are able to successfully connect with no problem and are connecting with the encryption options I have previously specified.

I have not had to modify anything for it to successfully work with the existing settings.

Looks very nice. Congratulations on your work so far. Hopefully more testers will also not have any problems (fingers crossed).

Regards,

Adolf.


On 29/11/2020 12:15, ummeegge wrote:
> Hi all,
> another bug has been fixed -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=211bce2dc6f9a3c0fcdee61f3afc0d3c2283f375
> . If the save button in the global section is used, it deletes the --auth parameter, this diff fixes it.
> for manual changes:
> 
> --- /srv/web/ipfire/cgi-bin/ovpnmain.cgi_advanced_encryption	2020-
> 11-27 10:37:47.405168037 +0100
> +++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi	2020-11-29
> 11:59:02.846338304 +0100
> @@ -1303,7 +1303,6 @@
>       $vpnsettings{'DDEST_PORT'} = $cgiparams{'DDEST_PORT'};
>       $vpnsettings{'DMTU'} = $cgiparams{'DMTU'};
>       $vpnsettings{'DCOMPLZO'} = $cgiparams{'DCOMPLZO'};
> -    $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
>   #wrtie enable
>   
>     if ( $vpnsettings{'ENABLED_BLUE'} eq 'on' ) {system("touch
> ${General::swroot}/ovpn/enable_blue 2>/dev/null");}else{system("unlink
> ${General::swroot}/ovpn/enable_blue 2>/dev/null");}
> 
> 
> Am Samstag, den 28.11.2020, 06:52 +0100 schrieb ummeegge:
> Hi all,
> made some fixes
> 
> - --tls-auth will now be displayed and saved correctly.
> - de.pl needed other 'save-enc-options' name since it was a double.
>      Fixes tls-crypt key generation.
> - Fixed comments and changed box size to prevent line break.
> 
> New version is here
> 
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b
> 
> located.
> 
> Best,
> 
> Erik
> 
> 
> Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
> Hi all,
> for the interested ones, have push the current state to my repo which
> can be found in here -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> feel free to test and criticize it :-) .
> 
> After integration and configuration, the 'save' button in the global
> section should also be pushed since --cipher will replaced by --data-
> channel-fallback. For the langs files, a update-lang-cache should be
> executed via console so the changes can take affect.
> 
> Happy testing. Best,
> 
> Erik
> 
> 
> 
> 
> 

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Hi Adolf,

Am Sonntag, den 29.11.2020, 14:12 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> I have successfully installed OpenVPN-2.5.0 and the new ovpnmain.cgi
> and language files onto my system. Everything is working fine. I can
> see the new tab for encryption options. All my existing settings were
> maintained. All three of my clients are able to successfully connect
> with no problem and are connecting with the encryption options I have
> previously specified.
Great, good to hear.

> 
> I have not had to modify anything for it to successfully work with
> the existing settings.
Very good am happy with this result too.

> 
> Looks very nice. Congratulations on your work so far. Hopefully more
> testers will also not have any problems (fingers crossed).
Thanks a bunch for testing and your feedback, may some more people come
around. Wish you all a nice peaceful end of the first advent.

P.S. The Blake HMAC in RW section have had a wrong bit value, have
fixed this :-).

Best,

Erik

> 
> Regards,
> 
> Adolf.
> 
> 
> On 29/11/2020 12:15, ummeegge wrote:
> > Hi all,
> > another bug has been fixed -->
> >   
> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=211bce2dc6f9a3c0fcdee61f3afc0d3c2283f375
> > . If the save button in the global section is used, it deletes the
> > --auth parameter, this diff fixes it.
> > for manual changes:
> > 
> > --- /srv/web/ipfire/cgi-
> > bin/ovpnmain.cgi_advanced_encryption    2020-
> > 11-27 10:37:47.405168037 +0100
> > +++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi        2020-11-29
> > 11:59:02.846338304 +0100
> > @@ -1303,7 +1303,6 @@
> >       $vpnsettings{'DDEST_PORT'} = $cgiparams{'DDEST_PORT'};
> >       $vpnsettings{'DMTU'} = $cgiparams{'DMTU'};
> >       $vpnsettings{'DCOMPLZO'} = $cgiparams{'DCOMPLZO'};
> > -    $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
> >   #wrtie enable
> >   
> >     if ( $vpnsettings{'ENABLED_BLUE'} eq 'on' ) {system("touch
> > ${General::swroot}/ovpn/enable_blue
> > 2>/dev/null");}else{system("unlink
> > ${General::swroot}/ovpn/enable_blue 2>/dev/null");}
> > 
> > 
> > Am Samstag, den 28.11.2020, 06:52 +0100 schrieb ummeegge:
> > Hi all,
> > made some fixes
> > 
> > - --tls-auth will now be displayed and saved correctly.
> > - de.pl needed other 'save-enc-options' name since it was a double.
> >      Fixes tls-crypt key generation.
> > - Fixed comments and changed box size to prevent line break.
> > 
> > New version is here
> > 
> >   
> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b
> > 
> > located.
> > 
> > Best,
> > 
> > Erik
> > 
> > 
> > Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
> > Hi all,
> > for the interested ones, have push the current state to my repo
> > which
> > can be found in here -->
> >   
> > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> > feel free to test and criticize it :-) .
> > 
> > After integration and configuration, the 'save' button in the
> > global
> > section should also be pushed since --cipher will replaced by --
> > data-
> > channel-fallback. For the langs files, a update-lang-cache should
> > be
> > executed via console so the changes can take affect.
> > 
> > Happy testing. Best,
> > 
> > Erik
> > 
> > 
> > 
> > 
> > 

Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer]

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

Hi,

> On 23 Nov 2020, at 20:49, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> Am Montag, den 23.11.2020, 17:58 +0000 schrieb Michael Tremer:
>> Hello everyone,
>> 
>> Good to see that we are moving forward on making OpenVPN on IPFire
>> better.
> Bigger hurdles at this time ;-).
> 
>> 
>> To avoid that the conversation is getting stuck again, can we split
>> the problems into many smaller ones instead of having one massive
>> thread again? I think I suggested that some time before and it would
>> really help us to stay on track with things and ideally merge
>> everything that is done already so that we do not end up with one
>> massive patchset that is getting really difficult to work with later
>> on.
> Might it be an idea to go for the initial post, with the update to
> 2.5.0 new crypto for N2N, nothing changed for RW. In the same or may
> the next core update a "Advanced Cyrpto Section" delivers data-cipher,
> data-cipher-fallback, can but must not be tls-cipher, tls-ciphersuite -
> -> both are new ?

Okay, the update for 2.5.0 has been merged. That should be rolled out now with no backward-compatibility issues.

Let’s see the rest.

>> 
>>> On 22 Nov 2020, at 16:30, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> Hi all,
>>> i am currently in the update process of the already realeased
>>> OpenVPN-
>>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update
>>> has
>>> been tested and worked so far also with the old default client
>>> configuration (tested with 2.4.9 client). There are two warnings
>>> -->
>> 
>> Which clients to we want to support?
>> 
>> Is it possible and do we want to support OpenVPN 2.3, too?
> Yes it is posible to support <= 2.3.x . Every client needs to be aware
> of the Galois-Counte-Mode otherwise we would need --> '--data-ciper-
> fallback' which is equal to the current --cipher directive in 2.5.0 ...
> Try to sort it in that way…

Adolf had some thoughts about it, and I will reply to his email.

>> 
>> Depending on when the last release has been, it might not be worth
>> it.
> It´s possible but also practical to deliver the chance to migrate via -
> -data-cipher-fallback (only one cipher, taken the already existing
> 'DCIPHER' in that case).

Yes, we should set that directive, if it is that simply for us.

>> 
>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
>>> negotiation
>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>> 
>> I think we have a good way to migrate cryptography.
> Me too, question is how.

I thought you were outlining this all along and that this is the path that we are following. We have the wiki page on the OpenVPN wiki which allows us to make some well-informed decisions.

>> 
>>> 2) WARNING: --topology net30 support for server configs with IPv4
>>> pools
>>> will be removed in a future release. Please migrate to --topology
>>> subnet as soon as possible.
>> 
>> This seems to be much trickier.
> Haven´t been there more than one hour ;-) but there seems to be more
> time with that (no 2.6 hint to change it)...

Okay, so lets ignore this entirely then for this time and we come back to it later.

I would assume that this is breaking existing setups, and we do not want to do that.

> 
>> 
>>> in the server log but it nevertheless works flawlessly.
>>> 
>>> Am working currently on an "Advanced Encryption Settings" page
>>> which
>>> includes currently four new directives --data-ciphers (data channel
>>> encryption), --data-ciphers-fallback (data-channel encryption for
>>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
>>> only)
>>> and --tls-ciphersuites (control channel >= TLSv3) all options are
>>> explained in here --> 
>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>> , which works here currently and looks like this:
>>> 
>>> Button to belong to this page:
>>> 
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>>> 
>>> And the page itself:
>>> 
> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>> 
>> In order to keep things like this archived for later, you can simply
>> attach them to the email that you send to the list :)
> Ohh didn´t see that :D hope i do not forget it until the next time...
> Best is i deliver the code and more people can go for a checkout ?

As always, I recommend planning first, and then coding. Obviously we might need to program some proof-of-concepts, but that is different to me.

>> 
>> Then I have some questions:
>> 
>> 1) Does this need to be an extra page? Why didn’t you put this on the
>> advanced server options page?
> Simply too much, i thought the IPSec workflow is the best one i could
> choose.

Too much what?

I absolutely disagree, because we are scattering the settings across two pages already which is entirely unnecessary. We never know where to put a setting, how can we expect our users to find them?

>> 2) What is the use-case for choosing different things for the
>> data/control channel?
> More possibilites equal to IPSec but also more flexibility to the
> existing infrastructure/features. Nevertheless a default can be
> existant like it is in IPsec advanced crypto page. Should we
> enable/disable/delete the control channel crypto section ?

There is a difference between IPsec and OpenVPN here though:

IPsec implementations are ancient and maximum compatibility is very difficult to achieve. There are also many in-hardware implementations out there that suck and that are sometimes very slow. So it makes sense to use a stronger cipher for IKE and probably even no encryption for ESP.

OpenVPN is different. We are dealing with software implementations only and I am not even aware of any other popular implementations than the one that we all use. So either you have a version that supports GCM or not, or TLSv3 or not.

I do not see the use-case why someone should choose a different one. Just because it is possible isn’t enough of a reason for me.

Do you have a use-case?

>> I am asking this because I find this really confusing. Why does
>> OpenVPN need different things selected for TLSv1.3 and <=TLSv1.2?
>> Should we not hide this from the user, because otherwise editing the
>> configuration file is easier?
> Yeah this is confusing. TLSv3 for the control channel is another
> dierctive (--tls-ciphersuites), the channel control with TLSv2 uses the
> --tls-cipher directive. May also not that bad, fututre sound of music,
> TLSv2 will sooner or later go and there is than --tls-ciphersuites ?!

Yes, in the backend it is a different directive, but that does not have to concern the user.

There should be one selection for all flavours of TLS. IPsec has some functions that compose the cipher suite out of what the user has selected so that strongSwan can understand it.

>> 
>> I assume that clients <= version 2.3 cannot use cipher negotiation?
>> How is it possible to select multiple options here and this still
>> works?
> That´s true. 2.3 have no plan how to use the NegotiationCipherProtocol
> . In that case the new directive '--data-ciphers-fallback algo' which
> is simply '--cipher alg' , as we know it, handles this.

I could see this as a simple dropdown as it is now and it would be possible to not select anything. That way the user can use this, or not.

>> 
>>> You can see also the default settings, were i need also your ideas
>>> and
>>> comments for may better defaults.
>> 
>> I am sure we have talked about this somewhere and we even came up
>> with a decision…
> Yes i know it too but we didn´t go into depth in there ;-) .

Lets do it now then...

>> 
>> It must be here on the list somewhere...
> 1000% :-) .
> 
>> 
>>> On the page itself is also more planned but to not overload this
>>> here
>>> now, i wanted to go now a two step procedure with this update.
>>> 
>>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
>>> regukar
>>> global settings for RW and N2N. A overview of the new crypto can be
>>> found in here -->
>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173
> .
>>> 2) I would push the "Advanced Encryption settings" development as
>>> seen
>>> above then as one patch <-- this would also eliminate the first
>>> warning
>>> causing --ncp-disable since we can delete this option then.
>> 
>> I do not understand how we can split this into two steps because I
>> thought OpenVPN 2.5 won’t work with the current settings?!
> For RW are only two warnings (NCP, topology) but it works here, which
> is for N2N not that hard since N2N do not understands
> 'push|SENT_CONTROL' and it works also not with --topology net30. I
> would give N2N all that new stuff for ciphers and HMACs but the RW runs
> for the first without modifications. This could be the second patch ?! 
> Ater that let´s check the warnings, one is here already more or less
> for me comfortably solved :D .

?

> 
>> 
>> -Michael
> 
> Great feedback thanks Michael...

-Michael

> 
>> 
>>> Everything else would come detached from this.
>>> 
>>> Some feedback might be nice.
>>> 
>>> Best,
>>> 
>>> Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer]

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

Hi,

> On 23 Nov 2020, at 23:29, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
> 
> Hi Michael,
> 
> 
> On 23/11/2020 19:00, Michael Tremer wrote:
>> Hi,
>>> On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com> wrote:
>>> 
>>> Hi Erik,
>>> 
>>> Thanks for all your work on OpenVPN. Much appreciated, especially in these challenging times of many changes.
>>> 
>>> Am I correct in my presumption that in the advanced encryption settings GUI we will be able to select multiple entries, which will then be made into a list in order that the entries are in the tables.
>>> 
>>> From the advanced encryption settings page I see that you have removed the old insecure options, which is good.
>> It is good to encourage people to use modern cryptography, but I would like to raise the point that if we want to support older clients, we will have to support the old crypto, too. Otherwise it is not worth to add the extra work if it is virtually unusable.
> 
> I understand the need/desire to support older clients but I just wonder how old we should be supporting. Erik's previous page picture showed the older crypto (BF-CBC, CAST etc) which were marked Data-Channel fallback (insecure). If those are going to be left in then I think they should be labelled Data-Channel fallback (insecure/deprecated) so people know they are not secure and/or likely to disappear before too long.

Yes, I would favour a second control for the fallback option, too.

The reason why I think we need to include these awfully broken and old ciphers here is because there are users out there using them. We will have to break their setup at some point, BUT we need to give them some options so that they can migrate away from it first.

That is why we added the labels as a compromise to discourage people from using the old ciphers. I would say that we need cipher negotiation first and then the fallback option for a while. Then, we can remove the older ciphers from the fallback option - or even better - the entire fallback option.

That would be a gradual change and avoid any downtime for people with many clients.

> I also want to be sure that if these unsecure algorithms are listed and selected for fallback I want to be sure that there is no way for my system to fallback to using them by accident or whatever. That is why I would then like to have the ability to not have any fallback algorithm selected. The default can be to have one or more selected but I would like to be able to unselect all fallback algorithms if they are of this type of security.

The default configuration should not longer enable these things. Agreed.

> 
>>> For the Data-Channel fallback do you have to have a default or can you unselect everything. There could be people who only want to connect to systems that have the strongest ciphers and just refuse to connect with weaker ones.
>>> 
>>> For the Control-Channel sections I would suggest swapping the order of TLSv2 and TLSv3 on the screen. The Data-Channel goes from most secure to least secure from left to right. I think that the Control-Channel should do the same.
>>> 
>>> I don't have any comments about the defaults. They seem reasonable to me.
>>> 
>>> Excellent work, it's looking very nice.
>>> 
>>> Regards,
>>> Adolf.
>>> 
>>> 
>>> On 22/11/2020 17:30, ummeegge wrote:
>>>> Hi all,
>>>> i am currently in the update process of the already realeased OpenVPN-
>>>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The update has
>>>> been tested and worked so far also with the old default client
>>>> configuration (tested with 2.4.9 client). There are two warnings -->
>>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
>>>> is a deprecated debug feature that will be removed in OpenVPN 2.6
>>>> 2) WARNING: --topology net30 support for server configs with IPv4 pools
>>>> will be removed in a future release. Please migrate to --topology
>>>> subnet as soon as possible.
>>>> in the server log but it nevertheless works flawlessly.
>>>> Am working currently on an "Advanced Encryption Settings" page which
>>>> includes currently four new directives --data-ciphers (data channel
>>>> encryption), --data-ciphers-fallback (data-channel encryption for
>>>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2 only)
>>>> and --tls-ciphersuites (control channel >= TLSv3) all options are
>>>> explained in here -->
>>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>>> , which works here currently and looks like this:
>>>> Button to belong to this page:
>>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>>>> And the page itself:
>>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>>>> You can see also the default settings, were i need also your ideas and
>>>> comments for may better defaults.
>>>> On the page itself is also more planned but to not overload this here
>>>> now, i wanted to go now a two step procedure with this update.
>>>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for regukar
>>>> global settings for RW and N2N. A overview of the new crypto can be
>>>> found in here -->
>>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173 .
>>>> 2) I would push the "Advanced Encryption settings" development as seen
>>>> above then as one patch <-- this would also eliminate the first warning
>>>> causing --ncp-disable since we can delete this option then.
>>>> Everything else would come detached from this.
>>>> Some feedback might be nice.
>>>> Best,
>>>> Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[Michael Tremer]

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

Hi,

> On 24 Nov 2020, at 16:27, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi all,
> 
> Am Montag, den 23.11.2020, 23:29 +0100 schrieb Adolf Belka:
>> Hi Michael,
>> 
>> 
>> On 23/11/2020 19:00, Michael Tremer wrote:
>>> Hi,
>>> 
>>>> On 23 Nov 2020, at 11:41, Adolf Belka <ahb.ipfire(a)gmail.com>
>>>> wrote:
>>>> 
>>>> Hi Erik,
>>>> 
>>>> Thanks for all your work on OpenVPN. Much appreciated, especially
>>>> in these challenging times of many changes.
>>>> 
>>>> Am I correct in my presumption that in the advanced encryption
>>>> settings GUI we will be able to select multiple entries, which
>>>> will then be made into a list in order that the entries are in
>>>> the tables.
>>>> 
>>>>  From the advanced encryption settings page I see that you have
>>>> removed the old insecure options, which is good.
>>> 
>>> It is good to encourage people to use modern cryptography, but I
>>> would like to raise the point that if we want to support older
>>> clients, we will have to support the old crypto, too. Otherwise it
>>> is not worth to add the extra work if it is virtually unusable.
>> 
>> I understand the need/desire to support older clients but I just
>> wonder how old we should be supporting. Erik's previous page picture
>> showed the older crypto (BF-CBC, CAST etc) which were marked Data-
>> Channel fallback (insecure). If those are going to be left in then I
>> think they should be labelled Data-Channel fallback
>> (insecure/deprecated) so people know they are not secure and/or
>> likely to disappear before too long.
> Did that now in the menu 'insecure/broken' for DES, BF and Cast.
> Shouldn´t we probably mark CBC in general also as 'insecure' ?

At least “not recommended”.

It would be bad to introduce more labels, but it is technically not broken.

>> I also want to be sure that if these unsecure algorithms are listed
>> and selected for fallback I want to be sure that there is no way for
>> my system to fallback to using them by accident or whatever. That is
>> why I would then like to have the ability to not have any fallback
>> algorithm selected. The default can be to have one or more selected
>> but I would like to be able to unselect all fallback algorithms if
>> they are of this type of security.
> Have tested this with a client (2.4.9) which have had AES-256-CBC as --
> cipher configured. The server provided --data-ciphers ChaCha20-
> Poly1305:AES-256-GCM but also --data-ciphers-fallback AES-256-CBC and
> the connection initiated the data channel with AES-256-GCM which i
> think is even better than the existing client configuration provides
> it. May there are also good news :-) .
> 
>> 
>>> 
>>>> For the Data-Channel fallback do you have to have a default or
>>>> can you unselect everything. There could be people who only want
>>>> to connect to systems that have the strongest ciphers and just
>>>> refuse to connect with weaker ones.
>>>> 
>>>> For the Control-Channel sections I would suggest swapping the
>>>> order of TLSv2 and TLSv3 on the screen. The Data-Channel goes
>>>> from most secure to least secure from left to right. I think that
>>>> the Control-Channel should do the same.
>>>> 
>>>> I don't have any comments about the defaults. They seem
>>>> reasonable to me.
>>>> 
>>>> Excellent work, it's looking very nice.
>>>> 
>>>> Regards,
>>>> Adolf.
>>>> 
>>>> 
>>>> On 22/11/2020 17:30, ummeegge wrote:
>>>>> Hi all,
>>>>> i am currently in the update process of the already realeased
>>>>> OpenVPN-
>>>>> 2.5.0 --> https://openvpn.net/community-downloads-2/ . The
>>>>> update has
>>>>> been tested and worked so far also with the old default client
>>>>> configuration (tested with 2.4.9 client). There are two
>>>>> warnings -->
>>>>> 1) DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
>>>>> negotiation
>>>>> is a deprecated debug feature that will be removed in OpenVPN
>>>>> 2.6
>>>>> 2) WARNING: --topology net30 support for server configs with
>>>>> IPv4 pools
>>>>> will be removed in a future release. Please migrate to --
>>>>> topology
>>>>> subnet as soon as possible.
>>>>> in the server log but it nevertheless works flawlessly.
>>>>> Am working currently on an "Advanced Encryption Settings" page
>>>>> which
>>>>> includes currently four new directives --data-ciphers (data
>>>>> channel
>>>>> encryption), --data-ciphers-fallback (data-channel encryption
>>>>> for
>>>>> clients <= OpenVPN-2.3.9), --tls-ciphers (control channel TLSv2
>>>>> only)
>>>>> and --tls-ciphersuites (control channel >= TLSv3) all options
>>>>> are
>>>>> explained in here -->
>>>>> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
>>>>> , which works here currently and looks like this:
>>>>> Button to belong to this page:
>>>>> 
>>>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption_button.png
>>>>> And the page itself:
>>>>> 
>>>>> https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_encryption.png
>>>>> You can see also the default settings, were i need also your
>>>>> ideas and
>>>>> comments for may better defaults.
>>>>> On the page itself is also more planned but to not overload
>>>>> this here
>>>>> now, i wanted to go now a two step procedure with this update.
>>>>> 1) Push OpenVPN-2.5.0 update with the new ciphers and HMACs for
>>>>> regukar
>>>>> global settings for RW and N2N. A overview of the new crypto
>>>>> can be
>>>>> found in here -->
>>>>> 
>>>>> https://community.ipfire.org/t/openvpn-2-5-development-version/2173
>>>>>  .
>>>>> 2) I would push the "Advanced Encryption settings" development
>>>>> as seen
>>>>> above then as one patch <-- this would also eliminate the first
>>>>> warning
>>>>> causing --ncp-disable since we can delete this option then.
>>>>> Everything else would come detached from this.
>>>>> Some feedback might be nice.
>>>>> Best,
>>>>> Erik

Re: OpenVPN-2.5.0 update procedure and idea collector

[ummeegge]

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

Good morning Adlof,
thanks for confirming.

Best,

Erik

Am Montag, den 30.11.2020, 15:41 +0100 schrieb Adolf Belka:
> Hi Erik,
> 
> I reverted back to OpenVPN-2.4.9 and had working clients. If I go
> into an existing client in edit mode and just press save then the
> "Download Insecure Client Package (zip)" icon also appears and if
> pressed also comes up with the Internal Server Error. So there is a
> problem with this but not related to your work on OpenVPN.
> 
> However, with 2.4.9 when I press the OpenVPN Connection Statistics
> button, I very quickly have statistics information on my open
> connections whereas nothing showed at all with the new ovpnmain.cgi.
> 
> Regards,
> 
> Adolf.
> 
> 
> On 30/11/2020 15:19, Adolf Belka wrote:
> > Hi Erik,
> > 
> > 
> > On 30/11/2020 13:41, ummeegge wrote:
> > > Hi Adolf,
> > > if you have time can you please make a short test with the new
> > > cgi ? If
> > > you press the yellow pencile for an existing RW connection and
> > > without
> > > modification, press only the save button, please use if presant
> > > one
> > > connection which have a zone in "Client has access to these
> > > networks on
> > > IPFire's site" configured.
> > > 
> > > I get currently a error message
> > > "Route 192.168.2.0/255.255.255.0 Already used by another client.
> > > (192.168.2.0/255.255.255.0) ". Am working in this section for a
> > > menu to
> > > modify new but also existing client configuration to give the
> > > possiblity to set also the new --data-ciphers directive but i get
> > > this
> > > error also after reverting the code... Tomatoes on eyes
> > > currently...
> > > 
> > > It might great to have there a feedback from you if this works
> > > you.
> > 
> > I get no error message when I press save. This is whether the
> > client is connected or is not connected via the vpn. The only thing
> > I had happen is that the icon for "Download Insecure Client Package
> > (zip)" becomes present and if I click on that then I get an
> > Internal Server Error message. All other icons work fine. All other
> > existing clients do not have the insecure client package icon.
> > 
> > The only other thing I have noticed is that if I click on the
> > OpenVPN Connection Statistics button I get a screen with a table
> > with the headings but no data showing. Not sure if this is related
> > to the work you are doing. I will revert back to the 2.4.9 version
> > and see if something shows in that table after a while.
> > 
> > Hope this helps,
> > 
> > Regards,
> > 
> > Adolf
> > 
> > > 
> > > Best,
> > > 
> > > Erik
> > > 
> > > Am Sonntag, den 29.11.2020, 14:12 +0100 schrieb Adolf Belka:
> > > > Hi Erik,
> > > > 
> > > > I have successfully installed OpenVPN-2.5.0 and the new
> > > > ovpnmain.cgi
> > > > and language files onto my system. Everything is working fine.
> > > > I can
> > > > see the new tab for encryption options. All my existing
> > > > settings were
> > > > maintained. All three of my clients are able to successfully
> > > > connect
> > > > with no problem and are connecting with the encryption options
> > > > I have
> > > > previously specified.
> > > > 
> > > > I have not had to modify anything for it to successfully work
> > > > with
> > > > the existing settings.
> > > > 
> > > > Looks very nice. Congratulations on your work so far. Hopefully
> > > > more
> > > > testers will also not have any problems (fingers crossed).
> > > > 
> > > > Regards,
> > > > 
> > > > Adolf.
> > > > 
> > > > 
> > > > On 29/11/2020 12:15, ummeegge wrote:
> > > > > Hi all,
> > > > > another bug has been fixed -->
> > > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=211bce2dc6f9a3c0fcdee61f3afc0d3c2283f375
> > > > > . If the save button in the global section is used, it
> > > > > deletes the
> > > > > --auth parameter, this diff fixes it.
> > > > > for manual changes:
> > > > > 
> > > > > --- /srv/web/ipfire/cgi-
> > > > > bin/ovpnmain.cgi_advanced_encryption    2020-
> > > > > 11-27 10:37:47.405168037 +0100
> > > > > +++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi        2020-11-29
> > > > > 11:59:02.846338304 +0100
> > > > > @@ -1303,7 +1303,6 @@
> > > > >        $vpnsettings{'DDEST_PORT'} = $cgiparams{'DDEST_PORT'};
> > > > >        $vpnsettings{'DMTU'} = $cgiparams{'DMTU'};
> > > > >        $vpnsettings{'DCOMPLZO'} = $cgiparams{'DCOMPLZO'};
> > > > > -    $vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
> > > > >    #wrtie enable
> > > > >         if ( $vpnsettings{'ENABLED_BLUE'} eq 'on' )
> > > > > {system("touch
> > > > > ${General::swroot}/ovpn/enable_blue
> > > > > 2>/dev/null");}else{system("unlink
> > > > > ${General::swroot}/ovpn/enable_blue 2>/dev/null");}
> > > > > 
> > > > > 
> > > > > Am Samstag, den 28.11.2020, 06:52 +0100 schrieb ummeegge:
> > > > > Hi all,
> > > > > made some fixes
> > > > > 
> > > > > - --tls-auth will now be displayed and saved correctly.
> > > > > - de.pl needed other 'save-enc-options' name since it was a
> > > > > double.
> > > > >       Fixes tls-crypt key generation.
> > > > > - Fixed comments and changed box size to prevent line break.
> > > > > 
> > > > > New version is here
> > > > > 
> > > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=7bd13546f3c5e28fd62e25b487e440690860339b
> > > > > 
> > > > > located.
> > > > > 
> > > > > Best,
> > > > > 
> > > > > Erik
> > > > > 
> > > > > 
> > > > > Am Donnerstag, den 26.11.2020, 19:47 +0100 schrieb ummeegge:
> > > > > Hi all,
> > > > > for the interested ones, have push the current state to my
> > > > > repo
> > > > > which
> > > > > can be found in here -->
> > > > > https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=34af1d714178b2cd0c27e8c39052a8c7ce87d116
> > > > > feel free to test and criticize it :-) .
> > > > > 
> > > > > After integration and configuration, the 'save' button in the
> > > > > global
> > > > > section should also be pushed since --cipher will replaced by
> > > > > --
> > > > > data-
> > > > > channel-fallback. For the langs files, a update-lang-cache
> > > > > should
> > > > > be
> > > > > executed via console so the changes can take affect.
> > > > > 
> > > > > Happy testing. Best,
> > > > > 
> > > > > Erik
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > 
> > >