Can't connect, loops with "Connection reset, restarting [0]"

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

jg3

Posts: 4
Joined: Tue Aug 06, 2013 1:01 am

Post by jg3 » Mon Sep 22, 2014 11:10 pm
Hi,

I've been using Viscosity regularly for over a year. Recently, I'm reasonably sure (but not certain) it was around the time I allowed the upgrade to 1.5x, I lost the ability to access my pfSense/OpenVPN system. It never gets out of "connecting" state. The log entries are below, but I don't know what to make of them. I tried in vain to re-install 1.5.1 on top of the existing install. I have reviewed and checked the settings on the OpenVPN server (which haven't changed in months) to make sure they appear correct (they do).

Although it is stored in my keychain, I verified my username/password is correct (it is). Incidentally, the same behavior occurs when I try using an incorrect password.


Code: Select all
Sep 21 15:05:53: Viscosity Mac 1.5.1 (1232)
Sep 21 15:05:53: Viscosity OpenVPN Engine Started
Sep 21 15:05:53: Running on Mac OS X 10.9.5
Sep 21 15:05:53: ---------
Sep 21 15:05:53: Checking reachability status of connection...
Sep 21 15:05:53: Connection is reachable. Starting connection attempt.
Sep 21 15:05:55: OpenVPN 2.3.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Aug 26 2014
Sep 21 15:06:11: Control Channel Authentication: using '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/connection.5BcI9f/ta.key' as a OpenVPN static key file
Sep 21 15:06:11: Attempting to establish TCP connection with [AF_INET]xx.xxx.yyy.zz:443 [nonblock]
Sep 21 15:06:12: TCP connection established with [AF_INET]xx.xxx.yyy.zz:443
Sep 21 15:06:12: TCPv4_CLIENT link local: [undef]
Sep 21 15:06:12: TCPv4_CLIENT link remote: [AF_INET]xx.xxx.yyy.zz:443
Sep 21 15:06:12: Connection reset, restarting [0]
Sep 21 15:06:12: SIGUSR1[soft,connection-reset] received, process restarting
Sep 21 15:06:12: Attempting to establish TCP connection with [AF_INET]xx.xxx.yyy.zz:443 [nonblock]
Sep 21 15:06:13: TCP connection established with [AF_INET]xx.xxx.yyy.zz:443
Sep 21 15:06:13: TCPv4_CLIENT link local: [undef]
Sep 21 15:06:13: TCPv4_CLIENT link remote: [AF_INET]xx.xxx.yyy.zz:443
Sep 21 15:06:13: Connection reset, restarting [0]
Sep 21 15:06:13: SIGUSR1[soft,connection-reset] received, process restarting
Sep 21 15:06:14: Attempting to establish TCP connection with [AF_INET]xx.xxx.yyy.zz:443 [nonblock]
Sep 21 15:06:15: TCP connection established with [AF_INET]xx.xxx.yyy.zz:443
Sep 21 15:06:15: TCPv4_CLIENT link local: [undef]
Sep 21 15:06:15: TCPv4_CLIENT link remote: [AF_INET]xx.xxx.yyy.zz:443
Sep 21 15:06:15: Connection reset, restarting [0]
Sep 21 15:06:15: SIGUSR1[soft,connection-reset] received, process restarting

James

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

Post by James » Mon Sep 22, 2014 11:34 pm
Hi jg3,

It appears you are able to initiate a connection, however it is then being disconnected. The most likely explanation is that the OpenVPN server is disconnecting you - I'd recommend checking the OpenVPN log in pfSense and see if it contains more information.

Other things to check include making sure that any firewall or network security software isn't terminating the connection attempt (try temporarily disabling it and see how you go), and that your server supports connections from OpenVPN 2.3 (Viscosity 1.5 dropped support for OpenVPN 2.2). OpenVPN 2.3 is backwards compatible with servers running an older version, however we do occasionally see compatibility issues, so it may be worth updating the version of OpenVPN and/or pfSense if you're still stuck.

Cheers,
James
James Bekkema
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

jg3

Posts: 4
Joined: Tue Aug 06, 2013 1:01 am

Post by jg3 » Tue Sep 23, 2014 12:02 am
Thanks, James. I found/fixed the issue. A boneheaded mistake and the firewall admin responsible for the err* has been reprimanded and put into time-out for a while.

The firewall rule for incoming 443\tcp traffic was disabled, sure, but the NAT rule was still in place and getting in the way of connecting to the openVPN daemon on the firewall itself.

Also, as a correction, when I fixed that problem and put in an incorrect password, Viscosity popped up a message telling me the credentials didn't jive (as I would expect).

Thanks for the help,

--jg3
3 posts Page 1 of 1