Internet and dns lookups stop working

238 views

Skip to first unread message

Gesias

unread,

Apr 1, 2016, 7:56:02 AM4/1/16

to tunnelblick-discuss

Hello!

I have a weird problem I could need some advice with. I used this guide to setup my servers https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04 . I ran through this troubleshooting guide https://tunnelblick.net/cConnectedBut.html and this on https://tunnelblick.net/cCommonProblems.html already.

I have one locally in the office and one server at home. Both worked until a week ago, now the one at home works but the one at the office does not give me any connection to internet or even being able to do dns lookups.

Roughly a week ago the electricity was cut at the office and the ip address changed, not sure how this would affect anything though, should be totally irrelevant since I am able to connect to the server.

I´ve tried to downgrade and upgrade the Tunnelblick client to a few other versions but it changed nothing. Removed and reinstalled the openvpn server also (with apt-get). Here is the connection log to the office server, very greatful for some input that may point me in the right direction.

Down by the end I see this

2016-04-01 13:32:57 /sbin/route add -net 81.250.X.X 192.168.0.1 255.255.255.255

route: writing to routing socket: File exists

add net 81.250.X.X: gateway 192.168.0.1: File exists

But my feeling is that its not the culprit, especially since it occurs in the log when accessing my home openvpn server and that one works just fine.

############################################################################################

*Tunnelblick: OS X 10.10.5; Tunnelblick 3.6.0a (build 4543.4546); prior version 3.5.8 (build 4270.4530); Admin user

Configuration kammis

"Sanitized" condensed configuration file for /Users/gesias/Library/Application Support/Tunnelblick/Configurations/kammis.tblk:

client

dev tun

proto udp

remote 81.250.X.X 1194

resolv-retry infinite

nobind

user nobody

group nogroup

persist-key

persist-tun

ns-cert-type server

comp-lzo

verb 3

<ca>

[Security-related line(s) omitted]

</ca>

<cert>

[Security-related line(s) omitted]

</cert>

<key>

[Security-related line(s) omitted]

</key>

================================================================================

Non-Apple kexts that are loaded:

Index Refs Address Size Wired Name (Version) <Linked Against>

117 0 0xffffff7f80cfa000 0xf000 0xf000 com.displaylink.driver.DisplayLinkDriver (2.4) <84 5 4 3>

139 3 0xffffff7f831f6000 0x57000 0x57000 org.virtualbox.kext.VBoxDrv (4.3.20) <7 5 4 3 1>

140 0 0xffffff7f8324d000 0x8000 0x8000 org.virtualbox.kext.VBoxUSB (4.3.20) <139 92 39 7 5 4 3 1>

141 0 0xffffff7f83255000 0x5000 0x5000 org.virtualbox.kext.VBoxNetFlt (4.3.20) <139 7 5 4 3 1>

145 0 0xffffff7f8325a000 0x6000 0x6000 org.virtualbox.kext.VBoxNetAdp (4.3.20) <139 5 4 1>

================================================================================

There are no unusual files in kammis.tblk

================================================================================

Configuration preferences:

useDNS = 1

-useDownRootPlugin = 1

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

-lastConnectionSucceeded = 1

================================================================================

Wildcard preferences:

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

================================================================================

Program preferences:

launchAtNextLogin = 1

notOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

tunnelblickVersionHistory = (

"3.6.0a (build 4543.4546)",

"3.5.8 (build 4270.4530)",

"3.6.1beta02 (build 4544)",

"3.6.0a (build 4543.4546)",

"3.5.8 (build 4270.4530)",

"3.5.7 (build 4270.4517)",

"3.5.5 (build 4270.4461)",

"3.5.4 (build 4270.4395)"

)

statusDisplayNumber = 0

lastLaunchTime = 481202971.8589

connectionWindowDisplayCriteria = showWhenConnecting

maxLogDisplaySize = 102400

lastConnectedDisplayName = kammis

keyboardShortcutIndex = 1

updateCheckAutomatically = 1

updateSendProfileInfo = 1

NSWindow Frame ConnectingWindow = -1155 472 389 187 -1920 -180 1920 1057

detailsWindowFrameVersion = 4270.4530

detailsWindowFrame = {{-1418, 262}, {912, 467}}

detailsWindowLeftFrame = {{0, 0}, {162, 350}}

