Viscosity dropping connection

Got a problem with Viscosity or need help? Ask here!

AlexK

Posts: 8
Joined: Fri Jul 17, 2009 8:08 pm

Post by AlexK » Fri Feb 20, 2015 9:40 pm
I am trying to set up a VPN connection between one of my Azure virtual machines and my Mac mini server.

I set up an Open VPN server on the Azure VM and am now trying to connect to it with Viscosity. Everything works from my Mac Pro, which I used to test the setup. I can ping back and forth, mount drives from the cloud machine on my desktop, etc.

I exported the Viscosity config and imported it into Viscosity 1.5.3 running on my Mac mini (OS X 10.10.2, same as the Mac Pro). I can get a connection to the VPN server on the VM, but Ping doesn't work and soon thereafter the connection drops without any log entry on Viscosity's side.

The server log looks like this:
Code: Select all
Fri Feb 20 10:28:20 2015 TCP connection established with [AF_INET]95.90.136.216:52865
Fri Feb 20 10:28:23 2015 95.90.136.216:52865 TLS: Initial packet from [AF_INET]95.90.136.216:52865, sid=fc90ad77 9e5c7a1c
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 VERIFY OK: depth=1, C=DE, ST=#####, L=#####, O="#####", OU=IT, CN=CA, name=CA, emailAddress=#####
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 VERIFY OK: depth=0, C=DE, ST=#####, L=#####, O="#####", OU=IT, CN=openvpn-cloud-gateway, name=openvpn-cloud-gateway, emailAddress=#####
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Feb 20 10:28:41 2015 95.90.136.216:52865 [openvpn-cloud-gateway] Peer Connection Initiated with [AF_INET]95.90.136.216:52865
Fri Feb 20 10:28:41 2015 openvpn-cloud-gateway/95.90.136.216:52865 OPTIONS IMPORT: reading client specific options from: C:\Program Files\OpenVPN\config\ccd\openvpn-cloud-gateway
Fri Feb 20 10:28:41 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Fri Feb 20 10:28:41 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Learn: 10.8.0.6 -> openvpn-cloud-gateway/95.90.136.216:52865
Fri Feb 20 10:28:41 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: primary virtual IP for openvpn-cloud-gateway/95.90.136.216:52865: 10.8.0.6
Fri Feb 20 10:28:41 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: internal route 192.168.178.0/24 -> openvpn-cloud-gateway/95.90.136.216:52865
Fri Feb 20 10:28:41 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Learn: 192.168.178.0/24 -> openvpn-cloud-gateway/95.90.136.216:52865
Fri Feb 20 10:28:43 2015 openvpn-cloud-gateway/95.90.136.216:52865 PUSH: Received control message: 'PUSH_REQUEST'
Fri Feb 20 10:28:43 2015 openvpn-cloud-gateway/95.90.136.216:52865 send_push_reply(): safe_cap=940
Fri Feb 20 10:28:43 2015 openvpn-cloud-gateway/95.90.136.216:52865 SENT CONTROL [openvpn-cloud-gateway]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.178.1,dhcp-option DOMAIN-SEARCH fritz.box,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)
Fri Feb 20 10:28:46 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:47 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:48 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=30
Fri Feb 20 10:28:49 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:50 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=30
Fri Feb 20 10:28:51 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=40
Fri Feb 20 10:28:52 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:53 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:54 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=30
Fri Feb 20 10:28:55 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:56 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:57 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:28:58 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=84
Fri Feb 20 10:28:59 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:29:00 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=84
Fri Feb 20 10:29:01 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
Fri Feb 20 10:29:02 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=84
Fri Feb 20 10:29:03 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=84
Fri Feb 20 10:29:04 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=84
Fri Feb 20 10:29:11 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=60
Fri Feb 20 10:29:14 2015 openvpn-cloud-gateway/95.90.136.216:52865 Connection reset, restarting [0]
Fri Feb 20 10:29:14 2015 openvpn-cloud-gateway/95.90.136.216:52865 SIGUSR1[soft,connection-reset] received, client-instance restarting
The Viscosity log look like this:
Code: Select all
Feb 20 11:28:18: Viscosity Mac 1.5.3 (1255)
Feb 20 11:28:18: Viscosity OpenVPN Engine Started
Feb 20 11:28:18: Running on Mac OS X 10.10.2
Feb 20 11:28:18: ---------
Feb 20 11:28:18: Checking reachability status of connection...
Feb 20 11:28:19: Connection is reachable. Starting connection attempt.
Feb 20 11:28:19: OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Dec  3 2014
Feb 20 11:28:19: library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Feb 20 11:28:20: Attempting to establish TCP connection with [AF_INET]191.233.94.147:1194 [nonblock]
Feb 20 11:28:23: TCP connection established with [AF_INET]191.233.94.147:1194
Feb 20 11:28:23: TCPv4_CLIENT link local: [undef]
Feb 20 11:28:23: TCPv4_CLIENT link remote: [AF_INET]191.233.94.147:1194
Feb 20 11:28:41: [openvpn-server] Peer Connection Initiated with [AF_INET]191.233.94.147:1194
Feb 20 11:28:43: TUN/TAP device /dev/tun0 opened
Feb 20 11:28:43: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Feb 20 11:28:43: /sbin/ifconfig tun0 delete
Feb 20 11:28:43: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Feb 20 11:28:43: /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
Feb 20 11:28:43: Initialization Sequence Completed
The connection seems to drop when I try to ping from the VM to the Mac mini, but not the other way round, which leads me to think that the server is at fault. But this is all pretty much greek to me, so who knows…

James

User avatar
Posts: 2083
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sun Feb 22, 2015 4:32 pm
Hi AlexK,

The problem does appear to lie with the server, notably these lines:
Code: Select all
Fri Feb 20 10:28:46 2015 openvpn-cloud-gateway/95.90.136.216:52865 MULTI: Outgoing TUN queue full, dropped packet len=235
However I'm afraid I'm not familiar enough with server-side problems to be able to give you a definite answer of what may be causing the problem. I'd first recommend checking that your Mac Pro and Mac Mini aren't somehow clashing (i.e. if you have them connected at the same time one may be dropping due to a conflicted certificate, or they both could be attempting to have the same VPN IP address due to CCD settings, etc.). After that I'd recommend looking at things like firewall and packet filter rules on the server's TUN interface to make sure it isn't blocking your Mac Mini's traffic.

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
2 posts Page 1 of 1