OpenVPN Support Forum

Community Support Forum
https://forums.openvpn.net/

[Solved]gave up trying to fetch IP address information

https://forums.openvpn.net/viewtopic.php?t=17877

Page 1 of 1

[Solved]gave up trying to fetch IP address information

Posted: Fri Jan 02, 2015 4:46 am
by mcsass
Happy New Year!

Can anyone help me with my configuration?

I am running OS X 10.8.5, trying to use Tunnelblick 3.4.2 to connect to my Netgear R7000 running DD-WRT.

After some trouble shooting and Googleing, I have decided to see if anyone else can help me with my latest issue.

The error I am getting is:

Code: Select all

2015-01-01 20:05:44 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting.
2015-01-01 20:06:14 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's IP address after connecting.
Any help would be greatly appreciated!

Code: Select all

*Tunnelblick: OS X 10.8.5; Tunnelblick 3.4.2 (build 4055.4161); Admin user

"Sanitized" condensed configuration file for /Library/Application Support/Tunnelblick/Shared/XXXVPN.tblk:

client
dev tun
proto udp
remote XXX.mynetgear.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
cipher BF-CBC
comp-lzo
redirect-gateway def1
verb 5


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

"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 XXX.mynetgear.com 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 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 client1.crt
key client1.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 BF-CBC

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
redirect-gateway def1

# Set log file verbosity.
verb 5

# Silence repeating messages
;mute 20

Re: gave up trying to fetch IP address information using the

Posted: Fri Jan 02, 2015 8:14 am
by maikcat
server config/log?

Michael.

Re: gave up trying to fetch IP address information using the

Posted: Mon Jan 12, 2015 6:09 pm
by kamal.gajendran@decisionnext.com
I am getting the same error as well. Everything was working until a week ago, and I started getting this error on the client with no changes on the server or client. I have been trying to debug this the last 2 days, but no luck yet.

Client log -
Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting
Client popup -
After connecting to xxx, the Internet does not appear to be reachable. This may mean that your VPN is not configured correctly
I was at TunnelBlick 3.4.x, and now upgraded to 3.5.beta04. Get the same error. Here is the client configuration -

Code: Select all

client
proto udp
remote xxxx.yyy.com
port 1194
dev tun
dev-type tun
ns-cert-type server
reneg-sec 86400
auth-user-pass
auth-retry interact
comp-lzo yes
verb 3
ca ca.crt
cert xxx.crt
key xxx.key
resolv-retry infinite
persist-key
persist-tun
mute-replay-warnings
keepalive 3 10
Server configuration (openvpn 2.3.2, Ubuntu 14.04 on AWS)

Code: Select all

port 1194
proto udp
dev tun
ca ca.crt
cert yyy.crt
key yyy.key
dh xxx.pem
server 10.8.0.0 255.255.255.0
keepalive 10 120
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
comp-lzo
user AAAAA
group BBBBB
persist-key
persist-tun

# use this for ldap + google authentication (can be used in combination with certificate)
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn

status openvpn-status.log
verb 3
Server logs -

Code: Select all

TLS: new session incoming connection from [AF_INET]xxx.xx.xx.xxx:1047
VERIFY OK
VERIFY OK
PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
TLS: Username/Password authentication succeeded for username '' 
Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
TLS: tls_multi_process: untrusted session promoted to semi-trusted
Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
PUSH: Received control message: 'PUSH_REQUEST'
send_push_reply(): safe_cap=940
SENT CONTROL [username]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

Re: gave up trying to fetch IP address information using the

Posted: Tue Jan 13, 2015 6:36 am
by maikcat
can you post the output of:

tracert 8.8.8.8 (on your client)
netstat -nr (client)
iptables -L -t nat -v (on your server)

Michael.

Re: gave up trying to fetch IP address information using the

Posted: Tue Jan 13, 2015 8:15 am
by kamal.gajendran@decisionnext.com
Hi Michael, thanks for trying to help. Here are the details you requested.

Client is a OS X 10.9.5.

Code: Select all