detailsWindowViewIndex = 4

detailsWindowConfigurationsTabIdentifier = log

leftNavSelectedDisplayName = kammis

AdvancedWindowTabIdentifier = sounds

haveDealtWithSparkle1dot5b6 = 1

haveDealtWithOldTunTapPreferences = 1

haveDealtWithOldLoginItem = 1

SUEnableAutomaticChecks = 1

SUFeedURL = https://www.tunnelblick.net/appcast-s.rss

SUScheduledCheckInterval = 86400

SUSendProfileInfo = 1

SULastCheckTime = 2016-04-01 11:29:31 +0000

SULastProfileSubmissionDate = 2016-03-30 14:13:05 +0000

SUHasLaunchedBefore = 1

WebKitDefaultFontSize = 11

WebKitStandardFont = .Helvetica Neue DeskInterface

================================================================================

Tunnelblick Log:

2016-04-01 13:32:49 *Tunnelblick: OS X 10.10.5; Tunnelblick 3.6.0a (build 4543.4546); prior version 3.5.8 (build 4270.4530)

2016-04-01 13:32:49 *Tunnelblick: Attempting connection with kammis using shadow copy; Set nameserver = 3; monitoring connection

2016-04-01 13:32:49 *Tunnelblick: openvpnstart start kammis.tblk 1337 3 0 1 0 1065264 -ptADGNWradsgnw 2.3.10

2016-04-01 13:32:49 OpenVPN 2.3.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Mar 19 2016

2016-04-01 13:32:49 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.09

2016-04-01 13:32:49 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2016-04-01 13:32:49 Need hold release from management interface, waiting...

2016-04-01 13:32:49 *Tunnelblick: openvpnstart starting OpenVPN

2016-04-01 13:32:50 *Tunnelblick: openvpnstart log:

Warning: Tunnelblick is using 'openvpn-down-root.so', so the route-pre-down script will not be used. You can override this by providing a custom route-pre-down script (which may be a copy of Tunnelblick's standard route-pre-down script) in a Tunnelblick VPN Configuration. However, that script will not be executed as root unless the 'user' and 'group' options are removed from the OpenVPN configuration file. If the 'user' and 'group' options are removed, then you don't need to use a custom route-pre-down script.OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):

/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.10/openvpn

--daemon

--log

/Library/Application Support/Tunnelblick/Logs/-SUsers-Sgesias-SLibrary-SApplication Support-STunnelblick-SConfigurations-Skammis.tblk-SContents-SResources-Sconfig.ovpn.3_0_1_0_1065264.1337.openvpn.log

--cd

/Library/Application Support/Tunnelblick/Users/gesias/kammis.tblk/Contents/Resources

--verb

--config

/Library/Application Support/Tunnelblick/Users/gesias/kammis.tblk/Contents/Resources/config.ovpn

--cd

/Library/Application Support/Tunnelblick/Users/gesias/kammis.tblk/Contents/Resources

--management

127.0.0.1

1337

--management-query-passwords

--management-hold

--script-security

--up

/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

--plugin

/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.10/openvpn-down-root.so

/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

2016-04-01 13:32:50 *Tunnelblick: Established communication with OpenVPN

2016-04-01 13:32:50 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2016-04-01 13:32:50 MANAGEMENT: CMD 'pid'

2016-04-01 13:32:50 MANAGEMENT: CMD 'state on'

2016-04-01 13:32:50 MANAGEMENT: CMD 'state'

2016-04-01 13:32:50 MANAGEMENT: CMD 'bytecount 1'

2016-04-01 13:32:50 MANAGEMENT: CMD 'hold release'

2016-04-01 13:32:50 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2016-04-01 13:32:50 PLUGIN_INIT: POST /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.10/openvpn-down-root.so '[/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.10/openvpn-down-root.so] [/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh] [-9] [-d] [-f] [-m] [-w] [-ptADGNWradsgnw]' intercepted=PLUGIN_UP|PLUGIN_DOWN

2016-04-01 13:32:50 Socket Buffers: R=[196724->196724] S=[9216->9216]

2016-04-01 13:32:50 MANAGEMENT: >STATE:1459510370,RESOLVE,,,

2016-04-01 13:32:50 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay

