Tls error tls handshake failed как исправить

I am configuring OpenVPN 2.3.6-1 on my Arch Linux server in order to encrypt SMB traffic over the public Internet. When I test the setup on one of my Linux virtual machine clients, I get the error: TLS Error: TLS handshake failed.

I quickly read (OpenVPN on OpenVZ TLS Error: TLS handshake failed (google suggested solutions not helping)) and tried to switch from the default UDP to TCP, but that only caused the client to repeatedly report that the connection timed out. I also tried disabling the cipher and TLS authentication, but that caused the server to fail with Assertion failed at crypto_openssl.c:523. In both instances, the required changes were made to both the client and server configurations.

I have been following the instructions at (https://wiki.archlinux.org/index.php/OpenVPN) to set up OpenVPN and the instructions at (https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts) to create the keys and certificates. The only deviations I have made from these instructions have been specifying my own computers’ names and their corresponding key/certificate file names.

See also my original question about securing SMB traffic over the Internet: (Simple encryption for Samba shares)

Can anybody explain how I can solve this issue?

Details:

Server: Arch Linux (up to date) connected directly to gateway via ethernet cable. No iptables.

Client: Arch Linux (up to date) virtual machine on VirtualBox 4.3.28r100309 Windows 8.1 host, bridged network adapter. No iptables. Windows Firewall disabled.

Gateway: Port forwarding for port 1194 enabled, no firewall restrictions.

Here are the configuration files on the server and client, respectively. I created these according to the instructions on the Arch Wiki.

/etc/openvpn/server.conf (Non-comment lines only):

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server-name.crt
key /etc/openvpn/server-name.key
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

/etc/openvpn/client.conf (Non-comment lines only):

client
dev tun
proto udp
remote [my public IP here] 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client-name.crt
key /etc/openvpn/client-name.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3

Here are the outputs of running openvpn on the machines with the above configurations. I started the server first, then the client.

The output of openvpn /etc/openvpn/server.conf on the server:

Thu Jul 30 17:02:53 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 17:02:53 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 17:02:53 2015 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 30 17:02:53 2015 Diffie-Hellman initialized with 2048 bit key
Thu Jul 30 17:02:53 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 17:02:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 17:02:53 2015 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=##:##:##:##:##:##
Thu Jul 30 17:02:53 2015 TUN/TAP device tun0 opened
Thu Jul 30 17:02:53 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 17:02:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 17:02:53 2015 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Jul 30 17:02:53 2015 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Thu Jul 30 17:02:53 2015 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2
Thu Jul 30 17:02:53 2015 GID set to nobody
Thu Jul 30 17:02:53 2015 UID set to nobody
Thu Jul 30 17:02:53 2015 UDPv4 link local (bound): [undef]
Thu Jul 30 17:02:53 2015 UDPv4 link remote: [undef]
Thu Jul 30 17:02:53 2015 MULTI: multi_init called, r=256 v=256
Thu Jul 30 17:02:53 2015 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Thu Jul 30 17:02:53 2015 IFCONFIG POOL LIST
Thu Jul 30 17:02:53 2015 Initialization Sequence Completed

The output of openvpn /etc/openvpn/client.conf on the client:

Thu Jul 30 21:03:02 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 21:03:02 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/client-name.key' is group or others accessible
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
Thu Jul 30 21:03:02 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 21:03:02 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 21:03:02 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Jul 30 21:03:02 2015 UDPv4 link local: [undef]
Thu Jul 30 21:03:02 2015 UDPv4 link remote: [AF_INET][my public IP here]:1194
Thu Jul 30 21:04:02 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 30 21:04:02 2015 TLS Error: TLS handshake failed
Thu Jul 30 21:04:02 2015 SIGUSR1[soft,tls-error] received, process restarting
Thu Jul 30 21:04:02 2015 Restart pause, 2 second(s)

Purpose of this troubleshooting page

This page is specifically about attempting to find and resolve problems with an OpenVPN client program failing to connect to an OpenVPN Access Server. It does not deal with problems in reaching a target system over the established VPN tunnel once the VPN tunnel is already working. That is handled in a separate page: troubleshooting reaching systems over the VPN tunnel.

So if for example you start the OpenVPN client connection and it issues an error and disconnects you, then the information here should help you in determining a possible cause and solution. If not, reach out to us on the support ticket system and provide as much detail as you can.

Locating the server log files

To diagnose problems with an OpenVPN server or client, it is helpful to look at the log files. The log files are located in specific areas on your computer systems, and the following is a general guide on how to find them and how to get the best information out of them. Log files are the place to check whenever you’re having any problems making a connection with an OpenVPN client program to the OpenVPN Access Server, they the information needed to ascertain what’s going wrong.

On the OpenVPN Access Server there is the server side log:
/var/log/openvpnas.log /var/log/openvpnas.node.log (in case of a failover setup)

In the event that you are having problems with starting the Access Server or certain portions of it, for example the web services, then it may be useful to stop the Access Server service, move the log file aside, then start the Access Server service, and stop it again immediately. This creates a new clean log file that contains the startup and shutdown sequence of the Access Server and no other extraneous information. This makes analysis of the log file much easier. To do so use these commands in order:

service openvpnas stop
mv /var/log/openvpnas.log /var/log/openvpnas.log.old
service openvpnas start
service openvpnas stop

You can then grab the /var/log/openvpnas.log file for analysis and start the Access Server again:

service openvpnas start

Locating the client log files

Log file location for the OpenVPN Connect Client for Windows:
C:Program Files (x86)OpenVPN TechnologiesOpenVPN Clientetclogopenvpn_(unique_name).log

The OpenVPN Connect Client for Mac:
/Library/Application Support/OpenVPN/log/openvpn_(unique_name).log

Macintosh may not show you this folder in finder as it only shows you certain things and hides others. So to get to the /Library folder, open Finder and in the menu at the top choose Go followed by Go to folder and then enter the path /Library to get into that directory. You can then go to the correct folder and look up the log file. Please also note that the OpenVPN Connect Client for Macintosh will have permissions set on the log file so that you cannot normally open it. To bypass this, right click the log file and choose the Get info option in the menu. Then at the bottom, under Sharing & Permissions, you will be able to use the yellow padlock icon to unlock the settings and to give everyone read access. Then you will be able to open the log file with a right click and selecting Open with and then choosing something like Text editor to view the contents of the log file.

Known error messages and possible solutions

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

This particular error can have multiple different causes as it is a fairly generic error message.
A possible explanation is that the client program is old and supports only TLS 1.0, but the server is expecting TLS level 1.1 or higher. To see if this is the case log on to the server and check the server side log file. The chances are high that your client program is an older version, like version 2.2 or older, and that it doesn’t know how to handle a modern TLS minimum level requirement, when you see messages that look like this on the server side:

OpenSSL: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol'
TLS_ERROR: BIO read tls_read_plaintext error'
TLS Error: TLS object -> incoming plaintext read error'
TLS Error: TLS handshake failed'
SIGUSR1[soft,tls-error] received, client-instance restarting'

The solution to this particular problem is to upgrade the client software to the latest version.
Another possible explanation is that the settings regarding TLS minimum requirement level have been altered but the OpenVPN client is using an older copy of the connection profile which has incorrect instructions. The settings on the client and the server must match for the connection to be successful. In this situation installing a new copy of the configuration profile will solve the issue. A complete uninstall, redownload, and reinstall of the OpenVPN Connect Client should take care of that for you.

And yet another possible explanation is that there is a blockade in place in a firewall or at the Internet service provider that is blocking or interfering with the TLS handshake in some way.

TLS Error: local/remote TLS keys are out of sync

For some reason the negotiated TLS key to be used on the client side for TLS encryption/decryption is different from the one used on the server side. That should never happen. When the client and server are talking to one another they agree upon a TLS key to be used for encrypting and decrypting traffic. By default in Access Server such a key is valid for 6 hours, and after those 6 hours, automatically the TLS refresh kicks in and they will agree upon a new key. There is a short overlap where both the old and new key are accepted, until the old key is expired and the new key must be used. If for some reason one side doesn’t do this, you see this error message.

A possible cause is a bug in the OpenVPN protocol with the version used in OpenVPN Connect Client which was resolved, where the automatic TLS key refresh would fail because the client and server couldn’t agree properly on the encryption cipher to use. So if you encounter this particular problem and you are using an OpenVPN3 based client like OpenVPN Connect Client 2.*, then consider updating to the latest version. You can do so for example per computer by downloading OpenVPN Connect Client for Windows or OpenVPN Connect Client for macOS from our website, and installing it. However a better solution would be to update your Access Server to the latest version so that you get the updated Connect Client embedded in there, and then downloading and installing the latest version of OpenVPN Connect Client from your Access Server. If you use other client software and it shows problems, try finding a newer version for it. Worst case scenario, you could also consider changing the TLS key refresh to something larger in the Advanced VPN page of the Admin UI, to avoid triggering the issue. This does of course lower security somewhat.

Server poll timeout

One of the very first steps that an OpenVPN client program will do when trying to connect to an OpenVPN Access Server is to simply send out a message requesting for a reply. So basically a “hello are you there?” message. The server is then supposed to respond and then a connection is started. However if you see a server poll timeout error message then the server could not be reached at the specified port. Why this is not possible is another question entirely, but the error message is very clear: there is simply no response at all on that address and port. So when you see this message it would be good to check if the port is actually open, if the port is correct, if the address you’re trying to reach can actually be reached from the Internet, and isn’t a private IP address only, and other such checks to confirm basic connectivity to the server. At this point you’re not even looking at a problem that has anything to do with the OpenVPN protocol itself. This is a most basic “this server cannot be reached” message.

A common mistake that is made is that people set up the Access Server on a private IP address but neglect to set up a proper FQDN DNS name for it, and configure that FQDN DNS name in the Admin UI under Server Network Settings in the Host name or IP address field. It is that field value that connection profiles generated and provisioned to the OpenVPN clients will be using to start a connection to. So if this is set to an internal private IP address that the Access Server was installed on, then the connection profiles will try to connect to that private IP address, which is unlikely to be reachable from anywhere else but the internal network that the Access Server itself is on. The solution is to set up a proper DNS name and configure that and save settings. Then uninstall, redownload, and reinstall the connection profile or OpenVPN Connect Client program and to try again.

Another common mistake is to forget to open the 3 ports required for OpenVPN Access Server to be reachable properly. By default these are TCP 443, TCP 943, and UDP 1194.

SESSION_ID only allowed to be used by client IP address that created it

OpenVPN Access Server uses a session-based-token system for server-locked and user-locked profiles. Auto-login type profiles don’t. What this means is that after a user authenticates successfully, they are given a session token to identify themselves with. Compare it to going to a party and you show up and pay your entry fees, and if you need to go out for a little bit, they give you a stamp on the back of your hand, or put a paper/plastic strip around your wrist, so that you can show up again later and be admitted access again. That’s a very simplified explanation. With a session token, each token is unique and uniquely identifies you. This avoids having to store your credentials in memory or bothering the user to reauthenticate when you temporarily lose contact with the server and reconnect again, so it’s safer and more convenient. The session token is locked to the IP address that the original authentication attempt was made from, this is a security feature. When you see this message it means the session token your client program offered to the server was generated originally from another IP address. This can happen for example if you switch Internet connection, like logging in at work, then moving your laptop home and it tries to reconnect automatically with the session token. This session token IP lock is a security feature that can be disabled to allow such automatic reconnects to occur without this error message.

Authentication Error: Session: your session has expired, please reauthenticate

The OpenVPN Access Server works with a session token based authentication system when you are using a server-locked or user-locked profile. When you authenticate successfully, you are given a session token instead. The session token identifies you now from that moment onward. By default the session token expires after 5 minutes of inactivity as in not being connected to the server, and it also expires after 24 hours by default. Furthermore, when the session token is generated on the server, it gets locked to the VPN client’s connecting IP address. This session IP lock can be disabled, and the timeout for session inactivity and the timeout for total session duration mentioned can also be adjusted. If for example you are on your phone and you are connected through WiFi, and you walk out of range of WiFi, and it switches to another Internet connection like 3G/4G or something, then your VPN client will disconnect but attempt to reconnect automatically. Your IP will now be different and as such the session token is not valid anymore. You will see an error like in the previous section in the server side log file (SESSION_ID only allowed to be used by client IP address that created it). And if your connection has lasted 24 hours in total, then it will also disconnect you if you’re on a session-based connection with server-locked or user-locked profile. The solution is to either use an auto-login type profile or to increase the session token duration.

unable to obtain session ID from vpn.yourserver.com, ports=443: (error description here)

This error message can be found in the capi.log file and also shown in the popup message in Windows or macOS when you use OpenVPN Connect Client for Windows or macOS. This error message indicates that a server-locked connection profile is being used, which is the default on OpenVPN Access Server when you download and install the OpenVPN Connect Client. A server-locked connection profile is designed to be user-agnostic, meaning it doesn’t carry any user-identifiable information in it, and is a sort of universal profile. This allows any valid user accounts to start a connection with this OpenVPN Connect Client. The credentials are passed over a secure HTTPS channel to the XML-RPC services of the Access Server for verification, and if approved, the client will receive a copy of the user-locked profile for this user, and a session token. Those will be used to start the OpenVPN tunnel. After the tunnel is disconnected, the user-locked profile and session token are deleted. But for this to work, there must be a working HTTPS connection to the web services of the Access Server.

unable to obtain session ID from vpn.yourserver.com, ports=443:
Other SSL errors:[(‘SSLroutines’,’SSL23_READ’,’ssl handshake failure’)]

This could indicate that the Connect Client was able to reach some service, but it does not appear to be the Access Server web services, or perhaps the traffic is mangled by some firewall or proxy solution. For example we have seen situations where OpenVPN Access Server was installed with default settings, and OpenVPN Connect Client was installed and working, and then the port was changed on the server side from TCP 443, to TCP 444 for example, and then a web server was setup on that same server system, with an HTTPS website running on it on port TCP 443. The OpenVPN Connect Client won’t have received an update to the new port setting for the Access Server web services, and so it tries to talk to the old port, where now a web server runs. This causes an unexpected problem that can result in this type of error. If you encounter this problem you should investigate if the port that the client is trying to reach is actually reachable by this client, and to try to determine if there really is an Access Server web service running there. If you changed the ports on the server you need to reinstall this client so it updates the settings.

unable to obtain session ID from vpn.yourserver.com, ports=443:
ConnectionRefusedError: 10061: No connection could be made because the target machine actively refused it

This is a very clear indication that the address and port that the OpenVPN Connect Client is trying to reach, does not have an Access Server web service running there. For example if you install OpenVPN Connect Client on a client computer, and then you go to the Access Server and change the ports that it listens to, then the client will still be trying to connect to the old ports that were originally configured. This can also sometimes occur if the address of your server is simply misconfigured. The solution is making sure that in the Admin UI in the Network Settings page you have set the address that your server can be reached at correctly (it is best to do a DNS name instead of an IP) and that the ports are how you want them, and then after that’s set up, to download and install the OpenVPN Connect Client on your client computers.

unable to obtain session ID from vpn.yourserver.com, ports=443:
XML-RPC: TimeoutError

This indicates that the Access Server web interface’s XML-RPC interface is unreachable. The OpenVPN Connect Client uses this interface to obtain the necessary certificates and configuration to start the OpenVPN connection when you are using a server-locked profile. You will not be needing the XML-RPC interface when you use user-locked and auto-login profiles. The advantage of server-locked profiles is that they are universal – any valid user at the Access Server can log in and connect. The timeout error just means the connection timed out, usually a firewall or such is blocking the connection. The solution is to ensure that the web interface is reachable from this OpenVPN client, or instead use a user-locked or auto-login type profile.

unable to obtain session ID from vpn.yourserver.com, ports=443:
XML-RPC function GetSession with 1 arguments may not be called at the configured relay level

The OpenVPN Connect Client program for Windows and macOS by default uses server-locked profiles. These contain only the information necessary to talk to the XML-RPC web interface of the Access Server for the purpose of authenticating a user and obtaining the required certificates and connection information to start the OpenVPN tunnel. This is done so this client is universal. It will work for all valid users on the server and isn’t locked to a specific user. This does require that the web interface is reachable and that under client settings in the Admin UI the XML-RPC function is set to at least limited functionality. Full functionality also works, but when you set this to disabled, then you will get this error. The solution is to either stop using server-locked profiles and switch to user-locked or auto-login profiles, or to enable at least limited functionality for XML-RPC calls. The default is limited functionality and that is sufficient for OpenVPN Connect Client and server-locked profiles.

See the logfile ‘C:Program Files (x86)OpenVPN TechnologiesOpenVPN Clientcoreovpntray.exe.log’ for details

If you see this error message while launching the OpenVPN Connect Client, and it fails to launch, you may be missing specific Microsoft Visual C++ Redistributable DLL library files. This issue was resolved in OpenVPN Connect Client for Windows version 2.5.0.136 by adding specific required library files into the OpenVPN Connect Client program directories. You should ensure you use up-to-date software to resolve this issue. You can upgrade your Access Server to the latest version so that it offers updated OpenVPN Connect Client software, or you can separately download the OpenVPN Connect Client for Windows from our website, to upgrade your existing Connect Client version.

Serial number not found in DB

OpenVPN Access Server by default comes with an internal PKI structure, which means a self-signed root certificate with unique certificates generated for each OpenVPN client for that server. These are all unique and tied together. This is part of the strength of OpenVPN, the identity of a VPN client and a VPN server are verified in both directions when a connection is made. The client verifies the server, and the server verifies the client. So for each user account you add to the Access Server, a unique certificate is generated. The certificate is bound to the user account name, so you can’t log in with the credentials for user bob with the certificates for user billy. Each certificate also has a serial number, a unique number identifying the certificate. If you see the error that the serial number is not found in the database, that means this certificate is not known to this server. Even if you revoke a certificate, it is still known to the server, and will not produce this particular error. So you may be using a certificate from a completely different Access Server by mistake, or maybe you started with a new setup of Access Server on your server and the certificates are wiped and new ones generated for the new setup, while you’re still using old certificates from the previous installation. To resolve this problem, make sure to delete the wrong connection profile from your client computer and obtain a new one from your current Access Server installation and use that to connect.

Open TAP device “” PATH=”” FAILED TUN Error: cannot acquire TAP handle EVENT: TUN_IFACE_CREATE cannot acquire TAP handle [FATAL-ERR] 2021 EVENT: DISCONNECTED Client exception in transport_recv: tun_exception: not connected

You may receive this error message when the OpenVPN Connect 3.x service stops or does not resume when you sign back into the computer. The issue is likely caused by an antivirus program. Specifically, we’ve seen this with ESET Antivirus. You can reconnect by restarting the service manually, but the automatic connection may still encounter the issue. To test, turn off ESET. If that resolves the issue, then you may want to open a support ticket with ESET.

See also the topic authentication problems for more possible error messages and solutions regarding authentication issues.

If you are facing “OpenVPN TLS handshake failed” Error on computer while attempting to setting up “OpenVPN”, then you are in right place. Here, we are discussing about this problem in details and providing some recommended methods/procedures to fix this error. Let’s take have a look at error message and then starts the discussion.

“Sun May 13 19:39:51 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Sun May 13 19:39:51 2018 TLS Error: TLS handshake failed”

About OpenVPN

“OpenVPN” is open-source commercial software that implements virtual private network techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access faculties. It is available in free for charge. With the digital privacy and online security continuing to be major concerns, more people are interested in “VPNs (Virtual Private Networks)” than ever before.

Pros:

• Free, open-source VPN
• Booted Privacy and Secure browsing
• Supported by developer community

Cons:

• Can lead to poor speeds when is use
• Too technical and complex for first use-timers
• Can be blocked by business proxies

However, it is important to remember that “OpenVPN” is not VPN Provide and it doesn’t add a piece of software to your desktop or simple plug-in to your browser that you click once to connect. “OpenVPN” is encryption protocol that can connect your VPN which means you will need to know exactly how to configure it to your specific server.

What is “OpenVPN TLS handshake failed” Error?

It is common TLS error that is appears while trying to connect to OpenVPN. This error message usually appears on Android, iOS, Windows, Mac and Linux OS based device. “HandShake” word refers to negotiation between two ends just like meeting between two different people for any propose, then shake hands at first, then go ahead with anything else. In this case, “handShake” refers to negotiations between two servers.

On other hand, “TLS (Transport Layer Security)” is used every time when you access a website or application over HTTPS, access emails, messages, and VOIP (Voice over Internet Protocol). In simple word, we can say that HTTPs is implementation of TLS encryption.

Now comes to matter “OpenVPN TLS handshake Failed” Error, it is one of the most common problems in setting up OpenVPN that is occurs due to several reasons. Some user reported that this error appears usually on Windows/Mac/iOS/Linux/Android OS based devices when Windows Firewall is blocking access for the “openvpn.exe”.

“TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)”

