Skip to content
Multiple server connections all routing over single tunnel interface
Got a problem with Viscosity or need help? Ask here!
- Posts: 1
- Joined: Sat Apr 23, 2022 3:19 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.
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!
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
This is clearly incorrect behavior. It's easily fixable by removing the bad route and doing: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
Code: Select all
, but this must be done every time I bring up a second connection in a terminal window. route add -net 10.4.0.0/15 -interface utun11
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!
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
2 posts
Page 1 of 1