I have openvpn server running and IPSEC VPN running. Both worked flawlessly until core 189, now both are broke. IPSEC failed to connect but not looked into that as to why yet. Just noticed the breakage at 0500 this morning. The openvpn connection from my Android 15 Pixel 6 gives log errors.
Nothing changed anywhere in any settings or on any devices. Thoughts on this?
Nothing changed regarding OpenVPN on CU189.
The auth-retry and providers options are unsupported on the client you are using but they are just ignored so no issue from that.
The issue is related to pkcs12 no longer being supported by the client you are using. Likely you had a client update on the device you are using.
This has been mentioned on other posts where users mentioned that their client had the message that pkcs12 was deprecated but would still be used if the user pressed yes to accept.
With your updated client it is obviously just no longer supporting pkcs12 and not accepting the certificate because of that.
I don’t fully understand why those clients no longer accept pkcs12 certificate bundles as they are still fully usable via openssl and are not deprecated in that program. Also the standard community linux command line client version, the Linux Network Manager OpenVPN pugin and the OpenVPN for Android app, all on latest versions, are all still happily accepting pkcs12 cert bundles. It only appears to be a few OpenVPN clients that have decided to no longer support pkcs12.
What program/package/app are you using for the OpenVPN connection on your client.
The only three options that I can think of in the short term are:-
In the next big update of the OpenVPN WUI page, hopefully early in the new year, when we move to using cipher negotiation, we will also have embedded .ovpn profile files for certs with and without passwords.
Searching on the syntax of the messages seen in your client, this suggests that you are using the OpenVPN Connect client.
This was designed for use with Access Server and CloudConnexa but can also work with open-source OpenVPN servers.
So it should work with the IPFire Community version.
However, I have also found info indicating that the OpenVPN3 server version that they designed did not include libraries to handle pkcs12 files and it looks like it has been decided to not include this capability at all. So it looks like it is the use of pkcs12 files in OpenVPN Connect that has been deprecated and now removed although pkcs12 continues to be run in many other clients.
When I click on the link to download the OpenVPN Connect client it sends me to the OpenVPN3 webpage so it looks like OpenVPN have also decided to remove the pkcs12 capability in their OpenVPN Connect client even if it is being used with the Community OpenVPN2 Server version which does have the pkcs12 library capability.
If your client is not OpenVPN Connect, it would be good to know which client and which version you are using.
Thank you for the reply and all the info. Yes, client is openvpn connect. Always worked great for years. Suppose core update and app update could have been a very odd coincidence. With openvpn considered solved, I will have to now see why ipsec broke at the exact same time between ipfire and watchguard devices.
—EDIT
IPSEC randomly decided to connect after rebooting the appliance so it appears something was hung there. It was only running for a couple weeks.
It ended up making more sense in the long run to spin up a VM for standalone openvpn server running latest build. It is more capable and easily upgrades to keep in line with current connection standards and practices.
– EDIT2
Just out of curiosity, I did figure out the multiple issues. IPfire is including several options that don’t appear they should be in the client config. A little trial and error and it does work now, though still staying with my standalone VPN server. See lines commented out.
#OpenVPN Client conf
tls-client
client
nobind
dev tun
proto udp
tun-mtu 1500
remote xxxxxxxxxxx.org 1194
#pkcs12 xxx.p12
cipher AES-256-GCM
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name xxxxxxxxxxxxxx.org name
mssfix 0
auth-nocache
#auth-token-user USER
#auth-token TOTP
#auth-retry interact
Those options all work with OpenVPN community clients on my Linux laptop and my Android phone.
I think the problem is that the OpenVPN Connect client which is using OpenVPN3 and not OpenVPN2 is not supporting several of the options that are available in OpenVPN2.
I am currently writing this via an OpenVPN connection with all of those options in place with no issues and have been for many days.
For OpenVPN Connect to not support the verify-x509-name option does not look like a good idea to me. That is making sure that the name used for the x509 matches with the name in the client certificate.
I agree, that’s why I’m not using it.
