can connect but can't surf.

[franck]

Hello,
It is really strange for me because It basically stopped working..

here are my logs:

openvpn.log


Thu Nov 10 22:14:11 2011 MULTI: multi_create_instance called
Thu Nov 10 22:14:11 2011 Re-using SSL/TLS context
Thu Nov 10 22:14:11 2011 LZO compression initialized
Thu Nov 10 22:14:11 2011 Control Channel MTU parms [ L:1560 D:168 EF:
68 EB:0 ET:0 EL:0 ]
Thu Nov 10 22:14:11 2011 Data Channel MTU parms [ L:1560 D:1450 EF:60
EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 10 22:14:11 2011 Local Options hash (VER=V4): '9915e4a2'
Thu Nov 10 22:14:11 2011 Expected Remote Options hash (VER=V4):
'2f2c6498'
Thu Nov 10 22:14:11 2011 TCP connection established with
[AF_INET]XX.XXX.XXX.XXX:55706
Thu Nov 10 22:14:11 2011 TCPv4_SERVER link local: [undef]
Thu Nov 10 22:14:11 2011 TCPv4_SERVER link remote:
[AF_INET]XX.XXX.XXX.XXX:55706
Thu Nov 10 22:14:11 2011 MULTI: multi_create_instance called
Thu Nov 10 22:14:11 2011 Re-using SSL/TLS context
Thu Nov 10 22:14:11 2011 LZO compression initialized
Thu Nov 10 22:14:11 2011 Control Channel MTU parms [ L:1560 D:168 EF:
68 EB:0 ET:0 EL:0 ]
Thu Nov 10 22:14:11 2011 Data Channel MTU parms [ L:1560 D:1450 EF:60
EB:135 ET:0 EL:0 AF:3/1 ]
Thu Nov 10 22:14:11 2011 Local Options hash (VER=V4): '9915e4a2'
Thu Nov 10 22:14:11 2011 Expected Remote Options hash (VER=V4):
'2f2c6498'
Thu Nov 10 22:14:11 2011 TCP connection established with
[AF_INET]XX.XXX.XX.XX:55706
Thu Nov 10 22:14:11 2011 TCPv4_SERVER link local: [undef]
Thu Nov 10 22:14:11 2011 TCPv4_SERVER link remote:
[AF_INET]XX.XXX.XX.XX:55706
Thu Nov 10 22:14:12 2011 XX.XXX.XX.XX:55706 TLS: Initial packet from
[AF_INET]XX.XXX.XX.XX:55706, sid=2ae829ee 1f8c48ba
Thu Nov 10 22:14:13 2011 XX.XXX.XX.XX:55706 VERIFY OK: depth=1, /C=FR/
ST=31/L=SanFrancisco/O=Fort-Funston/CN=Fort-Funston_CA/
emailAddress=m...@myhost.mydomain
Thu Nov 10 22:14:13 2011 XX.XXX.XX.XX:55706 VERIFY OK: depth=0, /C=FR/
ST=31/L=SanFrancisco/O=Fort-Funston/CN=mac/
emailAddress=m...@myhost.mydomain
Thu Nov 10 22:14:14 2011 XX.XXX.XX.XX:55706 Data Channel Encrypt:
Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Nov 10 22:14:14 2011 XX.XXX.XX.XX:55706 Data Channel Encrypt:
Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 22:14:14 2011 XX.XXX.XX.XX:55706 Data Channel Decrypt:
Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Nov 10 22:14:14 2011 XX.XXX.XX.XX:55706 Data Channel Decrypt:
Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 10 22:14:14 2011 XX.XXX.XX.XX:55706 Control Channel: TLSv1,
cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 10 22:14:14 2011 XX.XXX.XX.XX:55706 [mac] Peer Connection
Initiated with [AF_INET]XX.XXX.XX.XX:55706
Thu Nov 10 22:14:14 2011 mac/XX.XXX.XX.XX:55706 MULTI: Learn: 10.8.0.6
-> mac/XX.XXX.XX.XX:55706
Thu Nov 10 22:14:14 2011 mac/XX.XXX.XX.XX:55706 MULTI: primary virtual
IP for mac/XX.XXX.XX.XX:55706: 10.8.0.6
Thu Nov 10 22:14:16 2011 mac/XX.XXX.XX.XX:55706 PUSH: Received control
message: 'PUSH_REQUEST'
Thu Nov 10 22:14:16 2011 mac/XX.XXX.XX.XX:55706 SENT CONTROL [mac]:
'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
4.4.4.4,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)
Thu Nov 10 22:20:30 2011 mac/XX.XXX.XX.XX:55706 Connection reset,
restarting [0]
Thu Nov 10 22:20:30 2011 mac/XX.XXX.XX.XX:55706
SIGUSR1[soft,connection-reset] received, client-instance restarting
Thu Nov 10 22:20:30 2011 TCP/UDP: Closing socket

