Viscosity disconnects upon trying to set DNS routes

mgrandi · 16 February 2016 21:58

So yesterday, everything was fine, but then today, I can’t connect to my company’s VPN , and in the viscosity logs:

Feb 16 14:40:19: Viscosity Mac 1.6 (1328)
Feb 16 14:40:19: Viscosity OpenVPN Engine Started
Feb 16 14:40:19: Running on Mac OS X 10.11.3
Feb 16 14:40:19: ---------
Feb 16 14:40:19: Checking reachability status of connection...
Feb 16 14:40:19: Connection is reachable. Starting connection attempt.
Feb 16 14:40:21: OpenVPN 2.3.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan 29 2016
Feb 16 14:40:21: library versions: OpenSSL 1.0.2f  28 Jan 2016, LZO 2.09
Feb 16 14:40:30: Control Channel Authentication: using '/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/connection.hoXCKT/ta.key' as a OpenVPN static key file
Feb 16 14:40:30: Attempting to establish TCP connection with [AF_INET]IPHERE:1194 [nonblock]
Feb 16 14:40:31: TCP connection established with [AF_INET]IPHERE:1194
Feb 16 14:40:31: TCPv4_CLIENT link local (bound): [undef]
Feb 16 14:40:31: TCPv4_CLIENT link remote: [AF_INET]IPHERE9:1194
Feb 16 14:40:31: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Feb 16 14:40:32: [gateway-v01-1.servercert] Peer Connection Initiated with [AF_INET]IPHERE:1194
Feb 16 14:40:35: Opened utun device utun0
Feb 16 14:40:35: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Feb 16 14:40:35: /sbin/ifconfig utun0 delete
Feb 16 14:40:35: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Feb 16 14:40:35: /sbin/ifconfig utun0 10.10.10.130 10.10.10.129 mtu 1500 netmask 255.255.255.255 up
Feb 16 14:40:35: Initialization Sequence Completed
Feb 16 14:40:35: DNS mode set to: Split
Feb 16 14:40:35: VPN server IPHERE is not reachable. Route to server points to VPN interface utun0.
Feb 16 14:40:35: Route: IPHERE/255.255.255.224 None utun0
Feb 16 14:40:35: VPN server IPHERE is not reachable. Route to server points to VPN interface utun0.
Feb 16 14:40:35: Route: IPHERE/255.255.255.224 None utun0
Feb 16 14:40:35: VPN server IPHERE is not reachable. Route to server points to VPN interface utun0.
Feb 16 14:40:35: Route: IPHERE/255.255.255.224 None utun0
Feb 16 14:40:35: VPN server IPHERE is not reachable. Route to server points to VPN interface utun0.
Feb 16 14:40:35: Route: IPHERE/255.255.255.224 None utun0
Feb 16 14:40:35: SIGTERM[hard,] received, process exiting

If i set viscosity to disable DNS, then it connects fine.

the sysadmin says that I am connecting and authenticating fine:

Feb 16 20:49:20 openvpn[12371]: TCP connection established with [AF_INET]IPHERE:48206
Feb 16 20:49:22 openvpn[12604]: pam_krb5(openvpn): user mgrandi authenticated as mgrandi@WHATEVER
Feb 16 20:49:22 openvpn: user 'mgrandi' authenticated
Feb 16 20:49:22 openvpn[12371]: IPHHERE:48206 [mgrandi] Peer Connection Initiated with [AF_INET]IPHERE:48206
Feb 16 20:49:22 openvpn[12371]: mgrandi/IPHERE:48206 MULTI_sva: pool returned IPv4=10.10.10.18, IPv6=(Not enabled)

any idea?

James · 16 February 2016 23:19

Hi mgrandi,

That’s quite strange - Split DNS mode shouldn’t have any impact on your computer’s routing table. Indeed the option hasn’t really changed (on the Mac) since the previous release (Full DNS mode is a different story).

It would be greatly appreciated if you could preferably email us, or alternatively post here, copies of the OpenVPN configuration files for both the client (Viscosity) and the OpenVPN server (if possible). If posting them on the forum please censor out any sensitive details first. This will allow us to hopefully replicate the setup and see if we can find the cause.

You can find the config file for your connection 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

mgrandi · 17 February 2016 00:24

I’ll see if i can get the copy of the config file from the head sysadmin. As a note, tunnelblick seems to work fine with the same .ovpn configuration profile, which makes this even more strange .

#-- Config Auto Generated By Viscosity --#

