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.

Reply via email to