OpenVPN-2.6 Core Update 197 testing feedback

OpenVPN-2.6 Core Update 197 testing feedback

[Adolf Belka]

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

Hi All,

So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.

So now I have been evaluating existing connections and new connections.

There is good and bad news but more good than bad so progress is being made.

First thing was to test out my existing rw and n2n connections with CU197.

The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.

The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
It worked. I was able to login and check through WUI pages.
So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.

I don't think this is a breaking issue just a puzzling one.

I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.

Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
I will also do a test of a new client connection with my android phone.

I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.

This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.

I then deleted the line that had (Expired) in the Name column and enabled the other line.
The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.

I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.

Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.

So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.

So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.

I will also try and find some time to test out a new n2n installation with 2.6 at both ends.

So most critical things seem to be working but there are a couple of puzzling things to be dealt with.

Regards,

Adolf.

[-- Attachment #2: Screenshot_2025-07-25_14-12-40.png --]
[-- Type: image/png, Size: 24150 bytes --]

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Adolf Belka]

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

Hi All,

Forgot a couple of other screen shots for some minor things.

Some labels are slightly overlapping the ends of entry boxes and one box in the client certificate entry section for the land is twice as long as all the other entry boxes.

See the attached screenshots.

Regards,

Adolf.

On 25/07/2025 17:52, Adolf Belka wrote:
> Hi All,
> 
> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
> 
> So now I have been evaluating existing connections and new connections.
> 
> There is good and bad news but more good than bad so progress is being made.
> 
> First thing was to test out my existing rw and n2n connections with CU197.
> 
> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
> 
> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
> It worked. I was able to login and check through WUI pages.
> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.
> 
> I don't think this is a breaking issue just a puzzling one.
> 
> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
> 
> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
> I will also do a test of a new client connection with my android phone.
> 
> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.
> 
> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.
> 
> I then deleted the line that had (Expired) in the Name column and enabled the other line.
> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
> 
> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
> 
> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
> 
> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.
> 
> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
> 
> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.
> 
> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.
> 
> Regards,
> 
> Adolf.

[-- Attachment #2: Screenshot_2025-07-25_14-06-22.png --]
[-- Type: image/png, Size: 40489 bytes --]

[-- Attachment #3: Screenshot_2025-07-25_14-11-48.png --]
[-- Type: image/png, Size: 26411 bytes --]

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Michael Tremer]

Hello Adolf,

Thank you for doing all this testing and apologies for replying so late.

> On 25 Jul 2025, at 16:52, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi All,
> 
> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
> 
> So now I have been evaluating existing connections and new connections.
> 
> There is good and bad news but more good than bad so progress is being made.
> 
> First thing was to test out my existing rw and n2n connections with CU197.
> 
> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
> 
> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
> It worked. I was able to login and check through WUI pages.
> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.

Good to know that this has worked!

> I don't think this is a breaking issue just a puzzling one.

Mostly seems to be a client issue.

> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
> 
> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
> I will also do a test of a new client connection with my android phone.
> 
> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.

Where did you create the connection and where did you import it? I created a connection on c197 and them imported it on c197 again and it seemed to have worked.

> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.

Yes, I could see the screenshot. Something went wrong with creating the configuration line in the CSV file. Once there is something off, a lot seems to break at the same time.

> I then deleted the line that had (Expired) in the Name column and enabled the other line.
> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
> 
> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
> 
> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
> 
> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.

Okay, this sounds all very good. But I think we need to probably invest a lot of time to bring N2N to a good standard and I currently don’t have the resources for this. I am not sure if we broke things in this changeset of if they had been broken for a long time already.

> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
> 
> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.

Perfect!

Can we use the matrix on the wiki page to show what is working well and what isn’t?

  https://www.ipfire.org/docs/roadmap/openvpn-26

We might want to create a second table for N2N.

> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.

Cool. Hopefully we should be able to get it all done very soon!

Best,
-Michael

> Regards,
> 
> Adolf.
> <Screenshot_2025-07-25_14-12-40.png>

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Michael Tremer]

Hello Adolf,

I have a patch for the overlapping labels:

  https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=306516d99a8333ca7d91adba835c206ebbaf9b9b

The dropdown that is way too long is something that I cannot fix easily without rewriting a lot of code. Maybe I will find the time soon to do this, maybe we will release with it. It isn’t pretty, but at the same time not a blocker either.

-Michael

