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 4bk5hn5MWsz2ywH for ; Fri, 18 Jul 2025 10:32:41 +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 4bk5hk1WMNz2xXK for ; Fri, 18 Jul 2025 10:32:38 +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 4bk5hj4Q2tzPV; Fri, 18 Jul 2025 10:32:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1752834757; 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=Gx+nXIxM1BhCpHendZCTPG1YWpPgVPJuoORqY7Eg978=; b=ceKTuO3mj35REh+5DdcUqK/qRTg2Nw/KxVKptnGZwi2/bifrY+qvQD10yWMSNv/ehQnRAA 6iv8QIqj66Q8irlDe7ULn9FwfLFfr5dj36DDee7E4H+DLi6tPaXqa27ANwLb5d8rcpmd1+ SRgEakQ+kG19KSdnjgwrt/p1thKG+aGZo4Ovvip3xaoBL2h7gDklaiDbVH/snMs9f0j97l YlnHQ2SOfH28UpwflV8+Jmpa2vL0x0Q3DTOHJECau4spFVN5oyTPhdJCTno8+4hnuquxWI kTU810xfQmnDK9EOUVrXP/Q4cyAxTaXBlB8FGu3w9/V0YSPaGHCoBD09nJsLAA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1752834757; 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=Gx+nXIxM1BhCpHendZCTPG1YWpPgVPJuoORqY7Eg978=; b=FttUJXNCDO9ERFBYCKuUOkFqiLxXix9Ee+mCsdxy27aDchCqzMdyLd/5Y5u1RaDwqcoOMu VOUlcmJzmyTn23DQ== 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: <07070d6a-b7cc-4e10-9f33-69e009c695cf@ipfire.org> Date: Fri, 18 Jul 2025 11:32:37 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <0DA9F7B5-BD92-4406-95FB-61B45E444BB2@ipfire.org> References: <1396727E-BF73-4015-B853-B3F854806B28@ipfire.org> <7FE631A7-BAF8-4A92-AE02-A173D2C1E746@ipfire.org> <88C3BD62-7CBF-477A-845A-B9118C54A95D@ipfire.org> <07070d6a-b7cc-4e10-9f33-69e009c695cf@ipfire.org> To: Adolf Belka Hello Adolf, Thank you for testing this. I believe that I have fixed the = configuration changes in this commit: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D13b7e3803cfd= 803d42d4ef082fba37859aa1e2f7 Can you find out which iptables chain it is missing? This could = potentially be the reason why your Android client is not allowed to ping = anything. Best, -Michael > On 17 Jul 2025, at 12:58, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 15/07/2025 12:16, Michael Tremer wrote: >> 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=99= t 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. >=20 > So I cloned my CU195 vm and updated it to CU197 Unstable. I found an = issue. After updating, when I rebooted the system I got the message >=20 > iptables: No chain/target/match by that name. >=20 > I figured out that to fix this we need to restart the firewall in the = update.sh >=20 > However there was still the message >=20 > FAILURE: > You should not be reading this error message. > It means that an unforeseen error took place in = /etc/rc.d/rc6.d/K10openvpn-rw, which exited with a return value of 1. >=20 > After repeating the update on a new clone and checking at various = stages I discovered that the message is shown because the start of = openvpn-rw fails and this is because the server.conf file still has the = old configuration settings in it, such as >=20 > writepid /var/run/openvpn.pid > and > ncp-disable > etc >=20 > Pressing the Save button on the WUI page updates the server.conf file = with the new settings and then successfully starts the openvpn-rw = daemon. >=20 > So before running the openvpn-rw restart command some sort of command = needs to be run to update the server.conf file with the new settings = that have been defined in the update. >=20 >=20 > I also noticed that after updating the server.conf, if a reboot is = done then in the console screen you see that stopping openvpn-rw shows = up as FAIL >=20 > The daemon is actually stopped but the pid file is still present, = which gets ignored for the startup part of the reboot. > However the stop stage of any reboot will currently show the = openvpn-rw stop failing. That is not a big issue as the startup ignores = the pid that is present but I am sure there will be users flagging it up = when we do the actual release. >=20 > Regards, >=20 > Adolf. >=20 >> 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 >=20 >=20