Reasons behind OpenVPN TLS handshake failed issues

• Incorrect Client Configuration: The “OpenVPN” client config does not have the correct server address in its config file. The remote directive in the client config must point to either the server itself or the public IP address of the server network’s gateway.
• OpenVPN packets: A perimeter Firewall on server’s network is filtering out incoming OpenVPN packets. By Default OpenVPN uses UDP or TCP port number 1194.
• NAT/PAT: A NAT Gateway on the server’s network does not have a port forward rule for TCP/UDP 1194 to internal address of OpenVPN server machine.
• Firewall/routing blocking port: Windows Firewall is blocking access for the “openvpn.exe” binary.
• OSes block incoming connections: A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default unless configured otherwise.

[Tips & Tricks] How to Fix OpenVPN TLS handshake failed error on Windows 10?

Procedure 1: Change “TLS” protocol in Windows

Windows 10 and earlier versions of Windows centralize the protocol settings in the System. To fix “OpenVPN TLS handshake failed” Error, you can change TLS version via the steps below:

Step 1: Press “Windows + R” key from keyboard to open “Run Dialog Box”

Step 2: In the opened “Run Dialog Box”, type “inetcpl.cpl” and hit “Ok” button

Step 3: In the opened “Internet Properties” window, click on “Advanced” tab