tunnelblick logs:


2011-11-10 23:14:07 *Tunnelblick: OS X 10.6.8; Tunnelblick 3.2beta32
(build 2817)
2011-11-10 23:14:13 *Tunnelblick: Attempting connection with client;
Set nameserver = 1; monitoring connection
2011-11-10 23:14:13 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start client.conf 1337 1 0 0 0 49
2011-11-10 23:14:13 *Tunnelblick: openvpnstart message: Loading tun-
pre-lion.kext
2011-11-10 23:14:13 *Tunnelblick: Established communication with
OpenVPN
2011-11-10 23:14:13 OpenVPN 2.2.1 i386-apple-darwin10.8.0 [SSL] [LZO2]
[PKCS11] [eurephia] built on Sep 14 2011
2011-11-10 23:14:13 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2011-11-10 23:14:13 Need hold release from management interface,
waiting...
2011-11-10 23:14:13 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-11-10 23:14:13 MANAGEMENT: CMD 'pid'
2011-11-10 23:14:13 MANAGEMENT: CMD 'state on'
2011-11-10 23:14:13 MANAGEMENT: CMD 'state'
2011-11-10 23:14:13 MANAGEMENT: CMD 'hold release'
2011-11-10 23:14:13 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more
info.
2011-11-10 23:14:13 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-11-10 23:14:13 Control Channel Authentication: using 'ta.key' as
a OpenVPN static key file
2011-11-10 23:14:13 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2011-11-10 23:14:13 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2011-11-10 23:14:13 LZO compression initialized
2011-11-10 23:14:13 Control Channel MTU parms [ L:1560 D:168 EF:68 EB:
0 ET:0 EL:0 ]
2011-11-10 23:14:13 Socket Buffers: R=[262140->65536] S=[131070-
>65536]
2011-11-10 23:14:13 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:
135 ET:0 EL:0 AF:3/1 ]
2011-11-10 23:14:13 Local Options hash (VER=V4): '2f2c6498'
2011-11-10 23:14:13 Expected Remote Options hash (VER=V4): '9915e4a2'
2011-11-10 23:14:13 Attempting to establish TCP connection with
XX.XXX.XXX.XXX:443 [nonblock]
2011-11-10 23:14:13 MANAGEMENT: >STATE:1320963253,TCP_CONNECT,,,
2011-11-10 23:14:13 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn --cd /
Users/franck/Library/Application Support/Tunnelblick/Configurations --
daemon --management 127.0.0.1 1337 --config /Users/franck/Library/
Application Support/Tunnelblick/Configurations/client.conf --log /
Library/Application Support/Tunnelblick/Logs/-SUsers-Sfranck-SLibrary-
SApplication Support-STunnelblick-SConfigurations-Sclient.conf.
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 --down /Applications/
Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d
--up-restart
2011-11-10 23:14:14 TCP connection established with XX.XXX.XXX.XXX:443
2011-11-10 23:14:14 TCPv4_CLIENT link local: [undef]
2011-11-10 23:14:14 TCPv4_CLIENT link remote: XX.XXX.XXX.XXX:443
2011-11-10 23:14:14 MANAGEMENT: >STATE:1320963254,WAIT,,,
2011-11-10 23:14:14 MANAGEMENT: >STATE:1320963254,AUTH,,,
2011-11-10 23:14:14 TLS: Initial packet from XX.XXX.XXX.XXX:443,
sid=cc15c91b 524bb2ee
2011-11-10 23:14:15 VERIFY OK: depth=1, /C=FR/ST=31/L=SanFrancisco/
O=Fort-Funston/CN=Fort-Funston_CA/emailAddress=m...@myhost.mydomain
2011-11-10 23:14:15 VERIFY OK: depth=0, /C=FR/ST=31/L=SanFrancisco/
O=Fort-Funston/CN=server/emailAddress=m...@myhost.mydomain
2011-11-10 23:14:16 Data Channel Encrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-11-10 23:14:16 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-11-10 23:14:16 Data Channel Decrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-11-10 23:14:16 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-11-10 23:14:16 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-11-10 23:14:16 [server] Peer Connection Initiated with
XX.XXX.XXX.XXX:443
2011-11-10 23:14:17 MANAGEMENT: >STATE:1320963257,GET_CONFIG,,,
2011-11-10 23:14:18 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-11-10 23:14:19 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
4.4.4.4,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'
2011-11-10 23:14:19 OPTIONS IMPORT: timers and/or timeouts modified
2011-11-10 23:14:19 OPTIONS IMPORT: --ifconfig/up options modified
2011-11-10 23:14:19 OPTIONS IMPORT: route options modified
2011-11-10 23:14:19 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-11-10 23:14:19 ROUTE default_gateway=192.168.1.1
2011-11-10 23:14:19 TUN/TAP device /dev/tun0 opened
2011-11-10 23:14:19 MANAGEMENT: >STATE:1320963259,ASSIGN_IP,,10.8.0.6,
2011-11-10 23:14:19 /sbin/ifconfig tun0 delete
ifconfig: ioctl (SIOCDIFADDR):
Can't assign requested address
2011-11-10 23:14:19 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2011-11-10 23:14:19 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500
netmask 255.255.255.255 up
2011-11-10 23:14:19 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d tun0 1500 1560 10.8.0.6 10.8.0.5
init
No such key
2011-11-10 23:14:21 *Tunnelblick: Flushed the DNS cache
2011-11-10 23:14:21 /sbin/route add -net XX.XXX.XXX.XXX 192.168.1.1
255.255.255.255
add net XX.XXX.XXX.XXX:
gateway 192.168.1.1
2011-11-10 23:14:21 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0
add net 0.0.0.0: gateway
10.8.0.5
2011-11-10 23:14:21 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0
add net 128.0.0.0: gateway
10.8.0.5
2011-11-10 23:14:21 MANAGEMENT: >STATE:1320963261,ADD_ROUTES,,,
2011-11-10 23:14:21 /sbin/route add -net 10.8.0.1 10.8.0.5
255.255.255.255
add net 10.8.0.1: gateway
10.8.0.5
2011-11-10 23:14:21 Initialization Sequence Completed
2011-11-10 23:14:21 MANAGEMENT: >STATE:1320963261,CONNECTED,SUCCESS,
10.8.0.6,XX.XXX.XXX.XXX
2011-11-10 23:14:21 *Tunnelblick client.up.tunnelblick.sh: Retrieved
name server(s) [ 4.4.4.4 8.8.8.8 ] and WINS server(s) [ ] and using
default domain name [ openvpn ]
2011-11-10 23:14:21 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-11-10 23:14:21 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-11-10 23:14:21 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-11-10 23:14:57 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
2011-11-10 23:20:33 *Tunnelblick: Flushed the DNS cache
2011-11-10 23:20:33 event_wait : Interrupted system call (code=4)
2011-11-10 23:20:33 TCP/UDP: Closing socket
2011-11-10 23:20:33 /sbin/route delete -net 10.8.0.1 10.8.0.5
255.255.255.255
delete net 10.8.0.1: gateway
10.8.0.5
2011-11-10 23:20:33 /sbin/route delete -net XX.XXX.XXX.XXX 192.168.1.1
255.255.255.255
delete net XX.XXX.XXX.XXX:
gateway 192.168.1.1
2011-11-10 23:20:33 /sbin/route delete -net 0.0.0.0 10.8.0.5 128.0.0.0
delete net 0.0.0.0: gateway
10.8.0.5
2011-11-10 23:20:33 /sbin/route delete -net 128.0.0.0 10.8.0.5
128.0.0.0
delete net 128.0.0.0: gateway
10.8.0.5
2011-11-10 23:20:33 Closing TUN/TAP interface
2011-11-10 23:20:33 /Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d tun0 1500 1560 10.8.0.6 10.8.0.5
init
2011-11-10 23:20:33 SIGTERM[hard,] received, process exiting
2011-11-10 23:20:33 MANAGEMENT: >STATE:1320963633,EXITING,SIGTERM,,
2011-11-10 23:20:33 *Tunnelblick client.down.tunnelblick.sh: Cancelled
monitoring of system configuration changes
2011-11-10 23:20:33 *Tunnelblick client.down.tunnelblick.sh: Restored
the DNS and WINS configurations


