[Solved]Initialization Sequence Completed but no access

[Nico33]

Hello, I need help please, I will be grateful if you are patient enough to understand I'm a newbie here and I'm not english as well...
I installed OpenVPN by Homebrew, I'm running on Mac OsX Mavericks with latest updates.
I subscribed to a VPN server, I got my config file "*.ovpn", my key file "ta.key" and my ca file "ca.crt".
I would like to use OpenVPN through the terminal with commands line, but I've got Tunnelblick already installed that work perfectly.
I would like to be sure OpenVPN is working well by the terminal before uninstall Tunnelblick.
Tun/Tap Extensions are installed as well.

Here is my config file (.ovpn):

-------------------------

client
remote nl5.vpnfacile.net 443
dev tun
proto tcp
nobind
persist-key
persist-tun
tls-auth ta.key 1
ca ca.crt
cipher AES-256-CBC
keysize 256
link-mtu 1560
comp-lzo
auth-user-pass
verb 3

------------------------

So, When I want to start OpenVPN, I'm running this:

------------------------

sudo kextload tun.kext
sudo openvpn myconfigfile.ovpn

------------------------

Then I'm getting this:

------------------------

Wed Jan 28 11:20:58 2015 OpenVPN 2.3.6 x86_64-apple-darwin13.4.0 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Dec 2 2014
Wed Jan 28 11:20:58 2015 library versions: OpenSSL 1.0.2 22 Jan 2015, LZO 2.08
Enter Auth Username:********
Enter Auth Password:
Wed Jan 28 11:21:13 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Jan 28 11:21:13 2015 WARNING: file 'ta.key' is group or others accessible
Wed Jan 28 11:21:13 2015 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Wed Jan 28 11:21:13 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 28 11:21:13 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 28 11:21:13 2015 Socket Buffers: R=[131072->65536] S=[131072->65536]
Wed Jan 28 11:21:13 2015 Attempting to establish TCP connection with [AF_INET]185.56.161.130:443 [nonblock]
Wed Jan 28 11:21:14 2015 TCP connection established with [AF_INET]185.56.161.130:443
Wed Jan 28 11:21:14 2015 TCPv4_CLIENT link local: [undef]
Wed Jan 28 11:21:14 2015 TCPv4_CLIENT link remote: [AF_INET]185.56.161.130:443
Wed Jan 28 11:21:14 2015 TLS: Initial packet from [AF_INET]185.56.161.130:443, sid=72995fae 9a2e7f7a
Wed Jan 28 11:21:14 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jan 28 11:21:15 2015 VERIFY OK: depth=1, C=NL, ST=NL, L=Amsterdam, O=VPNFacile, CN=VPNFacile CA, emailAddress=*********
Wed Jan 28 11:21:15 2015 VERIFY OK: depth=0, C=NL, ST=NL, L=Amsterdam, O=VPNFacile, CN=server, emailAddress=tech@vpnfacile.net
Wed Jan 28 11:21:15 2015 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Jan 28 11:21:15 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 28 11:21:15 2015 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Jan 28 11:21:15 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 28 11:21:15 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Jan 28 11:21:15 2015 [server] Peer Connection Initiated with [AF_INET]185.56.161.130:443
Wed Jan 28 11:21:18 2015 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jan 28 11:21:18 2015 PUSH: Received control message: 'PUSH_REPLY,dhcp-option WINS 10.14.0.1,redirect-gateway def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.14.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.14.0.186 10.14.0.185'
Wed Jan 28 11:21:18 2015 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jan 28 11:21:18 2015 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jan 28 11:21:18 2015 OPTIONS IMPORT: route options modified
Wed Jan 28 11:21:18 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Jan 28 11:21:18 2015 Opening utun (connect(AF_SYS_CONTROL)): Resource busy
Wed Jan 28 11:21:18 2015 Opened utun device utun1
Wed Jan 28 11:21:18 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jan 28 11:21:18 2015 /sbin/ifconfig utun1 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
Wed Jan 28 11:21:18 2015 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Wed Jan 28 11:21:18 2015 /sbin/ifconfig utun1 10.14.0.186 10.14.0.185 mtu 1500 netmask 255.255.255.255 up
Wed Jan 28 11:21:18 2015 /sbin/route add -net 185.56.161.130 192.168.0.254 255.255.255.255
add net 185.56.161.130: gateway 192.168.0.254
Wed Jan 28 11:21:18 2015 /sbin/route add -net 0.0.0.0 10.14.0.185 128.0.0.0
add net 0.0.0.0: gateway 10.14.0.185
Wed Jan 28 11:21:18 2015 /sbin/route add -net 128.0.0.0 10.14.0.185 128.0.0.0
add net 128.0.0.0: gateway 10.14.0.185
Wed Jan 28 11:21:18 2015 /sbin/route add -net 10.14.0.1 10.14.0.185 255.255.255.255
add net 10.14.0.1: gateway 10.14.0.185
Wed Jan 28 11:21:18 2015 Initialization Sequence Completed

