Redirect-Gateway not working Mavericks| TB 3.4b20

[edward...@gmail.com]

Hey I cannot get redirect-gateway to work so that all traffic will route through vpn. This doesn't work whether redirect-gateway is specified in the server config or if I check 'while connected' - 'route all traffic through vpn'. 

A windows client using the same config on open vpn is able to connect to the server and the redirect gateway works.

Thus I assume this is a bug in the latest beta. 

The relevant error that shows in tunnelblick logs is:

2014-04-06 10:25:07 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing

Server config (openvpn running on windows 7. Tap is bridged in windows to the local ethernet)

port 443

proto udp

dev tap

ca ca.crt

cert server.crt

key server.key  # This file should be kept secret

dh dh4096.pem

push "redirect-gateway def1 bypass-dhcp"

#push "redirect-gateway def1"  (I have also tried this and it did not solve this problem)

keepalive 10 120

tls-auth ta.key 0 # This file is secret

cipher AES-256-CBC

comp-lzo

persist-key

persist-tun

status openvpn-status.log

verb 3

Below is copy of full TB diag export redacted:

*Tunnelblick: OS X 10.9.2; Tunnelblick 3.4beta20 (build 3727); prior version 3.4beta18 (build 3704); Admin user

"Sanitized" configuration file for /Users/client/Library/Application Support/Tunnelblick/Configurations/[redacted] Client.tblk:

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

# 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 link.[redacted].us 443

# 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 nobody

# 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

;secret static.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

cipher AES-256-CBC

# 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

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

Configuration preferences:

-routeAllTrafficThroughVpn = 0

-openvpnVersion = 2.3.2

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

-lastConnectionSucceeded = 1

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

Wildcard preferences:

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

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

Program preferences:

skipWarningThatIPAddressDidNotChangeAfterConnection = 1

notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1

tunnelblickVersionHistory = (

    "3.4beta20 (build 3727)",

    "3.4beta18 (build 3704)"

)

statusDisplayNumber = 0

showConnectedDurations = 1

connectionWindowDisplayCriteria = showWhenConnecting

maxLogDisplaySize = 102400

lastConnectedDisplayName = [redacted] Client

installationUID = 7352C6EC-E332-41D2-B902-21B4811A0A7F

keyboardShortcutIndex = 1

updateCheckAutomatically = 1

updateSendProfileInfo = 1

NSWindow Frame SettingsSheetWindow = 230 177 829 424 0 0 1280 778 

NSWindow Frame ConnectingWindow = 445 456 389 187 0 0 1280 778 

detailsWindowFrameVersion = 3727

detailsWindowFrame = {{520, 64}, {760, 714}}

detailsWindowLeftFrame = {{0, 0}, {135, 596}}

leftNavSelectedDisplayName = [redacted] Client

haveDealtWithSparkle1dot5b6 = 1

haveDealtWithOldTunTapPreferences = 1

SUEnableAutomaticChecks = 1

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

SUSendProfileInfo = 1

SULastCheckTime = 2014-04-06 13:28:30 +0000

SULastProfileSubmissionDate = 2014-03-31 16:09:05 +0000

SUHasLaunchedBefore = 1

WebKitDefaultFontSize = 11

WebKitStandardFont = Lucida Grande

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

Tunnelblick Log:

2014-04-06 10:24:56 OpenVPN 2.3.2 i386-apple-darwin10.8.0 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [MH] [IPv6] built on Jan  6 2014

2014-04-06 10:24:56 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2014-04-06 10:24:56 Need hold release from management interface, waiting...

2014-04-06 10:24:56 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2014-04-06 10:24:56 MANAGEMENT: CMD 'pid'

2014-04-06 10:24:56 MANAGEMENT: CMD 'state on'

2014-04-06 10:24:56 MANAGEMENT: CMD 'state'

2014-04-06 10:24:56 MANAGEMENT: CMD 'bytecount 1'

2014-04-06 10:24:56 MANAGEMENT: CMD 'hold release'

2014-04-06 10:24:56 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2014-04-06 10:24:56 *Tunnelblick: openvpnstart starting OpenVPN

2014-04-06 10:24:56 *Tunnelblick: Established communication with OpenVPN

2014-04-06 10:24:56 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file

2014-04-06 10:24:56 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-04-06 10:24:56 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-04-06 10:24:56 Socket Buffers: R=[196724->65536] S=[9216->65536]

2014-04-06 10:24:56 MANAGEMENT: >STATE:1396794296,RESOLVE,,,

2014-04-06 10:24:57 UDPv4 link local: [undef]

2014-04-06 10:24:57 UDPv4 link remote: [AF_INET][redacted]:443

2014-04-06 10:24:57 MANAGEMENT: >STATE:1396794297,WAIT,,,

2014-04-06 10:24:57 MANAGEMENT: >STATE:1396794297,AUTH,,,

