OpenVPN with laptop clients failing after pfSense Upgrade to 2.5.0
-
We upgraded the pfSense router from 2.4.5-p3 to 2.5.0.
No remote clients (Windows laptops, Linux laptops or data site VPNs on Linux via 4-G connections are able to connect after the upgrade.
Prior to the upgrade the pfSense OpenVPN system had been working without any failures or issues for three years.
The configurations are relatively standard with both Server and Client Certificates plus Client and TLS server keys.
I have tried several changes on the pfSense OVPN Server (ncp, etc) but without success. I just cannot get it to work.
The issue for us is that we have remote sites that involve long travel times if we have to modify the Client configurations. They are on 4-G Internet connections and we can't connect to the sites remotely without the VPN running because of carrier-grade NAT.
I'd therefore be very appreciative if we can find a solution to restore operation by making changes on only the server.
Here are the configuration files:
- pfSense OpenVPN Server (as upgraded to 2.5.0-RELEASE)
- an OpenVPN Client (Windows 10)
pfSense Server
General Information
Server mode Peer-to-Peer (SSL/TLS)
Protocol UDP on IPv4 only
Device mode tun
Interface WAN
Local port 1194
Description Data VPN Server – CCCryptographic Settings
TLS Configuration Use a TLS Key
TLS Key # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- … … -----END OpenVPN Static key V1-----
TLS Key Usage Mode TLS Authentication
TLS keydir direction Use default direction
Peer Certificate Authority CCDataCA
Peer Certificate Revocation list CCDataCRL(Server: Yes, CA: CCDataCA, In Use)
DH Parameter Length 2048 bit
ECDH Curve Use default
Data Encryption Negotiation Enable Data Encryption Negotiation
Data Encryption Algorithms AES-128-CBC AES-256-CBC
Fallback Data Encryption Algorithm AES-256-CBC
Auth digest algorithm SHA256
Hardware Crypto No Hardware Crypto Acceleration
Certificate Depth One (Client+Server)Tunnel Settings
IPv4 Tunnel Network 172.31.55.0/24
IPv6 Tunnel Network
Redirect IPv4 Gateway
Redirect IPv6 Gateway
IPv4 Local network(s) 172.31.54.0/24
IPv6 Local network(s) 10.8.2.0/24, 10.8.3.0/24
IPv6 Remote network(s)
Concurrent connections 20
Allow Compression Decompress incoming, do not compress outgoing (Asymmetric)
Compression Disable Compression [Omit Preference]
Push Compression Yes
Type-of-Service
Inter-client communication
Duplicate ConnectionClient Settings
Dynamic IP Yes
Topology SubnetPing settings
Inactive 0
Ping method keepalive
Interval 10
Timeout 60Advanced Configuration
Custom options
UDP Fast I/O
Exit Notify Disabled
Send/Receive Buffer Default
Gateway creation IPv4 only
Verbosity level 3
Windows 10 Client
##############################################Client-side OpenVPN 2.0 config file for
for connecting to the multi-client server
Last Edit:
25 Oct 2019 at 08:34 Eric
##############################################
client
connect-retry 2
dev tun
remote 203.86.xxx.yyy 1194
proto udp
resolv-retry infinite
nobind
Persist-tun
persist-key
ca CCDataCA.crt
cert FredDataUser.crt
key FredDataUser.key
cipher AES-256-CBC
auth SHA256
remote-cert-tls server
tls-auth server1.tls-auth 1
auth-user-pass
ns-cert-type server
auth-nocache
verb 5 -
Same here
Don't know why
-
I suspect you want Remote Access, not Peer to Peer for the server mode, though that's not the cause of the problem. I have found OpenVPN will connect when on the LAN side of pfsense, but not the WAN side. I have absolutely no idea why that is, as I have selected WAN as the interface to use. V2.5.1 will be available soon, so that might help. I'm also waiting for the 2.5 client for OpenSUSE Linux, to see if that helps. Regardless, considering all the complaints, OpenVPN 2.5.0 is clearly not ready for prime time.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
Please post the server log and client log from a single connection attempt to see what is happening there.
I didn't go over each line in the configs but nothing obvious stood out.
I don't know that it would affect OpenVPN but one user has reported a problem in IPsec where AES-NI is affecting SHA256 specifically but not other hashes. So if you have AES-NI, you can try just for one client to change from SHA256 to another hash that would also be a good test. That or disable the AES-NI module if you have it loaded.
@JKnott Please start your own thread to discuss your issue and include the server and client configs + connection logs from both sides. You've popped up in a couple different threads and none of them exactly match your symptoms and we need to treat each problem separately until we're 100% certain they are the same.
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!
-
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?
