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.
This topic has been deleted. Only users with topic management privileges can see it.
Hello everybody!
I have set up a freeipa with a freeradius, and I use my openvpn with a password and a token: very secure!
But the problem that I am having is the users are suffering vpn problems every hour aprox.
I was checking logs and it seems to happes always at XX:42:XX time.
I was reading a lot of documentation about radius and ipa and i have changed some config on them, but it is still failing, and the only info that i get from logs in my pfsense is:
Mar 17 14:36:06 openvpn 66107 XXX.XXX.XXX.XXX:56645 [xx-openvpn] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:56645
Mar 17 14:36:06 openvpn 66107 XXX.XXX.XXX.XXX:56645 TLS Auth Error: Auth Username/Password verification failed for peer
Mar 17 14:36:06 openvpn 66107 XXX.XXX.XXX.XXX:56645 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 1
Mar 17 14:36:06 openvpn user ‘xx-openvpn’ could not authenticate.
Mar 17 14:35:04 openvpn 66107 xx-openvpn/XXX.XXX.XXX.XXX:52420 [xx-openvpn] Inactivity timeout (–ping-restart), restarting
Mar 17 14:35:01 openvpn 66107 xx-openvpn/XXX.XXX.XXX.XXX:52420 TLS Error: local/remote TLS keys are out of sync: [AF_INET]XXX.XXX.XXX.XXX:52420 [1]
Mar 17 14:34:58 openvpn 66107 xx-openvpn/XXX.XXX.XXX.XXX:52420 TLS Error: local/remote TLS keys are out of sync: [AF_INET]XXX.XXX.XXX.XXX::52420 [1]
Mar 17 14:34:57 openvpn 66107 xx-openvpn/XXX.XXX.XXX.XXX:52420 TLS Error: local/remote TLS keys are out of sync: [AF_INET]XXX.XXX.XXX.XXX::52420 [1]
I thing that when i start to have the TLS error, it generate a timeout activty. The client try to reconnect but it needs a new token and them it fails.
So i have all my users (100) suffering an unstable service everyday.
i also have a «normal» openvpn server in my pfsense and it doesn ‘t happen…
PLEASE HELP ME ;D ;D
What version of pfSense / OpenVPN is used on each side of this?
Do you have any custom configuration settings anywhere that might be altering OpenVPN’s renegotiation parameters?
I am getting me crazy cause I was readiing all weekend forums and documentation about it…:
pfsense version: 2.3.3-RELEASE-p1 (amd64)
openvpn: on pfsense what is with the version, on my laptop for example OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016
As this problem is composed by 3 parts IPA+FreeRadius+Openvpn I have checked all the possibilities:
In IPA changing this data:
Password Policy
Max lifetime (days)
90
Min lifetime (hours)
3
History size (number of passwords)
0
Character classes
0
Min length
8
Max failures
6
Failure reset interval (seconds)
60
Lockout duration (seconds)
600Kerberos Ticket Policy
Max renew (seconds)
604800
Max life (seconds)
86400
In FreeRadius adding this config to the connection
vim /etc/raddb/dictionary
ATTRIBUTE Max-Daily-Session 36000 integer
Even in my openvpn:
Server
vi /var/etc/openvpn/server1.conf
reneg-sec 36000Client -> Local file *.ovpn
reneg-sec 0
I have restarted the service, and configured my vpn.
I dont know if the paths where I did the config was right, but seems than yes.
Some idea?
Thank you!!!
Is the OpenVPN server process restarting?
Anything in the system log, gateway log, or other logs around the time the error starts showing up?
Can you show the whole server configuration (minus any secret keys/names) from /var/etc/openvpn/ ?
This is the info I have got:
LOGS FROM SERVER
Mar 20 20:54:23 openvpn 54240 xxx.xxx.xxx.xxx:52921 TLS Auth Error: Auth Username/Password verification failed for peer
Mar 20 20:54:23 openvpn 54240 xxx.xxx.xxx.xxx:52921 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 1
Mar 20 20:54:23 openvpn user ‘user-openvpn’ could not authenticate.
Mar 20 20:53:26 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 [user-openvpn] Inactivity timeout (–ping-restart), restarting
Mar 20 20:53:26 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:25 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:25 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:24 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:23 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:22 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:19 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:17 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
Mar 20 20:53:15 openvpn 54240 user-openvpn/xxx.xxx.xxx.xxx:46288 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:46288 [1]
LOGS FROM CLIENT
Mon Mar 13 13:13:59 2017 [off-OpenVPN.domain.com] Inactivity timeout (–ping-restart), restarting
Mon Mar 13 13:13:59 2017 SIGUSR1[soft,ping-restart] received, process restarting
Mon Mar 13 13:14:01 2017 UDPv4 link local (bound): [undef]
Mon Mar 13 13:14:01 2017 UDPv4 link remote: [AF_INET]62.14.247.61:1194
Mon Mar 13 13:14:03 2017 [off-OpenVPN.domain.com] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:1194
Mon Mar 13 13:14:06 2017 AUTH: Received control message: AUTH_FAILED
Mon Mar 13 13:14:06 2017 /sbin/ip addr del dev tun0 192.168.52.11/24
Mon Mar 13 13:14:06 2017 SIGTERM[soft,auth-failure] received, process exiting
CONFIG FROM SERVER
dev ovpns1
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
reneg-sec 36000
keepalive 10 6000
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local XX.XX.XX.XX
tls-server
server 192.168.52.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
username-as-common-name
auth-user-pass-verify «/usr/local/sbin/ovpn_auth_verify user SVBB true server1 1194» via-env
tls-verify «/usr/local/sbin/ovpn_auth_verify tls ‘off-OpenVPN.domain.com’ 1»
lport 1194
management /var/etc/openvpn/server1.sock unix
push «route 192.168.0.0 255.255.255.0»
push «route 192.168.50.0 255.255.255.0»
push «route 192.168.250.0 255.255.255.0»
push «route 10.10.1.0 255.255.255.0»
push «route 10.10.3.0 255.255.255.0»
push «route 172.30.1.0 255.255.255.0»
push «route 172.30.2.0 255.255.255.0»
push «route 172.30.3.0 255.255.255.0»
push «route 172.30.4.0 255.255.255.0»
push «route 172.30.31.0 255.255.255.0»
push «route 172.30.35.0 255.255.255.0»
push «route 172.30.39.0 255.255.255.0»
push «route 172.29.0.0 255.255.224.0»
push «route 10.210.0.0 255.255.0.0»
push «route 10.57.31.0 255.255.255.0»
push «route 10.57.34.0 255.255.255.0»
push «route 192.168.100.0 255.255.255.0»
push «route 93.90.19.0 255.255.255.0»
push «route 109.70.39.0 255.255.255.0»
push «route 89.187.117.238 255.255.255.255»
push «route 77.240.112.0 255.255.240.0»
push «route 172.30.5.0 255.255.255.0»
push «route 93.90.20.0 255.255.255.0»
push «route 192.168.2.0 255.255.255.0»
push «dhcp-option DOMAIN mad01.domain.local»
push «dhcp-option DNS 93.90.19.234»
push «dhcp-option DNS 93.90.19.235»
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 192.168.0.162»
push «register-dns»
push «dhcp-option NTP 192.168.0.162»
push «dhcp-option NTP 192.168.0.163»
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float
topology subnet
CONFIG FROM CLIENT
dev tun
persist-tun
persist-key
cipher AES-128-CBC
auth SHA1
tls-client
client
resolv-retry infinite
reneg-sec 0
remote off.domain.com 1194 udp
lport 0
verify-x509-name «off-OpenVPN.domain.com» name
auth-user-pass
pkcs12 vpns-udp-1194-user-openvpn.p12
tls-auth vpns-udp-1194-user-openvpn-tls.key 1
ns-cert-type server
comp-lzo adaptive
Thank you for the interest and the help!
Regards
FIXED!!
https://forum.pfsense.org/index.php?topic=127601.0
Once I put the attributes in the server and in the client, the connection stay stable for the time i decide!!!
«reneg-sec 0» in server
«reneg-ser 36000» in client
THANK YOU VERY MUCH
«reneg-sec 0» in server
«reneg-ser 36000» in client
FWIW I would do it like this:
«reneg-sec 0» in client
«reneg-sec 36000» in server
That way the server setting is controlling and one change changes the renegotiation policy.
one day an openvpn that used to carry traffic for the last 7 years started to misbehave. openvpn’s own built in watchdog was restarting it every few minutes. one of the tunnels endpoints – a- is behind NAT that we don’t control, another – b – is a host with public ip address.
server b was claiming that keys are out of sync:
Apr 29 08:25:16 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:17 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:18 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:19 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:20 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:21 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:22 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:23 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:24 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:25 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:26 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:27 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:27 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:41408 [0]
Apr 29 08:25:30 brtr0 openvpn-a-B[27745]: [a-c] Peer Connection Initiated with [AF_INET]93.1.2.158:41408
Apr 29 08:26:31 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:36 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:41 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:42 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:42 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:43 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:45 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:49193 [0]
Apr 29 08:26:47 brtr0 openvpn-a-B[27745]: [a-c] Inactivity timeout (--ping-restart), restarting
Apr 29 08:26:47 brtr0 openvpn-a-B[27745]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 29 08:26:49 brtr0 openvpn-a-B[27745]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 29 08:26:49 brtr0 openvpn-a-B[27745]: Re-using SSL/TLS context
Apr 29 08:26:49 brtr0 openvpn-a-B[27745]: LZO compression initialized
Apr 29 08:26:49 brtr0 openvpn-a-B[27745]: Preserving previous TUN/TAP instance: tun2
Apr 29 08:26:49 brtr0 openvpn-a-B[27745]: UDPv4 link local (bound): [AF_INET]213.1.2.10:1779
Apr 29 08:26:49 brtr0 openvpn-a-B[27745]: UDPv4 link remote: [undef]
Apr 29 08:26:51 brtr0 openvpn-a-B[27745]: [a-c] Peer Connection Initiated with [AF_INET]93.1.2.158:49193
Apr 29 08:26:52 brtr0 openvpn-a-B[27745]: Initialization Sequence Completed
Apr 29 08:28:04 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:15472 [0]
Apr 29 08:28:06 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:15472 [0]
Apr 29 08:28:12 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:15472 [0]
Apr 29 08:28:13 brtr0 openvpn-a-B[27745]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]93.1.2.158:15472 [0]
Apr 29 08:28:19 brtr0 openvpn-a-B[27745]: [a-c] Inactivity timeout (--ping-restart), restarting
Apr 29 08:28:19 brtr0 openvpn-a-B[27745]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 29 08:28:21 brtr0 openvpn-a-B[27745]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 29 08:28:21 brtr0 openvpn-a-B[27745]: Re-using SSL/TLS context
Apr 29 08:28:21 brtr0 openvpn-a-B[27745]: LZO compression initialized
Apr 29 08:28:21 brtr0 openvpn-a-B[27745]: Preserving previous TUN/TAP instance: tun2
Apr 29 08:28:21 brtr0 openvpn-a-B[27745]: UDPv4 link local (bound): [AF_INET]213.1.2.10:1779
Apr 29 08:28:21 brtr0 openvpn-a-B[27745]: UDPv4 link remote: [undef]
Apr 29 08:28:22 brtr0 openvpn-a-B[27745]: [a-c] Peer Connection Initiated with [AF_INET]93.1.2.158:15472
Apr 29 08:28:23 brtr0 openvpn-a-B[27745]: Initialization Sequence Completed
which led to restarts of the vpn on the server a:
Apr 29 08:25:28 artr0 openvpn-A-b[5011]: [b-s] Inactivity timeout (--ping-restart), restarting
Apr 29 08:25:28 artr0 openvpn-A-b[5011]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: Re-using SSL/TLS context
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: LZO compression initialized
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: Preserving previous TUN/TAP instance: tun1
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: UDPv4 link local (bound): [undef]
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: UDPv4 link remote: [AF_INET]213.1.2.10:1779
Apr 29 08:25:30 artr0 openvpn-A-b[5011]: [b-s] Peer Connection Initiated with [AF_INET]213.1.2.10:1779
Apr 29 08:25:31 artr0 openvpn-A-b[5011]: Initialization Sequence Completed
Apr 29 08:26:49 artr0 openvpn-A-b[5011]: [b-s] Inactivity timeout (--ping-restart), restarting
Apr 29 08:26:49 artr0 openvpn-A-b[5011]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: Re-using SSL/TLS context
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: LZO compression initialized
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: Preserving previous TUN/TAP instance: tun1
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: UDPv4 link local (bound): [undef]
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: UDPv4 link remote: [AF_INET]213.1.2.10:1779
Apr 29 08:26:51 artr0 openvpn-A-b[5011]: [b-s] Peer Connection Initiated with [AF_INET]213.1.2.10:1779
Apr 29 08:26:52 artr0 openvpn-A-b[5011]: Initialization Sequence Completed
Apr 29 08:28:17 artr0 openvpn-A-b[5011]: [b-s] Inactivity timeout (--ping-restart), restarting
Apr 29 08:28:17 artr0 openvpn-A-b[5011]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: Re-using SSL/TLS context
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: LZO compression initialized
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: Preserving previous TUN/TAP instance: tun1
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: UDPv4 link local (bound): [undef]
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: UDPv4 link remote: [AF_INET]213.1.2.10:1779
Apr 29 08:28:19 artr0 openvpn-A-b[5011]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Apr 29 08:28:22 artr0 openvpn-A-b[5011]: [b-s] Peer Connection Initiated with [AF_INET]213.1.2.10:1779
Apr 29 08:28:23 artr0 openvpn-A-b[5011]: Initialization Sequence Completed
both a and b had in their configs:
ping 5
ping-restart 20
which lead to the restarts on the server a after communication breakdowns.
i still don’t understand real culprit of the problems. i suspect it might have something to do with the NAT behind which machine a is connected. but increasing the ping frequency from every 5s to every 1s has resolved the issue. for now at least:
ping 1
ping-restart 20
i had 409 vpn restarts 2 days ago, after applying this change.
Вот как оно, оказывается, бывает. Как говорится, есть фраза — в чужом глазу соломинку ты видишь, в своём глазу бревна не разглядишь. Я допустил чудовищную ошибку в конфиге, вместо параметра.
push "route 192.168.10.0 255.255.255.0"
В конфиге сервера я написал следующее.
push "route 192.168.0.0 255.255.255.0"
То он у меня и ломился, по несуществующему адресу. Теперь всё работает отлично, всё пингуется. Вот, публикую конфиг сервера, с работы.
proto udp
port 1200
dev tun
tls-server
topology subnet
route-method exe
route-delay 5
dev-node OpenVPN
server 10.8.0.0 255.255.255.0
route-gateway 10.8.0.1
client-config-dir "C:\Program Files\OpenVPN\ccd"
ca "C:\Program Files\OpenVPN\easy-rsa\keys\ca.crt"
cert "C:\Program Files\OpenVPN\easy-rsa\keys\server.crt"
key "C:\Program Files\OpenVPN\easy-rsa\keys\server.key"
dh "C:\Program Files\OpenVPN\easy-rsa\keys\dh2048.pem"
tls-auth "C:\Program Files\OpenVPN\easy-rsa\keys\ta.key" 0
push "route 192.168.10.0 255.255.255.0"
route 192.168.20.0 255.255.255.0 10.8.0.2
route 192.168.30.0 255.255.255.0 10.8.0.3
route 192.168.50.0 255.255.255.0 10.8.0.5
route 192.168.60.0 255.255.255.0 10.8.0.6
cipher BF-CBC
comp-lzo
verb 1
keepalive 5 60
sndbuf 524288
rcvbuf 524288
Маршруты
route 192.168.20.0 255.255.255.0 10.8.0.2
route 192.168.30.0 255.255.255.0 10.8.0.3
route 192.168.50.0 255.255.255.0 10.8.0.5
route 192.168.60.0 255.255.255.0 10.8.0.6
Я прописал, чтобы на будущее, когда всё выправлю, сделать связь между клиентами. Файлы в ccd я очистил. У меня ещё будут вопросы, вот, например мой конфиг, с которым я подключаюсь из дома.
ifconfig-push 10.8.0.7 255.255.255.0
push "dhcp-option DNS 192.168.10.12"
push "dhcp-option DOMAIN xxxx.local"
push "route 192.168.30.0 255.255.255.0"
push "route 192.168.60.0 255.255.255.0"
push "sndbuf 524288"
push "rcvbuf 524288"
iroute 192.168.12.0 255.255.255.0
Я ведь правильно указал там маршруты
push "route 192.168.30.0 255.255.255.0"
push "route 192.168.60.0 255.255.255.0"
Потому — что сервер о них не знает или нет, и их надо убрать? Вроде бы до добавления этих надписей у меня доступа в ту сеть не было!
Иногда выдаёт почему — то такую ошибку.
Thu May 23 22:47:59 2019 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:1200
Fist off thanks for reading this, I appreciate any and all suggestions.
I am having some serious problems reconnecting to my OpenVPN client using Riseup.net’s VPN.
I have spent a few days banging my head against the wall in attempts to set this up on my iOS devices….but that is a whole other issue.
I was however able to set it up on my Mac OS X specifically on my Windows Vista 32 bit BootCamp VM with relatively little trouble.
To originally connect I only had to modify the recommended Config file very slightly (Config file included at the end of this post):
— I had to enter the code directly into my config file
— And change «dev tap» to «dev tun»
So I was connected. (Note — I did test to ensure the VPN was actually working after I originally connected, it was. Also verified the .pem file (inserted as the coding in my config file) for authenticity). I left the VPN running. My computer went to sleep. Today I went to use the internet expecting (possibly incorrectly — I am now unsure if I was wrong to leave it running) to still be connected to the VPN. However I saw immediately I was not. I went to reconnect. And was (am) unable to.
My logs after attempting to connect (and getting a connection failed dialog box) show everything working as it should (as far as I can tell) until the end where I get the following lines:
Mon Sep 23 21:07:49 2013 us=276809 Initialization Sequence Completed
Mon Sep 23 21:07:49 2013 us=276809 MANAGEMENT: >STATE:1379995669,CONNECTED,SUCCESS, OMITTED
Mon Sep 23 21:22:50 2013 us=390350 Authenticate/Decrypt packet error: packet HMAC authentication failed
Mon Sep 23 21:23:39 2013 us=862180 TLS Error: local/remote TLS keys are out of sync: [AF_INET] VPN IP OMITTED [2]
Mon Sep 23 21:23:57 2013 us=395183 Authenticate/Decrypt packet error: packet HMAC authentication failed
Mon Sep 23 22:07:41 2013 us=296898 TLS: soft reset sec=0 bytes=513834601/0 pkts=708032/0
Mon Sep 23 22:07:41 2013 us=671299 VERIFY OK: depth=1, C=US, O=Riseup Networks, L=Seattle, ST=WA, CN=Riseup Networks, [email protected]
Mon Sep 23 22:07:41 2013 us=671299 VERIFY OK: depth=0, C=US, O=Riseup Networks, L=Seattle, ST=WA, CN=vpn.riseup.net
Mon Sep 23 22:07:46 2013 us=772508 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Sep 23 22:07:46 2013 us=772508 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 23 22:07:46 2013 us=772508 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Sep 23 22:07:46 2013 us=772508 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Sep 23 22:07:46 2013 us=772508 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
So I have searched for a solution online and I have included what I have attempted below, however I fear (know) I am not knowledgeable enough in this area to fix this myself. I apologize in advance for my ignorance. I do tech support for a living, but not this kind of tech support unfortunately.
Other notes and troubleshooting done —
— Windows Firewall is disabled completely, as well as other Anti-virus programs
— Tor is disabled completely
— No Proxies running
— Time is correct in all locations
— Router Firmware is up to date
— Able to connect to the internet and as far as I can tell all necessary ports are open.
— No settings have been altered since I was able to connect successfully.
— Ethernet as well as wifi connections attempted, resulted in same error.
-
Also tried adding the following lines to my config file (without success or change in error):
persist-key persist-tun proto tcp
(after reading that this error generally occurs on UDP connections, and is extremely rare on TCP)
resolv-retry infinite
(thinking the connection may have timed out since the issues occurred after leaving VPN connected during about 10 hrs of computer in sleep mode)
All attempts resulted in exact same error code included at the top of this post.
The original suggestions I found online stated —
-
(regarding the TLS Error) — This error should resolve itself within 60 seconds, or if not quit wait 120 seconds and try again. (Which isnt the case here…)
-
(regarding the Out of Sync» error) — If you continue to get «out of sync» errors and the link does not come up,
then it means that something is probably wrong with your config file. You
must use either ping and ping-restart on both sides of the connection, or
keepalive on the server side of a client/server connection, in order to
gracefully recover from «local/remote TLS keys are out
of sync» errors.
I wouldn’t be surprised if my config file is lacking, or not correct. However I can confirm I followed the instructions to a tee. And was able to connect originally (and have not modified my settings or config file since I was able to connect to when the error began occurring).
I have a very simple config file:
client
dev tun
tun-mtu 1500
remote vpn.riseup.net
auth-user-pass
ca RiseupCA.pem
redirect-gateway
verb 4
<ca>
-----BEGIN CERTIFICATE-----
[OMITTED]
-----END CERTIFICATE-----
</ca>
I would really appreciate any help or suggestions. I am at a total loss here, I know I’m asking a lot here.
Though I am a new user on this site I help others on many forums including Microsoft’s support community and especially Apple’s support communities, so I will definitely pass on anything I learn here to help others. Thanks so so so much in advance for reading this.
Приветствую.
Объединил два офиса посредством OpenVPN. Информацию по настройке в основном брал на этом ресурсе.
Вроде, всё заработало, но периодически случаются проблемы. Выглядит это так:
Соединение между клиентом и сервером как бы есть (по крайней мере OpenVPN-Control) показывает его наличие), но пакеты между сетями ходить перестают. Ни сервер, ни какие другие ресурсы со стороны клиента не пингуются. Если в этот момент посмотреть лог на клиенте, то там видно следующее:
Код: Выделить всё
Tue Jul 2 13:26:32 2013 [UNDEF] Inactivity timeout (--ping-restart), restarting
Tue Jul 2 13:26:32 2013 TCP/UDP: Closing socket
Tue Jul 2 13:26:32 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Jul 2 13:26:32 2013 Restart pause, 2 second(s)
Tue Jul 2 13:26:34 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul 2 13:26:34 2013 Re-using SSL/TLS context
Tue Jul 2 13:26:34 2013 LZO compression initialized
Tue Jul 2 13:26:34 2013 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Jul 2 13:26:34 2013 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Jul 2 13:26:34 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jul 2 13:26:34 2013 Local Options hash (VER=V4): '504e774e'
Tue Jul 2 13:26:34 2013 Expected Remote Options hash (VER=V4): '14168603'
Tue Jul 2 13:26:34 2013 UDPv4 link local (bound): [undef]
Tue Jul 2 13:26:34 2013 UDPv4 link remote: [AF_INET]123.123.123.123:1194
Tue Jul 2 13:26:34 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul 2 13:26:34 2013 TLS Error: Unroutable control packet received from [AF_INET]123.123.123.123:1194 (si=3 op=P_ACK_V1)
Tue Jul 2 13:26:35 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul 2 13:26:36 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul 2 13:26:36 2013 TLS Error: Unroutable control packet received from [AF_INET]123.123.123.123:1194 (si=3 op=P_ACK_V1)
Tue Jul 2 13:26:37 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul 2 13:26:39 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul 2 13:26:39 2013 [UNDEF] Inactivity timeout (--ping-restart), restarting
через какое-то время может появиться вот это:
Код: Выделить всё
Tue Jul 2 13:26:53 2013 [vpnsrv] Inactivity timeout (--ping-restart), restarting
Tue Jul 2 13:26:53 2013 TCP/UDP: Closing socket
Tue Jul 2 13:26:53 2013 SIGUSR1[soft,ping-restart] received, process restarting
Tue Jul 2 13:26:53 2013 Restart pause, 2 second(s)
Tue Jul 2 13:26:55 2013 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Jul 2 13:26:55 2013 Re-using SSL/TLS context
Tue Jul 2 13:26:55 2013 LZO compression initialized
Tue Jul 2 13:26:55 2013 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Jul 2 13:26:55 2013 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Jul 2 13:26:55 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Jul 2 13:26:55 2013 Local Options hash (VER=V4): '504e774e'
Tue Jul 2 13:26:55 2013 Expected Remote Options hash (VER=V4): '14168603'
Tue Jul 2 13:26:55 2013 UDPv4 link local (bound): [undef]
Tue Jul 2 13:26:55 2013 UDPv4 link remote: [AF_INET]123.123.123.123:1194
Tue Jul 2 13:26:55 2013 TLS Error: local/remote TLS keys are out of sync: [AF_INET]123.123.123.123:1194 [0]
Tue Jul 2 13:26:55 2013 TLS: Initial packet from [AF_INET]123.123.123.123:1194, sid=26a24dd3 c75415a2
Tue Jul 2 13:26:55 2013 VERIFY OK: depth=1, /C=RU/ST=MSK/L=Moscow/O=EGA/OU=IT/CN=vpnsrv/name=vpnsrv/emailAddress=postmaster
Tue Jul 2 13:26:55 2013 VERIFY OK: nsCertType=SERVER
Tue Jul 2 13:26:55 2013 VERIFY OK: depth=0, /C=RU/ST=MSK/L=Moscow/O=EGA/OU=IT/CN=vpnsrv/name=vpnsrv/emailAddress=postmaster
Tue Jul 2 13:26:55 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul 2 13:26:55 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 2 13:26:55 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul 2 13:26:55 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 2 13:26:55 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jul 2 13:26:55 2013 [vpnsrv] Peer Connection Initiated with [AF_INET]123.123.123.123:1194
Tue Jul 2 13:26:56 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:26:57 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:26:57 2013 SENT CONTROL [vpnsrv]: 'PUSH_REQUEST' (status=1)
Tue Jul 2 13:26:57 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:26:59 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:26:59 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:26:59 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:27:00 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
Tue Jul 2 13:27:01 2013 Authenticate/Decrypt packet error: packet HMAC authentication failed
В общем, факт в том, что разорванное соединение автоматически не восстанавливается, как по идее должно быть при использовании параметра «keepalive».
Конфиг сервера:
Код: Выделить всё
mode server
local 123.123.123.123
port 1194
proto udp
dev tun1
management 192.168.0.2 8330
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh2048.pem
server 10.1.1.0 255.255.255.0
topology subnet
ifconfig-pool-persist /usr/local/etc/openvpn/ipp1.txt 3600
push "dhcp-option DNS 192.168.1.250"
push "dhcp-option DOMAIN company.ru"
client-config-dir ccd
route 192.168.10.0 255.255.255.0 10.1.1.1
tls-server
tls-auth keys/ta.key 0
tls-timeout 120
auth SHA1
cipher BF-CBC
keepalive 1 5
comp-lzo
max-clients 100
user nobody
group nobody
persist-key
persist-tun
persist-local-ip
persist-remote-ip
push "persist-key"
push "persist-tun"
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
mute 20
конфиг клиента:
Код: Выделить всё
dev tun0
proto udp
remote 123.123.123.123
port 1194
client
auth-user-pass /etc/openvpn/passwd
resolv-retry infinite
pkcs12 /etc/openvpn/vpnsrv/sklad.p12
tls-client
tls-auth /etc/openvpn/vpnsrv/ta.key 1
auth SHA1
cipher BF-CBC
ns-cert-type server
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
Если на клиенте сервис openvpn остановить, подождать, пока на стороне сервера соединение сбросится и снова его запустить, то связь восстанавливается.
Посмотрите пожалуйста свежим взглядом, может что-то не так в настройках. Есть у меня подозрение, что дело в каких-то таймаутах или чём-то подобном.
И второй момент. Пока я боролся с этой проблемой, решил, как временное решение написать скрипт, который по отсутствию пинга нужного адреса будет останавливать, а потом снова запускать сервис openvpn.
Скрипт выглядит так:
Код: Выделить всё
#!/bin/bash
testip="192.168.1.250"
kol=$(/bin/ping -c 4 $testip | grep "received" | awk '{print $4}')
if [ $kol == 0 ]
then
echo "No ping to dc02. Waiting for 30 seconds..." | logger -t OPENVPNTEST
sleep 30
kol=$(/bin/ping -c 4 $testip | grep "received" | awk '{print $4}')
if [ $kol == 0 ]
then
echo "Restarting OpenVPN... " | logger -t OPENVPNTEST
echo "Stop OpenVPN service. " | logger -t OPENVPNTEST
/etc/init.d/openvpn stop | logger -t OPENVPNTEST
sleep 30
echo "Start OpenVPN service. " | logger -t OPENVPNTEST
/etc/init.d/openvpn start | logger -t OPENVPNTEST
sleep 5
/etc/init.d/openvpn status | logger -t OPENVPNTEST
exit 0
fi
fi
Проблема в том, что когда я этот скрипт запускаю вручную, то всё работает, а когда вставляю его в cron на выполнение через каждые 5 минут, то сервис openvpn останавливается, а вот запускаться обратно не хочет. Просто, не выдавая никаких ошибок, не стартует и всё. Последняя строка «/etc/init.d/openvpn status» выдаёт в лог VPN is not running.
Система ubuntu server 12.04. Скрипт запускаю из под рута. В чём тут может быть засада?
Topic: [SOLVED] OpenVPN tunnel to roadwarrior crashes after exactly one hour. Always. (Read 9405 times)
Hi
I installed opnsense on NUC pc with VLAN and stuff a month ago or something like that. I ‘upgraded’ from pfsense.
I have two openvpn daemons configured. One does site-to-site VPN using certificates to my VPS. That tunnel is stable as a rock. The other is for my laptop and is used as a roadwarrior. I have configured it to authenticate via TLS+OTP.
It connects fine, but after an hour — almost on the second — it crashes so that I can’t send any traffic through it. My VPN client tries to reconnect, but it can’t.
The log on opnsense says this:
Nov 24 14:24:59 openvpn[50931]: klaus/xxx.xxx.xxx.xxx:16962 TLS Error: local/remote TLS keys are out of sync: [AF_INET]xxx.xxx.xxx.xxx:16962 [1]
I tried googling that, but it didn’t really help me. Apparently noone on pfsense or opnsense have had this problem before :-p
Can anyone help?
/klaus
« Last Edit: December 05, 2016, 08:35:05 pm by franco »
Logged
This comes from OTP:
OpenVPN has a default of one hour, where the authentication is valid and needs to re-authenticate after this time. Because your one time password is not valid anymore at this time, the authentication fails and OpenVPN stops the connection. You need to change the amount of time between re-authentication and it will work longer. Because of this, you cannot use it in a way it is useful for a site-to-site vpn. Use a certificate instead of OTP for this use cases and OTP for road warrior connections.
Logged
At the bottom of the server config page in a recent OPNsense you find «Renegotiate time» where you can disable renegotiation. See the help description for details.
The whole OpenVPN stance on renegotiation is a bit silly as it essentially voids your credentials with OTP and the credentials are static when it’s not OTP, but that is for OpenVPN to ride out.
Logged
This comes from OTP:
OpenVPN has a default of one hour, where the authentication is valid and needs to re-authenticate after this time. Because your one time password is not valid anymore at this time, the authentication fails and OpenVPN stops the connection. You need to change the amount of time between re-authentication and it will work longer. Because of this, you cannot use it in a way it is useful for a site-to-site vpn. Use a certificate instead of OTP for this use cases and OTP for road warrior connections.
Thanks for the hint. I only use OTP on my roadwarrior currently. Site-to-site is just TLS.
I’ll take a look at the renegotiation settings to fix it. Many thanks!
/klaus
Logged
At the bottom of the server config page in a recent OPNsense you find «Renegotiate time» where you can disable renegotiation. See the help description for details.
The whole OpenVPN stance on renegotiation is a bit silly as it essentially voids your credentials with OTP and the credentials are static when it’s not OTP, but that is for OpenVPN to ride out.
Thanks. I set it to 0. I guess that’ll work.
/klaus
Logged
I tried to set the regetioation time to 0 as describe in help. That changes absolutely nothing. Tunnel still goes down after exactly one hour.
Does anyone have a suggestion to what else to try?
Thanks
/klaus
Logged
Did you set this for client and server?
Logged
I was testing this and had the same issue. After a few internet searches I found the right client parameter reneg-sec 0 . Based on Opnsense client recommendation for Windows I used Viscosity VPN client. In the Viscosity client right click on the OpenVPN profile you create for Opnsense/OpenVPN and select edit. On the advanced tab in the lower window add the setting. I tested this and have been up for hours without a drop. See the screenshot attached.
« Last Edit: December 07, 2016, 01:19:37 pm by s4rs »
Logged
« Last Edit: December 05, 2016, 08:34:55 pm by franco »
Logged