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.
I’m configuring an OpenVPN (version 2.3.10) server on a Windows 2012 server but I cannot make it to work.
The server is behind a router and I opened the 1194 port and created a rule to forward traffic on this port to the server.
Here is the log I see on the server when I try to connect from a client:
Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting
Where XX.XX.XX.XX is the ip of the client. So I understand from this that the client at least is able to arrive at the server, so there’s no routing or firewall issues.
I followed the description provided here Easy Windows Guide Any ideas?
MadHatter
79k20 gold badges183 silver badges231 bronze badges
asked Mar 23, 2016 at 7:04
6
What’s interesting is how the port number changes mid-stream:
Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
This makes me think that, somewhere between client and server, there is a misbehaving NAT device, a device with very short-lived state table entries, which is changing the source port number that it applies to the client’s established stream, causing the server to think that two short-lived communications are in progress, instead of one continuous one.
Such devices generally only do this with UDP, so I have advised you to confirm that you are using UDP, and try TCP instead. This you have done, and found that it fixes the problem. The next step is to identify the misbehaving NAT device, hit it with a club hammer, and replace it with one that doesn’t make the cardinal mistake of assuming that all UDP communications are ephemeral; but you have indicated that you’re happy with changing to TCP as a workaround, and so the matter is concluded.
answered Mar 23, 2016 at 10:39
MadHatterMadHatter
79k20 gold badges183 silver badges231 bronze badges
6
This is one of the most common error in setting up Openvpn and there is a FAQ entry for this. I’m going to quote this here:
TLS Error: TLS key negotiation failed to occur within 60 seconds
(check your network connectivity)One of the most common problems in setting up OpenVPN is that the two
OpenVPN daemons on either side of the connection are unable to
establish a TCP or UDP connection with each other.This is almost a result of:
- A perimeter firewall on the server’s network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port
number 1194).- 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.- A NAT gateway on the server’s network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server
machine.- The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file
must point to either the server itself or the public IP address of the
server network’s gateway.- Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it
to the «Exceptions» list) it for OpenVPN to work.
It’s highly likely that any of these is causing the same problem in your case too. So just go through the list one by one to resolve it.
Ref: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
MadHatter
79k20 gold badges183 silver badges231 bronze badges
answered Mar 23, 2016 at 8:23
DiamondDiamond
8,9213 gold badges23 silver badges38 bronze badges
4
I was getting TLS key negotiation timeouts like this. But in my case I realised that the remote link was a local IP address.
The VPN on our pfSense firewall had mistakenly been put on the LAN interface instead of the WAN interface, and so the exported config was set to try and connect to the firewall’s LAN IP address — which was never going to work with the client naturally being on a different LAN.
I think the main takeaways from this are:
-
Getting a key negotiation timeout does not necessarily mean you’ve even managed to connect to anything.
So at this stage it may still be worth checking you’re actually connecting to the right place, and there are no firewall rules blocking the connection, etc. Particularly if your configuration has been automatically generated.
Note that getting a login prompt does not mean that you’re connected, since OpenVPN asks for your credentials before trying to connect.
-
Make sure your VPN server is listening on the right interface.
(Of course, this is one of a number of server-side misconfigurations that could occur, such as firewall rules, putting the wrong port number, intermixing TCP and UDP, etc.)
answered Mar 21, 2017 at 12:18
mwfearnleymwfearnley
7881 gold badge10 silver badges21 bronze badges
I had the same error and no advice helped, everything seemed to be fine: IPs, ports, firewall, everything. Gone insane for 2 hours.
Solution was to change the protocol from UDP to TCP in the client config (apparently I disabled UDP on purpose a long while ago).
Hope this helps someone
LE: this solved my problem but it’s not the best approach as per below comments. You should use UDP instead of TCP. It helped me because I had different settings between the client and the server configs.
answered Jun 1, 2017 at 20:11
boschbosch
1856 bronze badges
5
None of the solutions mentioned earlier worked. In my case, even though the client log showed same error TLS Error: TLS key negotiation failed to occur within 60 seconds
, the server logs showed VERIFY ERROR: depth=0, error=CRL has expired
.
On the server, following steps resolved the connection issue:
# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn
answered Dec 5, 2018 at 3:49
mpprdevmpprdev
1511 gold badge1 silver badge5 bronze badges
Note that you can get a TLS key negotiation error, without successfully connecting to the OpenVPN server — or even successfully connecting to anything at all!
I modified a VPN config to connect to localhost, on a port that wasn’t listening on anything:
OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018 Windows version 6.2 (Windows 8 or greater) 64bit library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10 TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:12345 UDP link local (bound): [AF_INET][undef]:0 UDP link remote: [AF_INET]127.0.0.1:12345 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed SIGUSR1[soft,tls-error] received, process restarting ...
The error can lull you into a false sense that you’re talking to a VPN server.
You may even get prompted for credentials first, but nothing outside your computer has actually asked for them.
answered Aug 10, 2018 at 15:21
mwfearnleymwfearnley
7881 gold badge10 silver badges21 bronze badges
I ran into this error in AWS, where OpenVPN was installed on a server with a public IP, but on an instance which was in a private subnet, i.e. a subnet which didn’t have a route to an internet gateway.
Once I deployed OpenVPN on a server within a public subnet, it all worked nicely
On public/private subnets in AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html
answered Aug 29, 2018 at 15:15
ZoltánZoltán
2172 silver badges6 bronze badges
I also came across the TLS key negotiation failed to occur within 60 seconds
problem.
From the official suggestion, as Diamant post, there must be something wrong in the network connection. However, neither the firewall nor the NAT cause the problem.
In my case, I first checked the connection by nc -uvz xxx.xxx.xxx.xxx 1194
. The link is OK.
Besides, several other vpn clients within the same LAN work fine.
From somewhere I noticed that udp connection has some problems in response or port forward.
So I stop the running vpn clients from the largest ip to the hanging client, e.g, from «10.8.0.100» to «10.8.0.50».
Then start the stopped vpn clients in reverse.
Bang! All the vpn clients work propoerly.
In conclusion, there is a chance leads to TLS key negotiation failed to occur within 60 seconds
problem that multiple vpn clients within a LAN starting in a wrong sequence.
answered May 30, 2019 at 6:18
1
One possible reason is if the server requires TLS version newer then the TLS supported by the client. i.e 1.2 vs 1.0.
The obvious thing to try is to update the OpenVPN client, or modify the server side to accept TLS 1.0.
kenlukas
2,9862 gold badges14 silver badges25 bronze badges
answered Mar 24, 2020 at 17:45
You should create a SSL/TLS certificate on OMV and then enable secure connection SSL/TLS and add the created certificate.
So simple!
answered May 28, 2020 at 3:50
Are there more than two NetCards on your OVPN-Server?
In UDP, the source IP is not checked when responding. OVPN-Server will use the default configuration to send UDP data, so we need to specify the NetCard in server.conf.
local the-IP-in-client.ovpn
answered Aug 21, 2020 at 4:03
There seems to be a lot of different causes for the error — I was seeing this on the server for one client, but successfully connecting with another (the latter client being an android device using the OpenVPN Connect App).
What it turned out to be in my case is that I’d neglected to include a CommonName value when creating the server certificate — the app was ignoring this mistake but the other clients (OpenVPN plugin for Network Manager and pfSense) were validating this and refusing to continue the connection. This could be found within the client logs, but all that was visible on the server-side logs was:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
answered Apr 29, 2021 at 5:03
Модераторы: GRooVE, alexco
Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
-
Гость
- проходил мимо
OpenVPN не заводиться
Доброго времени суток ВСЕМ
Можете мне подсказать что не так ?
У клиента в логах openvpn.log ругань:
Код: Выделить всё
##########################################################
event_wait : Interrupted system call (code=4)
TCP/UDP: Closing socket
SIGTERM[hard,] received, process exiting
OpenVPN 2.0.6 i386-portbld-freebsd4.8 [SSL] [LZO] built on Sep 17 2008
Control Channel Authentication: using '/usr/local/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Outgoing Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
Incoming Control Channel Authentication: Using 128 bit message hash 'MD5' for HMAC authentication
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options hash (VER=V4): '03fa487d'
Expected Remote Options hash (VER=V4): '1056bce3'
UDPv4 link local (bound): [undef]:2000
UDPv4 link remote: xxx.xxx.xxx.xxx:2000
[b]TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed[/b]
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 2 second(s)
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options hash (VER=V4): '03fa487d'
Expected Remote Options hash (VER=V4): '1056bce3'
UDPv4 link local (bound): [undef]:2000
UDPv4 link remote: xxx.xxx.xxx.xxx:2000
А в логах сервера вот такая ругань:
##########################################################
Код: Выделить всё
[b]xx.xx.xx.xx:2000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
xx.xx.xx.xx:2000 SIGUSR1[soft,tls-error] received, client-instance restarting
MULTI: multi_create_instance called[/b]
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
xx.xx.xx.xx:2000 Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
xx.xx.xx.xx:2000 Local Options hash (VER=V4): '1056bce3'
xx.xx.xx.xx:2000 Expected Remote Options hash (VER=V4): '03fa487d'
xx.xx.xx.xx:2000 TLS: Initial packet from 62.80.178.22:2000, sid=ede7e96a 84c81a85
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
ifconfig сервера:
Код: Выделить всё
##########################################################
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.10.200.1 --> 10.10.200.2 netmask 0xffffffff
Opened by PID 19690
##########################################################
Сертификаты готовились на сервере, ось FreeBSD6.2 и OpenVPN 2.0.6
Клиент живет на FreeBSD4.8 и OpenVPN 2.0.6
Подскажите что не так.
Спасибо!
Последний раз редактировалось zingel 2008-09-19 12:45:26, всего редактировалось 1 раз.
Причина: юзай [code][/code]
-
Хостинг HostFood.ru
Услуги хостинговой компании Host-Food.ru
Хостинг HostFood.ru
Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2008-09-19 12:41:22
Код: Выделить всё
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
xx.xx.xx.xx:2000 write UDPv4: Permission denied (code=13)
эти строчки мне не нравятся
фаервол?
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
BI_J
- сержант
- Сообщения: 154
- Зарегистрирован: 2008-09-19 12:21:10
Re: OpenVPN не заводиться
Непрочитанное сообщение
BI_J » 2008-09-19 12:52:58
Все делалось по статье уважаемого mak_v_.
http://www.lissyara.su/?id=1685&comment … mment_4718
После совета проверить firewal, в логах клиента ситуация немного изменилась:
У клиента в логах openvpn.log ругань:
##########################################################
OpenVPN 2.0.6 i386-portbld-freebsd4.8 [SSL] [LZO] built on Sep 17 2008
Control Channel Authentication: using ‘/usr/local/etc/openvpn/keys/ta.key’ as a OpenVPN static key file
Outgoing Control Channel Authentication: Using 128 bit message hash ‘MD5’ for HMAC authentication
Incoming Control Channel Authentication: Using 128 bit message hash ‘MD5’ for HMAC authentication
LZO compression initialized
Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options hash (VER=V4): ’03fa487d’
Expected Remote Options hash (VER=V4): ‘1056bce3’
UDPv4 link local (bound): [undef]:2000
UDPv4 link remote: ip.ser.ve.ra:2000
TLS Error: Unroutable control packet received from ip.ser.ve.ra:2000 (si=3 op=P_ACK_V1)
TLS Error: Unroutable control packet received from ip.ser.ve.ra:2000 (si=3 op=P_ACK_V1)
.
.
.
VERIFY nsCertType ERROR: /C=UA/ST=Kiev/L=Kiev/O=server/OU=server/CN=server/emailAddress=admin@domen.com.ua, require nsCertType=SERVER
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 2 second(s)
У сервера ругань почти не изменилась:
##########################################################
ip.cli.en.ta:2000 TLS: new session incoming connection from 62.80.178.22:2000
ip.cli.en.ta:2000 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
ip.cli.en.ta:2000 TLS Error: TLS handshake failed
ip.cli.en.ta:2000 SIGUSR1[soft,tls-error] received, client-instance restarting
MULTI: multi_create_instance called
как я понимаю что то с сертификатами. Генерил как написано
-
serge
- майор
- Сообщения: 2133
- Зарегистрирован: 2006-07-30 15:34:14
- Откуда: Саратов
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
serge » 2008-09-19 14:52:30
Случаем не в клетке OpenVPN сидит?
Вот это смущает…
Unroutable control packet received from ip.ser.ve.ra:2000
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2008-09-19 14:57:22
и всетаки попробуйте ище раз пегенерировать сертификаты
у вас тип сертификата не совпадает
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
serge
- майор
- Сообщения: 2133
- Зарегистрирован: 2006-07-30 15:34:14
- Откуда: Саратов
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
serge » 2008-09-19 15:08:49
TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
дословно гуглом
TLS ключевые переговоры «не произойдет в течение 60 секунд (проверьте ваши сетевые подключения)
имхо, главная часть
проверьте ваши сетевые подключения
-
BI_J
- сержант
- Сообщения: 154
- Зарегистрирован: 2008-09-19 12:21:10
Re: OpenVPN не заводиться
Непрочитанное сообщение
BI_J » 2008-09-19 15:14:23
Спасибо за подсказки.
После очередной перегенирации сертификатов ситуация резко улучшилась
Но VPN так и не поднялся.
Теперь проблема кажеться в маршрутах со стороны клиента.
У клиента в логах openvpn.log
##########################################################
Код: Выделить всё
[server] Peer Connection Initiated with ip.ser.ve.ra:2000
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.10.200.1,ping 10,ping-
restart 120,ifconfig 10.10.200.2 10.10.200.1'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route options modified
gw ip.pro.vay.da
TUN/TAP device /dev/tun1 opened
/sbin/ifconfig tun1 10.10.200.2 10.10.200.1 mtu 1500 netmask 255.255.255.255 up
/usr/local/etc/openvpn/openvpn_up.sh tun1 1500 1538 10.10.200.2 10.10.200.1 init
/usr/local/etc/openvpn/openvpn_up.sh: permission denied
script failed: shell command exited with error status: 126
Fri Sep 19 14:02:08 2008 Exiting
##########################################################
Интернет удаленный клиент получает через модем провайдера через вот такое соединение:
ifconfig:
Код: Выделить всё
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1492
inet ip.cli.en.ta --> ip.pro.vay.da netmask 0xffffffff
Opened by PID 88
нужно как то рулить это дело
-
zingel
- beastie
- Сообщения: 6204
- Зарегистрирован: 2007-10-30 3:56:49
- Откуда: Moscow
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
zingel » 2008-09-19 15:14:47
TLS ключевые переговоры «не произойдет в течение 60 секунд (проверьте ваши сетевые подключения)
Это гугловский переводчик такую ересь выдал? Я в шоке…
Z301171463546 — можно пожертвовать мне денег
-
BI_J
- сержант
- Сообщения: 154
- Зарегистрирован: 2008-09-19 12:21:10
Re: OpenVPN не заводиться
Непрочитанное сообщение
BI_J » 2008-09-19 17:03:49
Сижу, смотрю на ошибку и в упор не замечаю грабли (стыдно белое перо ):
Код: Выделить всё
usr/local/etc/openvpn/openvpn_up.sh tun1 1500 1538 10.10.200.2 10.10.200.1 init
/usr/local/etc/openvpn/openvpn_up.sh: permission denied
script failed: shell command exited with error status: 126
после выполнения:
chmod 755 /usr/local/etc/openvpn/openvpn_up.sh
положение улучшилось
пинг пошол между 10.10.200.2 и 10.10.200.1
хух
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 14:23:37
Здрасти ребята. У меня такая вот проблема. Что делать? Подскажите пожалуйста.
Thu Feb 05 13:22:02 2009 Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Feb 05 13:22:02 2009 Local Options hash (VER=V4): ’03fa487d’
Thu Feb 05 13:22:02 2009 Expected Remote Options hash (VER=V4): ‘1056bce3’
Thu Feb 05 13:22:02 2009 UDPv4 link local (bound): [undef]:2000
Thu Feb 05 13:22:02 2009 UDPv4 link remote: 22.22.22.22:2000
Thu Feb 05 13:23:01 2009 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Feb 05 13:23:01 2009 TLS Error: TLS handshake failed
Thu Feb 05 13:23:01 2009 TCP/UDP: Closing socket
Thu Feb 05 13:23:01 2009 SIGUSR1[soft,tls-error] received, process restarting
Thu Feb 05 13:23:01 2009 Restart pause, 2 second(s)
Thu Feb 05 13:23:03 2009 Re-using SSL/TLS context
Thu Feb 05 13:23:03 2009 LZO compression initialized
Thu Feb 05 13:23:03 2009 Control Channel MTU parms [ L:1538 D:162 EF:62 EB:0 ET:0 EL:0 ]
Thu Feb 05 13:23:03 2009 Data Channel MTU parms [ L:1538 D:1450 EF:38 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Feb 05 13:23:03 2009 Local Options hash (VER=V4): ’03fa487d’
Thu Feb 05 13:23:03 2009 Expected Remote Options hash (VER=V4): ‘1056bce3’
Thu Feb 05 13:23:03 2009 UDPv4 link local (bound): [undef]:2000
Thu Feb 05 13:23:03 2009 UDPv4 link remote: 22.22.22.22:2000
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 14:36:05
check your network connectivity
перевод требуется ?
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 14:42:50
фаервол прверить
tcpdump-ом посмотреть
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
Re: OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 14:44:35
tcpdump -om
tcpdump version 3.9.4
libpcap version 0.9.4
Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ]
[ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ]
[ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
[ -W filecount ] [ -y datalinktype ] [ -Z user ]
[ expression ]
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 14:46:45
где <int> интерфейс через который openvpn ломится в интернет
2000 порт и можно еще приписать
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
Re: OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 15:10:00
#tcpdump -i fxp0 -np port 2000 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 15:11:41
ну и при запущенном tcpdump рестартануть openvpn
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
makihtow
- проходил мимо
- Сообщения: 8
- Зарегистрирован: 2009-02-05 14:18:31
Re: OpenVPN не заводиться
Непрочитанное сообщение
makihtow » 2009-02-05 15:40:25
Запустил tcpdump и сделал рестарт openvpn. Вот результат.
Код: Выделить всё
#tcpdump -i fxp0 -np port 2000 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on fxp0, link-type EN10MB (Ethernet), capture size 96 bytes
Код: Выделить всё
38 packets captured
4492 packets received by filter
0 packets dropped by kernel
-
hizel
- дядя поня
- Сообщения: 9032
- Зарегистрирован: 2007-06-29 10:05:02
- Откуда: Выборг
Re: OpenVPN не заводиться
Непрочитанное сообщение
hizel » 2009-02-05 15:47:18
у вас openvpn точно работает на 2000 порту udp?
если да то проверяйте фаервол
В дурацкие игры он не играет. Он просто жуткий, чу-чу, паровозик, и зовут его Блейн. Блейн — это Боль.
-
hz
- проходил мимо
- Сообщения: 4
- Зарегистрирован: 2009-03-24 9:59:09
Re: OpenVPN не заводиться
Непрочитанное сообщение
hz » 2009-03-24 10:27:16
День добрый.Помогите советом куда копать.Трабл в следующем:всё поднималось по описанию mac_v (отдельное спасибо).Туннель поднялся.Но проблема в следующем-внутрення сеть «филиала» видит внутреннее пространство за сервером впн.В обратную же сторону,т.е. то что находится внутри «головного офиса» не видит сетку «филиала».Выдаёт на ping ошибку ping: sendto: Invalid argument.Маршуты все прописаны.Руками прописывать пробывал маршрут до подсети «филиала» — ответ маршрут сущ-т.
-
zingel
- beastie
- Сообщения: 6204
- Зарегистрирован: 2007-10-30 3:56:49
- Откуда: Moscow
- Контактная информация:
Re: OpenVPN не заводиться
Непрочитанное сообщение
zingel » 2009-03-24 13:29:05
отдельную тему лучше
Z301171463546 — можно пожертвовать мне денег
-
Sanya0413
- проходил мимо
- Сообщения: 2
- Зарегистрирован: 2010-03-30 15:30:44
Re: OpenVPN не заводиться
Непрочитанное сообщение
Sanya0413 » 2010-03-30 16:31:46
# !/bin/sh
/bin/sh: Event not found.
# /sbin/route add -net 192.168.1.0 10.10.200.1
route: writing to routing socket: Network is unreachable
add net 193.168.1.0: gateway 10.10.200.1: Network is unreachable
при создании файла openvpn_up.sh пишет вот такую ругню.
все создал по статье, sockstat ‘ ом проверил openvpn поднялся на сервере и на клиенте, но пинги не идут((
0
1
Есть CentOS 6.5, на нём стоит OpenServer 2.3.2 в комплекте с Easy-RSA 2.0. Суть в том, что сервер запускается нормально, то есть в логе я вижу «Initialization Sequence Completed». Далее я на удалённой машине пытаюсь подключиться к серверу с клиента XP SP3 (через OpenVPN-GUI 2.0.9). Схема работы такая:
Клиент -> Роутер с NAT (1194->1194 сервера) -> Сервер
.
Итак, проблемы (Оставил только ошибки).
На клиенте
Wed Dec 04 12:52:21 2013 us=109151 VERIFY ERROR: depth=1, error=certificate signature failure: /C=RU/ST=RO/L=*****/O=*****/OU=*****/CN=NITELaB_CA/name=EasyRSA/emailAddress=*****
Wed Dec 04 12:52:21 2013 us=111888 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Dec 04 12:52:21 2013 us=113361 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 04 12:52:21 2013 us=114200 TLS Error: TLS handshake failed
Через некоторое время
Wed Dec 04 12:52:25 2013 us=739951 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 12:52:25 2013 us=740888 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 12:52:26 2013 us=977402 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
Wed Dec 04 12:52:26 2013 us=978382 TLS Error: Unroutable control packet received from IP_SERVER:1194 (si=3 op=P_CONTROL_V1)
В этот момент на сервере (Время последней хрени)
Wed Dec 4 12:54:20 2013 us=466053 IP_CLIENT:29011 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Dec 4 12:54:20 2013 us=466122 IP_CLIENT:29011 TLS Error: TLS handshake failed
Wed Dec 4 12:54:20 2013 us=466250 IP_CLIENT:29011 SIGUSR1[soft,tls-error] received, client-instance restarting
Все сертификаты перевыпускал уже 10 раз — ничего не меняется.
На сервере в IPTABLES открыт UDP 1194, SeLinux отключен.
Конфиг сервера
port 1194
proto udp
dev tun0
ca "/etc/openvpn/keys/ca.crt"
cert "/etc/openvpn/keys/server.crt"
key "/etc/openvpn/keys/server.key"
dh "/etc/openvpn/keys/dh1024.pem"
server 10.70.80.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway"
keepalive 10 60
tls-auth "/etc/openvpn/keys/ta.key" 0
cipher AES-128-CBC
comp-lzo
max-clients 5
user nobody
group nobody
persist-key
persist-tun
status "/var/log/openvpn/openvpn-status.log"
log "/var/log/openvpn/openvpn.log"
log-append "/var/log/openvpn/openvpn.log"
verb 4
Конфиг Win-клиента
client
proto udp
dev tun
dev-node TAP-Win32 Adapter V8 //Название адаптера в диспетчере
remote IP_SERVER
resolv-retry infinite
ca "C:\OpenVPN\ssl\ca.crt"
cert "C:\OpenVPN\ssl\nlbout.crt"
key "C:\OpenVPN\ssl\nlbout.key"
ns-cert-type server
tls-auth "C:\OpenVPN\ssl\ta.key" 1
cipher AES-128-CBC
comp-lzo
verb 4
Тестирую OpenVPN на удаленном VPS, не могу подключиться. Настраивал по этому туториалу . Подскажите, в чем может быть проблема?
log подключения
Fri Mar 28 12:48:47 2014 OpenVPN 2.2.2 Win32-MSVC++ [SSL] [LZO2] [PKCS11] built on Dec 15 2011
Fri Mar 28 12:48:50 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Mar 28 12:48:50 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Mar 28 12:48:50 2014 LZO compression initialized
Fri Mar 28 12:48:50 2014 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Mar 28 12:48:50 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Mar 28 12:48:50 2014 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Mar 28 12:48:50 2014 Local Options hash (VER=V4): 'd3a7571a'
Fri Mar 28 12:48:50 2014 Expected Remote Options hash (VER=V4): '5b1533a2'
Fri Mar 28 12:48:50 2014 UDPv4 link local: [undef]
Fri Mar 28 12:48:50 2014 UDPv4 link remote: *ip*:1194
Fri Mar 28 12:49:04 2014 TLS: Initial packet from *ip*:1194, sid=dc12be0a 9daee0c4
Fri Mar 28 12:49:04 2014 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Mar 28 12:49:37 2014 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=changeme/name=changeme/emailAddress=mail@host.domain
Fri Mar 28 12:49:37 2014 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=server/name=changeme/emailAddress=mail@host.domain
Fri Mar 28 12:49:50 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Mar 28 12:49:50 2014 TLS Error: TLS handshake failed
Fri Mar 28 12:49:50 2014 TCP/UDP: Closing socket
Fri Mar 28 12:49:50 2014 SIGUSR1[soft,tls-error] received, process restarting
var/log/messages
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS object -> incoming plaintext read error
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:22:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:23:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=6ee022fb cf324eca
Mar 28 12:24:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mar 28 12:24:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:24:57 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:32:43 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=b95a9146 f3028138
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS object -> incoming plaintext read error
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:33:04 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:33:44 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=6db967fe 9f5adbd3
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS_ERROR: BIO read tls_read_plaintext error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS object -> incoming plaintext read error
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS Error: TLS handshake failed
Mar 28 12:34:06 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT SIGUSR1[soft,tls-error] received, client-instance restarting
Mar 28 12:34:46 4dfd147a-abd5-4bde-9511-00a1cc04ec56 openvpn[21023]: MY_IP:PORT TLS: Initial packet from [AF_INET]MY_IP:PORT, sid=90e5468a 0d86403b
server.conf
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
fconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
server.ovpn
client
dev tun
proto udp
remote *IP* 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ca ca.crt
auth-user-pass
comp-lzo
reneg-sec 0
verb 3
- Печать
Страницы: [1] Вниз
Тема: Не могу подключиться к своему Openvpn (Прочитано 6908 раз)
0 Пользователей и 1 Гость просматривают эту тему.

S_POWER
Развернул OpenVPN на своём Ubuntu server 16.04, сделал всё по инструкции, служба работает, в ifconfig появился tun0, но клиент под windows не соеденяется. По разному менял настройки, всё равно результата нет.
Конфиг сервера
Конфиг клиента
Лог сервера
Лог клиента
Клиентские ключи, а так же ca.crt и ta.key в папке конфига клиента, серверные понятное дело на месте.
ipv4_forwarding включен
сервер за роутером, порт 1194 переброшен
openssl не трогал.
Если можно объясните попроще что не так, пользуюсь ubuntu меньше месяца,поэтому даже не понимаю в чём может быть проблема, помимо неправильных конфигов.
« Последнее редактирование: 04 Октября 2016, 07:59:49 от SATAN_POWER »

kalek
ls -l /etc/openvpn/keys/
?

S_POWER
root@ubuntuserver:~# ls -l /etc/openvpn/keys/
итого 40
-rw-r--r-- 1 root root 4250 окт 3 02:14 01.pem
-rw-r--r-- 1 root root 1403 окт 3 02:13 ca.crt
-rw------- 1 root root 916 окт 3 02:13 ca.key
-rw-r--r-- 1 root root 245 окт 3 02:14 dh1024.pem
-rw-r--r-- 1 root root 4250 окт 3 02:14 server.crt
-rw-r--r-- 1 root root 733 окт 3 02:14 server.csr
-rw------- 1 root root 916 окт 3 02:14 server.key
-rw-r--r-- 1 root root 636 окт 3 02:15 ta.key
« Последнее редактирование: 04 Октября 2016, 08:01:26 от SATAN_POWER »

kalek
Еще
route
и
ifconfig
Кроме того стоит выполнить
sudo chmod 600 /etc/openvpn/keys/ta.key
чтоб на него не ругалось.

S_POWER
root@ubuntuserver:~# route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 100 0 0 enp2s4
10.0.0.0 * 255.255.255.0 U 0 0 0 tun0
10.15.0.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
link-local * 255.255.0.0 U 1000 0 0 tun0
192.168.1.0 * 255.255.255.0 U 100 0 0 enp2s4
root@ubuntuserver:~# ifconfig
enp2s4 Link encap:Ethernet HWaddr 00:16:17:b6:a0:cd
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fd4d:2151:7a64:0:94a0:da2f:63db:be44/64 Scope:Общий
inet6 addr: fd4d:2151:7a64:0:99bd:f3a5:c1e2:19e1/64 Scope:Общий
inet6 addr: fe80::216:17ff:feb6:a0cd/64 Scope:Link
inet6 addr: fd4d:2151:7a64:0:311e:cd55:6df7:d5c4/64 Scope:Общий
inet6 addr: fd4d:2151:7a64:0:216:17ff:feb6:a0cd/64 Scope:Общий
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15516809 errors:0 dropped:0 overruns:0 frame:0
TX packets:19105302 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17641284188 (17.6 GB) TX bytes:19876678193 (19.8 GB)
lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:353323 errors:0 dropped:0 overruns:0 frame:0
TX packets:353323 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:1157858637 (1.1 GB) TX bytes:1157858637 (1.1 GB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.1 P-t-P:10.0.0.1 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

kalek
Судя по логу
Mon Oct 3 04:14:32 2016 217.118.78.105:54617 CRL: cannot read: /etc/openvpn/keys/01.pem
ругается на список отзыва сертификатов.
Mon Oct 3 04:14:32 2016 217.118.78.105:54617 TLS_ERROR: BIO read tls_read_plaintext error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
Для проверки можно попробовать его отключить — закомментировать строчку
crl-verify /etc/openvpn/keys/01.pem
Если заведется, дальше надо смотреть, все ли в порядке с этим файлом.

S_POWER
Спасибо!
Крайне удивлён, но заработало!
Что интересно я не генерировал список отзыва, 01.pem появился после генерации ключей сервера, 02.pem после генерации ключей клиента.
Возможно ли что в список 01 был занесён текущий клиент, из за того что я генерировал ключи 2 раза?
Можно ли где то посмотреть список всех выданных сертификатов?
- Печать
Страницы: [1] Вверх
Wondering how to resolve TLS key negotiation failed error in OpenVPN? We can help you.
As part of our Server Management Services, we assist our customers with several OpenVPN queries.
Today, let us see how our Support techs resolve this error.
How to resolve TLS key negotiation failed error in OpenVPN?
First and foremost, to diagnose problems with an OpenVPN server or client, it is helpful to look at the log files.
Locating the server log files
The log files are located in specific areas on your computer systems.
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.
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.
Then, 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
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.
TLS key negotiation failed error
Typical error will look as shown below:
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 blockage in place in a firewall or at the Internet service provider that is blocking or interfering with the TLS handshake in some way.
[Stuck in between? We’d be glad to assist you]
Conclusion
In short, today we saw steps followed by our Support Techs to resolve TLS key negotiation failed error in OpenVPN.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
Содержание
- OpenServer Ошибки с обеих сторон.
- OpenVPN Support Forum
- TLS handshake failed
- TLS handshake failed
OpenServer Ошибки с обеих сторон.
Есть CentOS 6.5, на нём стоит OpenServer 2.3.2 в комплекте с Easy-RSA 2.0. Суть в том, что сервер запускается нормально, то есть в логе я вижу «Initialization Sequence Completed». Далее я на удалённой машине пытаюсь подключиться к серверу с клиента XP SP3 (через OpenVPN-GUI 2.0.9). Схема работы такая:
На сервере в IPTABLES открыт UDP 1194, SeLinux отключен. Конфиг сервера
openssl verify -CAfile ca.crt client.crt
Делал, показывает ОК.
Вообще для меня тёмным пятном осталась настройка IPTABLES. Достаточно только открыть порт или необходимы ещё какие-то действия?
Ещё попробуй временно убрать tls-auth, в конфиге клиента client заменить на pull, а в конфиге сервера server заменить на
mode server
ifconfig 10.70.80.1 255.255.255.0
push «route-gateway 10.70.80.1»
Роутер с NAT (1194->1194 сервера)
Это должен быть DNAT. На всякий случай покажи iptables. Судя по тому, что клиент с сервером начали общаться — сделано правильно
Сделав данные действия получил в логе сервера
Ситуация такова: и в сервере, и на клиенте закоментировал строчки
Ошибка с TLS_ERROR: BIO read tls_read_plaintext error: появляется через раз, но вот с
Это при текущей секции server
Ты таблицу filter показал, а нужна ещё nat. Это iptables на роутере или на сервере? Я про роутер спрашивал
Опять встречаю iptables, настроенные в стиле pf — POLICY ACCEPT, и последнее правило DROP или REJECT. Почему не делать DROP/REJECT в POLICY? Удобнее же — можно просто добавлять новые правила, не контролируя, чтобы они встаил перед последним.
Как я понимаю, ошибка возникает из-за использования TLS Auth. Надо его отключить и попробовать установить соединение без него, а потом уже пробовать включить обратно. За него отвечает опция tls-auth, а ещё client и server раскрываются в несколько других опций, в том числе tls-client и tls-server. Надо как-то их убрать
server надо заменить на ifconfig . и что-то там ещё, потому что он раскрывается в tls-server, а мы пока пробуем завестись без tls auth.
после строки
tls-auth «C:\OpenVPN\ssl\ta.key» 1
на клиенте попробуйте прописать
auth MD5
IPTABLES, кроме портов, остался в том виде, в котором он идёт по дэфолту в СэнтОСе. IPTABLES я еще не постиг. Это IPTABLES на самом сервере VPN, на роутере (Asus RT-12N) просто идёт проброс с 1194 внешки на 1194 сервера.
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
Источник
I set up openvpn for my service server. Everything is fine in the test environment, but when I run deloy, I see that there is a large number of users with errors:
Tue Jun 14 08:35:05 2022 us=6947 xxx.xxx.xxx.xxx:8891 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Tue Jun 14 08:35:05 2022 us=7024 xxx.xxx.xxx.xxx:8891 TLS Error: TLS handshake failed Tue Jun 14 08:35:05 2022 us=7134 xxx.xxx.xxx.xxx:8891 SIGUSR1[soft,tls-error] received, client-instance restarting
After having a problem, I see that there are users who can connect again, but most of the users who fail to connect have the same thing in common are from countries like Algeria, Yemen, Brazil.
I have tried many solutions such as switching to tcp to change to other ports but the number of users having the above problem is still very large and none of the solutions really work.
This is my server config
port 1194 proto udp6 dev tun user root group nogroup persist-key persist-tun keepalive 10 120 topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 10.8.0.0 255.255.255.0" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" push "redirect-gateway def1 bypass-dhcp" server-ipv6 fd42:42:42:42::/112 tun-ipv6 push tun-ipv6 push "route-ipv6 2000::/3" push "redirect-gateway ipv6" dh none ecdh-curve prime256v1 tls-crypt tls-crypt.key duplicate-cn max-clients 3000 crl-verify crl.pem ca ca.crt cert server_YUi76qUq8Yad4OM7.crt key server_YUi76qUq8Yad4OM7.key auth SHA256 cipher AES-128-GCM ncp-ciphers AES-128-GCM tls-server tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 client-config-dir /etc/openvpn/ccd status /var/log/openvpn/status.log log-append /var/log/openvpn/vpn.log management localhost xxxx verb 4 script-security 3 down-pre up /etc/openvpn/tc.sh down /etc/openvpn/tc.sh client-connect /etc/openvpn/tc.sh client-disconnect /etc/openvpn/tc.sh
and this is the client’s
client proto udp explicit-exit-notify remote xxx.xxx.xxx.xxx 1194 dev tun resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server verify-x509-name server_YUi76qUq8Yad4OM7 name auth SHA256 auth-nocache cipher AES-128-GCM tls-client tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 ignore-unknown-option block-outside-dns setenv opt block-outside-dns # Prevent Windows 10 DNS leak verb 3