#viscosity name sigfig
#viscosity usepeerdns true
#viscosity startonopen false
#viscosity dns automatic
#viscosity ipv6 false
#viscosity dhcp true
remote <IP HERE> 1194 tcp-client
pull
auth-user-pass
tls-client
ns-cert-type server
tls-auth ta.key 1
persist-key
ca ca.crt
dev tun
persist-tun
cert cert.crt
comp-lzo adaptive
key key.key
verify-x509-name "gateway-v01-1.servercert" name
lport 0
cipher AES-256-CBC
resolv-retry infinite
auth SHA1

mgrandi · 17 February 2016 22:44

I’m having problems getting access to the server openvpn connection since I don’t actually have access to the box that its on, is the client configuration enough?

James · 18 February 2016 15:06

Hi mgrandi,

It looks like most options are getting pushed from the OpenVPN server, so unfortunately the configuration file doesn’t reveal much. If you can’t get access to the server configuration file then a more verbose copy of your client log would be appreciated, as this will list the options being sent.

You can increase the verbosity by editing your connection in Viscosity, clicking on the Advanced tab, and adding the command “verb 5” on a new line (with the quotes) on a new line in the commands area. Click Save, connect as normal, and then you can copy the updated log from the Details window.

I recommend emailing this to us, us there is probably too full to censor for posting on the forums (and we do need to get an idea of the routes/subnets being pushed to see what is clashing).

Once sent, I’d recommend removing the verb 5 command from your configuration, as otherwise the log will fill up quickly.

Cheers,
James

user5 · 18 February 2016 17:40

Viscosity 1.6 (Mac) definitely has DNS problems. In Split mode (or Automatic), internal looks simply fail. In Full mode, we experience this problem, where Viscosity erroneously detects a routing loop. In Split mode, routing works fine, and DNS lookups work by manually specifying the internal DNS server (“host foo.bar.lan 10.x.x.x” for example), but fail for general internal lookups. Note that our internal DNS records are in a zone (.lan) that does not exist in public DNS – that could be related.

== Server config ==

mode server
opt-verify
dev tap5015
script-security 2
proto udp
lport 5015
management 127.0.0.1 5015
float
comp-lzo
ping 3

tls-server
dh dh.pem
ca ca.crt
crl-verify ca.crl
cert openvpn.crt
key openvpn.key
reneg-bytes 0
reneg-pkts 0
reneg-sec 0

ifconfig-pool 10.0.129.8 10.0.129.255 255.255.0.0
ifconfig-pool-persist /tmp/openvpn_test.ifconfig_pool 1

verb 3
mute 20
mute-replay-warnings
mlock
user nobody
group nobody
persist-tun
persist-key
status /tmp/openvpn_test.status 1
status-version 3

push “ping 3”
push “ping-restart 10” # seconds

push “route 10.160.0.0 255.240.0.0 10.0.0.1”
push “route 10.173.0.0 255.255.0.0 10.0.128.0”
push “route 10.192.0.0 255.255.0.0 10.0.128.0”
push “route 73.13.0.0 255.255.0.0 10.0.0.1”
push “route 192.168.168.0 255.255.255.0 10.0.0.1”
push “route 192.168.254.0 255.255.255.0 10.0.0.218”

push “dhcp-option DNS 10.0.0.222”
push “dhcp-option DNS 10.0.0.111”

== Client config ==

dev tap
nobind
comp-lzo
resolv-retry infinite
pull
float

tls-client
ca ca.crt
cert mycert.crt
key mycert.key
verify-x509-name vpn.x.com name
reneg-bytes 0
reneg-pkts 0
reneg-sec 0

verb 3
mute 20
mute-replay-warnings
mlock
persist-tun
persist-key

remote vpn.x.com 1194 udp

== Client log ==

