VPN stopped working after upgrade to 1.7 (connect is OK)

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

guybrush

Posts: 4
Joined: Fri May 26, 2017 10:45 am

Post by guybrush » Fri May 26, 2017 10:56 am
After upgrading Viscosity to 1.7 I cannot use the VPN any longer. Nothing changed besides the Viscosity version (I understand that 1.7 is using a different version of OpenVPN, so this might be related?).

Also I have other devices using a different VPN client (Tunnelblick) and those still work.

I can successfully connect to the server, but then, the connection does not work.

ICMP (ping) to an IP address does work; DNS (should be full tunnel) and "everything else" does not work. Using tcpdump I see packets leaving the tunnel device on the Mac, arrive on the server, be answered (I see the reply go into the tunnel on the server), I think they even arrive on the physical interface on the Mac (1194/udp), but I cannot see them incoming on the tunnel interface on the Mac.

TCP (e.g. telnet to an IP on port 80) does not seem to work at all; I do not event see outgoing packets on the tunnel interface on the Mac.

In the Viscosity log the only "suspicious" entries I see (when connecting, not any longer afterwards) are "DNS change detected, restoring DNS settings".

What am I missing?

James

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

Post by James » Fri May 26, 2017 2:21 pm
Hi guybrush,

As you've already pointed out, Viscosity 1.7 contains an upgraded version of OpenVPN (version 2.4). This changes a number of things, from default cipher settings, compression changes, security changes, and configuration option changes. It's likely you're running into an incompatibility between your current configuration under OpenVPN 2.4 and the server's configuration and/or OpenVPN version.

OpenVPN 2.4 is able to connect to server's running older versions of OpenVPN, and typically you don't need to make any changes. However if the server is running a particularly old version, or a non-standard setup, you may need to make some tweaks to your configuration.

The most common problem in these instances is compression setting differences. It sounds likely in this instance that the client is expecting traffic to be either compressed or uncompressed, while the server is doing the opposite.

Generally for compression errors there should be a warning about a settings mistake when connecting, so check for this in the OpenVPN log in the Details window. Even if there are no messages in the log try editing your connection in Viscosity, going to the Options tab, and changing the "Compression" option to what the server expects. Typically for backwards compatibility setting the option to "LZO" works best, however if that doesn't make a difference try setting it to "Off".

If you're still seeing some traffic fail then it's likely a encryption cipher issue. If you're in control of the OpenVPN server now would be a good time to update to the latest version of OpenVPN and see if that helps. Otherwise you should get in touch with your VPN Provider and see if there are any configuration changes you should make.

Finally, if you're still stuck you can change the OpenVPN version to 2.3 under Preferences->Advanced. Although we only recommend doing that as a temporary measure, as it's likely version 2.3 support will be deprecated later in the year.

Cheers,
James
James Bekkema
Viscosity Developer

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

harald

Posts: 2
Joined: Tue May 23, 2017 7:26 pm

Post by harald » Sat May 27, 2017 2:00 am
Thanks a ton! Changing the setting of the OpenVPN version to use to 2.3 was the only thing that seemed to help in my case:

I wasn't able to ssh into any host after upgrading to 1.7. ssh did not go past
Code: Select all
debug1: SSH2_MSG_SERVICE_REQUEST sent
OpenVPN logs on the appliances did not reveal any useful information ...

guybrush

Posts: 4
Joined: Fri May 26, 2017 10:45 am

Post by guybrush » Sat May 27, 2017 9:50 pm
James wrote:
The most common problem in these instances is compression setting differences.
Well, add one to the most common mistake then :( That was it. I changed from
Code: Select all
comp-lzo no
to
Code: Select all
comp-lzo adaptive
in the advanced settings and the VPN started to work again.

Thank you very much!
guybrush

allengeorge

Posts: 1
Joined: Sun May 28, 2017 3:00 pm

Post by allengeorge » Sun May 28, 2017 3:02 pm
@guybrush: Thanks so much for the tip! Question though: how did you figure out that was the issue? I checked the Viscosity OpenVPN logs, but didn't see any warning or error messages related to compression.

guybrush

Posts: 4
Joined: Fri May 26, 2017 10:45 am

Post by guybrush » Mon May 29, 2017 4:13 pm
allengeorge wrote:
@guybrush: Thanks so much for the tip! Question though: how did you figure out that was the issue? I checked the Viscosity OpenVPN logs, but didn't see any warning or error messages related to compression.
Good point :) I did not see anything in the logs either. I just took a best guess form the information that compression settings mismatches are common and employed good old trial-and-error...

Also I am wondering if I might run into issues later with the "adaptive" scheme. If it currently works "by coincidence" because both sides (the server and the client) decided to compress, this might be different in a future situation and I have the mismatch again.

James

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

Post by James » Mon May 29, 2017 5:19 pm
Also I am wondering if I might run into issues later with the "adaptive" scheme. If it currently works "by coincidence" because both sides (the server and the client) decided to compress, this might be different in a future situation and I have the mismatch again.
What you'll probably want to do is remove the use of the "comp-lzo" command altogether from the advanced commands section, and instead set the "Compression" drop-down menu (under the Options tab) to LZO. This should work by the sound of your server's setup, and will ensure compatibility with future OpenVPN 2.4+ updates.

Of course, if you have the OpenVPN version set to 2.3 the Compression menu should be left on Off (as OpenVPN 2.3 does not support the newer compression command) and continue to use the "comp-lzo" command.

Cheers,
James
James Bekkema
Viscosity Developer

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

guybrush

Posts: 4
Joined: Fri May 26, 2017 10:45 am

Post by guybrush » Wed May 31, 2017 9:29 am
James wrote:
... remove the use of the "comp-lzo" command altogether from the advanced commands section, and instead set the "Compression" drop-down menu (under the Options tab) to LZO.
Thank you for this tip. That is what I have done now. Performance even felt boosted :D.

I set Viscosity to use OpenVPN 2.3 just for a quick test to confirm that the upgrade indeed was what made the connection not work and can confirm that setting it to 2.3 also did "fix" the problem. As pointed out this is rather a kludge though, so I obviously prefer the "real" solution I have now.
8 posts Page 1 of 1