Can't Browse After Connecting

[Jacob Cantele]

I'm having trouble getting set up with 3.2.1 on Lion...

I'm able to connect, but when I do, I'm unable browse the web. If I
don't set nameservers, I can connect and browse, but then I can't
access any internal resources. Other employees are able to connect
just fine.

2012-01-06 11:24:17 *Tunnelblick: OS X 10.7.2; Tunnelblick 3.2.1
(build 2891.2907)
2012-01-06 11:24:17 *Tunnelblick: Attempting connection with client;
Set nameserver = 1; monitoring connection
2012-01-06 11:24:17 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start client.ovpn 1337 1 0 0 0 49 -
atDASNGWrdasngw 2.1.4
2012-01-06 11:24:17 *Tunnelblick: openvpnstart message: Loading
tun.kext
2012-01-06 11:24:17 *Tunnelblick: Established communication with
OpenVPN
2012-01-06 11:24:17 OpenVPN 2.1.4 i386-apple-darwin10.8.0 [SSL] [LZO2]
[PKCS11] built on Dec 28 2011
2012-01-06 11:24:17 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2012-01-06 11:24:17 Need hold release from management interface,
waiting...
2012-01-06 11:24:17 MANAGEMENT: Client connected from 127.0.0.1:1337
2012-01-06 11:24:17 MANAGEMENT: CMD 'pid'
2012-01-06 11:24:17 MANAGEMENT: CMD 'state on'
2012-01-06 11:24:17 MANAGEMENT: CMD 'state'
2012-01-06 11:24:17 MANAGEMENT: CMD 'hold release'
2012-01-06 11:24:17 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.1.4/openvpn --
cd /
Users/mikerastiello/Library/Application Support/Tunnelblick/
Configurations --daemon --management 127.0.0.1 1337 --config /Users/
mikerastiello/Library/Application Support/Tunnelblick/Configurations/
client.ovpn --log /Library/Application Support/Tunnelblick/Logs/-
SUsers-Smikerastiello-SLibrary-SApplication Support-STunnelblick-
SConfigurations-Sclient.ovpn.1_0_0_0_49.1337.openvpn.log --management-
query-passwords --management-hold --script-security 2 --up /
Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw --down /
Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d -atDASNGWrdasngw --up-restart
2012-01-06 11:24:27 MANAGEMENT: CMD 'username "Auth" "mike.rastiello"'
2012-01-06 11:24:27 MANAGEMENT: CMD 'password [...]'
2012-01-06 11:24:27 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2012-01-06 11:24:27 Control Channel Authentication: tls-auth using
INLINE static key file
2012-01-06 11:24:27 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2012-01-06 11:24:27 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2012-01-06 11:24:27 LZO compression initialized
2012-01-06 11:24:27 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:
0 ET:0 EL:0 ]
2012-01-06 11:24:27 Socket Buffers: R=[42080->100000] S=[9216->100000]
2012-01-06 11:24:27 MANAGEMENT: >STATE:1325870667,RESOLVE,,,
2012-01-06 11:24:27 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:
135 ET:0 EL:0 AF:3/1 ]
2012-01-06 11:24:27 Local Options hash (VER=V4): '504e774e'
2012-01-06 11:24:27 Expected Remote Options hash (VER=V4): '14168603'
2012-01-06 11:24:27 UDPv4 link local: [undef]
2012-01-06 11:24:27 UDPv4 link remote: 173.11.222.39:1194
2012-01-06 11:24:27 MANAGEMENT: >STATE:1325870667,WAIT,,,
2012-01-06 11:24:27 MANAGEMENT: >STATE:1325870667,AUTH,,,
2012-01-06 11:24:27 TLS: Initial packet from 173.11.222.39:1194,
sid=c85d7eb2 a69301b6
2012-01-06 11:24:27 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
2012-01-06 11:24:27 VERIFY OK: depth=1, /CN=OpenVPN_CA
2012-01-06 11:24:27 VERIFY OK: nsCertType=SERVER
2012-01-06 11:24:27 VERIFY OK: depth=0, /CN=OpenVPN_Server
2012-01-06 11:24:28 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2012-01-06 11:24:28 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2012-01-06 11:24:28 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2012-01-06 11:24:28 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2012-01-06 11:24:28 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-
RSA-
AES256-SHA, 1024 bit RSA
2012-01-06 11:24:28 [OpenVPN_Server] Peer Connection Initiated with
173.11.222.39:1194
2012-01-06 11:24:29 MANAGEMENT: >STATE:1325870669,GET_CONFIG,,,
2012-01-06 11:24:30 SENT CONTROL [OpenVPN_Server]:
'PUSH_REQUEST' (status=1)
2012-01-06 11:24:30 PUSH: Received control message:
'PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5
30,dhcp-
pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 5,ping-
restart 40,redirect-private local,redirect-private bypass-dhcp,route-
gateway 5.5.16.1,route 5.5.0.0 255.255.240.0,route 192.168.0.0
255.255.0.0,route 172.16.0.0 255.240.0.0,route 10.0.0.0
255.0.0.0,dhcp-
option DNS 192.168.1.14,dhcp-option DNS 192.168.1.12,dhcp-option NBT
1,register-dns,auth-token SESS_ID_fRfuUgjJT8h+nhyTMl0nMA==,comp-lzo
yes,ifconfig 5.5.26.139 255.255.240.0'
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in
[PUSH-OPTIONS]:4: dhcp-pre-release (2.1.4)
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in
[PUSH-OPTIONS]:5: dhcp-renew (2.1.4)
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in
[PUSH-OPTIONS]:6: dhcp-release (2.1.4)
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in
[PUSH-OPTIONS]:20: register-dns (2.1.4)
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in
[PUSH-OPTIONS]:21: auth-token (2.1.4)
2012-01-06 11:24:30 OPTIONS IMPORT: timers and/or timeouts modified
2012-01-06 11:24:30 OPTIONS IMPORT: explicit notify parm(s) modified
2012-01-06 11:24:30 OPTIONS IMPORT: LZO parms modified
2012-01-06 11:24:30 OPTIONS IMPORT: --ifconfig/up options modified
2012-01-06 11:24:30 OPTIONS IMPORT: route options modified
2012-01-06 11:24:30 OPTIONS IMPORT: route-related options modified
2012-01-06 11:24:30 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2012-01-06 11:24:30 ROUTE default_gateway=192.168.1.254
2012-01-06 11:24:30 TUN/TAP device /dev/tun0 opened
2012-01-06 11:24:30 MANAGEMENT: >STATE:1325870670,ASSIGN_IP,,
5.5.26.139,
2012-01-06 11:24:30 /sbin/ifconfig tun0 delete
ifconfig: ioctl (SIOCDIFADDR):
Can't assign requested address
2012-01-06 11:24:30 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2012-01-06 11:24:30 /sbin/ifconfig tun0 5.5.26.139 5.5.26.139 netmask
255.255.240.0 mtu 1500 up
2012-01-06 11:24:30 /sbin/route add -net 5.5.16.0 5.5.26.139
255.255.240.0
add net 5.5.16.0: gateway
5.5.26.139
2012-01-06 11:24:30 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d -atDASNGWrdasngw tun0 1500 1542
5.5.26.139 255.255.240.0 init
No such key
2012-01-06 11:24:32 *Tunnelblick client.up.tunnelblick.sh: Retrieved
name server(s) [ 192.168.1.14 192.168.1.12 ] and WINS server(s) [ ]
and using default domain name [ openvpn ]
2012-01-06 11:24:32 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2012-01-06 11:24:32 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2012-01-06 11:24:32 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with process-network-changes
2012-01-06 11:24:38 *Tunnelblick: Flushed the DNS cache
2012-01-06 11:24:38 MANAGEMENT: >STATE:1325870678,ADD_ROUTES,,,
2012-01-06 11:24:38 /sbin/route add -net 5.5.0.0 5.5.16.1
255.255.240.0
add net 5.5.0.0: gateway
5.5.16.1
2012-01-06 11:24:38 WARNING: potential route subnet conflict between
local LAN [192.168.1.0/255.255.255.0] and remote VPN
[192.168.0.0/255.255.0.0]
2012-01-06 11:24:38 /sbin/route add -net 192.168.0.0 5.5.16.1
255.255.0.0
add net 192.168.0.0: gateway
5.5.16.1
2012-01-06 11:24:38 /sbin/route add -net 172.16.0.0 5.5.16.1
255.240.0.0
add net 172.16.0.0: gateway
5.5.16.1
2012-01-06 11:24:38 /sbin/route add -net 10.0.0.0 5.5.16.1 255.0.0.0
add net 10.0.0.0: gateway
5.5.16.1
2012-01-06 11:24:38 Initialization Sequence Completed
2012-01-06 11:24:38 MANAGEMENT: >STATE:1325870678,CONNECTED,SUCCESS,
5.5.26.139,x.x.x.x
2012-01-06 11:25:07 *Tunnelblick process-network-changes: A system
configuration change was ignored because it was not relevant


