why did you change ping-restart to 45?
I use static-office.conf sample (/usr/share/doc/packages/openvpn/sample-config-files/static-office.conf) in which ping-restart was set to 45. So I didn't deliberately reduce it. I use this rpm for installing openvpn in my client system:
http://download.opensuse.org/distribution/12.2/repo/oss/suse/x86_64/openvpn-2.2.2-3.1.2.x86_64.rpm.mirrorlist. On the other hand I check satic-office.conf in my server (CentOS 5.8); it was 45.
are you using oversized icmp packages?
No, I'm not. For example if just after establishing connection with server I only ping it, after about 17 pings the connection stalled:
ping -c 20 10.8.2.1
PING 10.8.2.1 (10.8.2.1) 56(84) bytes of data.
64 bytes from 10.8.2.1: icmp_seq=1 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=2 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=3 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=4 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=5 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=6 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=7 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=8 ttl=64 time=399 ms
64 bytes from 10.8.2.1: icmp_seq=9 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=10 ttl=64 time=397 ms
64 bytes from 10.8.2.1: icmp_seq=11 ttl=64 time=397 ms
64 bytes from 10.8.2.1: icmp_seq=12 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=13 ttl=64 time=397 ms
64 bytes from 10.8.2.1: icmp_seq=14 ttl=64 time=397 ms
64 bytes from 10.8.2.1: icmp_seq=15 ttl=64 time=395 ms
64 bytes from 10.8.2.1: icmp_seq=16 ttl=64 time=396 ms
64 bytes from 10.8.2.1: icmp_seq=17 ttl=64 time=397 ms
--- 10.8.2.1 ping statistics ---
20 packets transmitted, 17 received, 15% packet loss, time 19019ms
rtt min/avg/max/mdev = 395.898/396.857/399.007/1.078 ms
My OS ping document says:
-s packetsize
Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header
data.
if you simply ssh to the other side,is it stop responding too?
Do you mean ssh to server's public ip or 10.8.2.1? If you mean public server ip, in that case there is not any problem because I can see in my route table that any connection to my server's public ip is not going through vpn conneciton.
If you mean sshing into 10.8.2.1 just after establishing vpn connection, then I can't even ssh into server.
I've noticed if just after establishing connection with vpn server, I've activities like sshing into 10.8.2.1 or at least 17 times pinging 10.8.2.1 or surfing the Net, the connection will stall.
you have only ONE client...right?
Yes.