2016-04-01 13:32:50 UDPv4 link local: [undef]

2016-04-01 13:32:50 UDPv4 link remote: [AF_INET]81.250.X.X:1194

2016-04-01 13:32:50 MANAGEMENT: >STATE:1459510370,WAIT,,,

2016-04-01 13:32:50 MANAGEMENT: >STATE:1459510370,AUTH,,,

2016-04-01 13:32:50 TLS: Initial packet from [AF_INET]81.250.X.X:1194, sid=6d258b6a 636b5f18

2016-04-01 13:32:50 VERIFY OK: depth=1, C=SE, ST=ST, L=Stockholm, O=COMPANY, OU=COMPANY, CN=COMPANY CA, name=server, emailAddress=ges...@company.com

2016-04-01 13:32:50 VERIFY OK: nsCertType=SERVER

2016-04-01 13:32:50 VERIFY OK: depth=0, C=SE, ST=ST, L=Stockholm, O=COMPANY, OU=COMPANY, CN=server, name=server, emailAddress=ges...@company.com

2016-04-01 13:32:50 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

2016-04-01 13:32:50 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2016-04-01 13:32:50 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

2016-04-01 13:32:50 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2016-04-01 13:32:50 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

2016-04-01 13:32:50 [server] Peer Connection Initiated with [AF_INET]81.250.X.X:1194

2016-04-01 13:32:51 MANAGEMENT: >STATE:1459510371,GET_CONFIG,,,

2016-04-01 13:32:52 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

2016-04-01 13:32:52 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'

2016-04-01 13:32:52 OPTIONS IMPORT: timers and/or timeouts modified

2016-04-01 13:32:52 OPTIONS IMPORT: --ifconfig/up options modified

2016-04-01 13:32:52 OPTIONS IMPORT: route options modified

2016-04-01 13:32:52 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

2016-04-01 13:32:52 Opened utun device utun0

2016-04-01 13:32:52 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

2016-04-01 13:32:52 MANAGEMENT: >STATE:1459510372,ASSIGN_IP,,10.8.0.6,

2016-04-01 13:32:52 /sbin/ifconfig utun0 delete

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2016-04-01 13:32:52 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2016-04-01 13:32:52 /sbin/ifconfig utun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up

2016-04-01 13:32:52 PLUGIN_CALL: POST /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.10/openvpn-down-root.so/PLUGIN_UP status=0

2016-04-01 13:32:52 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun0 1500 1542 10.8.0.6 10.8.0.5 init

**********************************************

Start of output from client.up.tunnelblick.sh

Disabled IPv6 for 'SAMSUNG_Android'

Disabled IPv6 for 'Bluetooth DUN'

Disabled IPv6 for 'Ethernet'

Disabled IPv6 for 'FireWire'

Disabled IPv6 for 'Wi-Fi'

Disabled IPv6 for 'SAMSUNG Modem'

Disabled IPv6 for 'Bluetooth PAN'

Disabled IPv6 for 'USB Ethernet'

Disabled IPv6 for 'HUAWEI Mobile'

Retrieved from OpenVPN: name server(s) [ 208.67.222.222 208.67.220.220 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]

Not aggregating ServerAddresses because running on OS X 10.6 or higher

Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected

Saved the DNS and SMB configurations so they can be restored

Changed DNS ServerAddresses setting from '193.150.193.150 83.255.245.11' to '208.67.222.222 208.67.220.220'

Changed DNS SearchDomains setting from '' to 'openvpn'

Changed DNS DomainName setting from 'home' to 'openvpn'

Did not change SMB NetBIOSName setting of ''

Did not change SMB Workgroup setting of ''

Did not change SMB WINSAddresses setting of ''

DNS servers '208.67.222.222 208.67.220.220' will be used for DNS queries when the VPN is active

The DNS servers include only free public DNS servers known to Tunnelblick.

Flushed the DNS cache via dscacheutil

/usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

Notified mDNSResponder that the DNS cache was flushed

Setting up to monitor system configuration with process-network-changes

End of output from client.up.tunnelblick.sh

**********************************************

2016-04-01 13:32:57 *Tunnelblick: No 'connected.sh' script to execute

2016-04-01 13:32:57 /sbin/route add -net 81.250.X.X 192.168.0.1 255.255.255.255