--------------------------

It seems connected, but in safari for example It looks like It's offline...
I tried to disable my firewall to have look but nothing changes.
I also had a look on Tunnelblick and both logs seem similar.
I don't have any idea about what I'm done wrong, so if someone could give me a hand that will be really appreciated...

Thanks.

[maikcat]

possibly DNS issue,

can you post the output of

traceroute 8.8.8.8

after your client is up?

Michael.

[Nico33]

Hi, thanks for answering, When I'm connected to OpenVPN by the terminal,
"traceroute 8.8.8.8" give me:

--------------------------

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 10.10.0.1 (10.10.0.1) 321.365 ms 228.350 ms 284.699 ms
2 31.220.29.1 (31.220.29.1) 266.648 ms 293.144 ms 424.511 ms
3 ic-root.lux.as5577.net (199.59.206.97) 571.785 ms 360.492 ms 340.221 ms
4 te2-1.r3.ams.sara.nl.iptransit.com (204.26.60.14) 221.619 ms 207.589 ms 151.779 ms
5 xe-3-3-3.r2.ams.tc2.nl.iptransit.com (204.26.60.5) 217.637 ms 364.346 ms 231.898 ms
6 ae0.r1.haar.nl.iptransit.com (204.26.60.17) 235.957 ms 164.416 ms 239.752 ms
7 core1.ams.net.google.com (80.249.208.247) 271.480 ms 287.976 ms 292.689 ms
8 209.85.249.225 (209.85.249.225) 313.376 ms
209.85.248.79 (209.85.248.79) 273.973 ms
209.85.241.237 (209.85.241.237) 309.142 ms
9 google-public-dns-a.google.com (8.8.8.8) 177.856 ms 196.565 ms 227.284 ms

---------------------------

That begins to be too complicated for me to understand something here...

[maikcat]

can you please post the output of:

netstat -nr

on your client again with the vpn up?

Michael.

[Nico33]

Ok, sorry, first time I've done "traceroute 8.8.8.8" I forgot to kill Tunneblick that was running in background...
So, with Tunnelblick off and OpenVPN on "trace route 8.8.8.8" give me this:

------------------------

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 10.14.0.1 (10.14.0.1) 56.559 ms 56.077 ms 53.678 ms
2 185.56.161.129 (185.56.161.129) 52.635 ms 106.684 ms 53.808 ms
3 149.6.90.25 (149.6.90.25) 54.981 ms 52.932 ms 63.139 ms
4 130.117.0.173 (130.117.0.173) 57.213 ms 59.442 ms
130.117.0.129 (130.117.0.129) 57.616 ms
5 154.54.39.21 (154.54.39.21) 59.551 ms
154.54.39.97 (154.54.39.97) 60.151 ms
154.54.39.21 (154.54.39.21) 66.611 ms
6 154.54.39.129 (154.54.39.129) 60.115 ms 61.759 ms 59.805 ms
7 149.14.8.150 (149.14.8.150) 56.453 ms 56.707 ms 57.312 ms
8 216.239.47.23 (216.239.47.23) 56.416 ms
64.233.174.219 (64.233.174.219) 65.524 ms
216.239.47.23 (216.239.47.23) 78.563 ms
9 216.239.48.87 (216.239.48.87) 59.852 ms
216.239.47.53 (216.239.47.53) 67.931 ms
216.239.47.159 (216.239.47.159) 68.439 ms
10 8.8.8.8 (8.8.8.8) 87.971 ms 60.228 ms 57.690 ms

--------------------------

And "netstat -nr" give me this:

