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_...
And the page itself: https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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
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
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@ipfire.org Sent: Monday, November 23, 2020 4:15 AM To: development@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
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@ipfire.org Sent: Monday, November 23, 2020 4:15 AM To: development@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
Hi,
On 23 Nov 2020, at 14:28, Kienker, Fred fkienker@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@ipfire.org Sent: Monday, November 23, 2020 4:15 AM To: development@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
Hi all, a little update and some more experience. I was able to fully migrate all crypto options from the global section to the advanced crypto section. '--auth' and '--tls-auth' with their defaults. This might in my opinion be may a possible goal according to the RW ?! I have also extended the control channel protection with the new features which are '--tls-crypt' and the '--tls-crypt-v2' https://github.com/OpenVPN/openvpn/blob/master/doc/tls-crypt-v2.txt which might be also interesting for bigger business environments. Haven´t tested every little thing but so far it works good.
Experience: To fully use the negotiation with the clients, it is needed that the client do also have --data-ciphers entries --> https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negot... and runs therefor also >= OpenVPN-2.5.0 . The negotiation delivers three possiblities:
- Full negotiation: Both server and client support NCP - Partial negotiation: Only the client supports NCP (Known as "Poor man's NCP") - No negotiation: The client does not support NCP (The server NCP has no effect).
If the client is <= 2.5.0, '--data-ciphers' and '--data-ciphers- fallback' is not known as directive and the client refuses to start.
There arises a bigger question for me... When should we change the client.ovpn from '--cipher' to '--data-ciphers' and or '--data-ciphers- fallback' ...
This is again a not so nice one :-| .
Screenshots of the currrent state here are attached.
Best,
Erik
Am Montag, den 23.11.2020, 10:14 +0100 schrieb ummeegge: 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
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=34af1d71... 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
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=34af1d71... 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
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=34af1d71... 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
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=34af1d71... 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
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=34af1d71... 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
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=34af1d71... 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
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=34af1d71... 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
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=34af1d71... 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
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=7bd13546...
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=34af1d71... 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
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=7bd13546...
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=34af1d71... 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
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=7bd13546...
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=34af1d71... 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
Hi all, another bug has been fixed --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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.
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=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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=211bce2d... . 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=7bd13546...
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=34af1d71... 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
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 -->
- DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher negotiation
is a deprecated debug feature that will be removed in OpenVPN 2.6
- 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_...
And the page itself: https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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.
- 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
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_... 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 -->
- DEPRECATED OPTION: ncp-disable. Disabling dynamic cipher
negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
- 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_...
And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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.
- 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
.
- 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
Hi,
On 23 Nov 2020, at 11:41, Adolf Belka ahb.ipfire@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 -->
- 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_... And the page itself: https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_... 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.
- 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
Hi Michael,
On 23/11/2020 19:00, Michael Tremer wrote:
Hi,
On 23 Nov 2020, at 11:41, Adolf Belka ahb.ipfire@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 -->
- 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_... And the page itself: https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_... 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.
- 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
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@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/%C2%A0. 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 -->
- 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_... And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_... 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.
- 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
Hi,
On 24 Nov 2020, at 16:27, ummeegge ummeegge@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@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 -->
- 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_... And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_... 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.
- 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
Hi,
On 23 Nov 2020, at 23:29, Adolf Belka ahb.ipfire@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@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 -->
- 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_... And the page itself: https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_... 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.
- 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
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@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.
- 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.
- 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_...
And the page itself: https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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.
- 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
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@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).
- 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.
- 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_...
And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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:
- 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.
- 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.
- 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
.
- 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
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@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).
- 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.
- 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_...
And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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:
- 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.
- 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.
- 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
.
- 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
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@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/%C2%A0. 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).
- 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.
- 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_...
And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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:
- 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.
- 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.
- 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
.
- 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
Hi,
On 23 Nov 2020, at 20:49, ummeegge ummeegge@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@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.
- 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.
- 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_...
And the page itself:
https://people.ipfire.org/~ummeegge/OpenVPN-2.5.0/screenshots/ovpn_advanced_...
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:
- 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?
- 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.
- 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
.
- 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
-
Adolf Belka -
Kienker, Fred -
Michael Tremer -
ummeegge