The host certificate shown in the “Certifcate Authorities and -Keys” section of the OpenVPN setup page, the Host Certificate shows an ip that does not exist. (At least I can’t ping the address shown).
When, on a client, I attempt to connect it fails to connect. The log shows the address mentioned above.
After adding the .opvn file on the device, the first time I attempt to connect is also show this certificate when the user is prompted to select. But, I can’t find a way to either generate a new one (in the IPFIRE OpenVPN configuration) or select (on the client) it if I did.
Note that this will remove the Root/Host certificates but also all the client certificates. It basically takes you back to a fresh OpenVPN default page. Creating a new Root/Host certificate set requires all client connections to be re-created as they use the server certificate info.
So before you press the “Remove x509” button (If you do press it then you first get a warning about what will happen) make sure that the issue is an incorrectly defined IP/Hostname. If the OpenVPN clients used to be able to access the IPFire OpenVPN server then something must have changed.
Do you have a static IP from your ISP.
Do you have a Dynamic IP Address from your ISP. If so then when the IP changes your OpenVPN server would no longer be accessible.
In that case, set up a Dynamic DNS address to your ISP IP and use the DDNS name for the OpenVPN server.
That message means that the server certificate failed verification from your client for some reason.
It would be useful if you could show the full log messages from the client and also from the IPFire OpenVPN Server.
You can change sensitive items such as your Dynamic DNS host/domain name.
When you created the client connection did you use a password for the certificate or is password-less?
You have turned on TLS Channel Protection on the server and this is what is failing in the communication between client and server.
When you set up the client did you install the ta.key file from the IPFire client package into the appropriate place in the client for the tls authentication?
The client has an import .ovpn file option. This allows selection of the 3 files in the zip file downloaded and unzipped from the server. When adding a profile I must select the .ovpn and ta.key files otherwise it fails to parse and won’t add the profile.
I didn’t set TLS, at least not knowingly.
In the client settings the is a setting for minimum TLS version, it defaults to “profile default”. But, setting it to any of the options (1.0,1.3,etc.) seems to make no difference.
The section circled in red if checked is providing TLS Channel Protection and will give you tls-auth in the .ovpn file and you will get a ta.key file that has to be loaded up in your client.
The common issues with this are related to a firewall blocking the communication. In the case of IPFire it is set up to allow OpenVPN communications to occur so that is unlikely to be the problem unless you have specifically created Firewall Rules to block port 1194 or whichever port you are using.
The other cause that is mentioned is
The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network’s gateway.
Is the remote directive in your client .ovpn the same as your Dynamic DNS address
Ok, so TLS is checked by default and I never changed it.
The client is OpenVPN on Android.
I’m pretty sure I tried selecting all three files at one point, .opvn, .key, and .p12.
One thing I notice, is when I try to connect it always asks to select a certificate. But, the selection doesn’t show where the offered cert is coming from and doesn’t show enough of it to compare to what’s seen in the server.
I don’t think I have any port blocking specifically for 1194. I do have intrusion prevention enabled with Emergingthreats.net Community Rules.
Currently my cell service is intermittent so can’t tinker…(that’s where the client is installed)
The missing step for me was setting the password for the .p12.
Doing that and following the rest of the steps produced more steps (on the client) that I was not offered previously.
And, part of the problem appears to be a stale cert on the phone. I now have the new (working) cert and the stale one. Can’t seem to find a way to remove the old cert.