> On 25 Jul 2025, at 16:55, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi All,
> 
> Forgot a couple of other screen shots for some minor things.
> 
> Some labels are slightly overlapping the ends of entry boxes and one box in the client certificate entry section for the land is twice as long as all the other entry boxes.
> 
> See the attached screenshots.
> 
> Regards,
> 
> Adolf.
> 
> On 25/07/2025 17:52, Adolf Belka wrote:
>> Hi All,
>> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
>> So now I have been evaluating existing connections and new connections.
>> There is good and bad news but more good than bad so progress is being made.
>> First thing was to test out my existing rw and n2n connections with CU197.
>> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
>> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
>> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
>> It worked. I was able to login and check through WUI pages.
>> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.
>> I don't think this is a breaking issue just a puzzling one.
>> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
>> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
>> I will also do a test of a new client connection with my android phone.
>> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.
>> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.
>> I then deleted the line that had (Expired) in the Name column and enabled the other line.
>> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
>> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
>> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
>> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.
>> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
>> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.
>> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.
>> Regards,
>> Adolf.
> <Screenshot_2025-07-25_14-06-22.png><Screenshot_2025-07-25_14-11-48.png>

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Adolf Belka]

Hi Michael,

Good news.

On 04/08/2025 17:42, Michael Tremer wrote:
> Hello Adolf,
> 
> Thank you for doing all this testing and apologies for replying so late.
> 
>> On 25 Jul 2025, at 16:52, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi All,
>>
>> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
>>
>> So now I have been evaluating existing connections and new connections.
>>
>> There is good and bad news but more good than bad so progress is being made.
>>
>> First thing was to test out my existing rw and n2n connections with CU197.
>>
>> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
>>
>> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
>> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
>> It worked. I was able to login and check through WUI pages.
>> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.
> 
> Good to know that this has worked!
> 
>> I don't think this is a breaking issue just a puzzling one.
> 
> Mostly seems to be a client issue.

Yes.

> 
>> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
>>
>> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
>> I will also do a test of a new client connection with my android phone.
>>
>> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.
> 
> Where did you create the connection and where did you import it? I created a connection on c197 and them imported it on c197 again and it seemed to have worked.
> 
>> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.
> 
> Yes, I could see the screenshot. Something went wrong with creating the configuration line in the CSV file. Once there is something off, a lot seems to break at the same time.

I repeated making a new n2n connection, both with an empty set of client connections and also with existing rw & n2n connection in place.

I could not reproduce the issue with getting that double line shown in my screenshot. It looks like there was some hiccup or something when I did my initial test.

Have now created three new n2n connections and in all three cases the entry went as expected.

Additionally in all three cases I was able to ping in both directions with no problems.

> 
>> I then deleted the line that had (Expired) in the Name column and enabled the other line.
>> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
>>
>> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
>>
>> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
>>
>> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.
> 
> Okay, this sounds all very good. But I think we need to probably invest a lot of time to bring N2N to a good standard and I currently don’t have the resources for this. I am not sure if we broke things in this changeset of if they had been broken for a long time already.
> 
>> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
>>
>> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.
> 
> Perfect!
> 
> Can we use the matrix on the wiki page to show what is working well and what isn’t?
> 
>    https://www.ipfire.org/docs/roadmap/openvpn-26
> 
> We might want to create a second table for N2N.

I will see what I can do.

> 
>> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.
> 
> Cool. Hopefully we should be able to get it all done very soon!

So currently I am able to confirm that existing n2n connections and newly created n2n connections with CU197 at the end creating the new connection and CU196 at the end receiving it are all working as previously with CU196 at both ends.

Regards,
Adolf

> 
> Best,
> -Michael
> 
>> Regards,
>>
>> Adolf.
>> <Screenshot_2025-07-25_14-12-40.png>
> 
> 

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Adolf Belka]

Hi Michael,

On 04/08/2025 18:10, Michael Tremer wrote:
> Hello Adolf,
> 
> I have a patch for the overlapping labels:
> 
>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=306516d99a8333ca7d91adba835c206ebbaf9b9b

Confirm that there is no longer any problem.

> 
> The dropdown that is way too long is something that I cannot fix easily without rewriting a lot of code. Maybe I will find the time soon to do this, maybe we will release with it. It isn’t pretty, but at the same time not a blocker either.

I don't see it as a big issue, definitely not a blocker.

Regards,
Adolf.

> 
> -Michael
> 
>> On 25 Jul 2025, at 16:55, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi All,
>>
>> Forgot a couple of other screen shots for some minor things.
>>
>> Some labels are slightly overlapping the ends of entry boxes and one box in the client certificate entry section for the land is twice as long as all the other entry boxes.
>>
>> See the attached screenshots.
>>
>> Regards,
>>
>> Adolf.
>>
>> On 25/07/2025 17:52, Adolf Belka wrote:
>>> Hi All,
>>> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
>>> So now I have been evaluating existing connections and new connections.
>>> There is good and bad news but more good than bad so progress is being made.
>>> First thing was to test out my existing rw and n2n connections with CU197.
>>> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
>>> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
>>> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
>>> It worked. I was able to login and check through WUI pages.
>>> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.
>>> I don't think this is a breaking issue just a puzzling one.
>>> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
>>> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
>>> I will also do a test of a new client connection with my android phone.
>>> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.
>>> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.
>>> I then deleted the line that had (Expired) in the Name column and enabled the other line.
>>> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
>>> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
>>> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
>>> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.
>>> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
>>> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.
>>> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.
>>> Regards,
>>> Adolf.
>> <Screenshot_2025-07-25_14-06-22.png><Screenshot_2025-07-25_14-11-48.png>
> 

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Michael Tremer]