route: writing to routing socket: File exists

add net 81.250.X.X: gateway 192.168.0.1: File exists

2016-04-01 13:32:57 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0

add net 0.0.0.0: gateway 10.8.0.5

2016-04-01 13:32:57 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0

add net 128.0.0.0: gateway 10.8.0.5

2016-04-01 13:32:57 MANAGEMENT: >STATE:1459510377,ADD_ROUTES,,,

2016-04-01 13:32:57 /sbin/route add -net 10.8.0.1 10.8.0.5 255.255.255.255

add net 10.8.0.1: gateway 10.8.0.5

2016-04-01 13:32:57 GID set to nogroup

2016-04-01 13:32:57 UID set to nobody

2016-04-01 13:32:57 Initialization Sequence Completed

2016-04-01 13:32:57 MANAGEMENT: >STATE:1459510377,CONNECTED,SUCCESS,10.8.0.6,81.250.X.X

2016-04-01 13:33:02 *Tunnelblick process-network-changes: A system configuration change was ignored

================================================================================

"Sanitized" full configuration file

##############################################

# Sample client-side OpenVPN 2.0 config file #

# for connecting to multi-client server. #

# #

# This configuration can be used by multiple #

# clients, however each client should have #

# its own cert and key files. #

# #

# On Windows, you might want to rename this #

# file so it has a .ovpn extension #

##############################################

# Specify that we are a client and that we

# will be pulling certain config file directives

# from the server.

client

# Use the same setting as you are using on

# the server.

# On most systems, the VPN will not function

# unless you partially or fully disable

# the firewall for the TUN/TAP interface.

;dev tap

dev tun

# Windows needs the TAP-Win32 adapter name

# from the Network Connections panel

# if you have more than one. On XP SP2,

# you may need to disable the firewall

# for the TAP adapter.

;dev-node MyTap

# Are we connecting to a TCP or

# UDP server? Use the same setting as

# on the server.

;proto tcp

proto udp

# The hostname/IP and port of the server.

# You can have multiple remote entries

# to load balance between the servers.

#remote 192.168.0.16 1194

remote 81.250.X.X 1194

;remote my-server-2 1194

# Choose a random host from the remote

# list for load-balancing. Otherwise

# try hosts in the order specified.

;remote-random

# Keep trying indefinitely to resolve the

# host name of the OpenVPN server. Very useful

# on machines which are not permanently connected

# to the internet such as laptops.

resolv-retry infinite

# Most clients don't need to bind to

# a specific local port number.

nobind

# Downgrade privileges after initialization (non-Windows only)

user nobody

group nogroup

# Try to preserve some state across restarts.

persist-key

persist-tun

# If you are connecting through an

# HTTP proxy to reach the actual OpenVPN

# server, put the proxy server/IP and

# port number here. See the man page

# if your proxy server requires

# authentication.

;http-proxy-retry # retry on connection failures

;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot

# of duplicate packets. Set this flag

# to silence duplicate packet warnings.

;mute-replay-warnings

# SSL/TLS parms.

# See the server config file for more

# description. It's best to use

# a separate .crt/.key file pair

# for each client. A single ca

# file can be used for all clients.

# ca ca.crt

# cert client.crt

# key client.key

# Verify server certificate by checking

# that the certicate has the nsCertType

# field set to "server". This is an

# important precaution to protect against

# a potential attack discussed here:

# http://openvpn.net/howto.html#mitm

# To use this feature, you will need to generate

# your server certificates with the nsCertType

# field set to "server". The build-key-server

# script in the easy-rsa folder will do this.

ns-cert-type server

# If a tls-auth key is used on the server

# then every client must also have the key.

;tls-auth ta.key 1

# Select a cryptographic cipher.

# If the cipher option is used on the server

# then you must also specify it here.

;cipher x

# Enable compression on the VPN link.

# Don't enable this unless it is also

# enabled in the server config file.

comp-lzo

# Set log file verbosity.

verb 3

# Silence repeating messages

;mute 20

<ca>

[Security-related line(s) omitted]

</ca>

<cert>

[Security-related line(s) omitted]

</cert>

<key>

[Security-related line(s) omitted]

</key>

================================================================================

ifconfig output:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384

options=3<RXCSUM,TXCSUM>

inet6 ::1 prefixlen 128

