Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
Regards,
Adolf.
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
Regards,
Adolf.
Regards,
Adolf.
Hello Adolf,
Thank you for checking this one out.
On 4 Sep 2023, at 21:15, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
This is sad, but I think we already anticipated this.
I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l...). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression.
That being said, we should remove the checkbox anyway then, because the page says:
Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets.
So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space.
It should not be possible to enable this on new installations.
What do we do with this chaos now?
-Michael
Regards,
Adolf.
Regards,
Adolf.
-- Sent from my laptop
Hi Michael,
On 05/09/2023 18:30, Michael Tremer wrote:
Hello Adolf,
Thank you for checking this one out.
On 4 Sep 2023, at 21:15, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
This is sad, but I think we already anticipated this.
I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l...). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression.
That being said, we should remove the checkbox anyway then, because the page says:
Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets.
So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space.
It should not be possible to enable this on new installations.
I see what you are suggesting. We remove the checkbox in the iso and image files.
What we could also do is that in the next update we check if the server has LZO enabled and if not then the checkbox is removed on systems not using it.
That then leaves the people with the LZO checkbox enabled. I would suggest that I create a patch that places a warning message in red on the main OpenVPN WUI page that warns that the LZO option is not compressing since version 2.5.0 and that the option has been deprecated and will be removed by OpenVPN at some time in the future and requesting IPFire users to update their clients to remove the LZO option.
I should also test out what happens if the LZO option is enabled on the server but removed on the client. Does that also break the connection. The answer will probably be yes which will mean that IPFire admins will need to change all clients and the server at the same time.
Regards,
Adolf.
What do we do with this chaos now?
-Michael
Regards,
Adolf.
Regards,
Adolf.
-- Sent from my laptop
Hello,
On 5 Sep 2023, at 20:17, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 05/09/2023 18:30, Michael Tremer wrote:
Hello Adolf, Thank you for checking this one out.
On 4 Sep 2023, at 21:15, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
This is sad, but I think we already anticipated this. I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l...). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression. That being said, we should remove the checkbox anyway then, because the page says: Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets. So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space. It should not be possible to enable this on new installations.
I see what you are suggesting. We remove the checkbox in the iso and image files.
What we could also do is that in the next update we check if the server has LZO enabled and if not then the checkbox is removed on systems not using it.
That was my first thought as well, but what do we do with those people who disable it not knowing what they are doing and then needing to re-enable it?
That then leaves the people with the LZO checkbox enabled. I would suggest that I create a patch that places a warning message in red on the main OpenVPN WUI page that warns that the LZO option is not compressing since version 2.5.0 and that the option has been deprecated and will be removed by OpenVPN at some time in the future and requesting IPFire users to update their clients to remove the LZO option.
I think a solution could be that we add some kind of “compatibility” counter. Basically we set this to like “1”, or the current date:
COMPAT=20230906
And then we check that value when we decide whether to show the LZO box. Older systems don’t have the value set, newer systems will start this value as shown above.
That way we keep things as they are for users who are coming from an older version, and we remove all the nonsense for the new users. That might work well for the latter group.
However, it might be confusing because some installations have other features available than others. And for us as developers, this means that we actually never ever remove LZO. We will have to carry this shit around for basically forever.
I should also test out what happens if the LZO option is enabled on the server but removed on the client. Does that also break the connection. The answer will probably be yes which will mean that IPFire admins will need to change all clients and the server at the same time.
I believe this will also break the connection.
-Michael
Regards,
Adolf.
What do we do with this chaos now? -Michael
Regards,
Adolf.
Regards,
Adolf.
-- Sent from my laptop
-- Sent from my laptop
Hi Michael,
On 06/09/2023 15:54, Michael Tremer wrote:
Hello,
On 5 Sep 2023, at 20:17, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 05/09/2023 18:30, Michael Tremer wrote:
Hello Adolf, Thank you for checking this one out.
On 4 Sep 2023, at 21:15, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
This is sad, but I think we already anticipated this. I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l...). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression.
I found somewhere in OpenVPN, although I can't find it again now, a comment that most likely compression will get removed completely in the pre-2.7 era which leads me to believe that it will probably be tested out in the rc versions of 2.7
That being said, we should remove the checkbox anyway then, because the page says: Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets. So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space. It should not be possible to enable this on new installations.
I see what you are suggesting. We remove the checkbox in the iso and image files.
What we could also do is that in the next update we check if the server has LZO enabled and if not then the checkbox is removed on systems not using it.
That was my first thought as well, but what do we do with those people who disable it not knowing what they are doing and then needing to re-enable it?
Having to deal with that is very frustrating isn't it.
That then leaves the people with the LZO checkbox enabled.
I would suggest that I create a patch that places a warning message in red on the main OpenVPN WUI page that warns that the LZO option is not compressing since version 2.5.0 and that the option has been deprecated and will be removed by OpenVPN at some time in the future and requesting IPFire users to update their clients to remove the LZO option.
I think a solution could be that we add some kind of “compatibility” counter. Basically we set this to like “1”, or the current date:
COMPAT=20230906
And then we check that value when we decide whether to show the LZO box. Older systems don’t have the value set, newer systems will start this value as shown above.
So that would be file that is saved in the /var/ipfire/ovpn/ directory and would also need to be backed up.
That way we keep things as they are for users who are coming from an older version, and we remove all the nonsense for the new users. That might work well for the latter group.
I think that should work okay.
However, it might be confusing because some installations have other features available than others. And for us as developers, this means that we actually never ever remove LZO. We will have to carry this shit around for basically forever.
If I understand correctly, it would not be a difference in the cgi code but an additional file that has a value. We already have various files that have a certain value for some people and not for others depending if you RW and/or N2N. I think that could work.
In terms of having to have that code there for ever a way around is that in openvpn-2.6 they have added a new mode to the compress option.
compress migrate
If we have that in the server conf file then the following applies
******** Using migrate as compression algorithm enables a special migration mode. It allows migration away from the --compress/--comp-lzo options to no compression. This option sets the server to no compression mode and the server behaves identical to a server without a compression option for all clients without a compression in their config. However, if a client is detected that indicates that compression is used (via OCC), the server will automatically add --push compress stub-v2 to the client specific configuration if supported by the client and otherwise switch to comp-lzo no and add --push comp-lzo to the client specific configuration. ********
This would allow us to remove all the code that adds comp-lzo into the client configurations and only create clients without compression but if a client exists with compression then it will be accommodated.
This would allow users to progressively convert client configurations to remove the comp-lzo entry.
Then eventually the whole compression aspect is just removed in OpenVPN.
The only potential downside is that the --push options require a client of 2.3 or newer but if people still have OpenVPN clients of 2.2 or earlier then they have clients that are around 10 years old and must be very vulnerable.
Alternatively we stay with the compat option you suggested for the rest of IPFire2.x's life.
I should also test out what happens if the LZO option is enabled on the server but removed on the client. Does that also break the connection. The answer will probably be yes which will mean that IPFire admins will need to change all clients and the server at the same time.
I believe this will also break the connection.
That is exactly what happened. So currently all clients with comp-lzo would need to be updated at the same time but with the comp-migrate server option from 2.6 onwards the users could have a mixture of clients with and without the comp-lzo option.
Regards, Adolf.
-Michael
Regards,
Adolf.
What do we do with this chaos now? -Michael
Regards,
Adolf.
Regards,
Adolf.
-- Sent from my laptop
-- Sent from my laptop
Hi Michael,
Forgot to mention that compress migrate, that I mention in my previous reply, is recommended to migrate from compression to no compression but has also been deprecated and will be removed at some point (potentially in version 2.7) together with all compression related options.
Regards,
Adolf.
On 09/09/2023 13:18, Adolf Belka wrote:
Hi Michael,
On 06/09/2023 15:54, Michael Tremer wrote:
Hello,
On 5 Sep 2023, at 20:17, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 05/09/2023 18:30, Michael Tremer wrote:
Hello Adolf, Thank you for checking this one out.
On 4 Sep 2023, at 21:15, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
This is sad, but I think we already anticipated this. I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l...). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression.
I found somewhere in OpenVPN, although I can't find it again now, a comment that most likely compression will get removed completely in the pre-2.7 era which leads me to believe that it will probably be tested out in the rc versions of 2.7
That being said, we should remove the checkbox anyway then, because the page says: Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets. So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space. It should not be possible to enable this on new installations.
I see what you are suggesting. We remove the checkbox in the iso and image files.
What we could also do is that in the next update we check if the server has LZO enabled and if not then the checkbox is removed on systems not using it.
That was my first thought as well, but what do we do with those people who disable it not knowing what they are doing and then needing to re-enable it?
Having to deal with that is very frustrating isn't it.
That then leaves the people with the LZO checkbox enabled.
I would suggest that I create a patch that places a warning message in red on the main OpenVPN WUI page that warns that the LZO option is not compressing since version 2.5.0 and that the option has been deprecated and will be removed by OpenVPN at some time in the future and requesting IPFire users to update their clients to remove the LZO option.
I think a solution could be that we add some kind of “compatibility” counter. Basically we set this to like “1”, or the current date:
COMPAT=20230906
And then we check that value when we decide whether to show the LZO box. Older systems don’t have the value set, newer systems will start this value as shown above.
So that would be file that is saved in the /var/ipfire/ovpn/ directory and would also need to be backed up.
That way we keep things as they are for users who are coming from an older version, and we remove all the nonsense for the new users. That might work well for the latter group.
I think that should work okay.
However, it might be confusing because some installations have other features available than others. And for us as developers, this means that we actually never ever remove LZO. We will have to carry this shit around for basically forever.
If I understand correctly, it would not be a difference in the cgi code but an additional file that has a value. We already have various files that have a certain value for some people and not for others depending if you RW and/or N2N. I think that could work.
In terms of having to have that code there for ever a way around is that in openvpn-2.6 they have added a new mode to the compress option.
compress migrate
If we have that in the server conf file then the following applies
Using migrate as compression algorithm enables a special migration mode. It allows migration away from the --compress/--comp-lzo options to no compression. This option sets the server to no compression mode and the server behaves identical to a server without a compression option for all clients without a compression in their config. However, if a client is detected that indicates that compression is used (via OCC), the server will automatically add --push compress stub-v2 to the client specific configuration if supported by the client and otherwise switch to comp-lzo no and add --push comp-lzo to the client specific configuration.
This would allow us to remove all the code that adds comp-lzo into the client configurations and only create clients without compression but if a client exists with compression then it will be accommodated.
This would allow users to progressively convert client configurations to remove the comp-lzo entry.
Then eventually the whole compression aspect is just removed in OpenVPN.
The only potential downside is that the --push options require a client of 2.3 or newer but if people still have OpenVPN clients of 2.2 or earlier then they have clients that are around 10 years old and must be very vulnerable.
Alternatively we stay with the compat option you suggested for the rest of IPFire2.x's life.
I should also test out what happens if the LZO option is enabled on the server but removed on the client. Does that also break the connection. The answer will probably be yes which will mean that IPFire admins will need to change all clients and the server at the same time.
I believe this will also break the connection.
That is exactly what happened. So currently all clients with comp-lzo would need to be updated at the same time but with the comp-migrate server option from 2.6 onwards the users could have a mixture of clients with and without the comp-lzo option.
Regards, Adolf.
-Michael
Regards,
Adolf.
What do we do with this chaos now? -Michael
Regards,
Adolf.
Regards,
Adolf.
-- Sent from my laptop
-- Sent from my laptop
Hello,
On 9 Sep 2023, at 12:18, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 06/09/2023 15:54, Michael Tremer wrote:
Hello,
On 5 Sep 2023, at 20:17, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 05/09/2023 18:30, Michael Tremer wrote:
Hello Adolf, Thank you for checking this one out.
On 4 Sep 2023, at 21:15, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
On 04/09/2023 21:51, Adolf Belka wrote:
Hi All,
As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
Using my vm testbed, I created a client with LZO option enabled.
I made an opnvpn connection which was successful and worked.
Then I disabled LZO on the server but left the client as it was.
Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
nm-openvpn[1266]: Bad LZO decompression header byte: 42
Additionally trying to use the browser through the tunnel failed with the web sites timing out.
So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.
This is sad, but I think we already anticipated this. I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l...). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression.
I found somewhere in OpenVPN, although I can't find it again now, a comment that most likely compression will get removed completely in the pre-2.7 era which leads me to believe that it will probably be tested out in the rc versions of 2.7
Okay, this sounds good, but again we won’t have any kind of contingency plan to keep any existing configurations working.
That being said, we should remove the checkbox anyway then, because the page says: Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets. So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space. It should not be possible to enable this on new installations.
I see what you are suggesting. We remove the checkbox in the iso and image files.
What we could also do is that in the next update we check if the server has LZO enabled and if not then the checkbox is removed on systems not using it.
That was my first thought as well, but what do we do with those people who disable it not knowing what they are doing and then needing to re-enable it?
Having to deal with that is very frustrating isn't it.
Yes :)
That then leaves the people with the LZO checkbox enabled.
I would suggest that I create a patch that places a warning message in red on the main OpenVPN WUI page that warns that the LZO option is not compressing since version 2.5.0 and that the option has been deprecated and will be removed by OpenVPN at some time in the future and requesting IPFire users to update their clients to remove the LZO option.
I think a solution could be that we add some kind of “compatibility” counter. Basically we set this to like “1”, or the current date: COMPAT=20230906 And then we check that value when we decide whether to show the LZO box. Older systems don’t have the value set, newer systems will start this value as shown above.
So that would be file that is saved in the /var/ipfire/ovpn/ directory and would also need to be backed up.
We can just store this in /var/ipfire/ovpn/settings as a value.
That way we keep things as they are for users who are coming from an older version, and we remove all the nonsense for the new users. That might work well for the latter group.
I think that should work okay.
However, it might be confusing because some installations have other features available than others. And for us as developers, this means that we actually never ever remove LZO. We will have to carry this shit around for basically forever.
If I understand correctly, it would not be a difference in the cgi code but an additional file that has a value. We already have various files that have a certain value for some people and not for others depending if you RW and/or N2N. I think that could work.
In terms of having to have that code there for ever a way around is that in openvpn-2.6 they have added a new mode to the compress option.
compress migrate
Ah finally someone cares about this… but I am not sure if this is any good if we only get this as yet another stepping those. Because we would simply only delay the problem, but never make it go away entirely.
If we have that in the server conf file then the following applies
Using migrate as compression algorithm enables a special migration mode. It allows migration away from the --compress/--comp-lzo options to no compression. This option sets the server to no compression mode and the server behaves identical to a server without a compression option for all clients without a compression in their config. However, if a client is detected that indicates that compression is used (via OCC), the server will automatically add --push compress stub-v2 to the client specific configuration if supported by the client and otherwise switch to comp-lzo no and add --push comp-lzo to the client specific configuration.
This would allow us to remove all the code that adds comp-lzo into the client configurations and only create clients without compression but if a client exists with compression then it will be accommodated.
This would allow users to progressively convert client configurations to remove the comp-lzo entry.
If this is already available right now, we can then make it impossible to check the checkbox any more. We just have to see if this system has been installed in the past and then always add “compress migrate”, and it has been installed after the change, we won’t include that line in the OpenVPN server configuration. That should work well.
If it is possible to push the LZO setting, maybe we should do that instead of hardcoding it into the client configuration, too. That way it can be dynamically enabled/disabled without the clients being touched.
Then eventually the whole compression aspect is just removed in OpenVPN.
The only potential downside is that the --push options require a client of 2.3 or newer but if people still have OpenVPN clients of 2.2 or earlier then they have clients that are around 10 years old and must be very vulnerable.
Alternatively we stay with the compat option you suggested for the rest of IPFire2.x's life.
I think we might want a little bit of both? Or simple remove compression entirely for all installations and add “compress migrate”.
I should also test out what happens if the LZO option is enabled on the server but removed on the client. Does that also break the connection. The answer will probably be yes which will mean that IPFire admins will need to change all clients and the server at the same time.
I believe this will also break the connection.
That is exactly what happened. So currently all clients with comp-lzo would need to be updated at the same time but with the comp-migrate server option from 2.6 onwards the users could have a mixture of clients with and without the comp-lzo option.
Should we at some point create a wiki page with all the things that are going to break? We need to get all those things together so that eventually we can have our users do the change once and not multiple times again.
-Michael
Regards, Adolf.
-Michael
Regards,
Adolf.
What do we do with this chaos now? -Michael
Regards,
Adolf.
Regards,
Adolf.
-- Sent from my laptop
-- Sent from my laptop
-
Adolf Belka -
Michael Tremer