Feb 18 11:34:18: Viscosity Mac 1.6 (1328)
Feb 18 11:34:18: Viscosity OpenVPN Engine Started
Feb 18 11:34:18: Running on Mac OS X 10.10.5
Feb 18 11:34:18: ---------
Feb 18 11:34:18: Checking reachability status of connection…
Feb 18 11:34:18: Connection is reachable. Starting connection attempt.
Feb 18 11:34:18: OpenVPN 2.3.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan 29 2016
Feb 18 11:34:18: library versions: OpenSSL 1.0.2f 28 Jan 2016, LZO 2.09
Feb 18 11:34:19: WARNING: mlockall call failed: Function not implemented (errno=78)
Feb 18 11:34:21: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Feb 18 11:34:21: UDPv4 link local: [undef]
Feb 18 11:34:21: UDPv4 link remote: [AF_INET]96.3.205.0:5015
Feb 18 11:34:21: [vpn.x.com] Peer Connection Initiated with [AF_INET]96.3.205.0:5015
Feb 18 11:34:23: TUN/TAP device /dev/tap0 opened
Feb 18 11:34:23: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Feb 18 11:34:23: /sbin/ifconfig tap0 delete
Feb 18 11:34:23: NOTE: Tried to delete pre-existing tun/tap instance – No Problem if failure
Feb 18 11:34:23: /sbin/ifconfig tap0 10.0.129.8 netmask 255.255.0.0 mtu 1500 up
Feb 18 11:34:23: Initialization Sequence Completed
Feb 18 11:34:24: DHCP enabled on tap interface tap0
Feb 18 11:34:24: DNS mode set to: Full
Feb 18 11:34:24: Disabling DHCP on interface tap0 (not required)
Feb 18 11:34:25 DNS change detected, restoring DNS settings
Feb 18 11:34:29: VPN server 96.3.205.0 is not reachable. Route to server points to VPN interface tap0.
Feb 18 11:34:29: Route: 0.0.0.0/0.0.0.0 None tap0
Feb 18 11:34:29: VPN server 96.3.205.0 is not reachable. Route to server points to VPN interface tap0.
Feb 18 11:34:29: Route: 96.3.205.0/32 None tap0
Feb 18 11:34:29: SIGTERM[hard,] received, process exiting

James · 18 February 2016 19:03

Hi [email protected],

You appear to be using a TAP connection - please see here:
https://www.sparklabs.com/forum/t/viscosity-loses-connection-after-70-seconds/1126/1

Cheers,
James

user5 · 18 February 2016 19:30

Thanks, just tried unchecking “Enable DHCP”, to no avail. In TAP mode, no combination of “Enable DHCP” or Full or Split mode works. While unchecking “Enable DHCP” in TAP mode indeed fixes the erroneous detection of the routing loop, DNS still fails.

I also have a TUN mode server, and with it DNS lookups fail in in Split mode but succeed in Full mode.

Sorry, I don’t have time today to try the beta version. Sounds like we’re chasing two bugs, and it sounds like you’re suggesting that the disconnect bug is fixed in beta. I would think there’s still a bug with DNS in TAP mode and in TUN mode with the Split option.

James · 18 February 2016 20:52

Hi [email protected],

Split DNS mode requires that you set one or more domains, however there don’t appear to be any being pushed from the OpenVPN server or set locally in the client configuration. This means that the VPN set DNS servers won’t be getting used for any lookups. If you wish to use split mode you should set one or more DNS Domains to be associated with the connection. Please refer to the documentation at: http://www.sparklabs.com/support/kb/article/configuring-dns-and-wins-settings/

You can get away with not pushing any DNS Domains in Full DNS mode, however as you’re not routing all traffic through the VPN connection Split DNS mode is probably what you are after.

Cheers,
James

user5 · 18 February 2016 21:34

And as I already said, DNS doesn’t work in Full mode either (with TAP, unchecked “Enable DHCP” to work around the disconnection bug, and no domain pushed), so no, you can’t get away without pushing domains in Full mode.

Further, if Split mode requires a domain to be specified, then the Automatic setting is broken. Automatic must choose Full mode when there’s no domain pushed.

So this apparently breaks down into three bugs as follows.

Disconnecting (fixed in beta).
Automatic must choose Full when no domain is specified.
DNS doesn’t work in Full mode for TAP when no domain is specified.

markus.moldaschl · 19 February 2016 08:08

Hi,

I use Viscosity for a couple of years now and never had to care about DNS settings. Now, after the update to 1.6 I need to configure the IP of the VPNs DNS server and the the domain, otherwise it won’t resolve the proper ip addresses. After looking into the logs I found out that the VPN server does not push the domain.

I think I understood the DNS related changes in 1.6 but I’m still wondering how did viscosity know the domain before 1.6?

Thx
Markus

James · 19 February 2016 15:21

Hi Markus,

Viscosity wouldn’t have known about the domain previously if it weren’t being pushed or specified locally. It’s more likely that your connection was running in Full DNS mode (the default for previous versions unless the “Apply DNS settings simultaneously” option had been ticked) and so all DNS requests were being sent to the VPN server, not just requests for the remote network.

Cheers,
James

mgrandi · 19 February 2016 22:10

Logs were sent to email

mgrandi · 19 February 2016 23:14

Upgrading to the beta version 1.6.1b2 worked for me

in case anyone is wondering, the problem was the server was sending a route that clashed with the actual IP address of the vpn server itself

see https://www.sparklabs.com/forum/t/1-6-need-access-to-vpn-endpoint-network/1128/1