Step 4: Find “Security” section and here, you can add or remove TLS

Step 5: If the website is looking for TLS 1.2 and it is not checked, you need to check it. Similarly, if someone is experimenting with TLS 1.3, you need to check it

Step 6: Finally, click on “Apply” and “Ok” to save the changes. Once done, try opening the same website again

Procedure 2: Change TLS protocol in Firefox

Step 1: Open “Firefox” browser and type “about:config” in address bar and then hit “Enter” key

Step 2: Now, type “TLS” in search box and locate “security.tls.version.min”

Step 3: You can change it to “1 and 2 to force TLS 1 and 1.1”, “3 to force TLS 1.2”, “4 to force maximum protocol of TLS 1.3”

Procedure 3: Delete Browser profile or certificate database

Every browser maintains a database for certificates. For example, every Firefox profile has Cert8.db file. In case if delete that file, and restart fixes it, then the problem is related to the local certificate database.

In Windows 10 or other Windows OS based device, when you are using Internet Explorer or Edge browser, the Certificate Manager is responsible, or you can go to the edge://settings/privacy and click on Manage HTTPS/SSL certificates and settings. Delete the certificates and try again.

Procedure 4: Reset web browser

To reset Google Chrome settings, follow the steps below:

Step 1: Open Google Chrome browser and type “Chrome://Settings” in address bar and then hit “Enter” key

