Apparent Public IP Address not changed

[jason....@gmail.com]

I have tried both the beta build [Tunnelblick 3.6beta14 (build 4441, OS X 10.4.11+) released 2015-11-20] and the stable build [Tunnelblick 3.5.4 (build 4270.4395 for OS X 10.4.11+)] and both cause the following error

I have tried the "redirect-gateway def1" and the check box for "Route all IPv4 through the VPN" to no avail. I have read numerous posts to consult the OpenVPN documentation, message boards, and mail groups - all of which will tell me that the Netgear R7500v2 is not supported. 

But guess what, the same exact VPN server and the same exact client configuration works on Android 5.1.1 with OpenVPN Client and testing at www.whatismyip.com

There seems to be something amiss with Mac OS X 10.11.1 and Tunnelblick and setting up the routing table. 

For giggles, here is the sanitized client configuration file:

client

dev tap

proto udp

;dev-node NETGEAR-VPN

remote somewhere.com xyz

float

resolv-retry infinite

nobind

persist-key

persist-tun

ca ca.crt

cert client.crt

key client.key

cipher AES-128-CBC

comp-lzo

verb 5

I cannot retrieve the Netgear R7500v2 server configuration files. But I stress again, that the apparent IP address changes with Android OpenVPN Client (i.e., client changed but server unchanged, must be a problem with the other client).

[jkbull...gmail.com]

Please follow the instructions at Read Before You Post to get the info needed to diagnose problems.

Use the latest beta and change the client configuration's "verb" to 3 before getting the info.

The server configuration file is almost never needed to diagnose problems of this type.

One last thought: you aren't connecting to the Netgear from within that router's network, right? Because the IP address wouldn't change in that situation; it would always be the Netgear's public IP address, whether or not you were connected to its VPN. Your Android device is presumably connecting through a cell network, so it has a public IP address different from your Netgear.

PS: All that "Route all IPv4 traffic through the VPN" does is to start OpenVPN with the "redirect-gateway def1" option; it is as if you put "redirect-gateway def1" in your client configuration file.

[jason....@gmail.com]

I hurriedly and mistakenly tried Viscosity (which had the same non changing IP public address) and am now having problems loading the kext for the tap and tun devices for Tunnelblick after having uninstalled Viscosity. I will post back once I get Tunnelblick loading the tun and tap kexts again.

For reference I get this after uninstalling Viscosity and reinstalling Tunnelblick 3.6beta14 build 4441:

/Applications/Tunnelblick.app/Contents/Resources/tap-signed.kext is invalid; can't resolve dependencies.

I don't have any other tap or tun devices in the "kexstat" output or in the locations indicated here:

https://tunnelblick.net/cCommonProblems.html#an-openvpn-log-entry-says-tunnelblick-openvpnstart-status-247-error-unable-to-load-net.tunnelblick.tun-andor-net.tunnelblick.tap-kexts-in-5-tries.-status-71

[jkbull...gmail.com]

You might try restarting your computer, as a "Safe Boot" if a regular reboot doesn't help.

If you are using a beta of OS X 10.11.2 there is a problem with the kexts that is fixed in the Tunnelblick source code. (It is not the "resolve dependencies" problem; I've never seen that one.) A pre-release version of Tunnelblick that includes the fix is available, email me privately for a link to download it but don't bother if you are using 10.11.1 or lower because it won't help any other kext problems.

By the way, Tunnelblick itself has nothing to do with routing (other than using "route-gateway def1"); it is all done by OpenVPN – so I'm not surprised that Viscosity behaved the same way.