Hi Michael,
On 22/07/2025 14:47, Adolf Belka wrote:
Hi Michael,
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=ipfire-2.x.git;a=commitdiff;h=13b7e3803cfd803d42d4ef082fba37859aa1e2f7
The starting of the n2n and rw systems are still failing in the update.sh
script.
The n2n is giving this message in the update log
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
and the rw gives
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
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.
The message "FATAL: Module tun not found" I don't remember seeing in my last
test but not 100% sure.
I have realised that the initscript is still looking for the tun module in the
6.12.23 directory but the directory after the update is now 6.12.39
Regards,
Adolf.
So I think for the n2n initscript is is line 88 where the new chain
OVPNINPUTN2N is being used.
For the rw initscript I think it is lines 41 & 44 that both try to use the new
chain OVPNINPUTRW.
I think the firewall engine needs to be restarted before the openvpn-rw and
openvpn-n2n initscripts are attempted to be started.
I checked the server.conf file in my updated system and it had not been updated.
In the 197 update log there is a line
sed: -e expression #4, char 22: unknown option to `s'
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.
Regards,
Adolf.
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 <adolf.be...@ipfire.org> wrote:
Hi Michael,
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’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.
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
iptables: No chain/target/match by that name.
I figured out that to fix this we need to restart the firewall in the update.sh
However there was still the message
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.
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
writepid /var/run/openvpn.pid
and
ncp-disable
etc
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.
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.
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
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.
Regards,
Adolf.
Best,
-Michael
On 30 Jun 2025, at 12:13, Adolf Belka <adolf.be...@ipfire.org> wrote:
Hi Michael,
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.
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.
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.
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.
So the rw server and the n2n connection services have some interaction around
identifying the correct pid file.
Regards,
Adolf.
On 30/06/2025 11:55, Adolf Belka wrote:
Hi Michael,
On 30/06/2025 10:46, Michael Tremer wrote:
Hello Adolf,
The initscript works absolutely fine for me:
Interesting.
[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
/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
/var/run/openvpn:
total 0
[root@ipfire-openvpn ipfire-2.x]# /etc/init.d/openvpn-rw status
/usr/sbin/openvpn is not running.
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.
-Michael
On 30 Jun 2025, at 09:40, Michael Tremer <michael.tre...@ipfire.org> wrote:
Hello Adolf,
Thank you very much for looking into this for me.
On 29 Jun 2025, at 11:51, Adolf Belka <adolf.be...@ipfire.org> wrote:
Hi All,
Tested out the latest openvpn-rebase branch from @ms using the link to the iso
that he provided from the latest fixes.
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.
That is a good start.
Unfortunately the start and stop issue is still present.
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.
When I start the system running with the openvpn server running and then I
disable the server then it shows the server as stopped.
If I then enable the server and save then the checkbox is enabled but the
server stays stopped.
On the command line the status shows
/usr/sbin/openvpn is not running but /var/run/openvpn-rw.pid exists.
So the server stopped but the pid was not removed.
If I boot the system and the server was checked as enabled then everything
starts properly.
The boot screen shows
Starting OpenVPN Roadwarrior Server... OK
Starting OpenVPN Authenticator... OK
Starting OpenVPN N2N connection 'ipfirenet2net'... OK
then if I straight away reboot the shutdown screen shows
Stopping OpenVPN Authenticator... Not running WARN
Stopping OpenVPN Roadwarrior Server... FAIL
Stopping OpenVPN N2N connection 'ipfirenet2net'... OK
Okay, this is interesting. The authenticator cannot run without the RW service
being active. So this does not concern me at this point.
The RW server should however be running if it is enabled. Is there anything in
the logs that explains why it crashed?
The N2N connection starts and stops correctly and the pid is removed.
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.
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.
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.
Neither do I :) It is all very broken there and so there won't be a very clean
and obvious way ahead.
I will look into it.
Any other findings so far?
-Michael
Regards,
Adolf.