Step 2: Scroll towards end and click on “Advance settings”

Step 3: You will see the “Reset Browser Settings” button

Step 4: When you use this option, it will reset your profile to the post-fresh-install state

Step 5: This process will reset search engine, homepage, new tab page and pinned tabs to default. Extensions, add-ons and themes will be disabled and Content Settings will be reset. Cookies, Cache and Site data will be deleted.

Step 6: Once done, restart your browser and please check if “OpenVPN TLS handshake failed” Error is resolved.

To reset Microsoft Edge Chromium browser, follow the steps below:

 Step 1: Open Microsoft Edge browser

Step 2: Click on Open Settings

Step 3: Navigate to “Reset Settings”

Step 4: Click on “Restore Settings” to their default values.

Step 5: This process will reset your Startup page, new tab page, search engine and pinned tabs, disable all extensions and clear temporary data like cookies, and favourites, history and saved passwords will not be cleared.

Step 6: Once done, restart your browser and please check if the error is resolved.

To reset Firefox settings, follow the steps below:

Step 1: Open “Firefox browser”

Step 2: Go to “Settings > Help > Troubleshooting information”

Step 3: Click on “Reset Firefox” button.

Step 4: This process will reset search engine and homepage to default. Your extensions, sync settings, open tabs, tab groups, themes and toolbars will be removed. However, your passwords, from data, browsing history, favourites or bookmarks, cookies and plug-ins will not be removed. They will instead be moved to new profile.

