SparkLabs Forum.

Community Help.


MacOS Sierra Tap

I am attempting to get viscosity working since I've upgraded to Sierra. Everything used to work just fine under Yosemite but since the upgrade I have not been able to get routing to work. I am able to ping/traceroute the vpn server from the client, once connected, but ping/traceroute a server on the same network as the vpn server (192.168.10.23) blackholes at 192.168.20.1. Thoughts? Any help would be greatly appreciated! I've included everything I could think of below, if there is anything else you need let me know.

Code: Select all

Server Lan: 192.168.10.0/24
VPN CIDR: 192.168.20.0/24
Client Lan: 10.40.5.0


Server Config

Code: Select all

# Automatically generated configuration
daemon
server 192.168.20.0 255.255.255.0
proto udp
port 1194
dev tun21
comp-lzo adaptive
keepalive 15 60
verb 3
push "route 192.168.10.0 255.255.255.0"
client-config-dir ccd
client-to-client=
status-version 2
status status


Viscosity Config

Code: Select all

#-- Config Auto Generated By Viscosity --#

#viscosity dnssupport true
#viscosity name xxx
#viscosity startonopen true
#viscosity usepeerdns true
#viscosity dns split
#viscosity ipv6 false
#viscosity dhcp true
remote xxx.net 1194 udp
persist-key
tls-client
pull
ca ca.crt
dev tun
persist-tun
cert cert.crt
comp-lzo adaptive
nobind
key key.key


Connection Log

Code: Select all

Jan 04 17:16:09: Viscosity Mac 1.6.8b2 (1366)
Jan 04 17:16:09: Viscosity OpenVPN Engine Started
Jan 04 17:16:09: Running on Mac OS X 10.12.2
Jan 04 17:16:09: ---------
Jan 04 17:16:09: Checking reachability status of connection...
Jan 04 17:16:09: Connection is reachable. Starting connection attempt.
Jan 04 17:16:09: OpenVPN 2.3.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Dec 12 2016
Jan 04 17:16:09: library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.09
Jan 04 17:16:10: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Jan 04 17:16:10: UDPv4 link local: [undef]
Jan 04 17:16:10: UDPv4 link remote: [AF_INET]67.83.183.56:1194
Jan 04 17:16:11: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Jan 04 17:16:11: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Jan 04 17:16:11: [lugoues.net] Peer Connection Initiated with [AF_INET]xxx:xxx
Jan 04 17:16:14: Opening utun (connect(AF_SYS_CONTROL)): Resource busy
Jan 04 17:16:14: Opened utun device utun1
Jan 04 17:16:14: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Jan 04 17:16:14: /sbin/ifconfig utun1 delete
Jan 04 17:16:14: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Jan 04 17:16:14: /sbin/ifconfig utun1 192.168.20.6 192.168.20.5 mtu 1500 netmask 255.255.255.255 up
Jan 04 17:16:14: Initialization Sequence Completed
Jan 04 17:16:14: DNS mode set to: Split


Route Table

Code: Select all

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.40.5.1          UGSc          294       36     en3
default            10.40.5.1          UGScI          14        0     en0
default            192.168.20.5       UGScI           1        0   utun1
10.40.5/24         link#4             UCS             3        0     en3
10.40.5/24         link#5             UCSI            5        0     en0
10.40.5.1/32       link#4             UCS             8        0     en3
10.40.5.1          cc:ef:48:a4:6b:38  UHLWIir        32       40     en3    890
10.40.5.1          cc:ef:48:a4:6b:38  UHLWIir         3        0     en0    904
10.40.5.1/32       link#5             UCSI            3        0     en0
10.40.5.2          b4:75:e:62:35:d0   UHLWIi          1        2     en3   1190
10.40.5.2          b4:75:e:62:35:d0   UHLWIi          1        0     en0   1190
10.40.5.113/32     link#4             UCS             1        0     en3
10.40.5.115/32     link#5             UCS             1        0     en0
10.40.5.115        28:cf:e9:1a:b2:b7  UHLWIi          1        1     lo0
10.40.5.221        3c:7:54:63:90:a5   UHLWIi          1        0     en0   1174
10.40.5.255        link#4             UHLWbI          1       45     en3
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              4   119440     lo0
192.168.10         192.168.20.5       UGSc            3        7   utun1
192.168.20         192.168.20.5       UGSc            1        0   utun1
192.168.20.5       192.168.20.6       UHr             6        0   utun1
192.168.20.5/32    link#13            UCS             1        0   utun1
224.0.0/4          link#4             UmCS            3        0     en3
224.0.0/4          link#5             UmCSI           2        0     en0
224.0.0/4          link#13            UmCSI           1        0   utun1
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          1        0     en3
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          1        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          1     1484     en3
255.255.255.255/32 link#4             UCS             2        0     en3
255.255.255.255    link#4             UHLWbI          1       22     en3
255.255.255.255/32 link#5             UCSI            1        0     en0
255.255.255.255/32 link#13            UCSI            1        0   utun1


Client traceroute to machine on server network

Code: Select all

λ traceroute 192.168.10.23
traceroute to 192.168.10.23 (192.168.10.23), 64 hops max, 52 byte packets
 1  192.168.20.1 (192.168.20.1)  21.863 ms  24.134 ms  19.898 ms


Client traceroute to vpn server

Code: Select all

λ traceroute 192.168.10.1
traceroute to 192.168.10.1 (192.168.10.1), 64 hops max, 52 byte packets
 1  192.168.10.1 (192.168.10.1)  25.511 ms  23.755 ms  18.890 ms
Hi lugoues,

You have Tap in the topic title, however your setup is actually a Tun (routed) based setup. I'm mentioning this in case any of your setting have been set under the assumption you have a Tap (bridged) setup.

The routing for the 192.168.10.x and 192.168.20.x subnets looks fine from a client perspective. Most likely the problem lies on the server's end: from the sound of it NAT is not set up or no longer working. Please keep in mind as it is a run/routed setup bridging the tun interface to the local network on the server will not work.

Cheers,
James
Oops, yep I meant Tun, sorry about that.

This used to work >< and I have no idea what changed. ugh

So the routing looks ok server side (see below), i think?

The server is running 2.3.6 and the client 2.3.14, could that cause a problem? Is there a way to get viscosity to use an older version of openvpn?

Edit: Oh, regarding client side routing. The traceroute to 192.168.10.23 ends at 192.168.20.1, where is it suppose to go next?

Server side routing table

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.20.2    0.0.0.0         255.255.255.255 UH        0 0          0 tun21
192.168.20.0    192.168.20.2    255.255.255.0   UG        0 0          0 tun21
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         67.83.176.1     0.0.0.0         UG        0 0          0 vlan2
Hi lugoues,

I'm afraid we can only offer support for Viscosity itself - we don't have the support resources to be able to diagnose server setups. Someone from the community may be able to offer some advice, or you can re-setup your OpenVPN server setup from scratch using one of the server setup guides:
https://www.sparklabs.com/support/kb/ca ... up-guides/

Cheers,
James
4 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy