1.6 Need access to vpn endpoint network

[tmblue]

So 1.6 changed some stuff

I have my vpn concentrator on network 1.1.1.0/24 (IP's are faked to protect the innocent).

OpenVPN Server is at 1.1.1.11/24
OPenVPN Server hands out IPs from the 10.10.10.0/24 Network

Client connects to 1.1.1.11/24 but is handed a route citing that it should tunnel for any traffic destined to 1.1.1.0/24... VPN throws up it's hands and says forget this and quits. Works perfectly fine in every version for the last 5+ years (longer?) what is 1.6 doing and how can I disable what it's doing?

Feb 18 11:07:21: /sbin/ifconfig utun0 delete
Feb 18 11:07:21: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Feb 18 11:07:21: /sbin/ifconfig utun0 10.10.10.30 10.10.10.29 mtu 1500 netmask 255.255.255.255 up
Feb 18 11:07:21: Initialization Sequence Completed
Feb 18 11:07:21: DNS mode set to: Full
Feb 18 11:07:21: VPN server 1.1.1.11 is not reachable. Route to server points to VPN interface utun0.
Feb 18 11:07:21: Route:1.1.1.0/255.255.255.0 None utun0
Feb 18 11:07:21: VPN server 1.1.1.11 is not reachable. Route to server points to VPN interface utun0.
Feb 18 11:07:21: Route: 1.1.1.0/255.255.255.0 None utun0
Feb 18 11:07:21: SIGTERM[hard,] received, process exiting

Help me Rhonda help help me Rhonda.

[James]

Hi tmblue,

A full copy of your OpenVPN log and raw configuration file would be appreciated to help us debug the issue. Please feel free to censor out any sensitive details before posting these.

Your connection’s raw configuration file can be found at:
Your Home Folder/Library/Application Support/Viscosity/OpenVPN/#/config.conf

The Library folder is hidden under OS X. To get to it you'll need to open the "Go" menu in the Finder while holding down the Option key on your keyboard and click the Library item. Your Library folder will open.

Cheers,
James

[tmblue]

Sure James

#-- Config Auto Generated By Viscosity --#

#viscosity dnssupport true
#viscosity name SV2 1
#viscosity startonopen false
#viscosity usepeerdns true
#viscosity dns full
#viscosity ipv6 false
#viscosity dhcp true
remote 1.1.1.11 443 tcp-client
pull
auth-user-pass
tls-client
tls-auth ta.key 1
persist-key
ca ca.crt
dev tun
persist-tun
cert cert.crt
comp-lzo no
nobind
key key.key
dhcp-option DOMAIN domain.net
mute-replay-warnings
cipher DES-EDE3-CBC
resolv-retry 720
mute 20

LOG with failure

Feb 18 15:13:33: Viscosity Mac 1.6 (1328)
Feb 18 15:13:33: Viscosity OpenVPN Engine Started
Feb 18 15:13:33: Running on Mac OS X 10.10.5
Feb 18 15:13:33: ---------
Feb 18 15:13:33: Checking reachability status of connection...
Feb 18 15:13:33: Connection is reachable. Starting connection attempt.
Feb 18 15:13:34: OpenVPN 2.3.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan 29 2016
Feb 18 15:13:34: library versions: OpenSSL 1.0.2f 28 Jan 2016, LZO 2.09
Feb 18 15:13:39: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Feb 18 15:13:39: Control Channel Authentication: using '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/connection.o7NftN/ta.key' as a OpenVPN static key file
Feb 18 15:13:39: Attempting to establish TCP connection with [AF_INET]1.1.1.11:443 [nonblock]
Feb 18 15:13:40: TCP connection established with [AF_INET]1.1.1.11:443
Feb 18 15:13:40: TCPv4_CLIENT link local: [undef]
Feb 18 15:13:40: TCPv4_CLIENT link remote: [AF_INET]1.1.1.11:443
Feb 18 15:13:40: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Feb 18 15:13:40: [openvpn] Peer Connection Initiated with [AF_INET]1.1.1.11:443
Feb 18 15:13:42: Opened utun device utun0
Feb 18 15:13:42: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Feb 18 15:13:42: /sbin/ifconfig utun0 delete
Feb 18 15:13:42: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Feb 18 15:13:42: /sbin/ifconfig utun0 10.10.10.9 mtu 1500 netmask 255.255.255.255 up
Feb 18 15:13:42: Initialization Sequence Completed
Feb 18 15:13:42: DNS mode set to: Full
Feb 18 15:13:42: VPN server 1.1.1.11 is not reachable. Route to server points to VPN interface utun0.
Feb 18 15:13:42: Route: 1.1.1.0/255.255.255.0 None utun0
Feb 18 15:13:42: VPN server 1.1.1.11 is not reachable. Route to server points to VPN interface utun0.
Feb 18 15:13:42: Route: 1.1.1.0/255.255.255.0 None utun0
Feb 18 15:13:42: SIGTERM[hard,] received, process exiting


And note, that this is due to me sending a route via openvpn.
"push "route 1.1.1.0 255.255.255.0""

Because again I have systems with ACLS on the 1.1.1.0/24 network that can only be accessed via the VPN and thus by servers on the 10.10.10.0/24 (VPN internal Net). On 1.5 this isn't even an issue, works, even now I backed down to 1.5.6 (can't find a 1.5.10 downloadable) and it works, but to allow the connection to remain on 1.6 I have to comment it out in my ccd file on the OpenVPN server.

Thanks!
Tory

[James]

Hi Tory,

Adding the following line to your server (or adding the route to your Viscosity connection) should solve the issue:

Code: Select all

push "route 1.1.1.11 255.255.255.255 net_gateway"

As you know, the clashing routes would normally cause the connection to drop out. However thanks to the stateful nature of TCP, the TCP connection is able to remain active (using UDP instead would fail) despite the updated routing table. The above command sets a direct route to the OpenVPN server, avoiding the clash.

While the above workaround should resolve the issue (and optionally also let you use UDP instead if desired), I'll get back to you to see if this is something we can solve with 1.6. I do remember we added a special case to the reachability detection code in earlier versions of Viscosity to properly handle a TCP edge case like this - I'll see if a regression has occurred.

Cheers,
James

[tmblue]

Thanks James

Yes that allows me to work with 1.6 and I agree seems like some regression somewhere since this is not an issue in earlier versions.

I'll play some more but this solves my issue with upgrading my clients to 1.6.

Thanks
Tory

[James]

Hi Tory,

Glad to hear that solved the issue. We've also pushed out an updated beta version (1.6.1b2 at the time of writing) that should also allow you to connect without the explicit route.

Instructions for updating to beta versions can be found at:
https://www.sparklabs.com/forum/viewtop ... &t=34#p134

Cheers,
James

[tmblue]

Thanks James

I can confirm that I can now connect without the extra route.

Thanks again now go get some sleep, seems you are all over this place!!

Tory