Skip to content
Viscosity and Cisco VPN
Got a problem with Viscosity or need help? Ask here!
- Posts: 2
- Joined: Wed Jul 18, 2018 6:13 am
I wanted to start a new thread since viewtopic.php?t=16 seems to be very old now.
I'm using the latest Viscosity client 1.7.10 and Cisco AnyConnect 4.5.04029 and I'm unable to get both of them to play nicely together. I have to connect to my corp network using Cisco AnyConnect before I can start up Viscosity. The problem is that Viscosity is not able to set up the routes properly when AnyConnect is running. Any recommendations? We really need to get these two applications working at the same time.
I'm using the latest Viscosity client 1.7.10 and Cisco AnyConnect 4.5.04029 and I'm unable to get both of them to play nicely together. I have to connect to my corp network using Cisco AnyConnect before I can start up Viscosity. The problem is that Viscosity is not able to set up the routes properly when AnyConnect is running. Any recommendations? We really need to get these two applications working at the same time.
Hi jaymedrano,
The clash the old forum thread talks about is no longer valid. Back in those days both Viscosity and the Cisco client needed to have their own virtual network interface drivers, which could clash. However since then macOS added inbuilt support, and so the inclusion of drivers is no longer required (with the exception of TAP setups), and so there is no more driver clash.
It sounds likely the routing configuration of your connections themselves may clash (i.e. they both are using the same IP range, or attempting to route the same network range/s though the VPN connection, or attempting to route all traffic through them). I recommend examining the routing table for the connections and see if there are any clashes:
https://www.sparklabs.com/support/kb/ar ... ng-problem
If there are direct IP range clashes (for example both connections want to use 10.0.0.x) then I'm afraid there is no easy way around the problem. The best solution would be to modify one of the setups to use a different IP range or push out routes in a different range.
Cheers,
James
The clash the old forum thread talks about is no longer valid. Back in those days both Viscosity and the Cisco client needed to have their own virtual network interface drivers, which could clash. However since then macOS added inbuilt support, and so the inclusion of drivers is no longer required (with the exception of TAP setups), and so there is no more driver clash.
It sounds likely the routing configuration of your connections themselves may clash (i.e. they both are using the same IP range, or attempting to route the same network range/s though the VPN connection, or attempting to route all traffic through them). I recommend examining the routing table for the connections and see if there are any clashes:
https://www.sparklabs.com/support/kb/ar ... ng-problem
If there are direct IP range clashes (for example both connections want to use 10.0.0.x) then I'm afraid there is no easy way around the problem. The best solution would be to modify one of the setups to use a different IP range or push out routes in a different range.
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
- Posts: 2
- Joined: Wed Jul 18, 2018 6:13 am
I checked the routes that are created by AnyConnect and at this point there aren't any conflicts. It looks like the routes are being added to the wrong interface. I've tried adding the command "route-delay 20" (without quotes) to the commands area (under the Advanced tab) in Viscosity. The network interface should start with "tun" but in my situation it always with "en". Sometimes it'll work when there are multiple connections, or when a connection is closed and restarted. It seems like it's a problem with the ordering.
Code: Select all
172.30 172.155.224.1 UGSc 1 0 en0
Hi jaymedrano,
The interface used by a route depends the gateway address specified for the route: in the case of your example it means that 172.155.224.1 is only reachable by via the en0 interface.
For TAP/bridged interfaces this could mean that the tap interface isn't ready yet (it doesn't have an IP address assigned), which is why route-delay is used. However this doesn't apply to TUN/routed connections. It would have to be the result of a routing clash. Either a route is being added that points 172.155.224.1 through the en0 interface, or 172.155.224.1 isn't reachable through the VPN interface at the time the route is added.
As far as I'm aware there is nothing that would prevent AnyConnect and Viscosity from being able to operate at the same time, as long as the VPN connections themselves don't clash (for example overlapping routes, both trying to route all traffic through their VPN connections, both trying to set the system DNS, etc.).
Cheers,
James
The interface used by a route depends the gateway address specified for the route: in the case of your example it means that 172.155.224.1 is only reachable by via the en0 interface.
For TAP/bridged interfaces this could mean that the tap interface isn't ready yet (it doesn't have an IP address assigned), which is why route-delay is used. However this doesn't apply to TUN/routed connections. It would have to be the result of a routing clash. Either a route is being added that points 172.155.224.1 through the en0 interface, or 172.155.224.1 isn't reachable through the VPN interface at the time the route is added.
As far as I'm aware there is nothing that would prevent AnyConnect and Viscosity from being able to operate at the same time, as long as the VPN connections themselves don't clash (for example overlapping routes, both trying to route all traffic through their VPN connections, both trying to set the system DNS, etc.).
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Sorry to update an old post, but I found this searching on Google and I want to leave two tidbits here.
I've fought over the last year with issues between Viscosity and AnyConnect and this is what worked for me:
hope this helps,
I've fought over the last year with issues between Viscosity and AnyConnect and this is what worked for me:
- AnyConnect is very aggressive regarding routing table handling and breaks some setups. My solution was to switch to OpenConnect (no affiliation, just a happy user http://www.infradead.org/openconnect/ - also available on brew as openconnect-gui). Not only it is much faster to connect, but it also plays nicely with Viscosity;
- on some scenarios with either AnyConnect or OpenConnect, the routing table was left in an inconsistent state and the follow-up connection attempts would result in a "Can't assign requested address" error in the logs. The solution is to identify your main network interface (on my laptop it is en0 that maps to the Wifi adapter, it could be en1 on your case ) and do: sudo /bin/bash -c 'ifconfig en0 down; route flush ; ifconfig en0 up'
hope this helps,
5 posts
Page 1 of 1