Hi Michael,
On 16/04/2024 13:06, Michael Tremer wrote:
Hello Adolf,
On 15 Apr 2024, at 17:57, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
I did a fetch of the latest status of the OpenVPN-2.6 branch in your repo and then ran a build on it and did a fresh install with the iso that was created.
Thank you for helping me finding the nasty bugs that I building into all of this.
I think testing everything out is where I can definitely contribute on this project. So far I haven't found anything that is a big problem.
I then created the root/host x509 certificate set with no problems.
Created a Static IP Address pool. One thing I found here was that after creating 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 to get the correct subnet. I had made an error in the number I chose so that was why I was trying to edit it.
Yeah, this has been the same since forever. The problem is slightly that changing 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, but not essential.
Ah, I didn't realise that it was always like that. So I have never tried to change the subnet, only the name. I would agree that removing the edit option would seem to be a reasonable step.
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 pressed Save.
I am not entirely sure whether the defaults that we are choosing still make sense. If we support TLS Channel Protection, why is this not enabled? How much of a performance impact does it have? Why don’t we pre-fill the domain with the domain name of IPFire? We probably have to do a bit of investigation here what makes sense.
In terms of the TLS Channel Protection, I would definitely agree that we should select that by default and set the SHA512 as the default hash. It improves the security of the whole tunnel creation process and as far as I am aware does not have any downsides. Since I started using OpenVPN on IPFire, I have always had the TLS Channel Protection enabled and used.
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 that if you put the mouse over the hard disk icon it still says "Download Encrypted Client Package (zip)".
Okay, I will change the text :) There is now only one single configuration file.
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 the Save Advanced Settings button, whether something has been modified or not the Server Stops and will not restart.
This is kind of a new “feature”. I am trying to reload the server. Generally that works, but there are a couple of issues that I still have 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.
No problem. Can wait for the fix for that.
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, though.
That didn't work. I had to manually delete the pid from the console command line and then pressing the Save button started the server again.
If I deleted the pid then the server would start again. Running /etc/rc.d/init.d/openvpn-rw reload results in an OK message but running the status command 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.
IPFire diagnostics Section: openvpn Date: April 15, 2024
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/run/ovpnserver.log': Permission denied (errno=13) 18:46:59 openvpnserver[12829]: Options error: --writepid fails with '/var/run/openvpn.pid': Permission denied (errno=13) 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?
Not sure. I will check what the .ovpn profile contained that might have triggered this.
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: external 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=-1,code=4)
This looks like the reload is resulting in a SIGHUP[hard,] causing the process to restart but without having properly removed the pid file.
There is also the message about the ovpnserver.log I did not touch that file and after removing the pid file the server restarts and the system logs OpenVPN log has no mention about that log file in it.
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 with OpenVPN 2.5 and 2.6. I believe we should support all clients that support NCP. If they don’t, they will not work with a newly generated configuration. This is intentional.
I tested this on my Arch Linux laptop so it would have had 2.6.9 or 2.6.10 installed.
Clients that don’t 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 all the way :)
Glad to be of service.
Regards, Adolf.
-Michael
Regards,
Adolf