Hello,
i am in the process of setting up OpenVPN.
But I can’t get the service to start.
The log list of OpenVPN is empty.
Thank you.
???
Hi,
from what I can see in your screenshot (please redact it before posting!), there haven’t been any clients configured.
Did you -
- click “Static IP address pools” and fill the required fields in section Global Settings?
- click “Add” in section “Connection Status and -Control” and add a client?
I’m not sure if OpenVPN should be starting regardless of the missing configuration mentioned above, but I would give it a try and then see if it starts.
There is a bug in Core Update 183 regarding the openssl commands for creating a new root/host x509 certificate set.
This was due to an OpenSSL bug fix that was implemented in version 3.2.0
There have already been a couple of posts on this topic in the forum.
Please see the bug report
https://bugzilla.ipfire.org/show_bug.cgi?id=13595
for more details.
A patch to fix this has been submitted and will hopefully get into Core Update 184.
3 Likes
Thank you Adolf Belka,
I’ll probably have to wait for the next update.
It’s funny, on the homepage he says Online. 
but only here.
an interface for the OpenVPN, in your case the Red interface. If you uncheck the red interface and save the page so that no interfaces are checked then you will find that the OpenVPN entry will no longer be shown in the Home Page.
If you need to get OpenVPN working then you can
- Wait for the next update with the fix
- Do a backup, install Core Update 182, restore the backup, do the OpenVPN Root/Host certificate installation and then do a Core Update to 183 and then finish off the OpenVPN configuration.
- Manually implement the fix on your Core Update 183 system
The fix is to edit
/var/ipfire/ovpn/openssl/ovpn.cnf
and remove lines 87 and 88 which are the following
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
The same lines are used elsewhere in the same ovpn.cnf file so make sure that it is lines 87 & 88 in the section headed [ server ]
Before doing the edit make a copy of the file as ovpn.cnf.orig or whatever you want so that you have it as a backup and note down what the permissions and ownerships are in case you need to revert your changes.
When everything is working okay then you can delete the .orig file.
You will be able to tell it is working if you don’t get the
OpenSSL hat einen Fehler verursacht: 256
and both the root and the host certificates are present in the table on the main OpenVPN WUI page.
2 Likes
No sooner commented out than everything works.
Thank you.
Is something still missing here?
openvpn-connect-3.4.4.3412_signed.msi
OpenVPN-2.6.9-I001-amd64.msi
2024-02-22 16:26:00 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). OpenVPN ignores --cipher for cipher negotiations.
2024-02-22 16:26:00 WARNING: cannot stat file 'Schoenemann.p12': Das System kann die angegebene Datei nicht finden. (errno=2)
Options error: --pkcs12 fails with 'xxxx.p12': Das System kann die angegebene Datei nicht finden. (errno=2)
2024-02-22 16:26:00 WARNING: cannot stat file 'ta.key': Das System kann die angegebene Datei nicht finden. (errno=2)
Options error: --tls-auth fails with 'ta.key': Das System kann die angegebene Datei nicht finden. (errno=2)
Options error: Please correct these errors.
Use --help for more information.
The incorrect creation of certificates is not the only problem.
Different files are packed in the ZIP file. Core-Update 182 (5 files)/ Core-Update 183 ( 3 files)
Core 182
ta.key 1Kb
xxxx-TO-IPFire.ovpn 10Kb
xxxx.pem 3Kb
xxxx.key 4Kb
cacert.pem 3Kb
Core 183
xxxx.p12 7Kb
xxxx-TO-IPFire.ovpn 1Kb
ta.key 1Kb
Since the .ovpn contains almost nothing, no connection can be established.
Core 182
xxxx-TO-IPFire.ovpn 10Kb#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto tcp
tun-mtu 1400
remote 192.168.3.2 1194
;ca cacert.pem
;cert xxxx.pem
;key xxx.key
cipher AES-256-CBC
auth SHA512
;tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name ipfire-gast.localdomain-gast name
mssfix 0
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interact-----BEGIN CERTIFICATE-----
…
Core 183
xxxx-TO-IPFire.ovpn 10Kb#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto tcp
tun-mtu 1400
remote xxx-xxx.ddns.net 1194
pkcs12 xxxx.p12
cipher AES-256-CBC
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name ipfire.localdomain name
mssfix
auth-nocache
auth-token-user USER
auth-token TOTP
auth-retry interactNO MORE ENTRIES
A test with the Core 182 was carried out successfully.
I am therefore optimistic that with a correct .ovpn it will also work with the Core 183.
You are comparing apples with oranges here.
In Core Update 182 with those 5 files you have the insecure package set where the certificate has no password.
In Core Update 183 with those 3 files you have the secure package set where the certificate has a password.
If you want the same as with Core Update 182 with 5 files then when you create the client connection leave the two password boxes empty.
The .ovpn that you showed is what I have on my client connections to my Linux Laptop and to my Android Phone using the “OpenVPN for Android” app. In both cases the connections work fine and both have passwords associated with them.
Earlier you referenced .msi files related to your clients so I suspect your clients are windows machines.
I have no windows machines at all, so have no experience at all regarding windows clients.
This type of error message is saying that the client could not find the file in question. Did you specify to the windows client where it should find that file and also the .p12 file?
Does your windows client only accept a connection from a .ovpn that embeds the certificates and keys inside the .ovpn. If that is the case then you need to use the insecure client connection approach, without a password.
If the key has to be in the .ovpn then it cannot have a password.
2 Likes
The client connection icons will show if you have a secure version with a password or an insecure version without a password.
The connection labelled testing has an icon without a padlock symbol on it and that is used when the certificate has been created without a password.
The connection labelled testing2 has an icon with a padlock symbol on it and that is used when a password has been used for the certificate.
1 Like
Does your windows client only accept a connection from a .ovpn that embeds the certificates and keys inside the .ovpn. If that is the case then you need to use the insecure client connection approach, without a password.
If the key has to be in the .ovpn then it cannot have a password.
You have to come up with something like that first.
OK I’ll try it again with the unsafe variant. 
I know why I don’t have any Windows computers in my private life. You have more time to eat ice cream.
Just for information
2 Likes