2014-04-06 10:24:57 TLS: Initial packet from [AF_INET][redacted]:443, sid=[redacted]

2014-04-06 10:24:57 VERIFY OK: depth=1, C=US, ST=GA, L=[redacted], O=[redacted], OU=changeme, CN=[redacted]-CA, name=changeme, emailAddress=[redacted]\09

2014-04-06 10:24:57 VERIFY OK: nsCertType=SERVER

2014-04-06 10:24:57 VERIFY OK: depth=0, C=US, ST=GA, L=[redacted], O=[redacted], OU=changeme, CN=Server, name=server, emailAddress=[redacted]\09

2014-04-06 10:25:01 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

2014-04-06 10:25:01 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-04-06 10:25:01 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key

2014-04-06 10:25:01 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

2014-04-06 10:25:01 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA

2014-04-06 10:25:01 [Server] Peer Connection Initiated with [AF_INET][redacted]:443

2014-04-06 10:25:02 MANAGEMENT: >STATE:1396794302,GET_CONFIG,,,

2014-04-06 10:25:03 SENT CONTROL [Server]: 'PUSH_REQUEST' (status=1)

2014-04-06 10:25:05 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route-gateway dhcp,ping 10,ping-restart 120'

2014-04-06 10:25:05 OPTIONS IMPORT: timers and/or timeouts modified

2014-04-06 10:25:05 OPTIONS IMPORT: route options modified

2014-04-06 10:25:05 OPTIONS IMPORT: route-related options modified

2014-04-06 10:25:05 TUN/TAP device /dev/tap0 opened

2014-04-06 10:25:05 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1590   init

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

                                        Start of output from client.up.tunnelblick.sh

                                        Configuring tap DNS via DHCP asynchronously

                                        End of output from client.up.tunnelblick.sh

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

2014-04-06 10:25:07 NOTE: unable to redirect default gateway -- VPN gateway parameter (--route-gateway or --ifconfig) is missing

2014-04-06 10:25:07 Initialization Sequence Completed

2014-04-06 10:25:07 MANAGEMENT: >STATE:1396794307,CONNECTED,SUCCESS,,[redacted]

2014-04-06 10:25:07 *Tunnelblick: No 'connected.sh' script to execute

                                        Sleeping for 0 seconds to wait for DHCP to finish setup.

                                        Sleeping for 1 seconds to wait for DHCP to finish setup.

                                        Sleeping for 2 seconds to wait for DHCP to finish setup.

2014-04-06 10:25:11 Extracted DHCP router address: 192.168.1.1

                                        Sleeping for 3 seconds to wait for DHCP to finish setup.

                                        Retrieved from DHCP/BOOTP packet: name server(s) [ 192.168.1.1 ], 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

                                        Set ServerAddresses to 192.168.1.1

                                        Set SearchDomains   to openvpn

                                        Set DomainName       to openvpn

                                        Flushed the DNS Cache

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

2014-04-06 10:25:12 *Tunnelblick: This computer's apparent public IP address ([redacted but is not same as openvpn server]) was unchanged after the connection was made

2014-04-06 10:25:22 *Tunnelblick process-network-changes: A system configuration change was ignored

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

Console Log:

s

2014-04-06 08:38:44 Tunnelblick[9149] DEBUG: Updater: systemVersion 10.9.2 satisfies minimumSystemVersion 10.4.0

2014-04-06 08:38:44 Tunnelblick[9149] DEBUG: Updater: systemVersion 10.9.2 satisfies minimumSystemVersion 10.4.0

2014-04-06 08:59:04 Tunnelblick[9149] applicationShouldTerminate: termination because of Quit; delayed until 'shutdownTunnelblick' finishes

2014-04-06 08:59:04 Tunnelblick[9149] Finished shutting down Tunnelblick; allowing termination

2014-04-06 08:59:08 Tunnelblick[10222] Set program update feedURL to https://www.tunnelblick.net/appcast-b.rss

2014-04-06 08:59:10 Tunnelblick[10222] DEBUG: Updater: systemVersion 10.9.2 satisfies minimumSystemVersion 10.4.0

2014-04-06 08:59:10 Tunnelblick[10222] DEBUG: Updater: systemVersion 10.9.2 satisfies minimumSystemVersion 10.4.0

2014-04-06 08:59:18 Tunnelblick[10222] NSWorkspace volume notifications are taking longer than normal. This may be due to non-responding NFS hard mounts. Some volume notifications may arrive late or dropped. This message will only be reported once.

2014-04-06 09:07:59 Tunnelblick[10222] Putting off sleep until all OpenVPNs have terminated

2014-04-06 09:26:39 Tunnelblick[10222] setShutdownVariables: invoked, but have already set them

2014-04-06 09:26:39 Tunnelblick[10222] applicationShouldTerminate: termination because of restart; delayed until 'shutdownTunnelblick' finishes