Procedure 5: Ensuring the correct System time

Step 1: Press “Windows + I” keys together from keyboard to open “Settings App”

Step 2: In the “Settings App”, select “Time & Language”

Step 3: Go to the right pane, then toggle the switch under “Set Time Automatically” to “ON”

Step 4: After that, restart your computer and try visiting the website again to see if TLS handshake error is gone.

You may also read: Fix Cisco AnyConnect Certificate Validation Failure Problem

Conclusion

I am sure this article helped you to “Fix OpenVPN TLS handshake failed on Windows 10” with several easy methods/procedures. You can choose/follow either one or all procedures to fix this issue.

If you are unable to fix OpenVPN TLS handshake failed problem with the solutions mentioned above, then it might possible that your System has infected with malware or viruses. According to security researchers, malware or viruses cause several damages in your computer.

In this case, you can scan your computer with powerful antivirus software that has the ability to delete all types of malware or viruses from System.

You can also try another possible solution to fix this issue. We recommended you to Repair your PCs/laptops with powerful PC Repair Tools/Software that has the ability to remove all the faculty software, clean System registry, remove all types of malware or viruses, fix all types of bugs or errors and improves System performance as well. You can download powerful PC Repair Tool/Software via “Download” link below.

If you’ve encountered an error messaging saying “TSL Handshake Failed,” and you’re confused about what to do, you’re not alone. TLS handshake failed is a common error. While it can be a frustrating experience, there are ways to troubleshoot TLS handshake issues and solve them.

In this post, you’ll learn what the TLS Handshake Failed error is and why it occurs. Then you’ll learn how to troubleshoot TLS handshake issues. 

Let’s get started!

Understanding TLS/SSL

You need to make your website secure so as to establish secure connections between two servers. To do this, you’ll need to install a Secure Sockets Layer (SSL) certificate – SSL encryption and security protocol – on your site. This will enable your site to use HTTPS to ensure secure connections. 

Unfortunately, sometimes things don’t go as planned, and you may encounter a problem when making a connection between your site’s server and a visitor’s browser. The problem can occur as a ‘TLS Handshake Failed’ error or any other issue. 

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are security protocols that provide website encryption and identification. They are used to authenticate data transfers between servers, applications, systems such as browsers, and users.

Simply put, you need TLS/SSL certificates to secure your website using HTTPS. 

Understanding TLS/SSL handshake 

A TLS handshake is a form of communication and agreement between two servers – your sites’ host and the client’s server. It is the first step in the process of establishing a clear HTTPS connection. 

To authenticate and establish a connection, your site’s server and the client’s browser must shake hands, i.e., go through a series of checks (the handshake). This establishes the HTTPS connection parameters. 

What does this mean?

The client (usually a browser) typically sends a request to establish a secure connection to the site’s server. The server then sends a public key (protocol) to your device and ensures to check that key against a pre-prepared list of protocols/certificates. The device then generates a key and uses the server’s key to encrypt it. 

If this back and forth communication doesn’t yield a positive result, i.e., if the SSL handshake fails between the server and the client, HTTPS won’t generate a secure connection, which will result in a TLS/SSL handshake failure. This error can show in two forms; 

• HTTP/1.1 503 Service Unavailable
• Received fatal alert: handshake_failure (Error 525)

Note: You’ll see these error messages following an API call where a TLS handshake failure occurs.

What causes TLS handshake issues 

Generally, Error 525 or Error 503 usually means that there’s been a failed TLS handshake. Some of the causes of the failure can include;

On the server-side, the error causes include;

• Protocol mismatch: The server doesn’t support the protocol that the client used.
• Incorrect certificate: The hostname of the client’s URL does not match the hostname in the certificate stored at the server end, or the certificate is incomplete or invalid, or the certificate is incorrect or expired 
• Cipher suite mismatch: The server does not support the cipher suite that the client used.
• SNI enabled server: when the back end SNI (Server Name Identification) is enabled, but the client-server cannot communicate with the SNI servers.

On the client’s side, the causes can include;

• If the connection is being intercepted by a third party.
• If the client’s device has a wrong date or time.
• If the client is experiencing an error with the browser configuration.

How to troubleshoot TLS handshake issues

There are several potential causes of the “TLS Handshake issues.” You can use the following solutions to troubleshoot these issues;

Method #1: Update your system’s date and time

A wrong date or time setting is one of the key causes of TLS handshake issues. Because the system time helps to test whether the certificate is valid or expired, a mismatch between your device’s time or date and that of the server can make the certificates look expired.  

Fix the time and date by setting it to automatic, then visit the site again and see if the TLS handshake issue has been fixed. 

Method #2: Fix your Browser’s configuration to match the Latest TLS Protocol Support

Your browser is the ‘man in the middle’, and it can affect how your device communicates with the server. Any browser misconfiguration can cause TLS issues.

To check if your browser is the problem, try to use another browser to access the site and see if you are encountering the same problem. If the problem is occurring in all sites, then it’s a system problem. 

Perhaps there is a browser extension or security software on your device that is intercepting the TLS connections and causing the problematic TLS handshake. In a number of cases, a virus or malware on the system was involved.

