[Openvpn-users] OpenVPN 2.0 rc13 client restarting, why?

[Jelle Posthuma]

Dear list,

I'm not using any "ping" directive but still the OpenVPN client seems to
restart frequently because of inactivity, log snippet:

Thu Feb 17 12:02:14 2005 Initialization Sequence Completed
Thu Feb 17 12:04:26 2005 [OpenVPN_Server] Inactivity timeout
(--ping-restart), restarting
Thu Feb 17 12:04:26 2005 TCP/UDP: Closing socket


Client config, Windows XP SP2:
client
comp-lzo
dev tap
verb 3
remote xxx.xxx.xxx.xxx
cryptoapicert "SUBJ:someuser"
ca "someca.crt"


Server config, Windows 2000 Server SP4:
dev tap
verb 3
comp-lzo
pkcs12 server.p12
dh dh1024.key
push "dhcp-option WINS 192.168.51.1"
push "dhcp-option NBT 2"
push "route 192.168.50.0 255.255.255.0"
server 192.168.51.0 255.255.255.0


Can anybody give me a hint what could be the problem? I can't find out
why "ping-restart" occurs on the client side, is it because of the "mode
server" config?

Thanks,


Jelle

[Charles Duffy]

Post by Jelle Posthuma
I'm not using any "ping" directive but still the OpenVPN client seems to

I'm not sure why this is happening, but using keepalive (or
ping/ping-restart) is a good idea in server mode anyhow unless you're
running TCP -- otherwise, the server doesn't know when a client has
disconnected, and so can never remove them from its tables. (Yes, there's
the still-undocumented explicit-exit-notify option, but that won't work in
all cases).

I'm sure James or someone will be able to shed some light on the behaviour
you're seeing -- but in the meantime, I'd strongly recommend using the
keepalive macro on your server; not only will it stop this from happening,
but it'll keep you out of trouble in other respects as well.

[Mathias Sundman]

Post by Jelle Posthuma
I'm not using any "ping" directive but still the OpenVPN client seems to

Since 2.0-beta12, "--ping-restart 60" is by default enabled when working
in client mode.

Post by Jelle Posthuma
Thu Feb 17 12:02:14 2005 Initialization Sequence Completed
Thu Feb 17 12:04:26 2005 [OpenVPN_Server] Inactivity timeout
(--ping-restart), restarting
Thu Feb 17 12:04:26 2005 TCP/UDP: Closing socket

The real question is why the inactivity timeout occurs.

If you don't have any --ping in the server config, try add for example
--ping 15. I think it would be odd, but perhaps the server does not
send any inactivity pings by default even if the client expects them.

I've seen similar problems with the client keep re-connecting all the
time when I've done the mistake of connecting two PCs using the same
certificate to a server without using --duplicate-cn.

[Jelle Posthuma]

Post by Mathias Sundman
The real question is why the inactivity timeout occurs.
If you don't have any --ping in the server config, try add for example
--ping 15. I think it would be odd, but perhaps the server does not send
any inactivity pings by default even if the client expects them.
I've seen similar problems with the client keep re-connecting all the
time when I've done the mistake of connecting two PCs using the same
certificate to a server without using --duplicate-cn.

I've added "ping 15" to the server config and the client stays connected
nicely. No more ping-restarting on the client side, I'm a happy man :-)

Charles Duffy also replied that adding "ping 15" makes sense in order to
let the server know when the client disconnects. This sounds rather
logical but am I correct by saying that this info missing in the man
page currently?

[Charles Duffy]

Post by Jelle Posthuma
I've added "ping 15" to the server config and the client stays connected
nicely. No more ping-restarting on the client side, I'm a happy man :-)

...which is useful, yes.

That said, if I understand what Mathias was saying about --ping-restart
being implied on client mode, there's still potential for trouble.

If this is in fact implied only in client mode (and not in server mode),
that means that even with a ping directive on the server, the client still
isn't sending any pings and the server isn't expecting them -- the
client's only expecting and the server's only sending -- so there's still
no ability for the server to detect a client falling off the network,
unless you add ping-restart on the server or use the keepalive directive,
which will both add the right directives on the server *and* push them
over to the client so you don't need to maintain them in the client's
config file.

Moral of this story: Use --keepalive on your server.

[James Yonan]

Post by Charles Duffy

Post by Jelle Posthuma
I've added "ping 15" to the server config and the client stays connected
nicely. No more ping-restarting on the client side, I'm a happy man :-)

...which is useful, yes.
That said, if I understand what Mathias was saying about --ping-restart
being implied on client mode, there's still potential for trouble.
If this is in fact implied only in client mode (and not in server mode),
that means that even with a ping directive on the server, the client still
isn't sending any pings and the server isn't expecting them -- the
client's only expecting and the server's only sending -- so there's still
no ability for the server to detect a client falling off the network,
unless you add ping-restart on the server or use the keepalive directive,
which will both add the right directives on the server *and* push them
over to the client so you don't need to maintain them in the client's
config file.
Moral of this story: Use --keepalive on your server.

The client/server mode is really designed with the idea that keepalive
will be used on the server. If you are having problems with spurrious
restarts because of short-term network outages, it's best to use a high
timeout such as:

keepalive 10 600

The client by default will start out with a restart timeout of 60 seconds.
This is necessary because the client may need to restart before it
succeeds in connecting with the server and pulling the timeout parameter.

