From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN patchset from Erik's input Date: Wed, 22 Feb 2023 16:17:22 +0000 Message-ID: <618509F0-367D-419B-93FE-9750132F2C9B@ipfire.org> In-Reply-To: <3e45d933-4ae0-4d82-9154-6eadbe6c342b@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4870536715704680327==" List-Id: --===============4870536715704680327== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, > On 22 Feb 2023, at 12:54, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 22/02/2023 12:21, Michael Tremer wrote: >> Hello Adolf, >>> On 17 Feb 2023, at 11:46, Adolf Belka wrote: >>>=20 >>> Hi All, >>>=20 >>>=20 >>> I got Erik's OpenVPN patchset from some time ago and have created an upda= ted patchset based on the current state of IPFire. >> Okay. So I suppose it all applied well or you were able to fix any merge c= onflicts. > I had to end up applying all the patches manually. There were enough change= s with the OTP stuff plus the change to the system commands that many Hunks f= ailed to apply plus I found one hunk that applied in the wrong place. >=20 > So manual application just seemed the most secure if a bit long winded appr= oach. That was why I created the new patch set because that is now based on n= ext so any changes can be done relative to that patch set. >>> I applied those changes to ovpnmain.cgi and en.pl and installed them into= a vm clone on my testbed. >>>=20 >>> Here are some images of the changes. Basically the ciphers are moved from= the main page to an additional ciphers page. >> Yes, this is something the user ideally does not need to change. I would a= ctually not hesitate too much to just hardcode something as 99% of people wil= l be on the same settings. >> However, I do not understand why there are different options for the contr= ol and data channel. I do not see any reason why I would want different setti= ngs because I either support a certain cipher or I don=E2=80=99t. If I consid= er my data channel =E2=80=9Cless important=E2=80=9D or need more throughput a= nd use AES-128 instead of AES-256, then what is the benefit of keeping the co= ntrol channel on AES-256? >> Then there is labelling which isn=E2=80=99t clear to me. I suppose it work= s as follows: >> Data Channel is the new setting. It should in theory be possible to select= multiple options. >> Data Channel fallback seems to be what used to be on the front page before= and it should only allow to pick one option. If that is the case, then I bel= ieve that the UI suggests otherwise. This setting will then also go away with= OpenVPN 2.6.0. Is that correct? > That is what I would read it as. I will check if more than one option can b= e selected in the fallback set. Okay. Thank you. >> On the control channel the options are mislabeled. I suppose TLSv3 should = be TLSv1.3 and TLSv2 should be TLSv1.2 and possible less?! > That sounds like what is intended. >> I don=E2=80=99t really like it that there are two boxes, but since TLSv1.3= does not support many of the cipher suites that TLSv1.2 supports, there migh= t be no easy way around it. TLSv1.2 is on its way out, so we won=E2=80=99t ne= ed to support this for forever hopefully. >> Authentication: If there is only one option, the