Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Original question here: http://apple.stackexchange.com/questions/77245/viscosity-openvpn-tunnelblick-connect-but-all-rdp-connections-go-dead-after-abou

My VPN connection seems to be fine for almost exactly 10 minutes.

Here's the log:

 Jan 08 09:37:05: Viscosity Mac 1.4.2 (1092)
Jan 08 09:37:05: Viscosity OpenVPN Engine Started
Jan 08 09:37:05: Running on Mac OS X 10.8.2
Jan 08 09:37:05: ---------
Jan 08 09:37:05: Checking reachability status of connection...
Jan 08 09:37:05: Connection is reachable. Starting connection attempt.
Jan 08 09:37:08: OpenVPN 2.2.1 x86_64-apple-darwin10.8.0 [SSL] [LZO2] [PKCS11] [eurephia] built on Aug  1 2011
Jan 08 09:37:07: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Jan 08 09:37:07: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 08 09:37:07: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Jan 08 09:37:09: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jan 08 09:37:09: LZO compression initialized
Jan 08 09:37:09: UDPv4 link local (bound): [undef]:1194
Jan 08 09:37:09: UDPv4 link remote: 216.23.154.30:1194
Jan 08 09:37:10: [vpp-vpn001.verrus.com] Peer Connection Initiated with 216.23.154.30:1194
Jan 08 09:37:12: TUN/TAP device /dev/tun0 opened
Jan 08 09:37:12: /sbin/ifconfig tun0 delete
Jan 08 09:37:12: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Jan 08 09:37:12: /sbin/ifconfig tun0 10.103.11.145 10.103.11.146 mtu 1500 netmask 255.255.255.255 up
Jan 08 09:37:12: Initialization Sequence Completed
Jan 08 09:57:15: [vpp-vpn001.verrus.com] Inactivity timeout (--ping-restart), restarting
Jan 08 09:57:15: SIGUSR1[soft,ping-restart] received, process restarting
Jan 08 09:57:16: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Jan 08 09:57:16: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 08 09:57:16: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Jan 08 09:57:16: LZO compression initialized
Jan 08 09:57:16: UDPv4 link local (bound): [undef]:1194
Jan 08 09:57:16: UDPv4 link remote: 216.23.154.30:1194
Jan 08 09:57:17: [vpp-vpn001.verrus.com] Peer Connection Initiated with 216.23.154.30:1194
Jan 08 09:57:19: TUN/TAP device /dev/tun0 opened
Jan 08 09:57:19: /sbin/ifconfig tun0 delete
Jan 08 09:57:19: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Jan 08 09:57:19: /sbin/ifconfig tun0 10.103.11.145 10.103.11.146 mtu 1500 netmask 255.255.255.255 up
Jan 08 09:57:19: Initialization Sequence Completed

It seems to take about 10 minutes for Viscosity to notice that the connection has failed and attempt to renegotiate. My routing table doesn't appear to change. I've attempted and been able to replicate this behavior in both Tunnelblick and Viscosity.

I can actually watch the throughput drop to 0 within 10 seconds of the 10 minute mark.

My theory is that it centers around DHCP lease time but I haven't been able to figure out how to check that on OSX with an OpenVPN tun interface.

share|improve this question

1 Answer 1

Jan 08 09:57:15: [vpp-vpn001.verrus.com] Inactivity timeout (--ping-restart), restarting

From this line it's pretty much clear that there is a idle timeout set on the server side. So, when someone doesn't do anything for 20 minutes (it's not 10 minutes, what I can see from the logs), then the server resets the connection.

Can you please check the server side for this. May be something like keepalive 10 120. Not sure though. That you need to look into server.conf file.

share|improve this answer
    
I thought I wrote this out yesterday. Figured out the problem and it was me. I have multiple machines that I connect from and one of them is a VM that is pretty much always on and always connected. As soon as I turned off that VM everything works fine. –  Gary Jan 11 '13 at 4:15
    
Great. Glad you found the fix. –  GeekRide Jan 11 '13 at 5:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.