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
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
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.
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?
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
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:
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.
Connect to the VPN connection.
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”
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”
When you’re done testing, edit your connection again and remove the “route-nopull” command added earlier.
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?
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:
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):
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.
Connect to the VPN connection.
Open the Terminal application (located at /Applications/Utilities/Terminal) and run the following commands (without the quotes) and see if there is a delay:
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
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:
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:
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:
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!
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:
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).
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.
SparkLabs Newsletter
Thank you for being interested in keeping up with the latest news from us! Please double-check your email address below and then click the Subscribe button.
(and I’m trying to get everyone at work on it!) … I’m on Version 1.8 (1505)