Multiple server connections all routing over single tunnel interface

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

markmadsen

Posts: 1
Joined: Sat Apr 23, 2022 3:19 am

Post by markmadsen » Sat Apr 23, 2022 5:59 am
I have Viscosity 1.10.2 (1592) for OS X, and have been using it for quite awhile, but have never been able to make multiple connections (we have development and production VPNs) work. I definitely have the option for not binding local ports on both connections, given forum searches.

Using a single connection works fine, and I can switch between connections with only one active with no trouble. When I start two connections, the first one continues to work, and the second one started does not. Today investigated why, and the problem is in the routing table setup. In the following, I have two tunnel interfaces: utun10 and utun11. utun10 corresponds to the first VPN connection, and routes two networks (10.1/16 and 10.2/16). utun11 corresponds to the second VPN connection and routes a separate network (10.4/15).

Note that in the routing table, however, BOTH sets of VPN connection network routes are mapped to a single tunnel interface, even though two exist. It always routes all VPN traffic over the first TUN interface created.
Code: Select all
Internet:
Destination        Gateway            Flags           Netif Expire
default            192.168.1.254      UGScg             en0
default            link#20            UCSIg          utun10
default            link#21            UCSIg          utun11
10.1/16            172.27.232.1       UGSc           utun10
10.2/16            172.27.232.1       UGSc           utun10
10.4/15            172.27.232.1       UGSc           utun10
54.190.198.246/32  192.168.1.254      UGSc              en0
54.226.240.173/32  192.168.1.254      UGSc              en0
127                127.0.0.1          UCS               lo0
127.0.0.1          127.0.0.1          UH                lo0
169.254            link#6             UCS               en0      !
169.254.1.0        link#6             UHLSW             en0      !
169.254.169.254    link#6             UHRLSW            en0      !
172.27.224/20      172.27.232.1       UGSc           utun10
172.27.232/21      172.27.233.99      UGSc           utun10
172.27.232.254     172.27.232.254     UH             utun11
172.27.233.99      172.27.233.99      UH             utun10
This is clearly incorrect behavior. It's easily fixable by removing the bad route and doing:
Code: Select all
route add -net 10.4.0.0/15 -interface utun11
, but this must be done every time I bring up a second connection in a terminal window.

Two questions: (a) is there some configuration setting which will fix this without a software update? (b) if not, is it possible to request that this be fixed in an upcoming release? Thank you!

James

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

Post by James » Mon Apr 25, 2022 12:51 pm
Hi markmadsen,

The problem here appears to be that there is a clash with the IP ranges the OpenVPN connections are using. Both appear to have a gateway of "172.27.232.1", so are both likely attempting to route the 172.27.232.x IP range which is causing a gateway clash.

Please refer to the following KB article:
https://www.sparklabs.com/support/kb/ar ... taneously/

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
2 posts Page 1 of 1