From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4bz9bJ1MFvz30R0 for ; Fri, 08 Aug 2025 17:13:16 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R11" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4bz9bD4402z30Vk for ; Fri, 08 Aug 2025 17:13:12 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4bz9bC4vTVz3nS; Fri, 08 Aug 2025 17:13:11 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1754673191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zh5TzKiPwCau8OqDgC4ZJ0zn4Eezc17fxYtKRiRkJRw=; b=jC5zixJoeSDUmqavxc2appKVLrFLghDi+NzevEesiSQL8d4/31JP9VRk1uhd4jQ5GdbJlW reh8YrhFQzaE8GDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1754673191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zh5TzKiPwCau8OqDgC4ZJ0zn4Eezc17fxYtKRiRkJRw=; b=EQ10zo9MNWIqZHKe5ayfGUl279MNFI+HCtdZqyMhSn1zfgbzMZMZoYRE1OYbAr3qeo4Qq1 Gm19UQU8wwGL0Eu2ocrXrzXY2f1khC3pi2NcPsFDx3xUztph5KNUdfQq8rghh/DuN3jxXb RFWhsN6JoQIpjQhlcUWqwPl/7dn3Hk/YfNEYlEeVafpA+wUN6/XJzX9PczNphW4ZUtSfDP 7zdYbBISQt2L1atD2M3Rtx6aHwyw9MPDT+MwPd1yzkJJbgdQ+kCdU4vCBfaEkM4ITY0EEU tIXOeVB5rqBSu2hud0R8EVl03riXxiftNU+eaKDgALJfn7ftXuhmXwxoz1+0TA== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: OpenVPN-2.6 Core Update 197 testing feedback From: Michael Tremer In-Reply-To: Date: Fri, 8 Aug 2025 18:13:11 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <39E91213-65EA-4121-B124-0D68AE6378D7@ipfire.org> References: <92058959-4ab6-41de-917d-ebed4bdf45c0@ipfire.org> <74C67C3E-E975-48AE-863C-AEFCEE669B26@ipfire.org> To: Adolf Belka 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=E2=80=99s 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-t= esting Have a nice weekend! -Michael > On 8 Aug 2025, at 14:17, Adolf Belka wrote: >=20 > Hi Michael, >=20 > Good news. >=20 > 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 = wrote: >>>=20 >>> Hi All, >>>=20 >>> So the openvpn-2.6 issues with the update process from 196 to 197 = have been solved by the last patches that were applied. >>>=20 >>> So now I have been evaluating existing connections and new = connections. >>>=20 >>> There is good and bad news but more good than bad so progress is = being made. >>>=20 >>> First thing was to test out my existing rw and n2n connections with = CU197. >>>=20 >>> The existing rw connection from my Linux laptop worked without any = issues and could ping a machine on the green network. >>>=20 >>> 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. >=20 > Yes. >=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >=20 > I repeated making a new n2n connection, both with an empty set of = client connections and also with existing rw & n2n connection in place. >=20 > 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. >=20 > Have now created three new n2n connections and in all three cases the = entry went as expected. >=20 > Additionally in all three cases I was able to ping in both directions = with no problems. >=20 >>> 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. >>>=20 >>> I then reviewed the n2n logs for one end of the tunnel between the = ping working version and the ping not working version. >>>=20 >>> Basically the contents were the same, resulting in an = "Initialization Sequence Completed" message, so it looked like it was = fully working. >>>=20 >>> 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=E2=80=99t 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. >>>=20 >>> 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=E2=80=99t? >> https://www.ipfire.org/docs/roadmap/openvpn-26 >> We might want to create a second table for N2N. >=20 > I will see what I can do. >=20 >>> 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! >=20 > 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. >=20 > Regards, > Adolf >=20 >> Best, >> -Michael >>> Regards, >>>=20 >>> Adolf. >>>