Hi all,
I had a backup (IPF) from a working machine. VPN was configured with OpenVPN and I could access / dial in from my mobile phone. After a hardware failure I reinstalled 158 again from scratch and restored my IPF. It’s showing the same configuration as I had before but it’s not working.
Can it be that any one of the certificates is now wrong because the Box generated a set of new keys upon the first start?
How can I debug that?
Thanks a lot in advance,
Thomas
Your restore from your backup will replace all the certificates, conf files etc to the state they were in when the backup was done.
When you say it is not working do you mean that your client fails to connect or that it connects but then fails with the certificate handshake or what?
What messages are in the OpenVPN server log and in your OpenVPN client log.
The OpenVPN server log can be accessed from the Logs - System Logs menu and selecting OpenVPN in the dropdown box and then pressing Update.
Was the backup you restored from, from Core Update 158 or recent or from a much older Core Update?
I had a similar problem after restoring from a backup. OpenVPN clients could no longer connect.
On the client side, the connection log showed:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed.
In IPFire, I found in /var/log/messages the following:
ipfire openvpnserver[2370]: … VERIFY ERROR: depth=0, error=CRL has expired: C=redacted, ST=redacted, O=redacted, CN=redacted, serial=16
I checked the CRL in the OpenVPN server settings using the button “Show certificate revocation list”, and saw that the “Next Update” value was in the past. I then followed the instructions on https://wiki.ipfire.org/configuration/services/openvpn/config/upload_gen to renew the CRL. After the CRL was renewed, clients could again connect.
@stevecb - thanks.
Today I realized that I was unable to connect my roadwarrier OpenVPN clients, with the same connection log entries you quoted.
Your hint helped me to resolve the issue.
Also in my case, “Next Update” value was in the past.
Thanks!
I had exactly the same problem.
And running
openssl ca -config /var/ipfire/ovpn/openssl/ovpn.cnf -gencrl -out /var/ipfire/ovpn/crls/cacrl.pem
resolved this for me (v.186)
I think this problem came with the update to 186 where the update of CRL is not working anymore. We’ll see in about a month
If the update to Core Update 186 is carried out after 9th July 2024 then the corrected openvpn-crl-updater script was merged into the update. I have tested that and confirmed that it is working.
The fix is also in Core Update 187 which is currently released for Testing. The plan is to be able to release the full version by end of July so that release will then update your openvpn-crl-updater script to the correct one.
More details are in some posts in the main thread on this issue.
https://community.ipfire.org/t/log-summary-openvpn-no-crl-update/11816
https://community.ipfire.org/t/log-summary-openvpn-no-crl-update/11816/7
https://community.ipfire.org/t/log-summary-openvpn-no-crl-update/11816/11
Additionally restoring as backup no longer has the risk of providing an expired CRL as since Core Update 172 the openvpn-crl-updater script is run after every restore that you do ensuring that your restored certs have a fully updated CRL.
Hello,
I actually have the same problem with an expired CRL. Unfortunately I can’t run openssl ca -config /var/ipfire/ovpn/openssl/ovpn.cnf -gencrl -out /var/ipfire/ovpn/crls/cacrl.pem because there is no directory called openssl in /var/ipfire/ovpn/. Thats also the reason why the daily cron-script fails. Is there any possibility to generate a new cert without being forced to replace all client certs?
Best regards
Yes.
In the first link that I provided there is a post that gives the change needed to the command you used to give it the new location for the ovpn.cnf file
https://community.ipfire.org/t/log-summary-openvpn-no-crl-update/11816/5