From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4bwgmZ1zx4z32Mj for ; Mon, 4 Aug 2025 15:42:38 +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 4bwgmV51mNz2y9V for ; Mon, 4 Aug 2025 15:42:34 +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 4bwgmV0Hhgzmh; Mon, 4 Aug 2025 15:42:33 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1754322154; 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=6slJWpHh0ozEm7dvjYlPub9fG2ic13osclTfkOeSbVo=; b=B0YVj4xk8RfgfxagJ8/aP+Mv5GIl48gwb6CSg9EjGhSmkX9z/6shh7RLDW6uUx4tZUtQdd l70DQc7yx1IA+cAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1754322154; 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=6slJWpHh0ozEm7dvjYlPub9fG2ic13osclTfkOeSbVo=; b=gXM6yEKwSBA/iMOLUrho7TMR/2bnukzLasGAsXB93btmufkpAjuLVG3GDqubLWHEazrgeG qM+UVZ6R72BqjT0zTxv6OWiXIJwlbauptm2Aabh14g4ktYrHVIMnG3Y5U/5K+AZ8WP7sHd UhSB586mg44ZLUpfBg8BYcTLExlmz0PtxIyEZnfnba7VdldVzFBoBiKGH6nmuLWn7HKt9z Pigbp11mExVilwoJWilFFWHwq5tx2MolnTVfCt9gbvywT50F0LlOP/qVQrn7AA5xVMiMaw MO59JoxFDX1q19qGLCpwzI+NaSbdw2wSHeukhtLVg6UWZyL8oEHUwjb2+8RMww== 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: <92058959-4ab6-41de-917d-ebed4bdf45c0@ipfire.org> Date: Mon, 4 Aug 2025 16:42:33 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <74C67C3E-E975-48AE-863C-AEFCEE669B26@ipfire.org> References: <92058959-4ab6-41de-917d-ebed4bdf45c0@ipfire.org> To: Adolf Belka 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. > 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. > 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=99= 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. >=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. > 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, >=20 > Adolf. >