OpenVPN Server refusing to connect
-
Latest stable version of pfSense: 2.4.3-RELEASE-p1, openvpn-client-export: 1.4.14.
I have tried multiple times to set up an OpenVPN Remote access server, I have tried both manually and with the wizard. I have tried UDP and TCP, on port 1194 and 1195 respectively and verified the appropriate firewall rules were in place. I have tried Shimo and the OpenVPN client on macOS 10.13.4 and the OpenVPN client on an iPhone iOS 11.4. In all cases the client cannot connect and essentially hangs after requesting the password.
Here's the log from Shimo:
2018-05-31 14:45:58 State changed to: Contacting (before: Disconnected) 2018-05-31 14:45:58 OpenVPN management socket connected 2018-05-31 14:45:58 >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info 2018-05-31 14:45:58 >HOLD:Waiting for hold release:0 2018-05-31 14:46:10 >PASSWORD:Need 'Auth' username/password 2018-05-31 14:46:10 >STATE:1527795970,RESOLVE,,,,,, 2018-05-31 14:46:10 State changed to: Contacting (before: Contacting) 2018-05-31 14:46:10 >STATE:1527795970,WAIT,,,,,,Here's the pfSense Configuration screen for the last Wizard - UD - Port 1194 version:
The only OpenVPN log entries are repeats of:
May 28 21:17:18 openvpn 17848 192.168.123.182 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1527560233) Mon May 28 21:17:13 2018 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings May 28 21:17:18 openvpn 17848 192.168.123.182 TLS Error: incoming packet authentication failed from [AF_INET6]::ffff:192.168.123.182:52584 (via ::ffff:73.55.240.251%re2)I'm not sure why there should be an encryption error, the above isn't very helpful and my Google-Fu appears to be weak for this.
The above example is trying to connect via LAN, but coming in the WAN from Verizon is the same.
Did I miss something, as far as I can see it should all be working, but it isn't.
-
Have a look at the logs on your server: Status/System Logs/OpenVPN
-
@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!