I can ping the 10.8.0.6 adress from the open server to the client.
but i can't ping the server from the client.

Any idea ???

[jkbull...gmail.com]

If you are having a problem with Tunnelblick,

please post the contents of your configuration file and the entire contents of the OpenVPN log

with your question. Be sure to X out any sensitive information such as server IP addresses. See this post for instructions on copying the OpenVPN log.

And have you looked at Connects OK, But...?

[franck]

Hi, I can't ping anything from the client.
This is not a DNS issue.

cat client.conf
# Client

client

dev tun

proto tcp-client

remote xx.xxx.xxx.xxx 443

resolv-retry infinite

cipher AES-256-CBC

# Cles

ca ca.crt

cert mac.crt

key mac.key

tls-auth ta.key 1

# Securite

nobind

persist-key

persist-tun

comp-lzo

verb 3




On Nov 10, 11:50 pm, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> *If you are having a problem with Tunnelblick,*
> *please post the contents of your configuration file and the entire
> contents of the OpenVPN log*
> *with your question. *Be sure to X out any sensitive information such as
> server IP addresses. See this post<http://groups.google.com/group/tunnelblick-discuss/msg/716b4ef87dfd7e...> for

> instructions on copying the OpenVPN log.
>

> And have you looked at Connects OK, But...<http://code.google.com/p/tunnelblick/wiki/cConnectedBut>
> ?

