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 4bhFTf4vwDz331x for ; Tue, 15 Jul 2025 10:16: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) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R11" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4bhFTb18gKz2xZl for ; Tue, 15 Jul 2025 10:16:35 +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 4bhFTY5xZ9z91; Tue, 15 Jul 2025 10:16:33 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1752574594; 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=sCZaM434kWVgWnCBrHv7iChHDb4GQuCpNwdq6+2CFBM=; b=UX/HQSyxhJJUwgmy7JVAhAalug6aDv3UkgPy+xTzX9RGC/6xuuW0LJPdFZMEHgMV3DmgIk 2g/wDXcPP7zov1Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1752574594; 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=sCZaM434kWVgWnCBrHv7iChHDb4GQuCpNwdq6+2CFBM=; b=eYGvV61+Vz7jXePFCphbiQlOALo8/eqjTV9uEIot05457cniMw7WjpfR/tur/pAbmDM5+k t0B88ZyUDmUupf/Ocu8Pc8H/JZ6xPutuHtU+kbZ72hHJK+Rs8wE1qYTBayJcHvHwoGBiM2 XhvMtt2hJY7/Ag27izMDEwrK5ERDAkXNQi3sDPkrsAeTXklMOqy9C3YHu0sEdtgusxfrSE cgN+myX0A3O2hzKqoT7BSKnPT8fhm/lc9IL6dbeRxx4kNcLuwYPPRk3Q9HlepTTQdt8FO6 CBGcU4xAlOWJ3P55cJ4Fuh7xNe6iTZaNfVza2/1AbIScCeDVD8V7DiKwYwVl1w== 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: Feedback on the branch openvpn-rebase From: Michael Tremer In-Reply-To: Date: Tue, 15 Jul 2025 12:16:33 +0200 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <88C3BD62-7CBF-477A-845A-B9118C54A95D@ipfire.org> References: <1396727E-BF73-4015-B853-B3F854806B28@ipfire.org> <7FE631A7-BAF8-4A92-AE02-A173D2C1E746@ipfire.org> To: Adolf Belka Hello Adolf, Thank you for reporting this. I believe this was the last outstanding = issue that had to be resolved before the branch could be merged. Since it is now resolved, I went ahead and merged the branch into next = so that we are targeting releasing this with Core Update 197. It is absolutely important that we will give *a huge amount of testing* = because OpenVPN is being used by so many people and we don=E2=80=99t = want to break any existing setups, regardless of whether they are using = road warrior or net-to-net. So, please help us to test this all as soon as possible for a confident = release. Best, -Michael > On 30 Jun 2025, at 12:13, Adolf Belka wrote: >=20 > Hi Michael, >=20 > Before doing a fresh install I had a closer look and found that the = n2n config was no longer showing the status because it was not running = and wouldn't start due to the old pid still being present. >=20 > So what I have found is that if you have no openvpn server running and = start the rw server you can start and stop it with no problems and it = removes the openvpn-rw.pid. >=20 > If you only enable the n2n connection then the n2n connection is = started abnd can be stopped and started again with no problems and it = removes the ${name}n2n.pid file. >=20 > However if you start both the rw server and enable a n2n connection, = they both start okay but now if you stop the rw server it stops openvpn = but leaves the openvpn-rw.pid in place. If instead you disable the n2n = connection, this stops that service running but it fails to remove the = ${name}n2n.pid file. >=20 > So the rw server and the n2n connection services have some interaction = around identifying the correct pid file. >=20 > Regards, > Adolf. >=20 > On 30/06/2025 11:55, Adolf Belka wrote: >> Hi Michael, >> On 30/06/2025 10:46, Michael Tremer wrote: >>> Hello Adolf, >>>=20 >>> The initscript works absolutely fine for me: >> Interesting. >>>=20 >>> [root@ipfire-openvpn ipfire-2.x]# /etc/init.d/openvpn-rw status >>> /usr/sbin/openvpn is not running. >>> [root@ipfire-openvpn ipfire-2.x]# /etc/init.d/openvpn-rw start >>> Starting OpenVPN Roadwarrior Server... = = [ OK ] >>> Starting OpenVPN Authenticator... = = [ OK ] >>> [root@ipfire-openvpn ipfire-2.x]# /etc/init.d/openvpn-rw status >>> openvpn is running with Process ID(s) 27406. >>> [root@ipfire-openvpn ipfire-2.x]# ps aux | grep openvpn >>> nobody 27406 0.0 0.1 12052 7624 ? Ss 10:45 0:00 = /usr/sbin/openvpn --config /var/ipfire/ovpn/server.conf >>> root 27446 0.0 0.2 16580 10740 ? S 10:45 0:00 = /usr/bin/python3 /usr/sbin/openvpn-authenticator --daemon >>> root 27455 0.0 0.0 6660 2612 pts/1 S+ 10:45 0:00 = grep openvpn >>> [root@ipfire-openvpn ipfire-2.x]# ll /var/run/openvpn* >>> -rw------- 1 root root 227 Jun 30 10:45 /var/run/openvpn-rw.log >>> -rw-r--r-- 1 root root 6 Jun 30 10:45 /var/run/openvpn-rw.pid >>> srwxrwxrwx 1 root root 0 Jun 30 10:45 /var/run/openvpn.sock >>>=20 >>> /var/run/openvpn: >>> total 0 >>> [root@ipfire-openvpn ipfire-2.x]# /etc/init.d/openvpn-rw stop >>> Stopping OpenVPN Authenticator... = = [ OK ] >>> Stopping OpenVPN Roadwarrior Server... = = [ OK ] >>> [root@ipfire-openvpn ipfire-2.x]# ll /var/run/openvpn* >>> -rw------- 1 root root 227 Jun 30 10:45 /var/run/openvpn-rw.log >>> srwxrwxrwx 1 root root 0 Jun 30 10:45 /var/run/openvpn.sock >>>=20 >>> /var/run/openvpn: >>> total 0 >>> [root@ipfire-openvpn ipfire-2.x]# /etc/init.d/openvpn-rw status >>> /usr/sbin/openvpn is not running. >>>=20 >>> Can you confirm this on your system? Might the problem simply be = that your OpenVPN RW server crashes and then the PID file does not get = cleaned up properly? >> I already confirmed that because when it wouldn't start in the WUI = again, I used the manual commands. The only difference I see in the = commands is that I used /etc/rc.d/init.d/openvpn-rw >> My testing was also done on an install from the iso that you provided = the link to. >> One thing I noticed is that your /var/run/openvpn/ directory is = empty, so presumably no net 2 net config. I do have that, so I just = disabled the n2n connection (not deleted) and now my stop command is = working correctly. >> I then enabled the n2n connection again and the RW server can still = be successfully enabled/started and disabled/stopped and enabled/started = again. >> So whatever the problem is it was only present after I had restored = IPFire so that I got the rw and n2n connections. >> However now, the n2n connection no longer shows DISCONNECTED in a red = background but an empty space and now the n2n connection is no longer = showing up in my ps aux | grep openvpn listing, whereas before it did. >> I will try doing a fresh install again and test out with a fresh = config of the rw alone and then after that do a restore of my rw/n2n = connections and see what happens then. >> Regards, >> Adolf. >>>=20 >>> -Michael >>>=20 >>>> On 30 Jun 2025, at 09:40, Michael Tremer = wrote: >>>>=20 >>>> Hello Adolf, >>>>=20 >>>> Thank you very much for looking into this for me. >>>>=20 >>>>> On 29 Jun 2025, at 11:51, Adolf Belka = wrote: >>>>>=20 >>>>> Hi All, >>>>>=20 >>>>> Tested out the latest openvpn-rebase branch from @ms using the = link to the iso that he provided from the latest fixes. >>>>>=20 >>>>> The disable and enable checkbox now works. If you enable the = checkbox and save then the box is enabled and if you then disable and = save it the checkbox now is disabled so that previous issue is fixed. >>>>=20 >>>> That is a good start. >>>>=20 >>>>> Unfortunately the start and stop issue is still present. >>>>=20 >>>> This is less good. I am sure that I tested that the sever gets = properly started, restarted and stopped. I can look into this again. = Hopefully this should not stop us from conducting any further testing. >>>>=20 >>>>> When I start the system running with the openvpn server running = and then I disable the server then it shows the server as stopped. >>>>>=20 >>>>> If I then enable the server and save then the checkbox is enabled = but the server stays stopped. >>>>>=20 >>>>> On the command line the status shows >>>>>=20 >>>>> /usr/sbin/openvpn is not running but /var/run/openvpn-rw.pid = exists. >>>>>=20 >>>>> So the server stopped but the pid was not removed. >>>>>=20 >>>>> If I boot the system and the server was checked as enabled then = everything starts properly. >>>>>=20 >>>>> The boot screen shows >>>>>=20 >>>>> Starting OpenVPN Roadwarrior Server... OK >>>>> Starting OpenVPN Authenticator... OK >>>>> Starting OpenVPN N2N connection 'ipfirenet2net'... OK >>>>>=20 >>>>> then if I straight away reboot the shutdown screen shows >>>>>=20 >>>>>=20 >>>>> Stopping OpenVPN Authenticator... Not running WARN >>>>> Stopping OpenVPN Roadwarrior Server... FAIL >>>>> Stopping OpenVPN N2N connection 'ipfirenet2net'... OK >>>>=20 >>>> Okay, this is interesting. The authenticator cannot run without the = RW service being active. So this does not concern me at this point. >>>>=20 >>>> The RW server should however be running if it is enabled. Is there = anything in the logs that explains why it crashed? >>>>=20 >>>>> The N2N connection starts and stops correctly and the pid is = removed. >>>>>=20 >>>>> I believe that this might be due to the variable PIDFILE being = used for both the authenticator and the rw daemons and when the = openvpn-rw daemon is being shutdown it has the authenticator pid in the = PIDFILE variable and not the openvpn-rw.pid file name. >>>>=20 >>>> Yes, I had to play around a lot with this. The initscripts are = designed to deal with only one service and I hacked my way around it. >>>>=20 >>>>> I have tried various ways to change this in the openvpn-rw = initscript but I ended up fixing it for one thing but then creating a = problem for another one. Basically I think because I don't understand = how the whole initscript and pid process is running in IPFire. >>>>=20 >>>> Neither do I :) It is all very broken there and so there won't be a = very clean and obvious way ahead. >>>>=20 >>>> I will look into it. >>>>=20 >>>> Any other findings so far? >>>>=20 >>>> -Michael >>>>=20 >>>>>=20 >>>>> Regards, >>>>> Adolf. >>>=20 >>>=20 >>>=20 >=20