Hello Adolf,

Thanks again for your extensive testing.

I have merged next into master and the builders should push the update into testing tonight.

Let’s all give this another round of testing to release another solid update.

I also wrote the change log which I will probably post on Monday:

  https://www.ipfire.org/blog/ipfire-2-29-core-update-197-is-available-for-testing

Have a nice weekend!

-Michael

> On 8 Aug 2025, at 14:17, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> Good news.
> 
> On 04/08/2025 17:42, Michael Tremer wrote:
>> Hello Adolf,
>> Thank you for doing all this testing and apologies for replying so late.
>>> On 25 Jul 2025, at 16:52, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>> 
>>> Hi All,
>>> 
>>> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
>>> 
>>> So now I have been evaluating existing connections and new connections.
>>> 
>>> There is good and bad news but more good than bad so progress is being made.
>>> 
>>> First thing was to test out my existing rw and n2n connections with CU197.
>>> 
>>> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
>>> 
>>> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
>>> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
>>> It worked. I was able to login and check through WUI pages.
>>> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.
>> Good to know that this has worked!
>>> I don't think this is a breaking issue just a puzzling one.
>> Mostly seems to be a client issue.
> 
> Yes.
> 
>>> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
>>> 
>>> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
>>> I will also do a test of a new client connection with my android phone.
>>> 
>>> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.
>> Where did you create the connection and where did you import it? I created a connection on c197 and them imported it on c197 again and it seemed to have worked.
>>> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.
>> Yes, I could see the screenshot. Something went wrong with creating the configuration line in the CSV file. Once there is something off, a lot seems to break at the same time.
> 
> I repeated making a new n2n connection, both with an empty set of client connections and also with existing rw & n2n connection in place.
> 
> I could not reproduce the issue with getting that double line shown in my screenshot. It looks like there was some hiccup or something when I did my initial test.
> 
> Have now created three new n2n connections and in all three cases the entry went as expected.
> 
> Additionally in all three cases I was able to ping in both directions with no problems.
> 
>>> I then deleted the line that had (Expired) in the Name column and enabled the other line.
>>> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
>>> 
>>> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
>>> 
>>> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
>>> 
>>> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.
>> Okay, this sounds all very good. But I think we need to probably invest a lot of time to bring N2N to a good standard and I currently don’t have the resources for this. I am not sure if we broke things in this changeset of if they had been broken for a long time already.
>>> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
>>> 
>>> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.
>> Perfect!
>> Can we use the matrix on the wiki page to show what is working well and what isn’t?
>>   https://www.ipfire.org/docs/roadmap/openvpn-26
>> We might want to create a second table for N2N.
> 
> I will see what I can do.
> 
>>> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.
>> Cool. Hopefully we should be able to get it all done very soon!
> 
> So currently I am able to confirm that existing n2n connections and newly created n2n connections with CU197 at the end creating the new connection and CU196 at the end receiving it are all working as previously with CU196 at both ends.
> 
> Regards,
> Adolf
> 
>> Best,
>> -Michael
>>> Regards,
>>> 
>>> Adolf.
>>> <Screenshot_2025-07-25_14-12-40.png>

Re: OpenVPN-2.6 Core Update 197 testing feedback

[Adolf Belka]

Hi Michael,

Tested out creating a new n2n openvpn connection with CU197 on both ends.

Connection was created without any issues and ping worked both ways.

Also checked the commit

initscripts: Fix process check for processes with PID file

and can confirm that now when a reboot is done with a running openvpn server the shutdown of it is shown as OK and no longer showing a red FAIL due to the old pid file still being present although the daemon had been stopped. So that commit resolved that issue also.

Regards,

Adolf.


