From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Test of latest OpenVPN-2.6 repo up to commit "ovpnmain.cgi: Refactor top table of adding/creating connections" Date: Tue, 16 Apr 2024 12:06:27 +0100 Message-ID: <30219A16-BEF6-4632-8415-691C73476082@ipfire.org> In-Reply-To: <9e3a4fca-1347-4dd4-bc59-801ba5fc446f@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5651266524665026187==" List-Id: --===============5651266524665026187== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, > On 15 Apr 2024, at 17:57, Adolf Belka wrote: >=20 > Hi Michael, >=20 > I did a fetch of the latest status of the OpenVPN-2.6 branch in your repo a= nd then ran a build on it and did a fresh install with the iso that was creat= ed. Thank you for helping me finding the nasty bugs that I building into all of t= his. > I then created the root/host x509 certificate set with no problems. >=20 > Created a Static IP Address pool. One thing I found here was that after cre= ating it I could choose the edit function and modify the Name but the subnet = could not be modified. I had to delete the existing version and start again t= o get the correct subnet. I had made an error in the number I chose so that w= as why I was trying to edit it. Yeah, this has been the same since forever. The problem is slightly that chan= ging the subnet is becoming complicated when hosts have been created using IP= addresses from that subnet. So I am not sure whether there is a lot value in= creating the option to edit this when it is unused. It is a nice to have, bu= t not essential. > Went into the Advanced settings and enabled the TLS Channel Protection and = added entries into the DHCP Settings section for the Domain and DNS. Then pre= ssed Save. I am not entirely sure whether the defaults that we are choosing still make s= ense. If we support TLS Channel Protection, why is this not enabled? How much= of a performance impact does it have? Why don=E2=80=99t we pre-fill the doma= in with the domain name of IPFire? We probably have to do a bit of investigat= ion here what makes sense. > Then I created a Client Connection. The file icon I saw now is only a .ovpn= file with the certificates embedded into the .ovpn. A point I noticed is tha= t if you put the mouse over the hard disk icon it still says "Download Encryp= ted Client Package (zip)". Okay, I will change the text :) There is now only one single configuration fi= le. > After creating the client connection the Server started when I pressed the = Save button in the Roadwarrior Settings section. Yay \o/ > I then installed the client .ovpn into my laptop's Network Manager OpenVPN = plugin and the connection was successfully made. Double yay! \o/ \o/ > However I have noticed that if I then go to the Advanced Server and press t= he Save Advanced Settings button, whether something has been modified or not = the Server Stops and will not restart. This is kind of a new =E2=80=9Cfeature=E2=80=9D. I am trying to reload the se= rver. Generally that works, but there are a couple of issues that I still hav= e to sort out, as OpenVPN drops its permissions and runs as a privileged user= . However, we are writing the PID file as root and OpenVPN cannot edit this (= I am not even sure why it is trying to do so at all). This is hopefully easy = to fix, but I have not made it to that just yet. > Checking the status on the CLI the message cam back that the server was not= running but the pid was present. If you click the Save button on the main page again it should start again, th= ough. > If I deleted the pid then the server would start again. Running /etc/rc.d/i= nit.d/openvpn-rw reload results in an OK message but running the status comma= nd then gives the message that openvpn is not running but openvpn.pid exists = so it looks like the reload command is not executing correctly. This is a problem that is somewhere in the initscripts and keeps bothering me= for quite a while now. > In the WUI System Logs OpenVPN section the following was shown. >=20 > IPFire diagnostics > Section: openvpn > Date: April 15, 2024 >=20 > 18:46:59 openvpnserver[12829]: Use --help for more information. > 18:46:59 openvpnserver[12829]: Options error: Please correct these errors. > 18:46:59 openvpnserver[12829]: Options error: --status fails with '/var/ru= n/ovpnserver.log': Permission denied (errno=3D13) > 18:46:59 openvpnserver[12829]: Options error: --writepid fails with '/var/= run/openvpn.pid': Permission denied (errno=3D13) > 18:46:59 openvpnserver[12829]: Note: --cipher is not set. OpenVPN versions= before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in= this case. If you need this fallback please add '--data-ciphers-fallback BF-= CBC' to your configuration and/or add BF-CBC to --data-ciphers. Wait. Why is it logging this? Does this make any sense? > 18:46:59 openvpnserver[12829]: SIGHUP[hard,] received, process restarting > 18:46:59 openvpnserver[12829]: Linux ip addr del failed: external program = exited with error status: 2 > 18:46:59 openvpnserver[12829]: /sbin/ip addr del dev tun0 10.202.247.1/24 > 18:46:59 openvpnserver[12829]: Closing TUN/TAP interface > 18:46:59 openvpnserver[12829]: ERROR: Linux route delete command failed > 18:46:59 openvpnserver[12829]: ERROR: Linux route delete command failed: e= xternal program exited with error status: 2 > 18:46:59 openvpnserver[12829]: /sbin/ip route del 10.110.26.0/24 > 18:46:59 openvpnserver[12829]: event_wait : Interrupted system call (fd=3D= -1,code=3D4) >=20 > This looks like the reload is resulting in a SIGHUP[hard,] causing the proc= ess to restart but without having properly removed the pid file. >=20 > There is also the message about the ovpnserver.log I did not touch that fil= e and after removing the pid file the server restarts and the system logs Ope= nVPN log has no mention about that log file in it. >=20 > Let me know if you need any other information and I will provide it. Which client versions did you use to test this with? This should work both wi= th OpenVPN 2.5 and 2.6. I believe we should support all clients that support = NCP. If they don=E2=80=99t, they will not work with a newly generated configu= ration. This is intentional. Clients that don=E2=80=99t support NCP or where NCP has been disabled should = still work on older installations as we will configure the fallback cipher. So, this is great work. Thank you! It confirms that I have screwed this up al= l the way :) -Michael > Regards, >=20 > Adolf >=20 >=20 --===============5651266524665026187==--