|
|
On Wed, 1 Dec 2004, Charles Duffy wrote: > On Wed, 01 Dec 2004 09:29:16 +0000, Steve Shellswell wrote: > > >> This happens every time, immediately after startup -- right? > > > > No. Just sometimes. I first noticed it after I had started and stopped > > the client end several times in relatively quick succession. This is the > > output from starting openvpn manually... > > Hmm. This is *really* looking like a problem for James. > > One thing I'm still a touch unclear on: Does this only happen immediately > after startup, or can it happen later on? (You might want specify > --reneg-sec 30 or somesuch during debugging). This message can occur when running OpenVPN in UDP mode, as UDP is not connection-oriented, so there's no easy way for one side of the connection to know that the other side has gone down or restarted. This error will almost never occur when running in TCP mode, because TCP enforces solid client/server semantics and connection-reset when either side of the connection goes down. Suppose you have a UDP OpenVPN connection between "Client" and "Server". If Client is restarted, because it is a client, it will renegotiate new TLS keys with the server, and the keys will immediately be in sync. However if the Server is restarted, it will not know that it must force a key renegotiation with a previously connected client because servers don't initiate connections, they wait for them to be initiated by clients. The current solution uses ping/ping-restart or keepalive which will cause the client to renegotiate with the server if the server is restarted after a specified period of silence without any ping messages coming from the server. The disadvantage of this approach is that it is not immediate. If the server goes down, it may take a minute or more for clients to recognize this and renegotiate new keys with the restarted server. You can reduce the time-lag by using a small ping-restart value, but then you may restart based on "false posititve" triggers such as short-term network outages which last less that 60 seconds. There are other possible solutions, such as adding control info to the UDP channel which is similar to the mechanism used by TCP to immediately signal connection reset to OpenVPN if the other side of the connection goes down. This has been discussed but will probably not see implementation until post 2.0. So to answer your question, if you get the "local/remote TLS keys are out of sync" message and then shortly thereafter, both sides of the connection reconnect and the VPN link successfully comes back up, then OpenVPN is operating normally. 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. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users Warning: require_once(../../../archive_common.php) [function.require-once]: failed to open stream: No such file or directory in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2004-12/msg00022.html on line 238 Fatal error: require_once() [function.require]: Failed opening required '../../../archive_common.php' (include_path='/usr/local/lib/php') in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2004-12/msg00022.html on line 238 |