To fix this issue:

1. You may need to disable the security software or browser extensions on your device, or, 
2. Reset your browser.

Method #3: Check and Change TLS Protocols [in Windows]

Browser related problems can also be caused by protocol mismatch. 

For instance, if the browser is only configured for a specific TLS value, e.g., TLS 1.0 or TLS 1.1, but the server only supports TLS 1.2, then there’s the communication between the two will lack a mutually-supported protocol. This inevitably leads to a TLS handshake failure. 

To check this issue in your browser (Google Chrome): 

1. Open Chrome browser 
2. Go to Settings > Advanced 
3. Scroll down open Systems > Open your computer’s proxy settings
   
   
4. On the new popup Windows select the Advanced tab. 
5. In the advanced tab, under the Security section, see if the box next to Use TLS 1.2 is selected > check it if its not checked.
   
   
6. See if the boxes for SSL 2.0 and SSL 3.0 are checked > then uncheck them if so. Do the same for TLS 1.0 and TLS 1.1.
7. Click OK, then check to see if this process has resolved the handshake error.

Note: if you’re using Mac Os or Apple Safari, they don’t provide an option to disable or enable TLS/SSL protocols because TLS 1.2 is, by default, automatically enabled.

Method #4: Verify Your Server Configuration [to Support SNI]

Server name indication (SNI) configuration is one of the key causes of TLS issues. For the server to function properly, the SNI enables it to securely host several TLS certificates/protocols for one IP address.

On a server, each website has its own certificate. So, if the server isn’t SNI-enabled, there is a high likelihood of a TLS handshake failure because the server may fail to recognize the present certificate.

To check and see whether the site requires SNI, you can use the Qualys’ SSL Server Test. you’ll only need to input your site’s domain name, then click Submit and wait for the test to generate results.

On the results page, locate the message that reads “This site works only in browsers with SNI support”:

Method #5: Check and ensure that Cipher Suites Match

A Cipher Suites mismatch is also a key cause of TLS handshake issues, especially TLS handshake failure. Cipher suites are just a set of algorithms, including those for bulk encryption, key exchange, and message authentication code, which are used to secure TLS/SSL network connections.

If the server’s cipher suites don’t match with or support those of Cloudflare, there is a higher likelihood of a “TLD Handshake Failed” error.

To check the Cipher Suites configuration, you’ll again use the Qualys’ TLS Server Test. Again, just input your domain, then click Submit and wait for the report. 

On the results page, check under the Cipher Suites section to locate the Cipher information.

Be keen on the status such as those written ‘Weak.’ You can then correct them by comparing them with your browser support. 

Finally

We believe these tips have been easy to follow and that you were able to resolve the TLS handshake issue you encountered. TLS is an extremely vast topic, and there may be other solutions available. 

If you found this useful, you might like our email list. We share many new tips, tricks, troubleshooting, how-to guides, product comparisons, and many more help-centered articles every day. Short, elaborate, sweet, and practical!

Also, Read

> Fixed: potential Windows update database error detected
> What is Windows Service Host SuperFetch, and how do you fix it
> Fixed: Google Chrome is waiting for cache issue on Windows 10
> Solved: Ethernet Doesn’t Have A Valid IP Configuration in Windows 10

Как устранить проблемы с рукопожатием TLS?

Интернет сделал для нас удобным находить любую необходимую информацию. Вы можете посещать веб-сайты напрямую или использовать поисковую систему, например Google, для доступа к различным типам данных. Однако бывают случаи, когда мы не можем открывать веб-страницы, и этому может быть несколько причин. В некоторых случаях это может быть связано с вашим сетевым подключением. С другой стороны, еще одна распространенная проблема, которая вызывает эту проблему, — это сбой установления связи TLS.

Теперь вы можете спросить: «Что означает рукопожатие TLS?» TLS означает Transport Layer Security, протокол шифрования. Связь по этому протоколу остается конфиденциальной и безопасной. В этом посте мы собираемся объяснить, что происходит при рукопожатии TLS. Таким образом, вы лучше поймете концепцию. Более того, мы научим вас, как исправить ошибку сбоя установления связи TLS.

Что означает рукопожатие TLS?

Как мы все знаем, когда есть форма переговоров или приветствия между двумя людьми, мы скрепляем это рукопожатием. Точно так же, когда два сервера обмениваются данными и подтверждают друг друга, они формируют рукопожатие TLS. Во время этого процесса серверы проходят проверку. Они устанавливают шифрование при обмене ключами. После подтверждения подлинности всех деталей начнется обмен данными. Вот четыре этапа рукопожатия TLS:

1. Указывает версию TLS, которая будет использоваться для связи.
2. Выбор алгоритма шифрования для связи.
3. Открытый ключ и цифровая подпись эмитента сертификата SSL будут использоваться для проверки подлинности.
4. Будут созданы сеансовые ключи, которые затем будут обмениваться между двумя серверами.

Чтобы упростить задачу, обе стороны сначала скажут «привет». Затем сервер предоставит сертификат, который клиент проверит. После того, как будет подтверждена подлинность сертификата, начнется сеанс. Перед этим будет создан ключ, который позволит обмениваться данными между серверами.

Как исправить проблемы с рукопожатием TLS

К сожалению, если проблема связана с сервером, вы ничего не можете сделать. Например, если сертификат с сервера не может быть аутентифицирован, тогда это уже не в ваших руках. Однако, если у вас возникли проблемы с браузером, который вы используете, вы все равно можете попробовать множество обходных путей. Кроме того, если вы имеете дело с несоответствием в протоколе TLS, вы можете исправить проблему в браузере.

Сбой рукопожатия TLS может быть по разным причинам. Прежде чем пытаться решить проблему, убедитесь, что вы действительно имеете дело с ошибкой рукопожатия TLS. В большинстве случаев можно соблюдать следующие правила:

1. Попробуйте посетить другие сайты и посмотрите, сохраняется ли проблема.
2. Если вы используете сеть Wi-Fi, попробуйте переключиться на проводную.
3. Попробуйте другие сетевые подключения. Например, используйте другой маршрутизатор или переключитесь на общедоступную сеть.