$ netstat -nr 
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.5           UGSc           17        0   utun0
default            192.168.1.254      UGSc            5        0     en0
10.8.0.1/32        10.8.0.5           UGSc            0        0   utun0
10.8.0.5           10.8.0.6           UHr            27        0   utun0
xx.xxx.xx.xxx/32  192.168.1.254      UGSc            1        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              7   229635     lo0
128.0/1            10.8.0.5           UGSc            7        0   utun0
169.254            link#4             UCS             0        0     en0
192.168.1          link#4             UCS             2        0     en0
192.168.1.22       127.0.0.1          UHS             0        1     lo0
192.168.1.254      34:ef:44:7d:f0:e1  UHLWIir         3      232     en0   1200
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        3     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
fe80::8e1:192b:16dd:3ffe%en0            7c:d1:c3:16:ff:af               UHLWI           en0
fe80::6233:4bff:fe21:2b19%en0           60:33:4b:21:2b:19               UHLWI           en0
fe80::6676:baff:fe91:ec72%en0           64:76:ba:91:ec:72               UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#4                          UmCI            en0
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#4                          UmCI            en0

Code: Select all

Traceroute has started…

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
 1  10.8.0.1 (10.8.0.1)  99.086 ms  97.068 ms  98.447 ms
 2  100.101.150.193 (100.101.150.193)  108.076 ms  99.296 ms  100.687 ms
 3  100.90.233.15 (100.90.233.15)  97.747 ms  97.389 ms  100.724 ms
 4  100.90.233.36 (100.90.233.36)  98.531 ms  97.701 ms  98.302 ms
 5  * * *
 6  * * *
 7  100.67.133.29 (100.67.133.29)  100.498 ms  98.599 ms  100.520 ms
 8  100.67.142.92 (100.67.142.92)  100.754 ms  98.747 ms  99.077 ms
 9  100.67.156.80 (100.67.156.80)  98.175 ms  99.013 ms  99.250 ms
10  100.64.36.17 (100.64.36.17)  98.648 ms  108.636 ms  100.296 ms
11  * * *
12  * * *
13  * * *
14  100.64.16.199 (100.64.16.199)  97.880 ms  97.979 ms  97.959 ms
15  205.251.245.64 (205.251.245.64)  98.339 ms  102.001 ms  98.534 ms
16  72.21.220.68 (72.21.220.68)  97.663 ms  98.397 ms  97.966 ms
17  72.14.212.130 (72.14.212.130)  99.582 ms  102.917 ms  103.387 ms
18  209.85.250.67 (209.85.250.67)  101.005 ms  99.645 ms  98.073 ms
19  216.239.51.9 (216.239.51.9)  98.219 ms  102.506 ms  103.696 ms
20  google-public-dns-a.google.com (8.8.8.8)  99.471 ms  98.502 ms  98.978 ms

Code: Select all