and here is my client profile, with sensitive info xxxx'd out.


# Automatically generated OpenVPN client config file
# Generated on Fri Jan 6 03:08:36 2012 by localhost.localdom
# Note: this config file contains inline private keys
# and therefore should be kept confidential!
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=xx.xx
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=xxxx
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=vpn.xxxx.com:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# xxxx
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----xxxx
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN RSA PRIVATE KEY-----
xxxx
-----END RSA PRIVATE KEY-----
</key>

key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
xxxx
-----END OpenVPN Static key V1-----
</tls-auth>

## -----BEGIN RSA SIGNATURE-----
## DIGEST:xxxx
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## xxxx
## xxxx
## xxxx -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## xxxx-----END RSA SIGNATURE-----

[jkbull...gmail.com]

The immediate cause of your problem appears to be 

2012-01-06 11:24:38 WARNING: potential route subnet conflict between 
local LAN [192.168.1.0/255.255.255.0] and remote VPN 
[192.168.0.0/255.255.0.0] 

See https://groups.google.com/forum/#!topic/tunnelblick-discuss/QBdHinw7kak/discussion

There are also these messages:

2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in 
[PUSH-OPTIONS]:4: dhcp-pre-release (2.1.4) 
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in 
[PUSH-OPTIONS]:5: dhcp-renew (2.1.4) 
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in 
[PUSH-OPTIONS]:6: dhcp-release (2.1.4) 
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in 
[PUSH-OPTIONS]:20: register-dns (2.1.4) 
2012-01-06 11:24:30 Unrecognized option or missing parameter(s) in 
[PUSH-OPTIONS]:21: auth-token (2.1.4) 