После того, как вы установили причину проблемы, вы можете спросить: «Следует ли мне отключить квитирование TLS в моем браузере?» Мы понимаем ваше разочарование, но не рекомендуем этого делать. В конце концов, протокол TLS — один из лучших способов обеспечить безопасный просмотр. Действительно, вы можете продолжить просмотр веб-сайта даже с недействительным сертификатом. Однако вы никогда не должны совершать с ним какие-либо операции. Например, не отправляйте учетные данные пароля и не используйте свою кредитную карту.

С другой стороны, бывают случаи, когда сбой подтверждения TLS возникает из-за проблем с вашим браузером. В этом случае вы можете решить проблему, изменив некоторые настройки в вашем браузере. Ниже мы расскажем о некоторых из лучших обходных путей.

Решение 1. Обеспечение правильного системного времени

В большинстве случаев рукопожатие TLS не удается из-за неправильных настроек системного времени. Имейте в виду, что системное время является жизненно важным фактором при проверке того, действительно ли сертификат действителен или просрочен. Итак, если время на вашем ПК не совпадает со временем на сервере, то может показаться, что сертификаты больше не действительны. Поэтому мы рекомендуем вам установить системное время на «автоматическое». Вот шаги:

1. На клавиатуре нажмите Windows Key + I. Откроется приложение «Настройки».
2. В приложении «Настройки» выберите «Время и язык».
3. Перейдите на правую панель и установите переключатель в разделе «Автоматически устанавливать время» в положение «Вкл.».
4. Перезагрузите компьютер, затем попробуйте снова зайти на сайт, чтобы убедиться, что ошибка подтверждения TLS исчезла.

Решение 2. Изменение протокола TLS в Windows 10

Возможно, проблема связана с версией TLS, которую использует ваш браузер. Стоит отметить, что в Windows 10 и более ранних версиях операционной системы централизованы настройки протокола. Вы можете получить доступ к свойствам Интернета, чтобы переключиться на другую версию TLS. Для этого следуйте этим инструкциям:

1. Запустите диалоговое окно «Выполнить», нажав клавиши Windows + R на клавиатуре.
2. В диалоговом окне «Выполнить» введите «inetcpl.cpl» (без кавычек), затем нажмите «ОК».
3. В окне свойств Интернета перейдите на вкладку «Дополнительно».
4. Прокрутите вниз, пока не дойдете до раздела «Безопасность», где вы можете добавить или удалить протоколы TLS.
5. Если веб-сайт, к которому вы пытаетесь получить доступ, требует TLS 1.2, вам необходимо его выбрать.
6. Нажмите «Применить» и «ОК», чтобы сохранить внесенные изменения.
7. После изменения версии TLS попробуйте снова получить доступ к тому же веб-сайту.

Когда дело доходит до протоколов TLS, IE, Chrome и Edge используют возможности Windows. Между тем Firefox управляет собственной базой данных сертификатов и протоколами TLS. Итак, если вы хотите изменить версию TLS в Firefox, выполните следующие действия:

1. Запустите Firefox, затем введите «about: config» (без кавычек) в адресной строке.
2. Нажмите Enter, затем щелкните поле поиска.
3. Введите «TLS» (без кавычек), затем найдите security.tls.version.min.
4. Вы можете изменить это на любое из следующего:

Установите TLS 1 и 1.1, введя 1 и 2.

Включите TLS 1.2, введя 3.

Установите максимальный протокол TLS 1.3, введя 4.

Решение 3. Удаление базы данных сертификатов или профиля браузера

Браузеры хранят базу данных сертификатов. Например, профили Firefox поддерживают файл cert8.db. Есть один способ узнать, что ошибка установления связи TLS связана с локальной базой данных сертификатов. Вы можете попробовать удалить файл cert8.db в Firefox. Если ошибка исчезает при перезагрузке компьютера и браузера, значит, вы определили причину.

Для Edge за обработку сертификатов отвечает диспетчер сертификатов. Вы можете удалить сертификаты, выполнив следующие действия:

1. Откройте Edge, затем введите в адресной строке «edge: // settings / privacy» (без кавычек).
2. Щелкните параметр «Управление сертификатами и настройками HTTPS / SSL», затем удалите сертификаты.

Если у вас возникли проблемы с поиском базы данных сертификатов, лучше всего удалить профиль браузера. Как только вы это сделаете, вы можете снова попытаться получить доступ к веб-сайту, чтобы узнать, исчезла ли ошибка TLS.

Решение 4. Сброс настроек браузера

Если ни одно из исправлений, которыми мы поделились, не может решить проблему TLS, то последнее средство — сбросить настройки браузера. Лучший способ сделать это — удалить и переустановить браузер. Как только вы это сделаете, вы можете снова попытаться получить доступ к веб-сайту, чтобы проверить, исчезла ли ошибка TLS.

В некоторых случаях время установления связи TLS истекает, и вы не можете посетить веб-сайт. Когда это происходит, вы, естественно, спросите: «Сколько времени занимает рукопожатие TLS?» Что ж, это займет несколько секунд. Если это занимает больше минуты или двух, возможно, у вас медленное сетевое соединение. С другой стороны, также возможно, что ваш браузер перегружен расширениями, надстройками и прочим мусором.

Когда это происходит, вы должны использовать надежный очиститель нежелательной почты с ПК, например Auslogics BoostSpeed. Вы можете использовать этот инструмент, чтобы легко избавиться от ненужных файлов браузера. Более того, BoostSpeed ​​имеет функции, которые позволяют настраивать неоптимальные настройки браузера, обеспечивая плавную и быструю работу.

Какое из решений помогло вам решить проблему с подтверждением TLS?

Источник

OpenVPN Support Forum

Community Support Forum

TLS handshake failed

TLS handshake failed

Post by Bransonb3 » Sat Jan 06, 2018 4:57 pm

When I try to connect to my openvpn server I get TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) and TLS Error: TLS handshake failed. It looks like the server sees the client try to connect (TLS: Initial packet from. ) but doesn’t respond.