[jkbull...gmail.com]

So this was working, nothing has changed, and now it isn't working?

[franck]

Yes, well, I can't remember what changed...

[jkbull...gmail.com]

It is probably a routing issue. Or possibly a firewall issue, but that's unlikely.

Is "default_gateway=192.168.1.1" correct?

[franck]

yes, it's correct.

[franck]

without the VPN on I have:

Internet:
Destination Gateway Flags Refs Use
Netif Expire
default 192.168.1.1 UGSc 86 0
en0
127 localhost UCS 0 0
lo0
localhost localhost UH 0 51
lo0
169.254 link#4 UCS 0 0
en0
172.16.64/24 link#6 UC 1 0
vmnet8
172.16.64.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3
vmnet8
172.16.107/24 link#5 UC 1 0
vmnet1
172.16.107.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3
vmnet1
192.168.1 link#4 UCS 35 0
en0
192.168.1.1 0:1d:7e:bd:5:ad UHLWI 0 19
en0 1199
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3
en0

with the VPN on:

Internet:
Destination Gateway Flags Refs Use
Netif Expire
0/1 10.8.0.5 UGSc 1 0
tun0
default unknown UGSc 16 0
en0
10.8.0.1/32 10.8.0.5 UGSc 0 0
tun0
10.8.0.5 10.8.0.6 UH 6 0
tun0
xx.xxx.xxx.xxx/32 unknown UGSc 1 0
en0
127 localhost UCS 0 0
lo0
localhost localhost UH 2 89
lo0
128.0/1 10.8.0.5 UGSc 2 0
tun0
169.254 link#4 UCS 0 0
en0
172.16.64/24 link#6 UC 1 0
vmnet8
172.16.64.255 ff:ff:ff:ff:ff:ff UHLWbI 0 9
vmnet8
172.16.107/24 link#5 UC 1 0
vmnet1
172.16.107.255 ff:ff:ff:ff:ff:ff UHLWbI 0 9
vmnet1
192.168.1 link#4 UCS 3 0
en0
mac localhost UHS 0 0
lo0
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 6
en0