iptables -L -t nat -v
Chain PREROUTING (policy ACCEPT 178 packets, 12804 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 29 packets, 2842 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 13 packets, 954 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 13 packets, 954 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    eth0    ip-192-168-42-0.ec2.internal/24  anywhere            
  146  9746 MASQUERADE  all  --  any    eth0    ip-10-8-0-0.ec2.internal/24  anywhere

Re: gave up trying to fetch IP address information using the

Posted: Tue Jan 13, 2015 10:01 am
by maikcat
can you test that DNS resolving works?

packets are routed via vpn...

Michael

Re: gave up trying to fetch IP address information using the

Posted: Tue Jan 13, 2015 7:05 pm
by kamal.gajendran@decisionnext.com
Michael,

Yes, we want the packets routed via VPN. The DNS resolves both on the client and the server.

Code: Select all

Mac Client

$ nslookup www.example.com.
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	www.example.com
Address: 93.184.216.34

$ ping www.example.com
PING www.example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=46 time=98.537 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=46 time=98.705 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=46 time=98.498 ms

Code: Select all

Ubuntu 14.04 Server

$ nslookup www.example.com.
Server:		172.16.0.23
Address:	172.16.0.23#53

Non-authoritative answer:
Name:	www.example.com
Address: 93.184.216.34

$ ping www.example.com
PING www.example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=47 time=1.08 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=47 time=0.992 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=47 time=0.981 ms
thanks, Kamal

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 15, 2015 7:31 pm
by mcbrown
Just want to chime in because I have been having the exact same problem and found this thread searching for a resolution... a previously working configuration has recently started giving the same error in Tunnelblick (I can't say when it started with certainty, because several weeks had elapsed between VPN logins from the Mac client).

Client is running Tunnelblick 3.4.2 on OS X 10.10.1. Server is a Raspberry Pi running OpenVPN 2.2.1 on Raspbian.

Just like Kamal is observing, DNS is resolving on both client and server - on the client it is just resolving outside the VPN, despite checking the "Route all traffic through the VPN" option in Tunnelblick. I have made no configuration changes since the last successful use of the VPN, other than software updates.

I was starting to think it was a Yosemite issue, but perhaps it's an issue with Tunnelblick 3.4.2.

Re: gave up trying to fetch IP address information using the

Posted: Fri Jan 16, 2015 7:24 am
by Geoker
I'm also having the same problem.
Client is running Tunnelblick: OS X 10.10.1; Tunnelblick 3.4.3 (build4055.4198); prior version 3.4.2 (build 4055.4161)

And the servers are multiple openvpn and ubuntu versions.

Re: gave up trying to fetch IP address information using the

Posted: Fri Jan 16, 2015 1:13 pm
by Traffic
It would be useful if somebody posted full client and server logs at verb 4 and full config files.

Re: gave up trying to fetch IP address information using the

Posted: Sat Jan 17, 2015 9:40 pm
by mcbrown
Server config:

Code: Select all

port 1194
proto udp
dev tap0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/keyserver.crt
key /etc/openvpn/easy-rsa/keys/keyserver.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.1.19 255.255.255.0 192.168.1.240 192.168.1.254
push "route 192.168.1.0 255.255.255.0 192.168.1.1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.8.4"
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 # This file is secret
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 4
mute 10
Client config:

Code: Select all

client
dev tap0
proto udp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1
cipher AES-256-CBC
comp-lzo
verb 4
mute 20
Server log:

Code: Select all

Sat Jan 17 16:07:21 2015 us=182256 MULTI: multi_create_instance called
Sat Jan 17 16:07:21 2015 us=182823 1.2.3.4:52655 Re-using SSL/TLS context
Sat Jan 17 16:07:21 2015 us=183314 1.2.3.4:52655 LZO compression initialized
Sat Jan 17 16:07:21 2015 us=185141 1.2.3.4:52655 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sat Jan 17 16:07:21 2015 us=185408 1.2.3.4:52655 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF
:3/1 ]
Sat Jan 17 16:07:21 2015 us=185921 1.2.3.4:52655 Local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532
,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Sat Jan 17 16:07:21 2015 us=186268 1.2.3.4:52655 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tu
n-mtu 1532,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Sat Jan 17 16:07:21 2015 us=186709 1.2.3.4:52655 Local Options hash (VER=V4): '44bd8b5e'
Sat Jan 17 16:07:21 2015 us=186959 1.2.3.4:52655 Expected Remote Options hash (VER=V4): '48527533'
Sat Jan 17 16:07:21 2015 us=187485 1.2.3.4:52655 TLS: Initial packet from [AF_INET]1.2.3.4:52655, sid=d72723
6e 447fce72
Sat Jan 17 16:07:22 2015 us=339935 1.2.3.4:52655 Replay-window backtrack occurred [1]
Sat Jan 17 16:07:22 2015 us=417102 1.2.3.4:52655 VERIFY OK: depth=1, /C=US/ST=NY/L=NewYork/O=X/OU=changeme/CN=c
hangeme/name=changeme/emailAddress=Y@Z.com
Sat Jan 17 16:07:22 2015 us=421079 1.2.3.4:52655 VERIFY OK: depth=0, /C=US/ST=NY/L=NewYork/O=X/OU=changeme/CN=CLIENT/name=changeme/emailAddress=Y@Z.com
Sat Jan 17 16:07:25 2015 us=457006 1.2.3.4:52655 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 b
it key
Sat Jan 17 16:07:25 2015 us=457366 1.2.3.4:52655 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC 
authentication
Sat Jan 17 16:07:25 2015 us=457570 1.2.3.4:52655 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 b
it key
Sat Jan 17 16:07:25 2015 us=457778 1.2.3.4:52655 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC 
authentication
Sat Jan 17 16:07:25 2015 us=532495 1.2.3.4:52655 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 20
48 bit RSA
Sat Jan 17 16:07:25 2015 us=532908 1.2.3.4:52655 [CLIENT] Peer Connection Initiated with [AF_INET]1.2.3.4:52655
Sat Jan 17 16:07:25 2015 us=533360 CLIENT/1.2.3.4:52655 MULTI_sva: pool returned IPv4=192.168.1.241, IPv6
=48e1:bbbe:804e:f1b6:347b:f6b6:c1d:d1b7
Sat Jan 17 16:07:27 2015 us=631480 CLIENT/1.2.3.4:52655 PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 17 16:07:27 2015 us=631782 CLIENT/1.2.3.4:52655 send_push_reply(): safe_cap=960
Sat Jan 17 16:07:27 2015 us=632555 CLIENT/1.2.3.4:52655 SENT CONTROL [CLIENT]: 'PUSH_REPLY,route
 192.168.1.0 255.255.255.0 192.168.1.1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.8.4,route-gateway 192.168.1.19,ping 1
0,ping-restart 120,ifconfig 192.168.1.241 255.255.255.0' (status=1)
Sat Jan 17 16:07:31 2015 us=14749 CLIENT/1.2.3.4:52655 MULTI: Learn: 7a:c7:f8:52:94:47 -> CLIENT
/1.2.3.4:52655
Sat Jan 17 16:07:32 2015 us=157231 CLIENT/1.2.3.4:52655 Replay-window backtrack occurred [7]
Sat Jan 17 16:08:42 2015 us=753480 read UDPv4 [ECONNREFUSED|ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=196478 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=230807 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=430694 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=439961 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=506400 read UDPv4 [ECONNREFUSED|ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=588829 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=741358 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:43 2015 us=935385 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:44 2015 us=222903 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:44 2015 us=411791 NOTE: --mute triggered...
Client log:

Code: Select all

2015-01-17 16:07:14 *Tunnelblick: OS X 10.10.1; Tunnelblick 3.4.3 (build 4055.4198); prior version 3.4.2 (build 4055.4161)
2015-01-17 16:07:14 *Tunnelblick: Attempting connection with CLIENT using shadow copy; Set nameserver = 1; monitoring connection
2015-01-17 16:07:14 *Tunnelblick: openvpnstart start CLIENT.tblk 1337 1 0 1 0 17266 -ptADGNWradsgnw 2.3.6
2015-01-17 16:07:15 *Tunnelblick: openvpnstart log:
     Tunnelblick: Loading tap-signed.kext
     Tunnelblick: 
     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):
     
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6/openvpn
          --daemon
          --log
          /Library/Application Support/Tunnelblick/Logs/-SUsers-SX-SLibrary-SApplication Support-STunnelblick-SConfigurations-SCLIENT.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_17266.1337.openvpn.log
          --cd
          /Library/Application Support/Tunnelblick/Users/X/CLIENT.tblk/Contents/Resources
          --config
          /Library/Application Support/Tunnelblick/Users/X/CLIENT.tblk/Contents/Resources/config.ovpn
          --cd
          /Library/Application Support/Tunnelblick/Users/X/CLIENT.tblk/Contents/Resources
          --management
          127.0.0.1
          1337
          --management-query-passwords
          --management-hold
          --redirect-gateway
          def1
          --script-security
          2
          --up
          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw
          --down
          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw
          --route-pre-down
          /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw

2015-01-17 16:07:14 *Tunnelblick: openvpnstart starting OpenVPN
2015-01-17 16:07:15 *Tunnelblick: Established communication with OpenVPN
2015-01-17 16:07:15 us=491941 Current Parameter Settings:
2015-01-17 16:07:15 us=492077   config = '/Library/Application Support/Tunnelblick/Users/X/CLIENT.tblk/Contents/Resources/config.ovpn'
2015-01-17 16:07:15 us=492085   mode = 0
2015-01-17 16:07:15 us=492089   show_ciphers = DISABLED
2015-01-17 16:07:15 us=492093   show_digests = DISABLED
2015-01-17 16:07:15 us=492097   show_engines = DISABLED
2015-01-17 16:07:15 us=492101   genkey = DISABLED
2015-01-17 16:07:15 us=492105   key_pass_file = '[UNDEF]'
2015-01-17 16:07:15 us=492109   show_tls_ciphers = DISABLED
2015-01-17 16:07:15 us=492113 Connection profiles [default]:
2015-01-17 16:07:15 us=492117   proto = udp
2015-01-17 16:07:15 us=492121   local = '[UNDEF]'
2015-01-17 16:07:15 us=492125   local_port = 0
2015-01-17 16:07:15 us=492128   remote = '4.3.2.1'
2015-01-17 16:07:15 us=492132   remote_port = 1194
2015-01-17 16:07:15 us=492136   remote_float = DISABLED
2015-01-17 16:07:15 us=492140   bind_defined = DISABLED
2015-01-17 16:07:15 us=492144   bind_local = DISABLED
2015-01-17 16:07:15 us=492148   connect_retry_seconds = 5
2015-01-17 16:07:15 us=492151   connect_timeout = 10
2015-01-17 16:07:15 us=492155 NOTE: --mute triggered...
2015-01-17 16:07:15 us=492169 252 variation(s) on previous 20 message(s) suppressed by --mute
2015-01-17 16:07:15 us=492177 OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan  8 2015
2015-01-17 16:07:15 us=492187 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
2015-01-17 16:07:15 us=493033 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2015-01-17 16:07:15 us=493639 Need hold release from management interface, waiting...
2015-01-17 16:07:15 us=699843 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2015-01-17 16:07:15 us=762777 MANAGEMENT: CMD 'pid'
2015-01-17 16:07:15 us=762948 MANAGEMENT: CMD 'state on'
2015-01-17 16:07:15 us=763032 MANAGEMENT: CMD 'state'
2015-01-17 16:07:15 us=763148 MANAGEMENT: CMD 'bytecount 1'
2015-01-17 16:07:15 us=763221 MANAGEMENT: CMD 'hold release'
2015-01-17 16:07:15 us=763465 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2015-01-17 16:07:20 us=525460 MANAGEMENT: CMD 'password [...]'
2015-01-17 16:07:20 us=525780 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2015-01-17 16:07:20 us=526383 Control Channel Authentication: tls-auth using INLINE static key file
2015-01-17 16:07:20 us=526731 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-01-17 16:07:20 us=526900 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-01-17 16:07:20 us=527046 LZO compression initialized
2015-01-17 16:07:20 us=527231 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
2015-01-17 16:07:20 us=527379 Socket Buffers: R=[196724->65536] S=[9216->65536]
2015-01-17 16:07:20 us=527723 MANAGEMENT: >STATE:1421528840,RESOLVE,,,
2015-01-17 16:07:21 us=12940 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
2015-01-17 16:07:21 us=13157 Local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
2015-01-17 16:07:21 us=13260 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
2015-01-17 16:07:21 us=13369 Local Options hash (VER=V4): '48527533'
2015-01-17 16:07:21 us=13497 Expected Remote Options hash (VER=V4): '44bd8b5e'
2015-01-17 16:07:21 us=13604 UDPv4 link local: [undef]
2015-01-17 16:07:21 us=13798 UDPv4 link remote: [AF_INET]4.3.2.1:1194
2015-01-17 16:07:21 us=13968 MANAGEMENT: >STATE:1421528841,WAIT,,,
2015-01-17 16:07:21 us=108834 MANAGEMENT: >STATE:1421528841,AUTH,,,
2015-01-17 16:07:21 us=109012 TLS: Initial packet from [AF_INET]4.3.2.1:1194, sid=494d1b03 f4d0a11d
2015-01-17 16:07:21 us=815852 VERIFY OK: depth=1, C=US, ST=NY, L=NewYork, O=X, OU=changeme, CN=changeme, name=changeme, emailAddress=Y@Z.com
2015-01-17 16:07:21 us=816711 VERIFY OK: nsCertType=SERVER
2015-01-17 16:07:21 us=816827 VERIFY OK: depth=0, C=US, ST=NY, L=NewYork, O=X, OU=changeme, CN=keyserver, name=changeme, emailAddress=Y@Z.com
2015-01-17 16:07:25 us=411380 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2015-01-17 16:07:25 us=411593 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-01-17 16:07:25 us=411719 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2015-01-17 16:07:25 us=411992 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-01-17 16:07:25 us=412296 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
2015-01-17 16:07:25 us=412483 [keyserver] Peer Connection Initiated with [AF_INET]4.3.2.1:1194
2015-01-17 16:07:26 us=251964 MANAGEMENT: >STATE:1421528846,GET_CONFIG,,,
2015-01-17 16:07:27 us=480674 SENT CONTROL [keyserver]: 'PUSH_REQUEST' (status=1)
2015-01-17 16:07:27 us=558223 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0 192.168.1.1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.8.4,route-gateway 192.168.1.19,ping 10,ping-restart 120,ifconfig 192.168.1.241 255.255.255.0'
2015-01-17 16:07:27 us=558527 OPTIONS IMPORT: timers and/or timeouts modified
2015-01-17 16:07:27 us=558668 OPTIONS IMPORT: --ifconfig/up options modified
2015-01-17 16:07:27 us=558761 OPTIONS IMPORT: route options modified
2015-01-17 16:07:27 us=558845 OPTIONS IMPORT: route-related options modified
2015-01-17 16:07:27 us=558924 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2015-01-17 16:07:27 us=559533 TUN/TAP device /dev/tap0 opened
2015-01-17 16:07:27 us=559702 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2015-01-17 16:07:27 us=559860 MANAGEMENT: >STATE:1421528847,ASSIGN_IP,,192.168.1.241,
2015-01-17 16:07:27 us=559978 /sbin/ifconfig tap0 delete
                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2015-01-17 16:07:27 us=567244 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2015-01-17 16:07:27 us=567406 /sbin/ifconfig tap0 192.168.1.241 netmask 255.255.255.0 mtu 1500 up
2015-01-17 16:07:27 us=569901 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1590 192.168.1.241 255.255.255.0 init
                                        **********************************************
                                        Start of output from client.up.tunnelblick.sh
                                        Configuring tap DNS via OpenVPN
                                        Retrieved from OpenVPN: name server(s) [ 8.8.8.8 8.8.8.4 ], search domain(s) [  ] and SMB server(s) [  ] and using default domain name [ openvpn ]
                                        ServerAddresses '8.8.8.8 8.8.8.4' ignored because ServerAddresses was set manually
                                        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 8.8.8.8
                                        Set SearchDomains   to openvpn
                                        Set DomainName       to openvpn
                                        Flushed the DNS cache via dscacheutil
                                        No matching processes were found
                                        mDNSResponder not running. Not notifying it that the DNS cache was flushed
                                        Setting up to monitor system configuration with process-network-changes
                                        End of output from client.up.tunnelblick.sh
                                        **********************************************
2015-01-17 16:07:30 us=854206 /sbin/route add -net 4.3.2.1 4.20.10.1 255.255.255.255
                                        add net 4.3.2.1: gateway 4.20.10.1
2015-01-17 16:07:30 us=858052 /sbin/route add -net 0.0.0.0 192.168.1.19 128.0.0.0
                                        add net 0.0.0.0: gateway 192.168.1.19
2015-01-17 16:07:30 us=860031 /sbin/route add -net 128.0.0.0 192.168.1.19 128.0.0.0
                                        add net 128.0.0.0: gateway 192.168.1.19
2015-01-17 16:07:30 us=861833 MANAGEMENT: >STATE:1421528850,ADD_ROUTES,,,
2015-01-17 16:07:30 us=861944 /sbin/route add -net 192.168.1.0 192.168.1.1 255.255.255.0
                                        route: writing to routing socket: File exists
                                        add net 192.168.1.0: gateway 192.168.1.1: File exists
2015-01-17 16:07:30 us=863755 Initialization Sequence Completed
2015-01-17 16:07:30 us=863882 MANAGEMENT: >STATE:1421528850,CONNECTED,SUCCESS,192.168.1.241,4.3.2.1
2015-01-17 16:07:31 *Tunnelblick: No 'connected.sh' script to execute
2015-01-17 16:07:35 *Tunnelblick process-network-changes: A system configuration change was ignored
2015-01-17 16:08:06 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's name after connecting.
2015-01-17 16:08:36 *Tunnelblick: After 30.0 seconds, gave up trying to fetch IP address information using the ipInfo host's IP address after connecting.
2015-01-17 16:08:42 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed
2015-01-17 16:08:42 *Tunnelblick: Disconnecting using 'kill'
2015-01-17 16:08:42 us=193109 event_wait : Interrupted system call (code=4)
2015-01-17 16:08:42 us=193626 TCP/UDP: Closing socket
2015-01-17 16:08:42 us=193754 /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1590 192.168.1.241 255.255.255.0 init
                                        **********************************************
                                        Start of output from client.route-pre-down.tunnelblick.sh
                                        No action by client.route-pre-down.tunnelblick.sh is needed because this TAP connection does not use DHCP via the TAP device.
                                        End of output from client.route-pre-down.tunnelblick.sh
                                        **********************************************
2015-01-17 16:08:42 us=241425 /sbin/route delete -net 192.168.1.0 192.168.1.1 255.255.255.0
                                        delete net 192.168.1.0: gateway 192.168.1.1
2015-01-17 16:08:42 us=243296 /sbin/route delete -net 4.3.2.1 4.20.10.1 255.255.255.255
                                        delete net 4.3.2.1: gateway 4.20.10.1
2015-01-17 16:08:42 us=245736 /sbin/route delete -net 0.0.0.0 192.168.1.19 128.0.0.0
                                        delete net 0.0.0.0: gateway 192.168.1.19
2015-01-17 16:08:42 us=247692 /sbin/route delete -net 128.0.0.0 192.168.1.19 128.0.0.0
                                        delete net 128.0.0.0: gateway 192.168.1.19
2015-01-17 16:08:42 us=249407 Closing TUN/TAP interface
2015-01-17 16:08:42 us=249717 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -a -f -ptADGNWradsgnw tap0 1500 1590 192.168.1.241 255.255.255.0 init
                                        **********************************************
                                        Start of output from client.down.tunnelblick.sh
                                        Cancelled monitoring of system configuration changes
                                        Restored the DNS and SMB configurations
                                        Flushed the DNS cache via dscacheutil
                                        No matching processes were found
                                        mDNSResponder not running. Not notifying it that the DNS cache was flushed
                                        End of output from client.down.tunnelblick.sh
                                        **********************************************
2015-01-17 16:08:42 us=460441 SIGTERM[hard,] received, process exiting
2015-01-17 16:08:42 us=460603 MANAGEMENT: >STATE:1421528922,EXITING,SIGTERM,,
2015-01-17 16:08:43 *Tunnelblick: No 'post-disconnect.sh' script to execute
2015-01-17 16:08:43 *Tunnelblick: Expected disconnection occurred.

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 29, 2015 1:17 am
by mcbrown
Anyone have any thoughts?

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 29, 2015 4:06 am
by Traffic
mcbrown wrote:Anyone have any thoughts
mcbrown wrote:Sat Jan 17 16:08:44 2015 us=222903 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:44 2015 us=411791 NOTE: --mute triggered...
Firewall .. :?:

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 29, 2015 1:13 pm
by Traffic
Please check that the problem is not related to this:
topic18043.html#p48808

Also, I notice this:
mcbrown wrote:Server config:
Code:
server-bridge 192.168.1.19 255.255.255.0 192.168.1.240 192.168.1.254
There are two points to be aware of:
  • NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. I would change the subnet !
  • 192.168.1.19 is the server IP address - From the Manual:
    The Manual wrote:The gateway and netmask parameters to --server-bridge can be set to either the IP/netmask of the bridge interface, or the IP/netmask of the default gateway/router on the bridged subnet.
    So you could try setting --server-bridge 192.168.1.1 etc (assuming 192.168.1.1 is the default gateway for the LAN).

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 29, 2015 10:53 pm
by mcbrown
Traffic wrote:
mcbrown wrote:Anyone have any thoughts
mcbrown wrote:Sat Jan 17 16:08:44 2015 us=222903 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Sat Jan 17 16:08:44 2015 us=411791 NOTE: --mute triggered...
Firewall .. :?:
If you note the timestamps you will see that the "Connection refused" errors in the server log start when I disconnect the client. Is there some more graceful disconnection procedure that the server should be following?

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 29, 2015 10:57 pm
by mcbrown
Traffic wrote:Please check that the problem is not related to this:
topic18043.html#p48808
Will play around with this to see - thanks.
Traffic wrote:Also, I notice this:
mcbrown wrote:Server config:
Code:
server-bridge 192.168.1.19 255.255.255.0 192.168.1.240 192.168.1.254
There are two points to be aware of:
  • NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. I would change the subnet !
  • 192.168.1.19 is the server IP address - From the Manual:
    The Manual wrote:The gateway and netmask parameters to --server-bridge can be set to either the IP/netmask of the bridge interface, or the IP/netmask of the default gateway/router on the bridged subnet.
    So you could try setting --server-bridge 192.168.1.1 etc (assuming 192.168.1.1 is the default gateway for the LAN).
Yes, changing the subnet is on my (long) list of IT to-do's. But I have verified that the local subnets I have been connecting from are NOT 192.168.1.1, so it doesn't explain my issues.

I will try changing server-bridge as specified to see if that fixes things...

Re: gave up trying to fetch IP address information using the

Posted: Thu Jan 29, 2015 11:54 pm
by Traffic
mcbrown wrote:Is there some more graceful disconnection procedure that the server should be following
Using --explicit-exit-notify is the best practice (*for UDP connections / TCP does not require this and is not compatible) push it to the client.

See --explicit-exit-notify in The Manual v23x

Re: gave up trying to fetch IP address information using the

Posted: Mon Feb 09, 2015 3:53 pm
by mcbrown
Just to follow up on this:

The problem resolved itself, perhaps due to a Tunnelblick and/or Yosemite update. I made no changes to either my server or client configuration, other than to push "explicit-exit-notify" to clients as discussed by Traffic.

The only material configuration changes (as far as I can tell) are that Yosemite was updated from 10.10.1 to 10.10.2, and Tunnelblick from 3.4.2 to 3.4.3.

I'm curious to hear if any of the other Mac users on this thread experienced a similar "miraculous" recovery.

Re: gave up trying to fetch IP address information using the

Posted: Mon Feb 09, 2015 4:10 pm
by Traffic
mcbrown wrote:The only material configuration changes (as far as I can tell) are that Yosemite was updated from 10.10.1 to 10.10.2, and Tunnelblick from 3.4.2 to 3.4.3.
Thanks for letting us know 8-)

Just one thing:
mcbrown wrote:Server config:
Code:

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.8.4"
Should be 8.8.4.4
All times are UTC
Page 1 of 1
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/