I’m running openvpn 2.4.4 on Windows Server 2016 1607. I am trying to connect my Mac running OSX 10.13.2, using Tunnelblick 3.7.4b but have also tried connecting using the openvpn connect android app. I have port forwarded 1194 udp to my server, made an inbound and outbound windows firewall rule allowing openvpn.exe, allowed tunnelblick incoming connections on the mac firewall. I have also tried to run the server as admin.

#################################################
# Sample OpenVPN 2.0 config file for #
# multi-client server. #
# #
# This file is for the server side #
# of a many-clients one-server #
# OpenVPN configuration. #
# #
# OpenVPN also supports #
# single-machine single-machine #
# configurations (See the Examples page #
# on the web site for more info). #
# #
# This config should work on Windows #
# or Linux/BSD systems. Remember on #
# Windows to quote pathnames and use #
# double backslashes, e.g.: #
# «C:\Program Files\OpenVPN\config\foo.key» #
# #
# Comments are preceded with ‘#’ or ‘;’ #
#################################################

# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?
;proto tcp
proto udp

# «dev tun» will create a routed IP tunnel,
# «dev tap» will create an ethernet tunnel.
# Use «dev tap0» if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use «dev-node» for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tun
dev tap

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don’t need this.
dev-node Ethernet_7

# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the «easy-rsa» directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see «pkcs12» directive in man page).
ca «C:\Program Files\OpenVPN\config\ca.crt»
cert «C:\Program Files\OpenVPN\config\server.crt»
key «C:\Program Files\OpenVPN\config\server.key» # This file should be kept secret

# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh2048.pem 2048
dh «C:\Program Files\OpenVPN\config\dh4096.pem»

# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
topology subnet

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
;server 192.168.1.225 255.255.0.0

# Maintain a record of client virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt

# Configure server mode for ethernet bridging.
# You must first use your OS’s bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 192.168.1.227/255.255.0.0. Finally we
# must set aside an IP range in this subnet
# (start=192.168.3.1 end=192.168.3.254) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
server-bridge 192.168.1.227 255.255.0.0 192.168.3.1 192.168.3.254

# Configure server mode for ethernet bridging
# using a DHCP-proxy, where clients talk
# to the OpenVPN server-side DHCP server
# to receive their IP address allocation
# and DNS server addresses. You must first use
# your OS’s bridging capability to bridge the TAP
# interface with the ethernet NIC interface.
# Note: this mode only works on clients (such as
# Windows), where the client-side TAP adapter is
# bound to a DHCP client.
;server-bridge

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push «route 192.168.10.0 255.255.255.0»
;push «route 192.168.20.0 255.255.255.0»

# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory «ccd» for client-specific
# configuration files (see man page for more info).

# EXAMPLE: Suppose the client
# having the certificate common name «Thelonious»
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious’ private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using «dev tun» and «server» directives.

# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2

# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push «redirect-gateway def1 bypass-dhcp»

# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push «dhcp-option DNS 208.67.222.222»
;push «dhcp-option DNS 208.67.220.220»

# Uncomment this directive to allow different
# clients to be able to «see» each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server’s TUN/TAP interface.
client-to-client

# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE «COMMON NAME»,
# UNCOMMENT THIS LINE OUT.
;duplicate-cn

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

# For extra security beyond that provided
# by SSL/TLS, create an «HMAC firewall»
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn —genkey —secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be ‘0’
# on the server and ‘1’ on the clients.
;tls-auth «C:\Program Files\OpenVPN\config\ta.key» 0 # This file is secret

# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC

# Enable compression on the VPN link and push the
# option to the client (v2.4+ only, for earlier
# versions see below)
;compress lz4-v2
;push «compress lz4-v2»

# For compression compatible with older clients use comp-lzo
# If you enable it here, you must also
# enable it in the client config file.
;comp-lzo

# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100

# It’s a good idea to reduce the OpenVPN
# daemon’s privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the «Program FilesOpenVPNlog» directory).
# Use log or log-append to override this default.
# «log» will truncate the log file on OpenVPN startup,
# while «log-append» will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 1

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server. #
# #
# This configuration can be used by multiple #
# clients, however each client should have #
# its own cert and key files. #
# #
# On Windows, you might want to rename this #
# file so it has a .ovpn extension #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one. On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote [Public IP] 1194

# Choose a random host from the remote
# list for load-balancing. Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don’t need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here. See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description. It’s best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.

——BEGIN CERTIFICATE——
Redacted
——END CERTIFICATE——

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 5 (0x5)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=NC, L=High Point, O= Redacted, OU= Redacted, CN=BT-MonCon-SRV/name=Certificate Authority/emailAddress= Redacted
Validity
Not Before: Jan 5 04:57:55 2018 GMT
Not After : Jan 3 04:57:55 2028 GMT
Subject: C=US, ST=NC, L=High Point, O= Redacted, OU= Redacted, CN=BransonMac/name=BransonMac/emailAddress= Redacted
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
Redacted
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
Redacted
X509v3 Authority Key Identifier:
keyid: Redacted
DirName:/C=US/ST=NC/L=High Point/O= Redacted/OU= Redacted/CN=BT-MonCon-SRV/name=Certificate Authority/emailAddress= Redacted
serial: Redacted

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha256WithRSAEncryption
Redacted

——BEGIN CERTIFICATE——
Redacted
——END CERTIFICATE——

——BEGIN PRIVATE KEY——
Redacted
——END PRIVATE KEY——

# Verify server certificate by checking that the
# certicate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the keyUsage set to
# digitalSignature, keyEncipherment
# and the extendedKeyUsage to
# serverAuth
# EasyRSA can do this for you.
;remote-cert-tls BT-MonCon-SRV

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
# Note that v2.4 client/server will automatically
# negotiate AES-256-GCM in TLS mode.
# See also the ncp-cipher option in the manpage
cipher AES-256-CBC

# Enable compression on the VPN link.
# Don’t enable this unless it is also
# enabled in the server config file.
#comp-lzo

# Set log file verbosity.
verb 4

# Silence repeating messages
;mute 20

Источник