--------------------------

Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
0/1 10.14.0.185 UGSc 9 33 utun1
default 192.168.0.254 UGSc 2 0 en1
10.14.0.1/32 10.14.0.185 UGSc 0 0 utun1
10.14.0.185 10.14.0.186 UHr 15 0 utun1
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 5 11926 lo0
128.0/1 10.14.0.185 UGSc 3 0 utun1
169.254 link#5 UCS 0 0 en1
185.56.161.130/32 192.168.0.254 UGSc 1 0 en1
192.168.0 link#5 UCS 2 0 en1
192.168.0.12 127.0.0.1 UHS 0 4 lo0
192.168.0.254 0:7:cb:4b:97:cd UHLWIir 3 404 en1 1174
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 7 en1

Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UHL lo0
fd05:ea91:6ce6:e311::/64 fe80::2dbc:55bf:9b95:7e16%utun0 Uc utun0
fd05:ea91:6ce6:e311:2dbc:55bf:9b95:7e16 link#8 UHL lo0
fe80::%lo0/64 fe80::1%lo0 UcI lo0
fe80::1%lo0 link#1 UHLI lo0
fe80::%en1/64 link#5 UCI en1
fe80::148d:d8f2:185c:cf88%en1 2c:1f:23:54:4b:f9 UHLWI en1
fe80::daa2:5eff:fe91:aad1%en1 d8:a2:5e:91:aa:d1 UHLI lo0
fe80::%utun0/64 fe80::2dbc:55bf:9b95:7e16%utun0 UcI utun0
fe80::2dbc:55bf:9b95:7e16%utun0 link#8 UHLI lo0
ff01::%lo0/32 ::1 UmCI lo0
ff01::%en1/32 link#5 UmCI en1
ff01::%utun0/32 fe80::2dbc:55bf:9b95:7e16%utun0 UmCI utun0
ff02::%lo0/32 ::1 UmCI lo0
ff02::%en1/32 link#5 UmCI en1
ff02::%utun0/32 fe80::2dbc:55bf:9b95:7e16%utun0 UmCI utun0

-------------------------------

I can see that's talking about my virtual interface but what does it mean?

[Nico33]

OK, someone explain me where was the mistake (that was not really one, just miss to configure safari).
That's the solution and I confirm that's working:

(1) You don't need tuntap on OS X 10.6.8 or higher when using OpenVPN 2.3.something or higher, because OpenVPN will automatically use the "utun" device built into OS X. You can see that happening here:

Wed Jan 28 11:21:18 2015 Opened utun device utun1

(2) You can ignore the

Wed Jan 28 11:21:18 2015 /sbin/ifconfig utun1 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

message. It shows up because there was no existing utun1 device (which is correct) and is normal. That's why the following message appears:

Wed Jan 28 11:21:18 2015 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

(3) It is possible that a loaded tun kext interferes with using the utun device. So make sure the tun kext is unloaded when you try to connect to the VPN. The OpenVPN log should then start mentioning "utun0" instead of "utun1".

(4) Probably the reason you can't reach websites is a DNS problem. The setup you have gets instructions to use a DNS server from the OpenVPN server (in the "PUSH_REPLY"). The server tells the client (your computer) to use 8.8.8.8 and 8.8.4.4 (both are for Google Public DNS) while the VPN is connected. However, without doing anything else, that instruction will be ignored. OpenVPN (on OS X, anyway) doesn't deal with DNS and WINS itself, it assumes you have a helper script (usually an "up" script) that processes the request and sets up DNS and WINS on your computer as instructed. Tunnelblick includes several scripts to do just that; which one (or none) is specified by Tunnelblick's "Set DNS/WINS" setting.

When you are connected to the VPN, your DNS requests will not appear to come from your computer, they will appear to come from the OpenVPN server. If you have (as is typical) DNS set to your ISP's DNS servers, those servers will not respond to DNS requests from outside of their own network. The OpenVPN server is outside of their network, so they will ignore the DNS requests, and you won't be able to browse to "www.google.com" (but you should be able to browse to site by IP address instead of name).

A solution to this is to manually set your DNS to public DNS servers before connecting to the VPN. There is a list of servers at http://pcsupport.about.com/od/tipstrick ... ervers.htm.

(5) A simpler solution is to, well, use Tunnelblick! If you want to control it from the command line or Automator, use AppleScript (see https://code.google.com/p/tunnelblick/w ... iptSupport).

Thanks.

[maikcat]

(1) You don't need tuntap on OS X 10.6.8 or higher when using OpenVPN 2.3.something or higher, because OpenVPN will automatically use the "utun" device built into OS X. You can see that happening here:

I am NOT a mac user so the above is unknown to me..

(2) You can ignore the

Wed Jan 28 11:21:18 2015 /sbin/ifconfig utun1 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

message. It shows up because there was no existing utun1 device (which is correct) and is normal. That's why the following message appears:

Wed Jan 28 11:21:18 2015 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

thats why no one mentioned anything about it

(3) It is possible that a loaded tun kext interferes with using the utun device. So make sure the tun kext is unloaded when you try to connect to the VPN. The OpenVPN log should then start mentioning "utun0" instead of "utun1".

again not a mac user here...

4) Probably the reason you can't reach websites is a DNS problem.

you can read the first line of my first post

When you are connected to the VPN, your DNS requests will not appear to come from your computer, they will appear to come from the OpenVPN server.

this occurs because of 2 things, your default gateway is altered and possibly the openvpn server performs NAT.

so i will mark this one as solved.

Michael.

[rahul01]

You can change some lines in the openvpn configuration file ----------

Change "cipher AES-256-CBC" to "data-ciphers AES-256-CBC"
And then save and connect, you get successfully get the connectivity .