OpenVPN with laptop clients failing after pfSense Upgrade to 2.5.0
-
I found & tried the OpenSUSE 2.5.1 client, but it didn't make any difference. I also tried setting the interface to any, again no go.
-
@jimp said in OpenVPN with laptop clients failing after pfSense Upgrade to 2.5.0:
Please post the server log and client log from a single connection attempt to see what is happening there.
Server:
Feb 25 10:04:24 firewall openvpn[88273]: 99.245.217.240:32854 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb 25 10:04:24 firewall openvpn[88273]: 99.245.217.240:32854 TLS Error: TLS handshake failed
Feb 25 10:04:34 firewall openvpn[38758]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Feb 25 10:04:34 firewall openvpn[38758]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 25 10:04:34 firewall openvpn[38758]: TCP/UDP: Preserving recently used remote address: [AF_INET]172.16.0.1:1194
Feb 25 10:04:34 firewall openvpn[38758]: UDPv4 link local: (not bound)
Feb 25 10:04:34 firewall openvpn[38758]: UDPv4 link remote: [AF_INET]172.16.0.1:1194Client - OpenSUSE 15.2 network manager
2021-02-25T10:04:23.967189-05:00 E520 NetworkManager[1467]: <warn>
[1614265463.9636]
vpn-connection[0x5649aad226e0,58407612-4bce-4c1b-9421-3dcc15e7f6e7,"firewall-UDP4-1194-E520-config",0]:
VPN connection: connect timeout exceeded.
2021-02-25T10:04:23.971490-05:00 E520 nm-openvpn-serv[5314]: Connect
timer expired, disconnecting.
2021-02-25T10:04:23.974072-05:00 E520 nm-openvpn[5317]: SIGTERM[hard,]
received, process exiting
2021-02-25T10:04:23.974457-05:00 E520 NetworkManager[1467]: <warn>
[1614265463.9729]
vpn-connection[0x5649aad226e0,58407612-4bce-4c1b-9421-3dcc15e7f6e7,"firewall-UDP4-1194-E520-config",0]:
VPN plugin: failed: connect-failed (1)
2021-02-25T10:04:23.974809-05:00 E520 NetworkManager[1467]: <info>
[1614265463.9730]
vpn-connection[0x5649aad226e0,58407612-4bce-4c1b-9421-3dcc15e7f6e7,"firewall-UDP4-1194-E520-config",0]:
VPN plugin: state changed: stopping (5)
2021-02-25T10:04:23.975133-05:00 E520 NetworkManager[1467]: <info>
[1614265463.9730]
vpn-connection[0x5649aad226e0,58407612-4bce-4c1b-9421-3dcc15e7f6e7,"firewall-UDP4-1194-E520-config",0]:
VPN plugin: state changed: stopped (6)As I mentioned earlier, it will connect when the client is on the LAN side of pfsense, but not WAN side. The client is OpenVPN 2.5.1, but I had similar results with 2.4.3.
.
-
I addressed that to the OP of this thread. You need to start your own thread.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
-
@jknott said in OpenVPN with laptop clients failing after pfSense Upgrade to 2.5.0:
I am having the same problem as the OP. However, my own thread is here.
Your problem may seem similar, but there isn't nearly enough information to say they are the same. Make sure you have posted all of the info in your thread (server config, client config, connection logs) so it's all in one place and keep it there.
-
@jimp
[An Aside - sorry, I did try updating the post to include an extract of the log but received an "Error : Forbidden" message. I later discovered it was Firefox preventing me from editing the post or replying to other participants in the topic, so am using Brave to post this.]I'll post an extract from the log below. Names have been obfuscated. The Verbosity level is only set to 3 but the indication is probably sufficient to see the cause.
Now, I did experiment by changing "Certificate Depth" from "1" to "Do not check" and that did resolve the issue - the VPN's were once again operational. That would seem to imply that the issue with the validation of the common name in the certificates as discussed in more detail by others.
Yes, strictly speaking the Data VPN could be a Remote Access type rather than a Peer-to-Peer type VPN, but I don't believe that consideration is relevant to the issue at hand. We do have another OpenVPN server on the router that is a multi-site Peer-to-Peer system (offices to data centre type approach) with almost identical configuration so the same issue will apply there.
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 SIGUSR1[soft,tls-error] received, client-instance restarting
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 TLS Error: TLS handshake failed
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 TLS Error: TLS object -> incoming plaintext read error
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 TLS_ERROR: BIO read tls_read_plaintext error
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 VERIFY SCRIPT ERROR: depth=1, C=NZ, ST=Canterbury, L=Christchurch, O=Frederick Nurkus, emailAddress=frederick@gmail.com, CN=CCDataCA, OU=Engineering
Feb 25 17:18:42
openvpn
30178
118.149.76.4:58703 WARNING: Failed running command (--tls-verify script): external program exited with error status: 1
Feb 25 17:18:41
openvpn
30178
118.149.76.4:58703 TLS: Initial packet from [AF_INET]118.149.76.4:58703, sid=73ec816b ef7bf8f5
Feb 25 17:18:41
openvpn
30178
118.149.76.4:58703 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Feb 25 17:18:41
openvpn
30178
118.149.76.4:58703 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication -
If the depth check change fixed it, then it's one we're already aware of and working on a fix for.
You could try this change to see if it helps in the meantime.
diff --git a/src/usr/local/sbin/ovpn_auth_verify b/src/usr/local/sbin/ovpn_auth_verify index 021eb6c39ffebf8fac3c0ca660dc483b4e40d94a..4ca01f3b7ad2b532ead5bcc26a8834478d746181 100755 --- a/src/usr/local/sbin/ovpn_auth_verify +++ b/src/usr/local/sbin/ovpn_auth_verify @@ -24,14 +24,14 @@ if [ "$1" = "tls" ]; then for check_depth in $(/usr/bin/seq ${3} -1 0) do eval serial="\$tls_serial_${check_depth}" - RESULT=$(/usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&config=$config") + RESULT=$(/usr/local/bin/php-cgi -q /etc/inc/openvpn.tls-verify.php "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&config=$config") done else # Single quoting $password breaks getting the value from the variable. # Base64 and urlEncode usernames and passwords password=$(echo -n "${password}" | openssl enc -base64 | sed -e 's_=_%3D_g;s_+_%2B_g;s_/_%2F_g') username=$(echo -n "${username}" | openssl enc -base64 | sed -e 's_=_%3D_g;s_+_%2B_g;s_/_%2F_g') - RESULT=$(/usr/local/sbin/fcgicli -f /etc/inc/openvpn.auth-user.php -d "username=$username&password=$password&cn=$common_name&strictcn=$3&authcfg=$2&modeid=$4&nas_port=$5") + RESULT=$(/usr/local/bin/php-cgi -q /etc/inc/openvpn.auth-user.php "username=$username&password=$password&cn=$common_name&strictcn=$3&authcfg=$2&modeid=$4&nas_port=$5") fi if [ "${RESULT}" = "OK" ]; then -
@jimp
Jim, thanks for that. I will endeavour to try that over the next few days and will report back. -
@jimp Jim, I actioned the following on the pfSense router per your suggestions:
-
Made a backup copy of the script file /usr/local/sbin/ovpn_auth_verify
-
Edited the script file, and changed those two lines as indicated, then saved the file.
-
Reverted the setting of Certificate Depth in the OpenVPN Server configuration to "1", and saved the change.
-
Rebooted the router.
I'm happy to report that the OpenVPN clients logged in to the OpenVPN server without issues, so I believe that has resolved the issue.
[Aside - I forgot to mention in the previous posts that user authentication is via the local database, although you will probably have figured that out already.]
Thanks very much for your help,
Eric
-
-
This change worked for me, too.
Is there a point release coming which will include this fix?
-
@yobyot said in OpenVPN with laptop clients failing after pfSense Upgrade to 2.5.0:
This change worked for me, too.
Is there a point release coming which will include this fix?