On 08/08/2025 19:13, Michael Tremer wrote:
> Hello Adolf,
> 
> Thanks again for your extensive testing.
> 
> I have merged next into master and the builders should push the update into testing tonight.
> 
> Let’s all give this another round of testing to release another solid update.
> 
> I also wrote the change log which I will probably post on Monday:
> 
>    https://www.ipfire.org/blog/ipfire-2-29-core-update-197-is-available-for-testing
> 
> Have a nice weekend!
> 
> -Michael
> 
>> On 8 Aug 2025, at 14:17, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> Good news.
>>
>> On 04/08/2025 17:42, Michael Tremer wrote:
>>> Hello Adolf,
>>> Thank you for doing all this testing and apologies for replying so late.
>>>> On 25 Jul 2025, at 16:52, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> So the openvpn-2.6 issues with the update process from 196 to 197 have been solved by the last patches that were applied.
>>>>
>>>> So now I have been evaluating existing connections and new connections.
>>>>
>>>> There is good and bad news but more good than bad so progress is being made.
>>>>
>>>> First thing was to test out my existing rw and n2n connections with CU197.
>>>>
>>>> The existing rw connection from my Linux laptop worked without any issues and could ping a machine on the green network.
>>>>
>>>> The existing rw connection from my Android phone showed it was connected but ping to a machine on the green network no longer gave any response except 100% packet loss.
>>>> Based on a suggestion from @Michael I tried to connect to the IPFire WUI using the IP for the IPFire green interface.
>>>> It worked. I was able to login and check through WUI pages.
>>>> So the connection is definitely working but for some reason the ping command no longer works to a machine on the green network although it works with a CU196 system with the same client connection settings. However ping on the laptop works for both the CU196 and CU197 versions with the same client connection.
>>> Good to know that this has worked!
>>>> I don't think this is a breaking issue just a puzzling one.
>>> Mostly seems to be a client issue.
>>
>> Yes.
>>
>>>> I then tested out the existing n2n connection between a CU197 system at one end and a CU196 system at the other. Connection worked and ping worked in both directions.
>>>>
>>>> Then I created a new completely new client connection for the Linux Laptop. Connected via it and the connection was made successfully. I think I tried the ping and it worked but I am not 100% certain so I will do the test of creating a new connection again as I deleted the old rw connections when I was testing out the n2n connections.
>>>> I will also do a test of a new client connection with my android phone.
>>>>
>>>> I then created a new n2n connection between a CU197 acting as the server and a CU196 acting as the client.
>>> Where did you create the connection and where did you import it? I created a connection on c197 and them imported it on c197 again and it seemed to have worked.
>>>> This gave a peculiar result in the WUI as it provided two lines for the connection. I attach a screenshot of this as it is a bit difficult to explain. Hopefully the screenshot is accessible. If not let me know and I will put it in the paste system.
>>> Yes, I could see the screenshot. Something went wrong with creating the configuration line in the CSV file. Once there is something off, a lot seems to break at the same time.
>>
>> I repeated making a new n2n connection, both with an empty set of client connections and also with existing rw & n2n connection in place.
>>
>> I could not reproduce the issue with getting that double line shown in my screenshot. It looks like there was some hiccup or something when I did my initial test.
>>
>> Have now created three new n2n connections and in all three cases the entry went as expected.
>>
>> Additionally in all three cases I was able to ping in both directions with no problems.
>>
>>>> I then deleted the line that had (Expired) in the Name column and enabled the other line.
>>>> The connection then showed up as connected at both ends but doing a ping in either direction gave 100% packet loss, whereas the version with CU196 at both ends gave a good ping result in both directions.
>>>>
>>>> I then reviewed the n2n logs for one end of the tunnel between the ping working version and the ping not working version.
>>>>
>>>> Basically the contents were the same, resulting in an "Initialization Sequence Completed" message, so it looked like it was fully working.
>>>>
>>>> So I then tried accessing from one end of the tunnel the WUI of the other end via the IP URL. That worked. I could successfully log into the WUI of the far end of the tunnel.
>>> Okay, this sounds all very good. But I think we need to probably invest a lot of time to bring N2N to a good standard and I currently don’t have the resources for this. I am not sure if we broke things in this changeset of if they had been broken for a long time already.
>>>> So with 2.6 at one end of the tunnel and 2.5 at the other a new n2n connection is working in terms of actual data traffic, except for the ping traffic not seeming to work and the creation of an additional line in the Connection Status and -Control table of the OpenVPN WUI page.
>>>>
>>>> I will also try and find some time to test out a new n2n installation with 2.6 at both ends.
>>> Perfect!
>>> Can we use the matrix on the wiki page to show what is working well and what isn’t?
>>>    https://www.ipfire.org/docs/roadmap/openvpn-26
>>> We might want to create a second table for N2N.
>>
>> I will see what I can do.
>>
>>>> So most critical things seem to be working but there are a couple of puzzling things to be dealt with.
>>> Cool. Hopefully we should be able to get it all done very soon!
>>
>> So currently I am able to confirm that existing n2n connections and newly created n2n connections with CU197 at the end creating the new connection and CU196 at the end receiving it are all working as previously with CU196 at both ends.
>>
>> Regards,
>> Adolf
>>
>>> Best,
>>> -Michael
>>>> Regards,
>>>>
>>>> Adolf.
>>>> <Screenshot_2025-07-25_14-12-40.png>
> 
> 
>