inet 127.0.0.1 netmask 0xff000000

inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1

nd6 options=1<PERFORMNUD>

gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

stf0: flags=0<> mtu 1280

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>

ether c8:bc:c8:a3:8b:f2

inet 192.168.0.11 netmask 0xffffff00 broadcast 192.168.0.255

nd6 options=1<PERFORMNUD>

media: autoselect (1000baseT <full-duplex,flow-control>)

status: active

en1: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500

ether c8:bc:c8:e1:f1:09

nd6 options=1<PERFORMNUD>

media: autoselect (<unknown type>)

status: inactive

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078

lladdr dc:2b:61:ff:fe:e6:54:7e

nd6 options=1<PERFORMNUD>

media: autoselect <full-duplex>

status: inactive

p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304

ether 0a:bc:c8:e1:f1:09

media: autoselect

status: inactive

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff

================================================================================

jkbull...gmail.com

unread,

Apr 1, 2016, 8:58:23 AM4/1/16

to tunnelblick-discuss

Thanks for providing the diagnostic info (many people don't!).

First, is it possible that the power loss at the office reset some firewall there? I would think that would result in not being able to connect to the server, but maybe it was reset to not pass on some traffic.

Having said that, I think that the cause of the problem is indicated here, as you suspect:

2016-04-01 13:32:57 /sbin/route add -net 81.250.X.X 192.168.0.1 255.255.255.255
route: writing to routing socket: File exists

It means that the routing on the client computer seems to have a problem, at least with respect to the OpenVPN server address (81.250.X.X).

Because the symptoms you are seeing (no Internet access through the VPN) seem to indicate a routing problem, I think the solution will be to "reset" your client computer's routing table.

I'm not sure of the best way to do that, but please try the following (if you haven't already done so, sorry if this sounds condescending but I want to be thorough):

A. Disconnect from the network and then reconnect:

Unplug Ethernet (if it is being used)
Turn off WiFi (if it is on)
Turn WiFi back on (if it was on)
Reconnect Ethernet (if it was connected).

B. Restart the client computer in Safe Mode [apple.com] and then restart it normally.

C. Reset the routing table. I have no idea how to do this, perhaps someone else can help with that.

D. Remove and then reinstall the Ethernet and WiFi adapters. Mac OS X - Reinstalling Network Adapters [wisc.edu] looks like a good procedure (although I have never done it). The second part of Reset & Rebuild Network Settings & Preferences [mandarapte.com] might work, too.

After each of A, B, C, and D try the VPN.

Good luck. It would be great if you get it working and report back what helped.

On Friday, April 1, 2016 at 7:56:02 AM UTC-4, Gesias wrote:

Hello!

I have a weird problem I could need some advice with. I used this guide to setup my servers https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-14-04 . I ran through this troubleshooting guide https://tunnelblick.net/cConnectedBut.html and this on https://tunnelblick.net/cCommonProblems.html already.

I have one locally in the office and one server at home. Both worked until a week ago, now the one at home works but the one at the office does not give me any connection to internet or even being able to do dns lookups.

Roughly a week ago the electricity was cut at the office and the ip address changed, not sure how this would affect anything though, should be totally irrelevant since I am able to connect to the server.

I´ve tried to downgrade and upgrade the Tunnelblick client to a few other versions but it changed nothing. Removed and reinstalled the openvpn server also (with apt-get). Here is the connection log to the office server, very greatful for some input that may point me in the right direction.

Down by the end I see this
2016-04-01 13:32:57 /sbin/route add -net 81.250.X.X 192.168.0.1 255.255.255.255
route: writing to routing socket: File exists
add net 81.250.X.X: gateway 192.168.0.1: File exists

But my feeling is that its not the culprit, especially since it occurs in the log when accessing my home openvpn server and that one works just fine.

<snip>

Gesias

unread,

Apr 1, 2016, 9:05:41 AM4/1/16

to tunnelblick-discuss

Thanks a lot for the swift reply, I´ll runt through the tips and see if I can find something that works and of course, report back regardless!

Have a nice weekend!

Gesias

unread,

Apr 4, 2016, 10:44:30 AM4/4/16

to tunnelblick-discuss

Hello again,

Been looking at this the whole day today. Read up a bit about routing tables and different tools used to troubleshoot. Ran through your tips first but couldnt get anything to change unfortunately.

