OpenVPN Server refusing to connect
-
@gil That's the TLS error quoted above. Any idea what it means beyond the obvious?
-
The first thing I would do is switch that server from IPv4+IPv6 multihome to IPv4-only unless you know multihome is what you want.
Then I would blow out the client configuration, re-export a configuration, and re-import it in the client.
-
Hmmm. So after a nagging suspicion struck, apparently it's my Let's Encrypt certificate that is the problem (or the CA, whatever). Switched to the self-signed and everything works, including Multihome. It's weird because LE work for https access from the WAN. Oh, and Shimo on macOS keeps asking for the password in a loop, but OpenVPN Connect 2.5.0.136 works, ditto for OpenVPN iOS.
Lies, Damn Lies, and Encryption. Bah Humbug.
Obvious Error was Obvious, but still not helpful as to WHY. Grump.
-
OpenVPN Connect seems quite happy to connect over IPv6 as well.
-
OK. Yes. Didn't see that. You do not use a public CA for OpenVPN. You use a local CA.
Even if you were to get it working, any other cert generated by LetsEncrypt would also pass that validation step.
-
@derelict
Is that in the manual, wiki, or HOWTOs anywhere? I don’t recall seeing it?Do you mind explaining why? Enquiring minds want to know. ;-)
-
I thought I just did?
Even if you were to get it working, any other cert generated by LetsEncrypt would also pass that validation step.
That's pretty much the last thing anyone would want.
Pretty hard to document all the things people might try to do that they shouldn't do since that's essentially an infinite list.
None of the documentation produced says anything about using a public CA for a VPN to validate users. Even the certificate type would be incorrect.
-
@derelict
OK, I understand the words but not the meaning? Why would I not want a certificate validated by a public CA? Is a VPN not supposed to have any dependencies? -
@daplumber The OpenVPN documentation also recommends setting up your own CA [1].
The server only needs its own certificate/key -- it doesn't need to know the individual certificates of every client which might possibly connect to it.
The server will only accept clients whose certificates were signed by the master CA certificate (which we will generate below). And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection.
So as @Derelict said, if using a public CA was possible, then relying on a CA that issues certificates to anyone (without your consent) would allow anyone to authenticate on your VPN. There might be other layers to the authentication like a preshared-key, but you effectively neutralized one additional layer of security with a public CA.
By using your own CA, you know clients on the VPN cannot connect unless you grant them a client certificate, or they steal one you already issued to another client, or they take over your CA and issue their own... or an authorized client violates the trust of your VPN by giving away their client certificate, etc, etc.
Also, OpenVPN's certificate scheme requires that the certificates identify their type as server or client. I doubt Let's Encrypt offers client certificates, though some public CA's do.
Cheers
[1]: https://openvpn.net/index.php/open-source/documentation/howto.html#pki
-
@boxofrox
Ah!
<Sound of penny dropping, lightbulb turning on, forehead slap>Thank you, I forgot about the “certificate granting” part of a CA. What do you call it when you’re too young for a “senior moment” and too old for a rookie mistake? ;-)
Salaam, kudos, thanks!