2014-04-06 09:26:39 Tunnelblick[10222] Finished shutting down Tunnelblick; allowing termination

2014-04-06 09:28:29 Tunnelblick[479] Set program update feedURL to https://www.tunnelblick.net/appcast-b.rss

2014-04-06 09:34:41 WindowServer[98] CGError post_notification(const CGSNotificationType, void *const, const size_t, const bool, const CGSRealTimeDelta, const int, const CGSConnectionID *const, const pid_t): Timed out 1.000 second wait for reply from "Tunnelblick" for synchronous notification type 102 (kCGSDisplayWillSleep) (CID 0x23303, PID 479)

2014-04-06 09:34:42 Tunnelblick[479] Putting off sleep until all OpenVPNs have terminated

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

Non-Apple kexts that are loaded:

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

   48    0 0xffffff7f808fc000 0x46000    0x46000    at.obdev.nke.LittleSnitch (4052) <5 4 3 1>

  122    1 0xffffff7f822ea000 0x11000    0x11000    com.vmware.kext.vmci (90.5.7) <11 5 4 3 1>

  123    0 0xffffff7f822fb000 0xf000     0xf000     com.vmware.kext.vsockets (90.5.7) <122 7 5 4 3 1>

  124    0 0xffffff7f8230a000 0xa000     0xa000     com.vmware.kext.vmnet (0139.86.58) <5 4 3 1>

  125    0 0xffffff7f82314000 0xe000     0xe000     com.vmware.kext.vmx86 (0139.86.58) <7 5 4 3 1>

  126    0 0xffffff7f82322000 0x6000     0x6000     com.vmware.kext.vmioplug.12.1.13 (12.1.13) <34 5 4 3 1>

  131    0 0xffffff7f82328000 0x6000     0x6000     net.tunnelblick.tap (1.0) <7 5 4 1>

[jkbull...gmail.com]

This seems to be an OpenVPN issue (or OpenVPN configuration issue); it may be an OS X only issue but has nothing to do with Tunnelblick, as far as I can tell.

You should ask for help from OpenVPN experts:

• OpenVPN FAQ
• OpenVPN 2.3 Man Page
• OpenVPN Documentation
• OpenVPN Users Forum
• OpenVPN Users Mailing List

[edward...@gmail.com]

Thanks for the reply. I see now that tunnelblick must just be a GUI recompile of OpenVPN and thus you mean there may be a bug in the OpenVPN source. I'll look around there. 

As redirect-gateway would seem like a very commonly used feature I am curious if others are able to get redirect gateway to work on OS X Mavericks (10.9.2)?

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e

...

[jkbull...gmail.com]

Yes, it works for most people. There are a couple hundred thousand users of Tunnelblick 3.4beta20 under Mavericks. I think it has to do with the specific OpenVPN options that are being used.

One thing you could try is to use OpenVPN version 2.2.1 instead of 2.3.2. (Set it on the "Settings" tab of the "VPN Details…" window after selecting one or more configurations in the list on the left side of the window.)

[edward...@gmail.com]

Thanks. I actually was originally using 2.2.1 and then switched it to 2.3.2 to see if that would work. Incidentally I cannot switch back now. When I try it says "OpenVPN version  is not available. Using the latest, version 2.3.2"

[jkbull...gmail.com]

Ah. Sorry. That's a bug that was fixed in the source code (r2753) but hasn't been included in a release yet.

You should be able to select "2.2.1" (but not "Default (2.2.1)") and that will work. I will email you privately with a link to a pre-release version that fixes that problem (among others).

[edward...@gmail.com]

Got it thanks. Now I can set back to default. As expected, my original problem still persists. 

[edward...@gmail.com]

SOLUTION! 

Appears I finally have found a solution by adding a 10 second route delay just before the redirect-gateway on my server config file

push route-delay 10

Thanks to Nicholas posting solution and explantation here: https://groups.google.com/forum/#!searchin/tunnelblick-discuss/route-gateway$20dhcp/tunnelblick-discuss/5gg82CSGkUg/jNtvE4R0Nu0J

The challenge here is that OpenVPN configures all pulled routes after 
it completes interface configuration and before returning control to 
the calling application. This is fine in Windows, but in other 
operating systems it means that the configuration of the pulled routes 
happens before there is any gateway defined on the device.  The 
operating system accepts the route and its gateway, but since the 
gateway is not defined on any device yet, it assumes that it must use 
the existing default gateway to access THAT gateway, and thus binds 
the route to the interface with the default gateway, which is not the 
TAP interface (and, in my case, was en1, my wireless card interface). 
The solution is to tell OpenVPN to DELAY the configuration of routes. 
With no delay, OpenVPN configures the routes immediately and then 
returns. With a delay, for some unknown interesting reason, OpenVPN 
will wait that long AFTER the interface gets its IP address. So even a 
delay of 1 second is enough (I set mine to 5 just to give some 
cushion).