Started looking at the routing tables on the local computer which I got access to with netstat -rn

Then I moved forward using traceroute to see how different servers were found. Then I went back and looked for if openvpn handles these routes in any specific way, read this http://superuser.com/questions/851462/understanding-routing-table-with-openvpn and had a look at the logs when tunnelblick is disconnecting.

Tunnelblick were unable to restore/ remove a few entries in the routing table due to not being root. Have no idea why this affects only one of my VPN:s though but I compared the entries with with the listing of the netstat and started removing them one by one in the terminal. The one entry that reactivated internet connection again and made the traceroute work again was

sudo /sbin/route delete -net 128.0.0.0 10.8.0.5 128.0.0.0

The superuser post above explains why pretty well

>>>>

The reason this works is because when it comes to routing, a more specific route is always preferred over a more general route. And 0.0.0.0/0.0.0.0 (the default gateway) is as general as it gets. But if we insert the above two routes, the fact they are more specific means one of them will always be chosen before 0.0.0.0/0.0.0.0 since those two routes still cover the entire IP spectrum (0.0.0.0 thru 255.255.255.255).

VPNs do this to avoid messing w/ existing routes. They don’t need to delete anything that was already there, or even examine the routing table. They just add their own routes when the VPN comes up, and remove them when the VPN is shutdown. Simple.

Gesias

unread,

Apr 4, 2016, 11:11:09 AM4/4/16

to tunnelblick-discuss

I spoke too soon, it seems that was only working for me. Colleagues of mine did not have the same issue. Almost leaning towards the server having the problem now. The fix I wrote about before only helped briefly. I will continue to look into this and keep this thread updated.

2016-04-01 13:32:50 VERIFY OK: depth=1, C=SE, ST=ST, L=Stockholm, O=COMPANY, OU=COMPANY, CN=COMPANY CA, name=server, emailAddress=gesias@company.com

2016-04-01 13:32:50 VERIFY OK: nsCertType=SERVER

2016-04-01 13:32:50 VERIFY OK: depth=0, C=SE, ST=ST, L=Stockholm, O=COMPANY, OU=COMPANY, CN=server, name=server, emailAddress=gesias@company.com

jkbull...gmail.com

unread,

Apr 4, 2016, 11:29:08 AM4/4/16

to tunnelblick-discuss

OK.I think I see the problem and why the

route: writing to routing socket: File exists

error message showed up.

I'm sorry I didn't see this immediately. I think the solution is to remove the lines "user nobody" and "group nobody" from your configuration files.

You may also have to disconnect your network connections and/or restart the computer to get this to work the first time (because of the leftover routing from previous connections), but first you should try connecting/disconnecting a couple times without doing those.

The problem with "user nobody" and "group nobody" is that you can't use them if there is also routing being set up (as there is in your case), because although the routing is set up properly, OpenVPN then drops privileges and OpenVPN then does not have root privileges when it tries to restore the routing when disconnecting. (Although the "down-root" plugin allows OpenVPN to regain root privileges for the purposes of running the "down" script, the "down-root" plugin does not give root privileges for restoring the routing. That's an OpenPVN problem; there's nothing that Tunnelblick can do about it.

Most people in this situation just get rid of the "user nobody" and "group nobody" from their configuration files.

The only other solution that I know of is to create customized "up" and "down" scripts that contain all the routing. I have no ideas about how to do that, sorry.

kl...@apprl.com

unread,

Apr 20, 2016, 6:14:52 AM4/20/16

to tunnelblick-discuss

Sorry, havent been able to come back to this issue. My other computer, which I use outside the office works just fine still, so it narrows it down to the local computer and being inside the office. Other users had trouble getting internet access from the outside though but not sure if those problems are still a nuisance. Will come back when I learnt some more about it. Did apply the fix you suggested but it had no effect on my local computer, possibly I need to do a complete reset for it to work. At least thats what I´ll try next.

Gesias

unread,

May 2, 2016, 3:24:25 AM5/2/16

to tunnelblick-discuss, kl...@apprl.com

Last update, it recently started working for everyone again after some time. Probably some client side route/dns caching that timed out eventually and that we couldnt reset (yeah it doesnt make sense I know but thats my two cents).