Viscosity connection establishes slower than open vpn

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

rizjoj

Posts: 5
Joined: Sat Sep 14, 2019 6:03 am

Post by rizjoj » Sat Sep 14, 2019 6:15 am
Hi,

First of all: I LOOOOVE Viscosity :) (and I'm trying to get everyone at work on it!) ... I'm on Version 1.8 (1505)

The one thing that makes me sad is that the the OpenVpn client establishes the connection almost immediately after I enter the 2FA code where as in Viscosity I have to wait almost 10 seconds for the connection to establish after entering the 2FA code (This is even after updating to the latest). This is consistent across the 3 VPN networks we use at work. Once connected, though, everything is fine. I imported the .ovpn profile file and tweaked the dns to get everything working right.

Is there a config setting I need to do to fix this?

rcvbuf 100000
sndbuf 100000
setenv FORWARD_COMPATIBLE 1
setenv opt tls-version-min 1.0 or-highest
setenv PUSH_PEER_INFO
reneg-sec 604800
comp-lzo no
server-poll-timeout 4
ns-cert-type server
static-challenge "Enter Google Authenticator Code" 1

James

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

Post by James » Sun Sep 15, 2019 1:48 pm
Hi rizjoj,

I'd recommend seeing where exactly the delay lies: look at the OpenVPN log and look at the time between each line. I'd also recommend increasing the log verbosity to level 3 so you have a few more details. You can increase the log verbosity by adding the command "verb 3" (without the quotes) on a new line in the advanced commands section for your connection:
https://www.sparklabs.com/support/kb/article/advanced-configuration-commands/#specifying-advanced-configuration-commands

And instructions for how to view the OpenVPN log. Please feel free to posted a censored version of your log if you'd like our opinion on any of the times.
https://www.sparklabs.com/support/kb/article/viewing-the-openvpn-log/

However, there is an important difference to note here: your Viscosity connection is configured to use a "static-challenge", while by default the OpenVPN-AS client will use a "dynamic-challenge". The difference here is that you'll be prompted for your two-factor credentials immediately (before even actually being connected to the VPN server) with a static-challenge, while with a dynamic-challenge you won't be prompted until after you have connected and the server requests your two-factor credentials.

What this means in practice is that when connecting your Viscosity connection all of the time associated with establishing a connection, waiting for the server to authenticate you, etc. will come *after* the Google Authenticator prompt. While with the other client much of this delay will come *before* the prompt.

Cheers,
James
James Bekkema
Viscosity Developer

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

rizjoj

Posts: 5
Joined: Sat Sep 14, 2019 6:03 am

Post by rizjoj » Tue Sep 17, 2019 4:36 am
Thanks James,

I added the "verb 3" and I see more in the logs than I could before. There are two delays - the first one is it waiting on me to enter the 2FA from google authenticator ... the 2nd one is the one that varies from 5-10 seconds. It consistently shows it waiting after the "/sbin/route add -net 172.27.236.0 172.27.238.200 255.255.252.0" log. Is there anything I can do (on the client side) to reduce this delay?
Code: Select all
2019-09-16 14:31:30: Opened utun device utun10
2019-09-16 14:31:30: /sbin/ifconfig utun10 delete
2019-09-16 14:31:30: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2019-09-16 14:31:30: /sbin/ifconfig utun10 172.27.238.200 172.27.238.200 netmask 255.255.252.0 mtu 1500 up
2019-09-16 14:31:30: /sbin/route add -net 172.27.236.0 172.27.238.200 255.255.252.0
2019-09-16 14:31:36: /sbin/route add -net 34.202.255.184 192.168.1.1 255.255.255.255
2019-09-16 14:31:36: /sbin/route add -net 172.27.224.0 172.27.236.1 255.255.240.0
2019-09-16 14:31:36: /sbin/route add -net 10.0.0.0 172.27.236.1 255.255.0.0
2019-09-16 14:31:36: Initialization Sequence Completed
2019-09-16 14:31:36: DNS mode set to Split
2019-09-16 14:31:37: State changed to Connected
Thanks,
Riz.

James

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

Post by James » Tue Sep 17, 2019 4:51 pm
You are correct in that the delay appears to be associated with the "/sbin/route add -net 172.27.236.0 172.27.238.200 255.255.252.0" command. This line indicates the command being run to add the associated network route to the computer's routing table.

This is processed by macOS, so it's highly unusual for there to be a delay associated with it. I recommend you try running the command manually and see if there is the same delay. The steps for doing this:

1. Edit your connection in Viscosity, go to the Advanced tab, and add the command "route-nopull" (without the quotes) on a new line in the advanced commands area. This will cause OpenVPN to ignore the routes being sent by the server.

2. Connect to the VPN connection.

3. Open the Terminal application (located at /Applications/Utilities/Terminal) and run the following command (without the quotes). You'll need to enter your computer account's password: if the command runs properly afterwards it should return instantly. If it takes a few seconds then something is amiss.
"sudo route add -net 172.27.236.0 172.27.238.200 255.255.252.0"

4. If it takes a few seconds, try running it with verbose mode to see if there is any information available:
"sudo route -v add -net 172.27.236.0 172.27.238.200 255.255.252.0"

5. When you're done testing, edit your connection again and remove the "route-nopull" command added earlier.

Cheers,
James
James Bekkema
Viscosity Developer

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

rizjoj

Posts: 5
Joined: Sat Sep 14, 2019 6:03 am

Post by rizjoj » Wed Sep 18, 2019 6:09 am
Hi James,

I tried the "route-nopull" in advanced settings and it still took 6 seconds at the "route add" command. However, if I try it on the command line it returns instantly. In fact it returns instantly whether I'm connected to the VPN connection or not. (if I'm not connected, it doesn't complain that the file already exists). Anything else I could try?

Thanks,
Riz.
Code: Select all
sudo /sbin/route -v add -net 172.27.228.0 172.27.228.183 255.255.252.0
u: inet 172.27.228.0; u: inet 172.27.228.183; u: inet 255.255.252.0; RTM_ADD: Add Route: len 132, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 172.27.228.0 172.27.228.183 255.255.252.0
route: writing to routing socket: File exists
add net 172.27.228.0: gateway 172.27.228.183: File exists

James

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

Post by James » Fri Sep 20, 2019 8:14 pm
Hi rizjoj,

Sadly the route still won't be getting blocked from getting added by OpenVPN using the "route-nopull" command, as it's actually the subnet route for the ifconfig command. This is why your attempt to manually add the route is returning instantly with an error that the route already exists.

This makes it a little tricker to diagnose what is going on. I suggest you try connecting to your VPN connection, and then deleting and re-adding the route to see if that triggers the delay (it's unlikely, but worth a try). You can do this by entering something like so into the Terminal:
Code: Select all
sudo route delete -net 172.27.236.0 172.27.238.200 255.255.252.0
sudo route add -net 172.27.236.0 172.27.238.200 255.255.252.0

If that returns instantly, you can try blocking the ifconfig command in OpenVPN (which will stop it setting the IP address for your connection), and then setting the IP address and route manually to see if you get the delay. This can be done like so (assuming your assigned IP address is the same):

1. Edit your connection in Viscosity, go to the Advanced tab, and add the command "pull-filter ignore ifconfig" (without the quotes) on a new line in the advanced commands area. Click Save.
2. Connect to the VPN connection.
3. Open the Terminal application (located at /Applications/Utilities/Terminal) and run the following commands (without the quotes) and see if there is a delay:
Code: Select all
sudo ifconfig utun10 172.27.238.200 172.27.238.200 netmask 255.255.252.0 mtu 1500 up
sudo route add -net 172.27.236.0 172.27.238.200 255.255.252.0
Cheers,
James
James Bekkema
Viscosity Developer

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

rizjoj

Posts: 5
Joined: Sat Sep 14, 2019 6:03 am

Post by rizjoj » Tue Sep 24, 2019 4:01 am
Hi James,

So I tried all the commands on the terminal, and they returned almost immediately. (even using the updated IPs from Viscosity's "Details..." log).

So I tried the "pull-filter ignore ifconfig" advanced command and I saw something a bit different in the logs:
Code: Select all
2019-09-23 13:53:32: Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
2019-09-23 13:53:32: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
2019-09-23 13:53:32: Opened utun device utun10
2019-09-23 13:53:38: /sbin/route add -net 34.202.255.184 192.168.1.1 255.255.255.255
2019-09-23 13:53:38: /sbin/route add -net 172.27.224.0 172.27.236.1 255.255.240.0
2019-09-23 13:53:38: /sbin/route add -net 10.0.0.0 172.27.236.1 255.255.0.0
2019-09-23 13:53:38: Initialization Sequence Completed
2019-09-23 13:53:38: DNS mode set to Split
2019-09-23 13:53:38: State changed to Connected
So "Opened utun device utun10" took 6 seconds.

And then I ran, on the terminal:
Code: Select all
sudo /sbin/ifconfig utun10 172.27.239.22 172.27.239.22 netmask 255.255.252.0 mtu 1500 up
sudo /sbin/route add -net 172.27.236.0 172.27.239.22 255.255.252.0
and got:
Code: Select all
add net 172.27.236.0: gateway 172.27.239.22
almost instantly.

I also uninstalled my other open vpn client installation completely just in case there was something going on there that was affecting the connection settings here (but that was a long shot anyway).

Thanks for trying though, I'll let you decide if you want to try anything more but I suppose I can live with a 5-6 second delay if it's this involved. I appreciate the support - that alone makes the paid version well worth it!

Thanks,
Riz.

James

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

Post by James » Mon Sep 30, 2019 9:51 am
Hi Riz,

It's interesting that the delay is still occurring: at this point I'm convinced the server must be pushing a "route-delay" command (which is completely unnecessary, at least in regards to Viscosity). Try restoring your connection back to normal, and then add the following command to the advanced commands area:
Code: Select all
pull-filter ignore route-delay
Also make sure a "route-delay" command isn't present in the advanced commands area (there isn't one listed in your original post, but it doesn't hurt to double-check).

If the above command works and removes the delay, then it means the server has "push 'route-delay 5'" or something similar in its configuration file. This likely should be removed (if you're in control of the OpenVPN server).

Cheers,
James
James Bekkema
Viscosity Developer

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

rizjoj

Posts: 5
Joined: Sat Sep 14, 2019 6:03 am

Post by rizjoj » Tue Oct 01, 2019 3:38 am
Hi James,

Bingo! That was it! Let me see if I can work with our IT/DevOps team to have them remove the uneccessary "push route-delay" command. I'm a happy camper now - and I love Viscosity even more now! :)

Thanks for persisting!
Riz.
9 posts Page 1 of 1