the "unknown" for default and for xx.xxx.xxx.xxx which is the VPN
server, are strange isn't it ?

[franck]

no one ?
could someone copy me his routing tables using tunnelblick so i could
compare ?
regards

[jkbull...gmail.com]

I don't think this would cause your problem, but looking at your Tunnelblick, log, I noticed "redirect-gateway def1 bypass-dhcp" among the options being pushed by the server. "bypass-dhcp" may not be available on a Mac (on the OpenVPN man page it is described as "Available on Windows clients, may not be available on non-Windows clients").

In my routing table, the second through fourth entries are

default            a.b.c.d      UGSc            3        0     en0

default            a.b.c.d      UGScI           0        0     en2

default            link#7       UCSI            0        0     en3

(where a.b.c.d is my local router/gateway).

So 

[franck]

OK It's fixed,
I just realised the server rebooted and I was missing those commands:

sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

thanks for your help!

PS: bypass-dhcp do work...

[Friedrich Romstedt]

2011/11/19 franck <franc...@gmail.com>:

> OK It's fixed,
>  I just realised the server rebooted and I was missing those commands:
>
> sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
> iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

So "unknown" is the DNS PTR for your 192.168.1.1 router in the
server's net? You could try $netstat -nr for this, to suppress the
DNS lookup.

Why couldn't you ping the server before, does this work now? Maybe
the server is configured to ignore ICMP packets? I understand that
the SNAT is necessary for internet traffic, but why is it important if
you do just $ping 10.8.0.1 on the client? Maybe you ping'ed the
server's eth0 address? That would explain it.

Friedrich

[franck]

Hi Friedrich,

192.168.1.1 is the local router client side (which is the DHCP
server.)

I just did the test again,

I do have the "unknown line" on my mac routing tables instead of
192.168.1.1, if i haven't done the "iptables -t nat -A POSTROUTING -s
10.8.0.0/24 -o eth0 -j MASQUERADE " command on the server side.
I do get a get a DHCP lease on the mac though.

++

On Nov 19, 8:57 pm, Friedrich Romstedt <friedrichromst...@gmail.com>
wrote:
> 2011/11/19 franck <franck4...@gmail.com>:

[Friedrich Romstedt]

2011/11/20 franck <franc...@gmail.com>:

> 192.168.1.1 is the local router client side (which is the DHCP
> server.)

And the server's subnet is not 192.168.1.0/24 by accident too?

> I just did the test again,

Did you include the -n switch?

> I do have the "unknown line" on my mac routing tables instead of
> 192.168.1.1, if i haven't done the  "iptables -t nat -A POSTROUTING -s
> 10.8.0.0/24 -o eth0 -j MASQUERADE " command on the server side.

It's strange to me that it depends on the SNAT. SNAT like
masquerading should make more connections work, rather than less.

I searched for an explanation of when "netstat -r" displays "unknown",
and the only useful occurence of "unknown" in netstat's + route's
manpages says, that it prints numerical addresses if the hostname is
"unknown". So we conclude that it might think the hostname of
192.168.1.1 just happens to be "unknown", literally. That's why I
asked for the "netstat -r -n" output.

To be clear, after having configured the masquerading, the IP shows up
again? Very strange. This behaviour is currently completely unclear
to me.

> I do get a get a DHCP lease on the mac though.

DHCP does work via broadcasts, afaik. So it's not related to routing
through subnets, since it must work also before you have an IP at all.

Have a nice day,
Friedrich