From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka 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: Fri, 03 May 2024 19:15:41 +0200 Message-ID: In-Reply-To: <19CEFA42-6B41-4355-9483-F40DC3633E80@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7751100688311789741==" List-Id: --===============7751100688311789741== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On 22/04/2024 19:35, Michael Tremer wrote: > Hello, >=20 >> On 22 Apr 2024, at 11:19, Adolf Belka wrote: >> >> =EF=BB=BFHi Michael, >> >>> On 16/04/2024 13:06, Michael Tremer wrote: >>> Hello Adolf, >>>>> On 15 Apr 2024, at 17:57, Adolf Belka wrote: >>>> >>>> Hi Michael, >>>> >>>> I did a fetch of the latest status of the OpenVPN-2.6 branch in your rep= o and then ran a build on it and did a fresh install with the iso that was cr= eated. >>> 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 thi= s 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 subn= et could not be modified. I had to delete the existing version and start agai= n to get the correct subnet. I had made an error in the number I chose so tha= t 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 usin= g IP addresses from that subnet. So I am not sure whether there is a lot valu= e 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 t= o change the subnet, only the name. I would agree that removing the edit opti= on would seem to be a reasonable step. >=20 > I am on a flight right now and can=E2=80=99t check. I think this is impleme= nted 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. >=20 >>>> Went into the Advanced settings and enabled the TLS Channel Protection a= nd 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 ma= ke sense. 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 = domain with the domain name of IPFire? We probably have to do a bit of invest= igation here what makes sense. >> >> In terms of the TLS Channel Protection, I would definitely agree that we s= hould select that by default and set the SHA512 as the default hash. It impro= ves the security of the whole tunnel creation process and as far as I am awar= e does not have any downsides. Since I started using OpenVPN on IPFire, I hav= e always had the TLS Channel Protection enabled and used. >=20 > It=E2=80=99s does have a downside which I consider quite significant: it=E2= =80=99s 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. >=20 > 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=E2=80=99t 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 o= f it uses a lot of bandwidth so if using TLS does make it slower I would not = notice. Regards, Adolf. >=20 >>>> Then I created a Client Connection. The file icon I saw now is only a .o= vpn 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 Enc= rypted Client Package (zip)". >>> Okay, I will change the text :) There is now only one single configuratio= n file. >>>> After creating the client connection the Server started when I pressed t= he Save button in the Roadwarrior Settings section. >>> Yay \o/ >>>> I then installed the client .ovpn into my laptop's Network Manager OpenV= PN 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 pres= s the Save Advanced Settings button, whether something has been modified or n= ot the Server Stops and will not restart. >>> This is kind of a new =E2=80=9Cfeature=E2=80=9D. I am trying to reload th= e 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 th= is (I am not even sure why it is trying to do so at all). This is hopefully e= asy to fix, but I have not made it to that just yet. >> >> No problem. Can wait for the fix for that. >=20 > I think I have some bad news then. This doesn=E2=80=99t quite work, simply = because OpenVPN is not doing consistent things the first time it starts and w= hen it reloads. It checks some directory permissions instead of the actual fi= le it needs to access and that does not seem to make any sense to me. So we n= eed to maybe reach out to upstream and see if we can fix this long-term. >=20 > But overall I didn=E2=80=99t think that this is what I was hoping for as th= e OpenVPN server shuts down the entire tun interface and therefore disconnect= s 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 kee= p all connections alive. >=20 > In the meantime, I have changed the default configuration so that the serve= r 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=E2= =80=99t notice too much. >=20 > This has however the downside that if the admin clicks Save, all clients wi= ll reconnect without warning. This might be better than what we had before bu= t it isn=E2=80=99t good. >=20 >>>> 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 comman= d line and then pressing the Save button started the server again. >=20 > Yes I ran into that too but wasn=E2=80=99t sure if this was because of my d= evelopment system. This is a general issue with the init functions. >=20 >>>> 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 co= mmand then gives the message that openvpn is not running but openvpn.pid exis= ts so it looks like the reload command is not executing correctly. >>> This is a problem that is somewhere in the initscripts and keeps botherin= g 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 erro= rs. >>>> 18:46:59 openvpnserver[12829]: Options error: --status fails with '/var= /run/ovpnserver.log': Permission denied (errno=3D13) >>>> 18:46:59 openvpnserver[12829]: Options error: --writepid fails with '/v= ar/run/openvpn.pid': Permission denied (errno=3D13) >>>> 18:46:59 openvpnserver[12829]: Note: --cipher is not set. OpenVPN versi= ons 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 tr= iggered this. >>>> 18:46:59 openvpnserver[12829]: SIGHUP[hard,] received, process restarti= ng >>>> 18:46:59 openvpnserver[12829]: Linux ip addr del failed: external progr= am 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= =3D-1,code=3D4) >>>> >>>> This looks like the reload is resulting in a SIGHUP[hard,] causing the p= rocess 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 bot= h with OpenVPN 2.5 and 2.6. I believe we should support all clients that supp= ort NCP. If they don=E2=80=99t, they will not work with a newly generated con= figuration. This is intentional. >> >> I tested this on my Arch Linux laptop so it would have had 2.6.9 or 2.6.10= installed. >=20 > Okay, let=E2=80=99s keep it to 2.6 for now until we have stabilised this an= d then check if 2.5 still works fine. >=20 >>> Clients that don=E2=80=99t support NCP or where NCP has been disabled sho= uld still work on older installations as we will configure the fallback ciphe= r. >>> So, this is great work. Thank you! It confirms that I have screwed this u= p all the way :) >> >> Glad to be of service. >=20 > lol. Of course :) >=20 >> >> Regards, >> Adolf. >>> -Michael >>>> Regards, >>>> >>>> Adolf >>>> >>>> --===============7751100688311789741==--