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 4bn7dr4s4lz330j for ; Wed, 23 Jul 2025 09:10:40 +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 4bn7dn0tcPz2xQW for ; Wed, 23 Jul 2025 09:10:37 +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 4bn7dg4ppNz1XX; Wed, 23 Jul 2025 09:10:31 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1753261831; 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=72VTSpx0soT8jhz4LgRBDGSGPLsdY60zjHQ/6bToYG8=; b=3I+n0ckWHgqPK01AwmB2TOdYXtKotL1MNgsB/SeRFncgipKUDLPamxU0M2eeVlwYydoOGH K0yv0ljcObqSy8CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1753261831; 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=72VTSpx0soT8jhz4LgRBDGSGPLsdY60zjHQ/6bToYG8=; b=YFMZifFxvudW+P3IHNzQ0pRRvT6enjt2gk4KJMC/wu6JTOq15ruAobKt0EbBmabVgduPs0 DkJRC+zX1batMcz5DDngSgr6+FjfGfRaFG/H8Jtl36KoPa6QFWpt96d0aVJfxfAsNCfekT FN+Zm5MTs8jZVdJgNHUB9Mq6sb1VVrz9BpsuMlnGVQlLflgYneyijBqW2RuknbvYXrNJ0U ShixriRY2YYu+34RynoEpbdS78KRX46SoKnOBvmexeX2IAv+IX900jB0bSFy2xCg2iYi8k XxDVoq3QGv2LjllrhkImYYgGs6VS4+6ojfhsmWeBzXFw2RlfBFWCrFiawPFJwg== 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: <0dfab62b-8d05-4a13-8328-b0aecad1880f@ipfire.org> Date: Wed, 23 Jul 2025 10:10:31 +0100 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <4A96D393-99F4-4EC4-AD23-3CAE3CD46AB6@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> <0DA9F7B5-BD92-4406-95FB-61B45E444BB2@ipfire.org> <0dfab62b-8d05-4a13-8328-b0aecad1880f@ipfire.org> To: Adolf Belka Hello, Thank you for looking into this. I have not given this all too much = testing, yet, so this is very valuable for me. I like these checklists = that I can just work through. So here we go... > On 22 Jul 2025, at 13:47, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 18/07/2025 12:32, Michael Tremer wrote: >> 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 >=20 > The starting of the n2n and rw systems are still failing in the = update.sh script. >=20 > The n2n is giving this message in the update log >=20 > iptables: No chain/target/match by that name. > modprobe: FATAL: Module tun not found in directory = /lib/modules/6.12.23-ipfire > Starting OpenVPN N2N connection 'ipfirenet2net'... = OK >=20 > and the rw gives >=20 > modprobe: FATAL: Module tun not found in directory = /lib/modules/6.12.23-ipfire > iptables: No chain/target/match by that name. > iptables: No chain/target/match by that name. > Starting OpenVPN Roadwarrior Server... = FAIL > Starting OpenVPN Authenticator... = OK >=20 > I believe that the message "iptables: No chain/target/match by that = name." is because new chains are used in the initscripts and the = firewall has not been restarted in the update.sh scrip so the chains are = not yet recognised. Yes, so let=E2=80=99s reload the firewall before we restart the OpenVPN = connections: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D3eefc5fc6d98= b6a117284c30c8ef0b3f67440c52 > The message "FATAL: Module tun not found" I don't remember seeing in = my last test but not 100% sure. That is correct. This is only since Arne updated the kernel. modprobe = weirdly does not seem to check whether the module is already loaded = (which it should be) when OpenVPN has been used, but look for it in the = modules directory of the running kernel. That would have been removed to = make space for the new kernel. Hence the message. I am now simply throwing away the message: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D39172586ac87= 78d34392ef881dda3eca797239a4 > So I think for the n2n initscript is is line 88 where the new chain = OVPNINPUTN2N is being used. >=20 > For the rw initscript I think it is lines 41 & 44 that both try to use = the new chain OVPNINPUTRW. >=20 > I think the firewall engine needs to be restarted before the = openvpn-rw and openvpn-n2n initscripts are attempted to be started. Yes, see above. > I checked the server.conf file in my updated system and it had not = been updated. >=20 > In the 197 update log there is a line >=20 > sed: -e expression #4, char 22: unknown option to `s' Here, I must have been too fast with my copy-and-pasting. I pushed a = fix: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D81e867c96620= ac5f000f68afa6b4cc36066f1a78 > So the update to the server.conf failed and after a lot of looking at = the command I realised that the forward slashes for the pathname of the = openvpn-rw.log file were not escaped. Indeed. I normally use @ as the separator which allows me to use slashes = without escaping them. However, we are removing a line and that line = insisted on the slash. Since I didn=E2=80=99t want to mix separators in = the same sed command this happened. Well. Meh. But you found it :) Any more for more? -Michael >=20 > Regards, >=20 > Adolf. >=20 >> 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 >=20 >=20