Openvpn tls error local remote tls keys are out of sync

This page is specifically about attempting to find and resolve problems with an OpenVPN client program failing to connect to an OpenVPN Access Server.

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! :D

    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)
    600

    Kerberos 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 36000

    Client -> 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 —

    1. (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…)

    2. (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


    Понравилась статья? Поделить с друзьями:

    Читайте также:

  • Openvpn tls error cannot locate hmac in incoming packet from
  • Openvpn tls crypt unwrap error packet too short
  • Openvpn terminated with exit code 1 как устранить ошибку
  • Openvpn tcp connect failed unknown error
  • Openssl error 14077410

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии