We should not have any configuration files that we share in this place,
therefore this patch is moving it into /usr/share/openvpn where we
should be able to update it without any issues.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- When bug#11408 was fixed it was missed that key 41 has disabled inserted into it when
uploading into the N2N client. This replaced the no-pass entry for all N2N connections
resulting in the ovpnmain.cgi not being able to show the status correctly as the code
looks for pass or no-pass.
- The disabled entry has been present for a very long time and is not utilised anywhere
in the code.
- This fix ensures that key 41 in the uploaded N2N connection has no-pass entered
- Tested out and confirmed in my vm testbed.
Fixes: Bug#13548
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This was fixed by moving the code for checking if the common name is already used, to
the same location as the code for checking if the connection name is already used.
- Tested out on vm testbed and confirmed that the certificates are not created and the
index.txt not updated if the common name is flagged as already being used. If the
entry is changed to use a new CN and Save pressed then the certs are saved and the
index.txt updated. If Cancel is pressed then no certs are saved and index.txt is not
updated.
Fixes: Bug#13404
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- At long last I have re-visited the patch submission for bug #11048 and fixed the issues
that caused the problems last time I evaluated it in Testing.
- The insecure package download icon is shown if entry 41 in /var/ipfire/ovpn/ovpnconfig
is set to no-pass. The code block on ovpnmain.cgi that deals with this checks if the
connection is a host and if the first password entry is a null. Then it adds no-pass
to ovpnconfig.
- The same block of code is also used for when he connection is edited. However at this
stage the password entry is back to null because the password value is only kept until
the connection has been saved. Therefore doing an edit results in the password value
being taken as null even for connections with a password.
- This fix enters no-pass if the connection type is host and the password is null, pass if
the connection type is host and the password has characters. If the connection type is
net then no-pass is used as net2net connections dop not have encrypted certificates.
- The code has been changed to show a different icon for unencrypted and encrypted
certificates.
- Separate patches are provided for the language file change, the provision of a new icon
and the code for the update.sh script for the Core Update to update all existing
connections, if any exist, to have either pass or no-pass in index 41.
- This patch set was a joint collaboration between Erik Kapfer and Adolf Belka
- Patch set, including the code for the Core Update 180 update.sh script has been tested
on a vm testbed
Fixes: Bug#11048
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Suggested-by: Adolf Belka <adolf.belka@ipfire.org>
Suggested-by: Erik Kapfer <ummeegge@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- If the certificate name has underscores in it then the status always shows as DISCONNECTED
alothough the actual connection is working and can be used.
- The certificate with underscores works fine. RFC5280 accepts underscores in the name.
- The code for checking the status splits up the status message and takes the first part
as the common name for the connection. Then there is a regex command which rerplaces
any underscores in the status common name with spaces. This results in the connection
with underscores in the certificate name never matching any status feedback common
name as the underscores have been replaced by spaces.
- This has been tested to work with my vm test bed. With existing code the connection with
underscores in the certificate name permanently showed DISCONNECTED. With the code change
the connection shows as CONNECTED very quickly.
Fixes: Bug#13190
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This was fixed for creating a static ip address pool name in bug#12865 but was not
applied to the case when the static ip address pool name was being edited.
- This fix corrects that oversight.
Fixes: Bug#13136
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- This now only adds "providers legacy default" to the config files of connections that
have legacy certificates, both for n2n and roadwarrior.
- This new approach also removes the requirement to have code in the update.sh script
or in backup.pl so those earlier modifications are removed in two additional patches
combined with this one in a set.
- The -legacy option has been removed from the pkcs12 creation part of the code as
otherwise this creates a certificate in legacy format, which is not wanted. All new
connection certificates being created will be based on openssl-3.x
Fixes: Bug#13137
Suggested-by: Michael Tremer <michael.tremer@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- With a n2n connection .p12 certificate created wityh openssl-1.1.1x the line
providers legacy default is required in the n2nconf file to enable it to start.
- Any openssl-3.x attempt to open a .p12 file created with openssl-1.1.1x will result in
a failure and an error message. All the openssl commands dealing with pkcs12 (.p12)
files need to have the -legacy option added to them.
Fixes: Bug#13137
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- Any insecure connections made with openssl-3.x can have the cert and key extracted but
if the insecure connection was made from prior to CU175 Testing then it used
openssl-1.1.1 which causes an error under openssl-3.x due to the old version being able
to accept older ciphers no longer accepted by openssl-3.x
- Adding the -legacy option to the openssl commands enables openssl-3.x to successfully
open them and extract the cert and key
- Successfully tested on a vm system. Confirmed that the downloaded version under
openssl-3.x worked exactly the same as the version downloaded under openssl-1.1.1
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- The insecure package download icon is shown if entry 41 in /var/ipfire/ovpn/ovpnconfig
is set to no-pass. The code block on ovpnmain.cgi that deals with this checks if the
connection is a host and if the first password entry is a null. Then it adds no-pass
to ovpnconfig.
- The same block of code is also used for when he connection is edited. However at this
stage the password entry is back to null because the password value is only kept until
the connection has been saved. Therefore doing an edit results in the password value
being taken as null even for connections with a password.
- This fix enters no-pass if the connection type is host and the password is null, pass if
the connection type is host and the password has characters. If the connection type is
net then no-pass is used as net2net connections dop not have encrypted certificates.
- The code has been changed to show a different icon for unencrypted and encrypted
certificates.
- Separate patches are provided for the language file change, the provision of a new icon
and the code for the update.sh script for the Core Update to update all existing
connections, if any exist, to have either pass or no-pass in index 41.
- This patch set was a joint collaboration between Erik Kapfer and Adolf Belka
- Patch set, including the code for the Core Update 175 update.sh script has been tested
on a vm testbed
Fixes: Bug#11048
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Tested-by: Erik Kapfer <ummeegge@ipfire.org>
Suggested-by: Adolf Belka <adolf.belka@ipfire.org>
Suggested-by: Erik Kapfer <ummeegge@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- In six places <td class'base'> has been used instead of <td class='base'>
- This patch fixes that error - tested on my vm testbed. Selecting Inspect Element now
shows the corrrect result rather than class 'base' being set to null.
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
- On CU172 Testing Build: master/eb9e29f9 when selecting the OpenVPN menu it showed the
Diffie-Hellman info and pressing back took you to the same DH page.
- Tested patch suggestion from Erik on vm testbed and confirmed that it worked.
Suggested-by: Erik Kapfer <erik.kapfer@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
We already moved away from 2048-MODP in Core Update 170. Similarly,
German Federal Office for Information Security (BSI) recommends shifting
away from RSA keys below 3,000 bits by the end of 2022 at the latest.
The only place left in IPFire 2.x where we generate such keys is for
IPsec and OpenVPN host certificates. This patch increases their key
sizes to 4,096 bits as well - CA certificates already have this length.
Existing VPN connections cannot be migrated automatically. However, only
the respective host certificate has to be regenerated - thanks to the CA
certificates' key length being sufficient, there is no need to replace
the entire VPN CA.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- The fix for bug #12428 removed spaces from the validhostname subroutine as hostnames are
not supposed to have spaces
- This resulted in spaces no longer being allowed for the Static IP Address Pools names
- New subroutine created called validccdname in general-functions.pl
Fixes: Bug #12865
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- Patch https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=2feacd989823aa1dbd5844c315a9abfd49060487
from May 2021 put the variable containing the .p12 content into double quotes which
causes the contents to be treated as text whereas the .p12 file is an application file.
- Most people must be downloading the zip package of .p12, ovpn.conf and ta.key files so
the problem was not noticed till now and flagged up in the forum.
https://community.ipfire.org/t/openvpn-p12-password-on-android-problem/8127
- The problem does not occur for the .p12 file in the zip file as the downloading of the
zip file does not have the variable name in double quotes.
- Putting the zip file variable into double quotes caused the downloaded zip file to be
corrupt and not able to be opened as an archive.
- Removing the double quotes from the .p12 variable name caused the separate .p12 file
download to be able to be correctly opened.
- The same quoted variable name is used also for the cacert.pem, cert.pem, servercert.pem
and ta.key file downloads. To be consistent the same change has been applied to these.
Fixes: Bug #2883
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
These configuration option are required to make the client authenticate
itself against the server.
The server may then accept those credentials without any further ado or
ask for a OTP.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Although Perl modules tend to take a long time to load, it is better to
do this at the beginning so that loading the script will show any
errors.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Add two-factor authentication (2FA) to OpenVPN host connections with
one-time passwords.
The 2FA can be enabled or disabled per host connection and requires the
client to download it's configuration again after 2FA has beend enabled
for it.
Additionally the client needs to configure an TOTP application, like
"Google Authenticator" which then provides the second factor.
To faciliate this every connection with enabled 2FA
gets an "show qrcode" button after the "show file" button in the
host connection list to show the 2FA secret and an 2FA configuration QRCode.
When 2FA is enabled, the client needs to provide the second factor plus
the private key password (if set) to successfully authorize.
This only supports time based one-time passwords, TOTP with 30s
window and 6 digits, for now but we may update this in the future.
Signed-off-by: Timo Eissler <timo.eissler@ipfire.org>
Bumping across one of our scripts with very long trailing whitespaces, I
thought it might be a good idea to clean these up. Doing so, some
missing or inconsistent licence headers were fixed.
There is no need in shipping all these files en bloc, as their
functionality won't change.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
OpenVPN might try to connect via IPv6 in rare occasions.
To avoid that, we can tell it to use IPv4 exclusively.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Option "--secret" was deprecated in OpenVPN 2.4 and removed in OpenVPN 2.5
It was replaced by "secret". If "--secret" is used with genkey then a user warning is
printed and this is what gives the Internal server error.
- Patch was defined by Erik Kapfer but currently he does not have a build environment
so I have submitted the patch on his behalf.
- Patch tested on a vm testbed running Core Update 160. Confirmed that without patch the
error still occurs and with patch everything runs smoothly.
Fixes: Bug #12574
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by : Erik Kapfer <ummeegge@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
This parameter can either be "host" or "net", but the existing check
only allows "net" entries. Since other entries are also valid but
don't require further action, this patch removes the error message.
Fixes: #12686
Signed-off-by: Leo-Andres Hofmann <hofmann@leo-andres.de>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This disables the theme support and makes it impossible to use any other
themes than the ipfire default theme.
The only intention of this patch is to hardcode the theme to ipfire.
To change any cgi we have is an ugly way, but the only way to do this
fast. The colour handling needs certainly to be improved as well, but
this will and should be done in other patches.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
OpenVPN is an absolute mess. The behaviour of configuration
parameters has been changed over the time; default values have been
changed over time; and it looks like nobody is actually testing
anything any more.
I have been spending hours today on figuring out why OpenVPN
is so damn slow. On a Lightning Wire Labs IPFire Mini Appliance
it achieves about 100 MBit/s in the default configuration when
"openssl speed -evp aes-256-gcm" achieves over 3.5 GBit/s.
Changing any of the cryptography parameters does not change
anything. Throughput remains around 100 MBit/s.
I finally set "cipher none" and "auth none" which disables
encryption and authentication altogether but does not increase
throughput. From here on it was absolutely clear that it was
not a crypto issue.
OpenVPN tries to be smart here and does its own fragmentation.
This is the worst idea I have heard of all day, because that job
is normally done best by the OS.
Various settings which allow the user to "tune" this are grossly
ineffective - let alone it isn't even clear what I am supposed
to configure anywhere. Setting "fragment 1500" weirdly still
does not convince openvpn to generate a packet that is longer
than 1400 bytes. Who'd a thunk?
There is a number of other parameters to set the MTU or which
are related to it (tun-mtu, link-mtu, fragment, mssfix).
On top of all of this we have two "bugs" in ovpnmain.cgi which
are being fixed in this patch:
1) mssfix can be configured by the user. However, we always
enable it in openvpn. The default is on, we only add "mssfix"
which simply turns it on.
It is now being disabled when the user has chosen so in the
web UI. I do not know if this is backwards-compatible.
2) We cap the MTU (tun-mtu) at 1500 bytes when fragment is being
used. So it becomes pointless that the user can this and the
user is not being made aware of this when they hit the save
button.
This was added when we added path MTU discovery. Since that
did not work and was removed, we can remove this now, too.
I archived a solid 500-600 MBit/s of goodput with these settings:
* Disable mssfix
* Set "fragment" to 0
* Set MTU to 9000
I am sure the MTU could be further increased to have bigger packets,
but I did not test how badly this will affect latency of the tunnel.
OpenVPN seems to only be able to handle a certain amount of packets
a second - no matter what. With larger packets, the throughput of
the tunnel increases, but latency might as well.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Cc: Erik Kapfer <erik.kapfer@ipfire.org>
Cc: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