James

[Mathias Sundman]

Post by James Yonan
The client/server mode is really designed with the idea that keepalive
will be used on the server. If you are having problems with spurrious
restarts because of short-term network outages, it's best to use a high
keepalive 10 600
The client by default will start out with a restart timeout of 60 seconds.
This is necessary because the client may need to restart before it
succeeds in connecting with the server and pulling the timeout parameter.

But if the client defaults to use --ping-restart 60, shouldn't the server
send pings at say every 10 sec by default then to avoid the problem he saw
when not using --ping/--keep-alive on the server?

[James Yonan]

Post by Mathias Sundman

Post by James Yonan
The client/server mode is really designed with the idea that keepalive
will be used on the server. If you are having problems with spurrious
restarts because of short-term network outages, it's best to use a high
keepalive 10 600
The client by default will start out with a restart timeout of 60 seconds.
This is necessary because the client may need to restart before it
succeeds in connecting with the server and pulling the timeout parameter.

But if the client defaults to use --ping-restart 60, shouldn't the server
send pings at say every 10 sec by default then to avoid the problem he saw
when not using --ping/--keep-alive on the server?

That's a good point -- if you don't use --keepalive on the server, no
--ping-restart will be pushed to the client, so it will use its default
value of 60, and will therefore tend to restart when there's no active
tunnel traffic.

That means if you really don't want to use keepalive on the server, you
would need to set --ping-restart 0 on the client.

It would probably make sense to issue a warning on the server if either
keepalive or ping is missing.

James

[Mathias Sundman]

Post by James Yonan

Post by Mathias Sundman
But if the client defaults to use --ping-restart 60, shouldn't the server
send pings at say every 10 sec by default then to avoid the problem he saw
when not using --ping/--keep-alive on the server?

That's a good point -- if you don't use --keepalive on the server, no
--ping-restart will be pushed to the client, so it will use its default
value of 60, and will therefore tend to restart when there's no active
tunnel traffic.
That means if you really don't want to use keepalive on the server, you
would need to set --ping-restart 0 on the client.
It would probably make sense to issue a warning on the server if either
keepalive or ping is missing.

I think I'd prefer to remove the default --ping-restart 60 on the client
side. I just don't think it makes sence without having the server default
to use --ping xx.

If you want normal keep-alive behaviour, you put --keep-alive in the
server config, and --ping-restart will be pushed to the client. If you
really want the client to ping-restart on inactivity (no --ping on the
server), I think you should specify that in the client config with
--ping-restart (or push it).

[James Yonan]

Post by Mathias Sundman

Post by James Yonan

Post by Mathias Sundman
But if the client defaults to use --ping-restart 60, shouldn't the server
send pings at say every 10 sec by default then to avoid the problem he saw
when not using --ping/--keep-alive on the server?

That's a good point -- if you don't use --keepalive on the server, no
--ping-restart will be pushed to the client, so it will use its default
value of 60, and will therefore tend to restart when there's no active
tunnel traffic.
That means if you really don't want to use keepalive on the server, you
would need to set --ping-restart 0 on the client.
It would probably make sense to issue a warning on the server if either
keepalive or ping is missing.

I think I'd prefer to remove the default --ping-restart 60 on the client
side. I just don't think it makes sence without having the server default
to use --ping xx.
If you want normal keep-alive behaviour, you put --keep-alive in the
server config, and --ping-restart will be pushed to the client. If you
really want the client to ping-restart on inactivity (no --ping on the
server), I think you should specify that in the client config with
--ping-restart (or push it).

Initially I had the same idea, that the client would start with
ping-restart undefined until it pulled a value from the server. But this
doesn't work very well in practice, and there were problem reports on the
list at that time where people were complaining that the OpenVPN client
was locking up. It turns out that the client was starting, but because
ping-restart was not set, if there was any problem during the startup
(prior to options pull), like a dynamic DNS name changing its IP address,
the client wouldn't re-resolve the name because it couldn't restart, and
would therefore lock up until the process was manually restarted.

So I would tend to argue that the client should have a reasonable non-zero
default for ping-restart, since a ping-restart may be needed before the
parameter can be pulled from the server. If you don't want to use it, you
can always disable it with --ping-restart 0.

James

[Mathias Sundman]

Post by James Yonan

Post by Mathias Sundman
I think I'd prefer to remove the default --ping-restart 60 on the
client side. I just don't think it makes sence without having the
server default to use --ping xx.

Initially I had the same idea, that the client would start with
ping-restart undefined until it pulled a value from the server. But
this doesn't work very well in practice, and there were problem reports
on the list at that time where people were complaining that the OpenVPN
client was locking up. It turns out that the client was starting, but
because ping-restart was not set, if there was any problem during the
startup (prior to options pull), like a dynamic DNS name changing its IP
address, the client wouldn't re-resolve the name because it couldn't
restart, and would therefore lock up until the process was manually
restarted.
So I would tend to argue that the client should have a reasonable
non-zero default for ping-restart, since a ping-restart may be needed
before the parameter can be pulled from the server. If you don't want
to use it, you can always disable it with --ping-restart 0.

Okay, that makes sence. Lets just add to the man page that OpenVPN
defaults to a value of 60 for --ping-restart in client mode, and that
--ping-restart can be disabled by setting it to 0.

And perhaps add a warning msg in the server log like you suggested.