Hi,
On 22/04/2024 19:35, Michael Tremer wrote:
Hello,
On 22 Apr 2024, at 11:19, Adolf Belka adolf.belka@ipfire.org wrote:
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.
I am on a flight right now and can’t check. I think this is implemented like this now, or do I need to make any changes?
It is the same as we currently have, so no change, so that is fine with me.
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.
It’s does have a downside which I consider quite significant: it’s slow. Mainly because of the hash function which needs to be run once for each packet. It also adds some overhead to each packet since the hash has to be transferred. I believe there is some truncation but this is still huge.
Since OpenVPN is already quite slow and single-threaded, this is not going to make it any faster. Now performance should not come before security but I don’t know what the actual impact is to the average user.
Understand the concern. All my testing and usage on my production system has not had a lot of traffic. My OpenVPN Roadwarrior usage is basically accessing my network to be able to access my emails and some other basic stuff. None of it uses a lot of bandwidth so if using TLS does make it slower I would not notice.
Regards, Adolf.
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.
I think I have some bad news then. This doesn’t quite work, simply because OpenVPN is not doing consistent things the first time it starts and when it reloads. It checks some directory permissions instead of the actual file it needs to access and that does not seem to make any sense to me. So we need to maybe reach out to upstream and see if we can fix this long-term.
But overall I didn’t think that this is what I was hoping for as the OpenVPN server shuts down the entire tun interface and therefore disconnects every client. Since it does all that, we might just as well re-execute the entire binary from scratch. I wanted to just reload the configuration but keep all connections alive.
In the meantime, I have changed the default configuration so that the server will send a notification to the client that it is going down. Therefore UDP clients will try to reconnect very quickly and hopefully the user doesn’t notice too much.
This has however the downside that if the admin clicks Save, all clients will reconnect without warning. This might be better than what we had before but it isn’t good.
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.
Yes I ran into that too but wasn’t sure if this was because of my development system. This is a general issue with the init functions.
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.
Okay, let’s keep it to 2.6 for now until we have stabilised this and then check if 2.5 still works fine.
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.
lol. Of course :)
Regards, Adolf.
-Michael
Regards,
Adolf