-OPTIONS]:21: auth-token (2.1.4)

The server has apparently specified a number of options that are not recognized in OpenVPN 2.1.4. And  are a lot of options being pushed by the server that appear to be Windows-only and/or tap-only (you are apparently connecting via tun, not tap). So there could be problems there, too.

[Jacob Cantele]

Thanks so much for the quick response.

Could you give further clarification specific changes need to be made
on the server side to resolve those errors you noted?

Is it possible to make tunnelblick connect over tap instead of tun?
What is the best configuration to use?

On Jan 6, 1:06 pm, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> The immediate cause of your problem appears to be
>
> 2012-01-06 11:24:38 WARNING: potential route subnet conflict between
> local LAN [192.168.1.0/255.255.255.0] and remote VPN
> [192.168.0.0/255.255.0.0]
>

> Seehttps://groups.google.com/forum/#!topic/tunnelblick-discuss/QBdHinw7k...

[jkbull...gmail.com]

I'm sorry, but I can't provide much more information -- you should contact the OpenVPN forum and user groups for that. There are links to them in the left column on the Tunnelblick home page.

It is possible that the errors will be ignored, but you definitely need to fix the subnet conflict problem. The easiest way is probably to change the network address of the router you are trying to connect from (your home router, I assume). If you can change it to 192.168.XXX.0/255.255.255.0 where the XXX is something other than 0, that problem should be fixed.

I would note, however, that it is probably a mistake for whoever set up the network you are VPN-ing into to have set up their network using the most common subnet used by home routers (192.168.0.0/255.255.255.0) because of conflicts such as the one you encountered. Some hotel networks, for example, use that subnet, and would cause this same problem. If they changed the network you wouldn't have this problem and wouldn't need to change your home router settings.

[jkbull...gmail.com]

Also, see An OpenVPN log entry says "potential route subnet conflict" in the Common Problems wiki.

[Jacob Cantele]

Thanksn we been able to get users online by changing their home IP
subnet (we don't want to change the entire company's subnet). But, the
weird thing is, none of our PC users have this issue when using the
official client, even with the same subnet. Is there anything further
we could do to resolve this since it is only affecting our Mac users?

On Jan 6, 3:42 pm, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> Also, see An OpenVPN log entry says "potential route subnet conflict"<http://code.google.com/p/tunnelblick/wiki/cCommonProblems#An_OpenVPN_..."potential_route_subnet_conflict&> in
> the Common Problems wiki.

[jkbull...gmail.com]

I don't know of any way to resolve the conflict other than changing one of the subnets.

Conflicting subnets can be a problem even for your Windows users if they have a device with a local IP address that is the same as a device on your company subnet with the same IP address.