MAC-address of the tap Interface
5,288 views
Skip to first unread message
Lupus
Jan 23, 2012, 1:47:56 PM1/23/12
to tunnelbli...@googlegroups.com
Hi,
these are my first attempts to establish a bridged ethernet connection from my Mac at home (MacOS 10.6, Tunnelblick 3.2.2) to our company network (Linux Debian, OpenVPN 2.1_rc11 x86_64-pc-linux-gnu). The openvpn-server is not the gateway/router, nor the local DHCP-server. Our company DHCP-server uses the interface MAC-addresses to identify the machines and distribute fixed IP-addresses. There is no dynamic pool of addresses. What I would love to have is the DHCP-server giving a fixed IP to the client machine after connecting. I believe I managed a successful connection after trying numerous settings in both TB-client and Linux-server, but as expected the client will not receive an IP in the company's subnet (192.168.101.x). My Mac at home is set to DHCP, however in its own private network (192.168.178.x). Looking at the logs from server,client, and dhcp everything behaves fine: the openvpn-server seems to forward the discover-request to the DHCP-server, which then tries to find a match in its list. But of course this cannot work as the MAC-address is a virtual (or how should I call it) one corresponding to the tap-Interface on the client. This wouldn't be a problem if it was the same address for each connection on the same client. However, it seems to change on every connection, and there is no common pattern in it (at least I cannot see any). I wonder if there could be any way to statically set the MAC-address for the tap-interface when it is established by TB. Is this done by any system-calls that cannot be influenced? Any other ideas how I could "tell" the DHCP-server that a particular vpn-client is connecting?
Many thanks for your ideas, Lupus
jkbull...gmail.com
Jan 23, 2012, 2:13:17 PM1/23/12
to tunnelbli...@googlegroups.com
Take a look at the OpenVPN "lladdr" option (see http://www.openvpn.net/index.php/open-source/documentation/manuals/427-openvpn-22.html).
It lets you specify a link layer address (MAC address) that will be used for TAP connections.
Lupus
Jan 23, 2012, 4:28:25 PM1/23/12
to tunnelblick-discuss
Terrific jkbull, thanks a lot. That looks very promising.
Interestingly, the lladdr option wasn't listed when I tried "openvpn --
help" on then Linux version. Is that because it is version 2.1?
Having (almost) solved the dhcp-issue, I must admit that I was a bit
too optimistic about my "successful connection". To be honest, that
was referring to attempts within the company subnet. I used my Mac at
work with TB to connect to the OpenVPN Server within the 192.168.101.x
network. Maybe this is a stupid idea, but it was easy to watch the
logs on both ends of the connection. I thought that was enough proof
that I chose the right parameters. Well not quite... Now that I'm
trying to connect from home, it isn't working. I did change the IP for
the remote server in the TB-settings and configured the router for
port-forwarding to the openvpn-server. Am I sure what I'm doing you
might think. Well, good question. What makes me pretty confident, is
the fact that I have quite a couple of ports on the router opened/
forwarded to local machines (for ssh, vnc etc.). I can see in the
routers NAT-table that my home-Mac is connected to the server, but the
server is not responding at all (nothing in the log). I know I should
post my configs now, but it will take a moment to strip the comments.
Is there anything particular I have overseen? Things like HTTP-Proxy,
SOCKS-proxy don't apply to this scenario, do they?
Thanks again for your quick support, Lupus
Interestingly, the lladdr option wasn't listed when I tried "openvpn --
help" on then Linux version. Is that because it is version 2.1?
Having (almost) solved the dhcp-issue, I must admit that I was a bit
too optimistic about my "successful connection". To be honest, that
was referring to attempts within the company subnet. I used my Mac at
work with TB to connect to the OpenVPN Server within the 192.168.101.x
network. Maybe this is a stupid idea, but it was easy to watch the
logs on both ends of the connection. I thought that was enough proof
that I chose the right parameters. Well not quite... Now that I'm
trying to connect from home, it isn't working. I did change the IP for
the remote server in the TB-settings and configured the router for
port-forwarding to the openvpn-server. Am I sure what I'm doing you
might think. Well, good question. What makes me pretty confident, is
the fact that I have quite a couple of ports on the router opened/
forwarded to local machines (for ssh, vnc etc.). I can see in the
routers NAT-table that my home-Mac is connected to the server, but the
server is not responding at all (nothing in the log). I know I should
post my configs now, but it will take a moment to strip the comments.
Is there anything particular I have overseen? Things like HTTP-Proxy,
SOCKS-proxy don't apply to this scenario, do they?
Thanks again for your quick support, Lupus
Lupus
Jan 25, 2012, 7:52:08 AM1/25/12
to tunnelblick-discuss
Hi
On 23 Jan., 22:28, Lupus <a...@seqlab.de> wrote:
> ... Now that I'm trying to connect from home, it isn't working.
As an update to my previous post: it is working now. The problem was
related to the bridge interface. I used the bridge-start and bridge-
stop scripts from the Debian bridge-utils package as recommended by
the openvpn.net HOWTO http://www.openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html
. Apparently the default route is lost during setup, and thus the
openvpn-server had no connectivity to the outside world at all. I
didn't notice that while testing inside the company's private subnet.
Back to my original problem: the TB-client should receive an IP-
address from the company's DHCP-server. But before proceeding I really
should post my setup.
The remote (company) network can be reached via two different public
IP-addresses (load-balanced) and has a private network in the
192.168.101.0/24 range.
The router is at 192.168.101.1, the DHCP-server at 192.168.101.6, and
the OpenVPN-server at 192.168.101.10. On the public side port 9010 is
opened and forwarded to port 1194 on the OpenVPN-server
(192.168.101.10). That part is working ok, I think. On the OpenVPN-
server the (relevant) interfaces look like this (after running bridge-
start):
# ifconfig -a
br0 Link encap:Ethernet HWaddr 00:25:90:1d:1e:e8
inet addr:192.168.101.10 Bcast:192.168.101.255 Mask:
255.255.255.0
inet6 addr: fe80::225:90ff:fe1d:1ee8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3717329 errors:0 dropped:0 overruns:0 frame:0
TX packets:4374725 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2837890783 (2.6 GiB) TX bytes:4143672206 (3.8 GiB)
eth0 Link encap:Ethernet HWaddr 00:25:90:1d:1e:e8
inet6 addr: fe80::225:90ff:fe1d:1ee8/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:4960381 errors:0 dropped:0 overruns:0 frame:0
TX packets:5733252 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2970969373 (2.7 GiB) TX bytes:4219961987 (3.9 GiB)
Memory:fafe0000-fb000000
tap0 Link encap:Ethernet HWaddr 7e:24:40:71:2e:a5
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:81 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:27081 (26.4 KiB) TX bytes:0 (0.0 B)
So the bridge-interface has correctly taken the IP from the former
dhcp-configured eth0 interface. The server.conf file for the openvpn
server looks like this:
# cat server.conf
local 192.168.101.10
port 1194
proto tcp-server
tls-server
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem
server-bridge
push "redirect-gateway"
keepalive 10 120
comp-lzo
max-clients 10
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
;log openvpn.log
log-append openvpn.log
verb 4
;mute 20
My home situation is a private subnet behind a home-router
(192.168.178.0/24) The Tunnelblick client is configured as:
client
dev tap
proto tcp
remote 77.20.123.xxx 9010
remote 193.175.25.xxx 9010
resolv-retry infinite
nobind
# Client1 specific pseudo-Mac-address
lladdr 00:03:93:57:57:57
;user nobody
;group nobody
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 4
;mute 20
The logs look like this
server:
Wed Jan 25 13:28:01 2012 us=673611 MULTI: multi_create_instance called
Wed Jan 25 13:28:01 2012 us=673681 Re-using SSL/TLS context
Wed Jan 25 13:28:01 2012 us=673709 LZO compression initialized
Wed Jan 25 13:28:01 2012 us=673805 Control Channel MTU parms [ L:1576
D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Jan 25 13:28:01 2012 us=673824 Data Channel MTU parms [ L:1576 D:
1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Jan 25 13:28:01 2012 us=673849 Local Options String: 'V4,dev-type
tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher BF-
CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Jan 25 13:28:01 2012 us=673857 Expected Remote Options String:
'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-
lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Jan 25 13:28:01 2012 us=673877 Local Options hash (VER=V4):
'3e6d1056'
Wed Jan 25 13:28:01 2012 us=673889 Expected Remote Options hash
(VER=V4): '31fdf004'
Wed Jan 25 13:28:01 2012 us=673911 TCP connection established with
77.22.5.xx:62043
Wed Jan 25 13:28:01 2012 us=673924 Socket Buffers: R=[131072->131072]
S=[131072->131072]
Wed Jan 25 13:28:01 2012 us=673934 TCPv4_SERVER link local: [undef]
Wed Jan 25 13:28:01 2012 us=673944 TCPv4_SERVER link remote:
77.22.5.21:62043
Wed Jan 25 13:28:02 2012 us=653550 77.22.5.xx:62043 TLS: Initial
packet from 77.22.5.xx:62043, sid=8fbc3386 ea3c6874
Wed Jan 25 13:28:03 2012 us=406028 77.22.5.xx:62043 VERIFY OK:
depth=1, /C=DE/ST=NS/L=GOETTINGEN/O=SEQLAB/OU=IT-Department/
CN=cruncher/emailAddress=x...@seqlab.de
Wed Jan 25 13:28:03 2012 us=406195 77.22.5.xx:62043 VERIFY OK:
depth=0, /C=DE/ST=NS/O=SEQLAB/OU=IT-Department/CN=client1/
emailAddress=x...@seqlab.de
Wed Jan 25 13:28:03 2012 us=649286 77.22.5.xx:62043 Data Channel
Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 25 13:28:03 2012 us=649330 77.22.5.xx:62043 Data Channel
Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 25 13:28:03 2012 us=649392 77.22.5.xx:62043 Data Channel
Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 25 13:28:03 2012 us=649402 77.22.5.xx:62043 Data Channel
Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 25 13:28:03 2012 us=750047 77.22.5.xx:62043 Control Channel:
TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Jan 25 13:28:03 2012 us=750091 77.22.5.xx:62043 [client1] Peer
Connection Initiated with 77.22.5.xx:62043
Wed Jan 25 13:28:03 2012 us=750146 client1/77.22.5.xx:62043 MULTI: no
dynamic or static remote --ifconfig address is available for
client1/77.22.5.x:62043
Wed Jan 25 13:28:06 2012 us=169190 client1/77.22.5.xx:62043 PUSH:
Received control message: 'PUSH_REQUEST'
Wed Jan 25 13:28:06 2012 us=169288 client1/77.22.5.xx:62043 SENT
CONTROL [client1]: 'PUSH_REPLY,redirect-gateway,route-gateway
dhcp,ping 10,ping-restart 120' (status=1)
Wed Jan 25 13:28:09 2012 us=45882 client1/77.22.5.xx:62043 MULTI:
Learn: 00:03:93:57:57:57 -> client1/77.22.5.xx:62043
######################################################################
TB client:
2012-01-25 13:28:00 *Tunnelblick: OS X 10.6.5; Tunnelblick 3.2.2
(build 2891.2917)
...
2012-01-25 13:28:01 us=498205 proto = tcp-client
2012-01-25 13:28:01 us=498217 local = '[UNDEF]'
2012-01-25 13:28:01 us=498228 local_port = 0
2012-01-25 13:28:01 us=498239 remote = '77.20.123.xxx'
2012-01-25 13:28:01 us=498251 remote_port = 9010
2012-01-25 13:28:01 us=498262 remote_float = DISABLED
2012-01-25 13:28:01 us=498273 bind_defined = DISABLED
2012-01-25 13:28:01 us=498284 bind_local = DISABLED
2012-01-25 13:28:01 us=498296 connect_retry_seconds = 5
2012-01-25 13:28:01 us=498307 connect_timeout = 10
2012-01-25 13:28:01 us=498318 connect_retry_max = 0
2012-01-25 13:28:01 us=498329 socks_proxy_server = '[UNDEF]'
2012-01-25 13:28:01 us=498340 socks_proxy_port = 0
2012-01-25 13:28:01 us=498351 socks_proxy_retry = DISABLED
2012-01-25 13:28:01 us=498363 Connection profiles [1]:
2012-01-25 13:28:01 us=498374 proto = tcp-client
2012-01-25 13:28:01 us=498385 local = '[UNDEF]'
2012-01-25 13:28:01 us=498396 local_port = 0
2012-01-25 13:28:01 us=498408 remote = '193.175.25.222'
2012-01-25 13:28:01 us=498419 remote_port = 9010
2012-01-25 13:28:01 us=498430 remote_float = DISABLED
2012-01-25 13:28:01 us=498441 bind_defined = DISABLED
2012-01-25 13:28:01 us=498452 bind_local = DISABLED
2012-01-25 13:28:01 us=498464 connect_retry_seconds = 5
2012-01-25 13:28:01 us=498475 connect_timeout = 10
2012-01-25 13:28:01 us=498486 connect_retry_max = 0
2012-01-25 13:28:01 us=498497 socks_proxy_server = '[UNDEF]'
2012-01-25 13:28:01 us=498508 socks_proxy_port = 0
2012-01-25 13:28:01 us=498520 socks_proxy_retry = DISABLED
2012-01-25 13:28:01 us=498531 Connection profiles END
2012-01-25 13:28:01 us=498542 remote_random = DISABLED
2012-01-25 13:28:01 us=498553 ipchange = '[UNDEF]'
2012-01-25 13:28:01 us=498565 dev = 'tap'
2012-01-25 13:28:01 us=498576 dev_type = '[UNDEF]'
2012-01-25 13:28:01 us=498587 dev_node = '[UNDEF]'
2012-01-25 13:28:01 us=498598 lladdr = '00:03:93:57:57:57'
2012-01-25 13:28:01 us=498610 topology = 1
2012-01-25 13:28:01 us=498621 tun_ipv6 = DISABLED
2012-01-25 13:28:01 us=498632 ifconfig_local = '[UNDEF]'
2012-01-25 13:28:01 us=498643 ifconfig_remote_netmask = '[UNDEF]'
2012-01-25 13:28:01 us=498655 ifconfig_noexec = DISABLED
2012-01-25 13:28:01 us=498666 ifconfig_nowarn = DISABLED
2012-01-25 13:28:01 us=498692 shaper = 0
2012-01-25 13:28:01 us=498704 tun_mtu = 1500
2012-01-25 13:28:01 us=498715 tun_mtu_defined = ENABLED
2012-01-25 13:28:01 us=498726 link_mtu = 1500
2012-01-25 13:28:01 us=498737 link_mtu_defined = DISABLED
2012-01-25 13:28:01 us=498749 tun_mtu_extra = 32
2012-01-25 13:28:01 us=498760 tun_mtu_extra_defined = ENABLED
2012-01-25 13:28:01 us=498771 fragment = 0
2012-01-25 13:28:01 us=498783 mtu_discover_type = -1
2012-01-25 13:28:01 us=498794 mtu_test = 0
2012-01-25 13:28:01 us=498805 mlock = DISABLED
2012-01-25 13:28:01 us=498817 keepalive_ping = 0
2012-01-25 13:28:01 us=498828 keepalive_timeout = 0
2012-01-25 13:28:01 us=498839 inactivity_timeout = 0
2012-01-25 13:28:01 us=498850 ping_send_timeout = 0
2012-01-25 13:28:01 us=498861 ping_rec_timeout = 0
2012-01-25 13:28:01 us=498877 ping_rec_timeout_action = 0
2012-01-25 13:28:01 us=498888 ping_timer_remote = DISABLED
2012-01-25 13:28:01 us=498900 remap_sigusr1 = 0
2012-01-25 13:28:01 us=498911 explicit_exit_notification = 0
2012-01-25 13:28:01 us=498922 persist_tun = ENABLED
2012-01-25 13:28:01 us=498934 persist_local_ip = DISABLED
2012-01-25 13:28:01 us=498945 persist_remote_ip = DISABLED
2012-01-25 13:28:01 us=498959 persist_key = ENABLED
2012-01-25 13:28:01 us=498971 mssfix = 1450
2012-01-25 13:28:01 us=498982 passtos = DISABLED
2012-01-25 13:28:01 us=498994 resolve_retry_seconds = 1000000000
2012-01-25 13:28:01 us=499005 username = '[UNDEF]'
2012-01-25 13:28:01 us=499017 groupname = '[UNDEF]'
2012-01-25 13:28:01 us=499028 chroot_dir = '[UNDEF]'
2012-01-25 13:28:01 us=499039 cd_dir = '/Users/Lupus/Library/
Application Support/Tunnelblick/Configurations/cruncherglobal.tblk/
Contents/Resources'
2012-01-25 13:28:01 us=499051 writepid = '[UNDEF]'
2012-01-25 13:28:01 us=499062 up_script = '/Applications/
Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -
a -atDASNGWrdasngw'
2012-01-25 13:28:01 us=499078 down_script = '/Applications/
Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d
-a -atDASNGWrdasngw'
2012-01-25 13:28:01 us=499091 down_pre = DISABLED
2012-01-25 13:28:01 us=499106 up_restart = ENABLED
2012-01-25 13:28:01 us=499118 up_delay = DISABLED
2012-01-25 13:28:01 us=499130 daemon = ENABLED
2012-01-25 13:28:01 us=499142 inetd = 0
2012-01-25 13:28:01 us=499153 log = ENABLED
2012-01-25 13:28:01 us=499165 suppress_timestamps = DISABLED
2012-01-25 13:28:01 us=499177 nice = 0
2012-01-25 13:28:01 us=499189 verbosity = 4
2012-01-25 13:28:01 us=499201 mute = 0
2012-01-25 13:28:01 us=499212 gremlin = 0
2012-01-25 13:28:01 us=499224 status_file = '[UNDEF]'
2012-01-25 13:28:01 us=499236 status_file_version = 1
2012-01-25 13:28:01 us=499247 status_file_update_freq = 60
2012-01-25 13:28:01 us=499259 occ = ENABLED
2012-01-25 13:28:01 us=499271 rcvbuf = 65536
2012-01-25 13:28:01 us=499283 sndbuf = 65536
2012-01-25 13:28:01 us=499294 sockflags = 0
2012-01-25 13:28:01 us=499309 fast_io = DISABLED
2012-01-25 13:28:01 us=499321 lzo = 7
2012-01-25 13:28:01 us=499333 route_script = '[UNDEF]'
2012-01-25 13:28:01 us=499345 route_default_gateway = '[UNDEF]'
2012-01-25 13:28:01 us=499357 route_default_metric = 0
2012-01-25 13:28:01 us=499369 route_noexec = DISABLED
2012-01-25 13:28:01 us=499381 route_delay = 0
2012-01-25 13:28:01 us=499392 route_delay_window = 30
2012-01-25 13:28:01 us=499404 route_delay_defined = DISABLED
2012-01-25 13:28:01 us=499416 route_nopull = DISABLED
2012-01-25 13:28:01 us=499428 route_gateway_via_dhcp = DISABLED
2012-01-25 13:28:01 us=499440 max_routes = 100
2012-01-25 13:28:01 us=499452 allow_pull_fqdn = DISABLED
2012-01-25 13:28:01 us=499463 management_addr = '127.0.0.1'
2012-01-25 13:28:01 us=499490 management_port = 1337
2012-01-25 13:28:01 us=499502 management_user_pass = '[UNDEF]'
2012-01-25 13:28:01 us=499514 management_log_history_cache = 250
2012-01-25 13:28:01 us=499526 management_echo_buffer_size = 100
2012-01-25 13:28:01 us=499538 management_write_peer_info_file =
'[UNDEF]'
2012-01-25 13:28:01 us=499550 management_client_user = '[UNDEF]'
2012-01-25 13:28:01 us=499562 management_client_group = '[UNDEF]'
2012-01-25 13:28:01 us=499574 management_flags = 6
2012-01-25 13:28:01 us=499585 shared_secret_file = '[UNDEF]'
2012-01-25 13:28:01 us=499597 key_direction = 0
2012-01-25 13:28:01 us=499609 ciphername_defined = ENABLED
2012-01-25 13:28:01 us=499620 ciphername = 'BF-CBC'
2012-01-25 13:28:01 us=499632 authname_defined = ENABLED
2012-01-25 13:28:01 us=499643 authname = 'SHA1'
2012-01-25 13:28:01 us=499655 prng_hash = 'SHA1'
2012-01-25 13:28:01 us=499666 prng_nonce_secret_len = 16
2012-01-25 13:28:01 us=499678 keysize = 0
2012-01-25 13:28:01 us=499689 engine = DISABLED
2012-01-25 13:28:01 us=499701 replay = ENABLED
2012-01-25 13:28:01 us=499713 mute_replay_warnings = DISABLED
2012-01-25 13:28:01 us=499724 replay_window = 64
2012-01-25 13:28:01 us=499736 replay_time = 15
2012-01-25 13:28:01 us=499747 packet_id_file = '[UNDEF]'
2012-01-25 13:28:01 us=499759 use_iv = ENABLED
2012-01-25 13:28:01 us=499774 test_crypto = DISABLED
2012-01-25 13:28:01 us=499786 tls_server = DISABLED
2012-01-25 13:28:01 us=499798 tls_client = ENABLED
2012-01-25 13:28:01 us=499809 key_method = 2
2012-01-25 13:28:01 us=499821 ca_file = 'ca.crt'
2012-01-25 13:28:01 us=499832 ca_path = '[UNDEF]'
2012-01-25 13:28:01 us=499844 dh_file = '[UNDEF]'
2012-01-25 13:28:01 us=499855 cert_file = 'client1.crt'
2012-01-25 13:28:01 us=499867 priv_key_file = 'client1.key'
2012-01-25 13:28:01 us=499878 pkcs12_file = '[UNDEF]'
2012-01-25 13:28:01 us=499890 cipher_list = '[UNDEF]'
2012-01-25 13:28:01 us=499902 tls_verify = '[UNDEF]'
2012-01-25 13:28:01 us=499913 tls_export_cert = '[UNDEF]'
2012-01-25 13:28:01 us=499925 tls_remote = '[UNDEF]'
2012-01-25 13:28:01 us=499936 crl_file = '[UNDEF]'
2012-01-25 13:28:01 us=499948 ns_cert_type = 0
2012-01-25 13:28:01 us=499981 remote_cert_ku[i] = 0
….
2012-01-25 13:28:01 us=500166 remote_cert_eku = '[UNDEF]'
2012-01-25 13:28:01 us=500177 tls_timeout = 2
2012-01-25 13:28:01 us=500189 renegotiate_bytes = 0
2012-01-25 13:28:01 us=500200 renegotiate_packets = 0
2012-01-25 13:28:01 us=500212 renegotiate_seconds = 3600
2012-01-25 13:28:01 us=500223 handshake_window = 60
2012-01-25 13:28:01 us=500234 transition_window = 3600
2012-01-25 13:28:01 us=500246 single_session = DISABLED
2012-01-25 13:28:01 us=500257 push_peer_info = DISABLED
2012-01-25 13:28:01 us=500269 tls_exit = DISABLED
2012-01-25 13:28:01 us=500280 tls_auth_file = '[UNDEF]'
2012-01-25 13:28:01 us=500306 pkcs11_protected_authentication =
DISABLED
…
2012-01-25 13:28:01 us=500503 pkcs11_private_mode = 00000000
...
2012-01-25 13:28:01 us=500703 pkcs11_cert_private = DISABLED
...
2012-01-25 13:28:01 us=500889 pkcs11_pin_cache_period = -1
2012-01-25 13:28:01 us=500900 pkcs11_id = '[UNDEF]'
2012-01-25 13:28:01 us=500912 pkcs11_id_management = DISABLED
2012-01-25 13:28:01 us=500933 server_network = 0.0.0.0
2012-01-25 13:28:01 us=500946 server_netmask = 0.0.0.0
2012-01-25 13:28:01 us=500959 server_bridge_ip = 0.0.0.0
2012-01-25 13:28:01 us=500972 server_bridge_netmask = 0.0.0.0
2012-01-25 13:28:01 us=500985 server_bridge_pool_start = 0.0.0.0
2012-01-25 13:28:01 us=500998 server_bridge_pool_end = 0.0.0.0
2012-01-25 13:28:01 us=501010 ifconfig_pool_defined = DISABLED
2012-01-25 13:28:01 us=501037 ifconfig_pool_start = 0.0.0.0
2012-01-25 13:28:01 us=501052 ifconfig_pool_end = 0.0.0.0
2012-01-25 13:28:01 us=501065 ifconfig_pool_netmask = 0.0.0.0
2012-01-25 13:28:01 us=501077 ifconfig_pool_persist_filename =
'[UNDEF]'
2012-01-25 13:28:01 us=501089 ifconfig_pool_persist_refresh_freq =
600
2012-01-25 13:28:01 us=501101 n_bcast_buf = 256
2012-01-25 13:28:01 us=501113 tcp_queue_limit = 64
2012-01-25 13:28:01 us=501124 real_hash_size = 256
2012-01-25 13:28:01 us=501136 virtual_hash_size = 256
2012-01-25 13:28:01 us=501147 client_connect_script = '[UNDEF]'
2012-01-25 13:28:01 us=501159 learn_address_script = '[UNDEF]'
2012-01-25 13:28:01 us=501171 client_disconnect_script = '[UNDEF]'
2012-01-25 13:28:01 us=501183 client_config_dir = '[UNDEF]'
2012-01-25 13:28:01 us=501194 ccd_exclusive = DISABLED
2012-01-25 13:28:01 us=501206 tmp_dir = '/var/folders/Vg/
VgdNz5IJEBGy6ie8zTeU9k+++TI/-Tmp-/'
2012-01-25 13:28:01 us=501218 push_ifconfig_defined = DISABLED
2012-01-25 13:28:01 us=501231 push_ifconfig_local = 0.0.0.0
2012-01-25 13:28:01 us=501244 push_ifconfig_remote_netmask = 0.0.0.0
2012-01-25 13:28:01 us=501255 enable_c2c = DISABLED
2012-01-25 13:28:01 us=501267 duplicate_cn = DISABLED
2012-01-25 13:28:01 us=501279 cf_max = 0
2012-01-25 13:28:01 us=501290 cf_per = 0
2012-01-25 13:28:01 us=501301 max_clients = 1024
2012-01-25 13:28:01 us=501313 max_routes_per_client = 256
2012-01-25 13:28:01 us=501325 auth_user_pass_verify_script =
'[UNDEF]'
2012-01-25 13:28:01 us=501336 auth_user_pass_verify_script_via_file
= DISABLED
2012-01-25 13:28:01 us=501348 ssl_flags = 0
2012-01-25 13:28:01 us=501360 port_share_host = '[UNDEF]'
2012-01-25 13:28:01 us=501371 port_share_port = 0
2012-01-25 13:28:01 us=501383 client = ENABLED
2012-01-25 13:28:01 us=501394 pull = ENABLED
2012-01-25 13:28:01 us=501406 auth_user_pass_file = '[UNDEF]'
2012-01-25 13:28:01 us=501423 OpenVPN 2.2.1 i386-apple-darwin10.8.0
[SSL] [LZO2] [PKCS11] [eurephia] built on Jan 8 2012
2012-01-25 13:28:01 us=501565 MANAGEMENT: TCP Socket listening on
127.0.0.1:1337
2012-01-25 13:28:01 us=502290 Need hold release from management
interface, waiting...
2012-01-25 13:28:01 us=568076 MANAGEMENT: Client connected from
127.0.0.1:1337
2012-01-25 13:28:01 us=578578 MANAGEMENT: CMD 'pid'
2012-01-25 13:28:01 us=578698 MANAGEMENT: CMD 'state on'
2012-01-25 13:28:01 us=578792 MANAGEMENT: CMD 'state'
2012-01-25 13:28:01 us=578931 MANAGEMENT: CMD 'hold release'
2012-01-25 13:28:01 us=579262 WARNING: No server certificate
verification method has been enabled. See http://openvpn.net/howto.html#mitm
for more info.
2012-01-25 13:28:01 us=579282 NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts
2012-01-25 13:28:01 us=588274 WARNING: file 'client1.key' is group or
others accessible
2012-01-25 13:28:01 us=589115 LZO compression initialized
2012-01-25 13:28:01 us=589269 Control Channel MTU parms [ L:1576 D:140
EF:40 EB:0 ET:0 EL:0 ]
2012-01-25 13:28:01 us=589372 Socket Buffers: R=[262140->65536]
S=[131070->65536]
2012-01-25 13:28:01 us=589394 Data Channel MTU parms [ L:1576 D:1450
EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
2012-01-25 13:28:01 us=589435 Local Options String: 'V4,dev-type
tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher BF-
CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-01-25 13:28:01 us=589448 Expected Remote Options String: 'V4,dev-
type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher
BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-01-25 13:28:01 us=589475 Local Options hash (VER=V4): '31fdf004'
2012-01-25 13:28:01 us=589493 Expected Remote Options hash (VER=V4):
'3e6d1056'
2012-01-25 13:28:01 us=589533 Attempting to establish TCP connection
with 77.20.123.xxx:9010 [nonblock]
2012-01-25 13:28:01 us=589588 MANAGEMENT: >STATE:
1327494481,TCP_CONNECT,,,
2012-01-25 13:28:01 *Tunnelblick: Established communication with
OpenVPN
2012-01-25 13:28:02 us=590393 TCP connection established with
77.20.123.xxx:9010
2012-01-25 13:28:02 us=590504 TCPv4_CLIENT link local: [undef]
2012-01-25 13:28:02 us=590538 TCPv4_CLIENT link remote: 77.20.123.xxx:
9010
2012-01-25 13:28:02 us=590618 MANAGEMENT: >STATE:1327494482,WAIT,,,
2012-01-25 13:28:02 us=610722 MANAGEMENT: >STATE:1327494482,AUTH,,,
2012-01-25 13:28:02 us=610798 TLS: Initial packet from 77.20.123.xxx:
9010, sid=0ea52f1d 8fa08a56
2012-01-25 13:28:02 us=998254 VERIFY OK: depth=1, /C=DE/ST=NS/
L=GOETTINGEN/O=SEQLAB/OU=IT-Department/CN=cruncher/
emailAddress=a...@seqlab.de
2012-01-25 13:28:02 us=998564 VERIFY OK: depth=0, /C=DE/ST=NS/O=SEQLAB/
OU=IT-Department/CN=cruncher/emailAddress=a...@seqlab.de
2012-01-25 13:28:03 us=631867 Data Channel Encrypt: Cipher 'BF-CBC'
initialized with 128 bit key
2012-01-25 13:28:03 us=631925 Data Channel Encrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
2012-01-25 13:28:03 us=632007 Data Channel Decrypt: Cipher 'BF-CBC'
initialized with 128 bit key
2012-01-25 13:28:03 us=632024 Data Channel Decrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
2012-01-25 13:28:03 us=632171 Control Channel: TLSv1, cipher TLSv1/
SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2012-01-25 13:28:03 us=632209 [cruncher] Peer Connection Initiated
with 77.20.123.xxx:9010
2012-01-25 13:28:04 us=869605 MANAGEMENT: >STATE:
1327494484,GET_CONFIG,,,
2012-01-25 13:28:06 us=107189 SENT CONTROL [cruncher]:
'PUSH_REQUEST' (status=1)
2012-01-25 13:28:06 us=150895 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway,route-gateway dhcp,ping 10,ping-restart
120'
2012-01-25 13:28:06 us=151018 OPTIONS IMPORT: timers and/or timeouts
modified
2012-01-25 13:28:06 us=151061 OPTIONS IMPORT: route options modified
2012-01-25 13:28:06 us=151074 OPTIONS IMPORT: route-related options
modified
2012-01-25 13:28:06 us=151186 ROUTE default_gateway=192.168.178.1
2012-01-25 13:28:06 us=152351 TUN/TAP device /dev/tap0 opened
2012-01-25 13:28:06 us=152824 /sbin/ifconfig tap0 lladdr
00:03:93:57:57:57
2012-01-25 13:28:06 us=157671 TUN/TAP link layer address set to
00:03:93:57:57:57
2012-01-25 13:28:06 us=157810 /Applications/Tunnelblick.app/Contents/
Resources/client.up.tunnelblick.sh -m -w -d -a -atDASNGWrdasngw tap0
1500 1576 init
2012-01-25 13:28:08 us=928758 NOTE: unable to redirect default gateway
-- VPN gateway parameter (--route-gateway or --ifconfig) is missing
2012-01-25 13:28:08 us=928843 Initialization Sequence Completed
2012-01-25 13:28:08 us=928866 MANAGEMENT: >STATE:
1327494488,CONNECTED,SUCCESS,,77.20.123.xxx
2012-01-25 13:28:09 *Tunnelblick: Flushed the DNS cache
2012-01-25 13:28:11 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 0 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:11 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 1 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:13 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 2 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:15 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 3 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:18 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 4 seconds to wait for DHCP to finish setup.
#########################################################################################
I hope this is not too much of info. Did I miss anything in the
configs? Would you say the problem is on the server or on the client
side?
Thanks, Lupus
On 23 Jan., 22:28, Lupus <a...@seqlab.de> wrote:
> ... Now that I'm trying to connect from home, it isn't working.
related to the bridge interface. I used the bridge-start and bridge-
stop scripts from the Debian bridge-utils package as recommended by
the openvpn.net HOWTO http://www.openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html
. Apparently the default route is lost during setup, and thus the
openvpn-server had no connectivity to the outside world at all. I
didn't notice that while testing inside the company's private subnet.
Back to my original problem: the TB-client should receive an IP-
address from the company's DHCP-server. But before proceeding I really
should post my setup.
The remote (company) network can be reached via two different public
IP-addresses (load-balanced) and has a private network in the
192.168.101.0/24 range.
The router is at 192.168.101.1, the DHCP-server at 192.168.101.6, and
the OpenVPN-server at 192.168.101.10. On the public side port 9010 is
opened and forwarded to port 1194 on the OpenVPN-server
(192.168.101.10). That part is working ok, I think. On the OpenVPN-
server the (relevant) interfaces look like this (after running bridge-
start):
# ifconfig -a
br0 Link encap:Ethernet HWaddr 00:25:90:1d:1e:e8
inet addr:192.168.101.10 Bcast:192.168.101.255 Mask:
255.255.255.0
inet6 addr: fe80::225:90ff:fe1d:1ee8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3717329 errors:0 dropped:0 overruns:0 frame:0
TX packets:4374725 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2837890783 (2.6 GiB) TX bytes:4143672206 (3.8 GiB)
eth0 Link encap:Ethernet HWaddr 00:25:90:1d:1e:e8
inet6 addr: fe80::225:90ff:fe1d:1ee8/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:4960381 errors:0 dropped:0 overruns:0 frame:0
TX packets:5733252 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2970969373 (2.7 GiB) TX bytes:4219961987 (3.9 GiB)
Memory:fafe0000-fb000000
tap0 Link encap:Ethernet HWaddr 7e:24:40:71:2e:a5
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:81 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:27081 (26.4 KiB) TX bytes:0 (0.0 B)
So the bridge-interface has correctly taken the IP from the former
dhcp-configured eth0 interface. The server.conf file for the openvpn
server looks like this:
# cat server.conf
local 192.168.101.10
port 1194
proto tcp-server
tls-server
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem
server-bridge
push "redirect-gateway"
keepalive 10 120
comp-lzo
max-clients 10
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
;log openvpn.log
log-append openvpn.log
verb 4
;mute 20
My home situation is a private subnet behind a home-router
(192.168.178.0/24) The Tunnelblick client is configured as:
client
dev tap
proto tcp
remote 77.20.123.xxx 9010
remote 193.175.25.xxx 9010
resolv-retry infinite
nobind
# Client1 specific pseudo-Mac-address
lladdr 00:03:93:57:57:57
;user nobody
;group nobody
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 4
;mute 20
The logs look like this
server:
Wed Jan 25 13:28:01 2012 us=673611 MULTI: multi_create_instance called
Wed Jan 25 13:28:01 2012 us=673681 Re-using SSL/TLS context
Wed Jan 25 13:28:01 2012 us=673709 LZO compression initialized
Wed Jan 25 13:28:01 2012 us=673805 Control Channel MTU parms [ L:1576
D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Jan 25 13:28:01 2012 us=673824 Data Channel MTU parms [ L:1576 D:
1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Jan 25 13:28:01 2012 us=673849 Local Options String: 'V4,dev-type
tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher BF-
CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Jan 25 13:28:01 2012 us=673857 Expected Remote Options String:
'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-
lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Jan 25 13:28:01 2012 us=673877 Local Options hash (VER=V4):
'3e6d1056'
Wed Jan 25 13:28:01 2012 us=673889 Expected Remote Options hash
(VER=V4): '31fdf004'
Wed Jan 25 13:28:01 2012 us=673911 TCP connection established with
77.22.5.xx:62043
Wed Jan 25 13:28:01 2012 us=673924 Socket Buffers: R=[131072->131072]
S=[131072->131072]
Wed Jan 25 13:28:01 2012 us=673934 TCPv4_SERVER link local: [undef]
Wed Jan 25 13:28:01 2012 us=673944 TCPv4_SERVER link remote:
77.22.5.21:62043
Wed Jan 25 13:28:02 2012 us=653550 77.22.5.xx:62043 TLS: Initial
packet from 77.22.5.xx:62043, sid=8fbc3386 ea3c6874
Wed Jan 25 13:28:03 2012 us=406028 77.22.5.xx:62043 VERIFY OK:
depth=1, /C=DE/ST=NS/L=GOETTINGEN/O=SEQLAB/OU=IT-Department/
CN=cruncher/emailAddress=x...@seqlab.de
Wed Jan 25 13:28:03 2012 us=406195 77.22.5.xx:62043 VERIFY OK:
depth=0, /C=DE/ST=NS/O=SEQLAB/OU=IT-Department/CN=client1/
emailAddress=x...@seqlab.de
Wed Jan 25 13:28:03 2012 us=649286 77.22.5.xx:62043 Data Channel
Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 25 13:28:03 2012 us=649330 77.22.5.xx:62043 Data Channel
Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 25 13:28:03 2012 us=649392 77.22.5.xx:62043 Data Channel
Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jan 25 13:28:03 2012 us=649402 77.22.5.xx:62043 Data Channel
Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 25 13:28:03 2012 us=750047 77.22.5.xx:62043 Control Channel:
TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Jan 25 13:28:03 2012 us=750091 77.22.5.xx:62043 [client1] Peer
Connection Initiated with 77.22.5.xx:62043
Wed Jan 25 13:28:03 2012 us=750146 client1/77.22.5.xx:62043 MULTI: no
dynamic or static remote --ifconfig address is available for
client1/77.22.5.x:62043
Wed Jan 25 13:28:06 2012 us=169190 client1/77.22.5.xx:62043 PUSH:
Received control message: 'PUSH_REQUEST'
Wed Jan 25 13:28:06 2012 us=169288 client1/77.22.5.xx:62043 SENT
CONTROL [client1]: 'PUSH_REPLY,redirect-gateway,route-gateway
dhcp,ping 10,ping-restart 120' (status=1)
Wed Jan 25 13:28:09 2012 us=45882 client1/77.22.5.xx:62043 MULTI:
Learn: 00:03:93:57:57:57 -> client1/77.22.5.xx:62043
######################################################################
TB client:
2012-01-25 13:28:00 *Tunnelblick: OS X 10.6.5; Tunnelblick 3.2.2
(build 2891.2917)
...
2012-01-25 13:28:01 us=498205 proto = tcp-client
2012-01-25 13:28:01 us=498217 local = '[UNDEF]'
2012-01-25 13:28:01 us=498228 local_port = 0
2012-01-25 13:28:01 us=498239 remote = '77.20.123.xxx'
2012-01-25 13:28:01 us=498251 remote_port = 9010
2012-01-25 13:28:01 us=498262 remote_float = DISABLED
2012-01-25 13:28:01 us=498273 bind_defined = DISABLED
2012-01-25 13:28:01 us=498284 bind_local = DISABLED
2012-01-25 13:28:01 us=498296 connect_retry_seconds = 5
2012-01-25 13:28:01 us=498307 connect_timeout = 10
2012-01-25 13:28:01 us=498318 connect_retry_max = 0
2012-01-25 13:28:01 us=498329 socks_proxy_server = '[UNDEF]'
2012-01-25 13:28:01 us=498340 socks_proxy_port = 0
2012-01-25 13:28:01 us=498351 socks_proxy_retry = DISABLED
2012-01-25 13:28:01 us=498363 Connection profiles [1]:
2012-01-25 13:28:01 us=498374 proto = tcp-client
2012-01-25 13:28:01 us=498385 local = '[UNDEF]'
2012-01-25 13:28:01 us=498396 local_port = 0
2012-01-25 13:28:01 us=498408 remote = '193.175.25.222'
2012-01-25 13:28:01 us=498419 remote_port = 9010
2012-01-25 13:28:01 us=498430 remote_float = DISABLED
2012-01-25 13:28:01 us=498441 bind_defined = DISABLED
2012-01-25 13:28:01 us=498452 bind_local = DISABLED
2012-01-25 13:28:01 us=498464 connect_retry_seconds = 5
2012-01-25 13:28:01 us=498475 connect_timeout = 10
2012-01-25 13:28:01 us=498486 connect_retry_max = 0
2012-01-25 13:28:01 us=498497 socks_proxy_server = '[UNDEF]'
2012-01-25 13:28:01 us=498508 socks_proxy_port = 0
2012-01-25 13:28:01 us=498520 socks_proxy_retry = DISABLED
2012-01-25 13:28:01 us=498531 Connection profiles END
2012-01-25 13:28:01 us=498542 remote_random = DISABLED
2012-01-25 13:28:01 us=498553 ipchange = '[UNDEF]'
2012-01-25 13:28:01 us=498565 dev = 'tap'
2012-01-25 13:28:01 us=498576 dev_type = '[UNDEF]'
2012-01-25 13:28:01 us=498587 dev_node = '[UNDEF]'
2012-01-25 13:28:01 us=498598 lladdr = '00:03:93:57:57:57'
2012-01-25 13:28:01 us=498610 topology = 1
2012-01-25 13:28:01 us=498621 tun_ipv6 = DISABLED
2012-01-25 13:28:01 us=498632 ifconfig_local = '[UNDEF]'
2012-01-25 13:28:01 us=498643 ifconfig_remote_netmask = '[UNDEF]'
2012-01-25 13:28:01 us=498655 ifconfig_noexec = DISABLED
2012-01-25 13:28:01 us=498666 ifconfig_nowarn = DISABLED
2012-01-25 13:28:01 us=498692 shaper = 0
2012-01-25 13:28:01 us=498704 tun_mtu = 1500
2012-01-25 13:28:01 us=498715 tun_mtu_defined = ENABLED
2012-01-25 13:28:01 us=498726 link_mtu = 1500
2012-01-25 13:28:01 us=498737 link_mtu_defined = DISABLED
2012-01-25 13:28:01 us=498749 tun_mtu_extra = 32
2012-01-25 13:28:01 us=498760 tun_mtu_extra_defined = ENABLED
2012-01-25 13:28:01 us=498771 fragment = 0
2012-01-25 13:28:01 us=498783 mtu_discover_type = -1
2012-01-25 13:28:01 us=498794 mtu_test = 0
2012-01-25 13:28:01 us=498805 mlock = DISABLED
2012-01-25 13:28:01 us=498817 keepalive_ping = 0
2012-01-25 13:28:01 us=498828 keepalive_timeout = 0
2012-01-25 13:28:01 us=498839 inactivity_timeout = 0
2012-01-25 13:28:01 us=498850 ping_send_timeout = 0
2012-01-25 13:28:01 us=498861 ping_rec_timeout = 0
2012-01-25 13:28:01 us=498877 ping_rec_timeout_action = 0
2012-01-25 13:28:01 us=498888 ping_timer_remote = DISABLED
2012-01-25 13:28:01 us=498900 remap_sigusr1 = 0
2012-01-25 13:28:01 us=498911 explicit_exit_notification = 0
2012-01-25 13:28:01 us=498922 persist_tun = ENABLED
2012-01-25 13:28:01 us=498934 persist_local_ip = DISABLED
2012-01-25 13:28:01 us=498945 persist_remote_ip = DISABLED
2012-01-25 13:28:01 us=498959 persist_key = ENABLED
2012-01-25 13:28:01 us=498971 mssfix = 1450
2012-01-25 13:28:01 us=498982 passtos = DISABLED
2012-01-25 13:28:01 us=498994 resolve_retry_seconds = 1000000000
2012-01-25 13:28:01 us=499005 username = '[UNDEF]'
2012-01-25 13:28:01 us=499017 groupname = '[UNDEF]'
2012-01-25 13:28:01 us=499028 chroot_dir = '[UNDEF]'
2012-01-25 13:28:01 us=499039 cd_dir = '/Users/Lupus/Library/
Application Support/Tunnelblick/Configurations/cruncherglobal.tblk/
Contents/Resources'
2012-01-25 13:28:01 us=499051 writepid = '[UNDEF]'
2012-01-25 13:28:01 us=499062 up_script = '/Applications/
Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -
a -atDASNGWrdasngw'
2012-01-25 13:28:01 us=499078 down_script = '/Applications/
Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d
-a -atDASNGWrdasngw'
2012-01-25 13:28:01 us=499091 down_pre = DISABLED
2012-01-25 13:28:01 us=499106 up_restart = ENABLED
2012-01-25 13:28:01 us=499118 up_delay = DISABLED
2012-01-25 13:28:01 us=499130 daemon = ENABLED
2012-01-25 13:28:01 us=499142 inetd = 0
2012-01-25 13:28:01 us=499153 log = ENABLED
2012-01-25 13:28:01 us=499165 suppress_timestamps = DISABLED
2012-01-25 13:28:01 us=499177 nice = 0
2012-01-25 13:28:01 us=499189 verbosity = 4
2012-01-25 13:28:01 us=499201 mute = 0
2012-01-25 13:28:01 us=499212 gremlin = 0
2012-01-25 13:28:01 us=499224 status_file = '[UNDEF]'
2012-01-25 13:28:01 us=499236 status_file_version = 1
2012-01-25 13:28:01 us=499247 status_file_update_freq = 60
2012-01-25 13:28:01 us=499259 occ = ENABLED
2012-01-25 13:28:01 us=499271 rcvbuf = 65536
2012-01-25 13:28:01 us=499283 sndbuf = 65536
2012-01-25 13:28:01 us=499294 sockflags = 0
2012-01-25 13:28:01 us=499309 fast_io = DISABLED
2012-01-25 13:28:01 us=499321 lzo = 7
2012-01-25 13:28:01 us=499333 route_script = '[UNDEF]'
2012-01-25 13:28:01 us=499345 route_default_gateway = '[UNDEF]'
2012-01-25 13:28:01 us=499357 route_default_metric = 0
2012-01-25 13:28:01 us=499369 route_noexec = DISABLED
2012-01-25 13:28:01 us=499381 route_delay = 0
2012-01-25 13:28:01 us=499392 route_delay_window = 30
2012-01-25 13:28:01 us=499404 route_delay_defined = DISABLED
2012-01-25 13:28:01 us=499416 route_nopull = DISABLED
2012-01-25 13:28:01 us=499428 route_gateway_via_dhcp = DISABLED
2012-01-25 13:28:01 us=499440 max_routes = 100
2012-01-25 13:28:01 us=499452 allow_pull_fqdn = DISABLED
2012-01-25 13:28:01 us=499463 management_addr = '127.0.0.1'
2012-01-25 13:28:01 us=499490 management_port = 1337
2012-01-25 13:28:01 us=499502 management_user_pass = '[UNDEF]'
2012-01-25 13:28:01 us=499514 management_log_history_cache = 250
2012-01-25 13:28:01 us=499526 management_echo_buffer_size = 100
2012-01-25 13:28:01 us=499538 management_write_peer_info_file =
'[UNDEF]'
2012-01-25 13:28:01 us=499550 management_client_user = '[UNDEF]'
2012-01-25 13:28:01 us=499562 management_client_group = '[UNDEF]'
2012-01-25 13:28:01 us=499574 management_flags = 6
2012-01-25 13:28:01 us=499585 shared_secret_file = '[UNDEF]'
2012-01-25 13:28:01 us=499597 key_direction = 0
2012-01-25 13:28:01 us=499609 ciphername_defined = ENABLED
2012-01-25 13:28:01 us=499620 ciphername = 'BF-CBC'
2012-01-25 13:28:01 us=499632 authname_defined = ENABLED
2012-01-25 13:28:01 us=499643 authname = 'SHA1'
2012-01-25 13:28:01 us=499655 prng_hash = 'SHA1'
2012-01-25 13:28:01 us=499666 prng_nonce_secret_len = 16
2012-01-25 13:28:01 us=499678 keysize = 0
2012-01-25 13:28:01 us=499689 engine = DISABLED
2012-01-25 13:28:01 us=499701 replay = ENABLED
2012-01-25 13:28:01 us=499713 mute_replay_warnings = DISABLED
2012-01-25 13:28:01 us=499724 replay_window = 64
2012-01-25 13:28:01 us=499736 replay_time = 15
2012-01-25 13:28:01 us=499747 packet_id_file = '[UNDEF]'
2012-01-25 13:28:01 us=499759 use_iv = ENABLED
2012-01-25 13:28:01 us=499774 test_crypto = DISABLED
2012-01-25 13:28:01 us=499786 tls_server = DISABLED
2012-01-25 13:28:01 us=499798 tls_client = ENABLED
2012-01-25 13:28:01 us=499809 key_method = 2
2012-01-25 13:28:01 us=499821 ca_file = 'ca.crt'
2012-01-25 13:28:01 us=499832 ca_path = '[UNDEF]'
2012-01-25 13:28:01 us=499844 dh_file = '[UNDEF]'
2012-01-25 13:28:01 us=499855 cert_file = 'client1.crt'
2012-01-25 13:28:01 us=499867 priv_key_file = 'client1.key'
2012-01-25 13:28:01 us=499878 pkcs12_file = '[UNDEF]'
2012-01-25 13:28:01 us=499890 cipher_list = '[UNDEF]'
2012-01-25 13:28:01 us=499902 tls_verify = '[UNDEF]'
2012-01-25 13:28:01 us=499913 tls_export_cert = '[UNDEF]'
2012-01-25 13:28:01 us=499925 tls_remote = '[UNDEF]'
2012-01-25 13:28:01 us=499936 crl_file = '[UNDEF]'
2012-01-25 13:28:01 us=499948 ns_cert_type = 0
2012-01-25 13:28:01 us=499981 remote_cert_ku[i] = 0
….
2012-01-25 13:28:01 us=500166 remote_cert_eku = '[UNDEF]'
2012-01-25 13:28:01 us=500177 tls_timeout = 2
2012-01-25 13:28:01 us=500189 renegotiate_bytes = 0
2012-01-25 13:28:01 us=500200 renegotiate_packets = 0
2012-01-25 13:28:01 us=500212 renegotiate_seconds = 3600
2012-01-25 13:28:01 us=500223 handshake_window = 60
2012-01-25 13:28:01 us=500234 transition_window = 3600
2012-01-25 13:28:01 us=500246 single_session = DISABLED
2012-01-25 13:28:01 us=500257 push_peer_info = DISABLED
2012-01-25 13:28:01 us=500269 tls_exit = DISABLED
2012-01-25 13:28:01 us=500280 tls_auth_file = '[UNDEF]'
2012-01-25 13:28:01 us=500306 pkcs11_protected_authentication =
DISABLED
…
2012-01-25 13:28:01 us=500503 pkcs11_private_mode = 00000000
...
2012-01-25 13:28:01 us=500703 pkcs11_cert_private = DISABLED
...
2012-01-25 13:28:01 us=500889 pkcs11_pin_cache_period = -1
2012-01-25 13:28:01 us=500900 pkcs11_id = '[UNDEF]'
2012-01-25 13:28:01 us=500912 pkcs11_id_management = DISABLED
2012-01-25 13:28:01 us=500933 server_network = 0.0.0.0
2012-01-25 13:28:01 us=500946 server_netmask = 0.0.0.0
2012-01-25 13:28:01 us=500959 server_bridge_ip = 0.0.0.0
2012-01-25 13:28:01 us=500972 server_bridge_netmask = 0.0.0.0
2012-01-25 13:28:01 us=500985 server_bridge_pool_start = 0.0.0.0
2012-01-25 13:28:01 us=500998 server_bridge_pool_end = 0.0.0.0
2012-01-25 13:28:01 us=501010 ifconfig_pool_defined = DISABLED
2012-01-25 13:28:01 us=501037 ifconfig_pool_start = 0.0.0.0
2012-01-25 13:28:01 us=501052 ifconfig_pool_end = 0.0.0.0
2012-01-25 13:28:01 us=501065 ifconfig_pool_netmask = 0.0.0.0
2012-01-25 13:28:01 us=501077 ifconfig_pool_persist_filename =
'[UNDEF]'
2012-01-25 13:28:01 us=501089 ifconfig_pool_persist_refresh_freq =
600
2012-01-25 13:28:01 us=501101 n_bcast_buf = 256
2012-01-25 13:28:01 us=501113 tcp_queue_limit = 64
2012-01-25 13:28:01 us=501124 real_hash_size = 256
2012-01-25 13:28:01 us=501136 virtual_hash_size = 256
2012-01-25 13:28:01 us=501147 client_connect_script = '[UNDEF]'
2012-01-25 13:28:01 us=501159 learn_address_script = '[UNDEF]'
2012-01-25 13:28:01 us=501171 client_disconnect_script = '[UNDEF]'
2012-01-25 13:28:01 us=501183 client_config_dir = '[UNDEF]'
2012-01-25 13:28:01 us=501194 ccd_exclusive = DISABLED
2012-01-25 13:28:01 us=501206 tmp_dir = '/var/folders/Vg/
VgdNz5IJEBGy6ie8zTeU9k+++TI/-Tmp-/'
2012-01-25 13:28:01 us=501218 push_ifconfig_defined = DISABLED
2012-01-25 13:28:01 us=501231 push_ifconfig_local = 0.0.0.0
2012-01-25 13:28:01 us=501244 push_ifconfig_remote_netmask = 0.0.0.0
2012-01-25 13:28:01 us=501255 enable_c2c = DISABLED
2012-01-25 13:28:01 us=501267 duplicate_cn = DISABLED
2012-01-25 13:28:01 us=501279 cf_max = 0
2012-01-25 13:28:01 us=501290 cf_per = 0
2012-01-25 13:28:01 us=501301 max_clients = 1024
2012-01-25 13:28:01 us=501313 max_routes_per_client = 256
2012-01-25 13:28:01 us=501325 auth_user_pass_verify_script =
'[UNDEF]'
2012-01-25 13:28:01 us=501336 auth_user_pass_verify_script_via_file
= DISABLED
2012-01-25 13:28:01 us=501348 ssl_flags = 0
2012-01-25 13:28:01 us=501360 port_share_host = '[UNDEF]'
2012-01-25 13:28:01 us=501371 port_share_port = 0
2012-01-25 13:28:01 us=501383 client = ENABLED
2012-01-25 13:28:01 us=501394 pull = ENABLED
2012-01-25 13:28:01 us=501406 auth_user_pass_file = '[UNDEF]'
2012-01-25 13:28:01 us=501423 OpenVPN 2.2.1 i386-apple-darwin10.8.0
[SSL] [LZO2] [PKCS11] [eurephia] built on Jan 8 2012
2012-01-25 13:28:01 us=501565 MANAGEMENT: TCP Socket listening on
127.0.0.1:1337
2012-01-25 13:28:01 us=502290 Need hold release from management
interface, waiting...
2012-01-25 13:28:01 us=568076 MANAGEMENT: Client connected from
127.0.0.1:1337
2012-01-25 13:28:01 us=578578 MANAGEMENT: CMD 'pid'
2012-01-25 13:28:01 us=578698 MANAGEMENT: CMD 'state on'
2012-01-25 13:28:01 us=578792 MANAGEMENT: CMD 'state'
2012-01-25 13:28:01 us=578931 MANAGEMENT: CMD 'hold release'
2012-01-25 13:28:01 us=579262 WARNING: No server certificate
verification method has been enabled. See http://openvpn.net/howto.html#mitm
for more info.
2012-01-25 13:28:01 us=579282 NOTE: the current --script-security
setting may allow this configuration to call user-defined scripts
2012-01-25 13:28:01 us=588274 WARNING: file 'client1.key' is group or
others accessible
2012-01-25 13:28:01 us=589115 LZO compression initialized
2012-01-25 13:28:01 us=589269 Control Channel MTU parms [ L:1576 D:140
EF:40 EB:0 ET:0 EL:0 ]
2012-01-25 13:28:01 us=589372 Socket Buffers: R=[262140->65536]
S=[131070->65536]
2012-01-25 13:28:01 us=589394 Data Channel MTU parms [ L:1576 D:1450
EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
2012-01-25 13:28:01 us=589435 Local Options String: 'V4,dev-type
tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher BF-
CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2012-01-25 13:28:01 us=589448 Expected Remote Options String: 'V4,dev-
type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher
BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2012-01-25 13:28:01 us=589475 Local Options hash (VER=V4): '31fdf004'
2012-01-25 13:28:01 us=589493 Expected Remote Options hash (VER=V4):
'3e6d1056'
2012-01-25 13:28:01 us=589533 Attempting to establish TCP connection
with 77.20.123.xxx:9010 [nonblock]
2012-01-25 13:28:01 us=589588 MANAGEMENT: >STATE:
1327494481,TCP_CONNECT,,,
2012-01-25 13:28:01 *Tunnelblick: Established communication with
OpenVPN
2012-01-25 13:28:02 us=590393 TCP connection established with
77.20.123.xxx:9010
2012-01-25 13:28:02 us=590504 TCPv4_CLIENT link local: [undef]
2012-01-25 13:28:02 us=590538 TCPv4_CLIENT link remote: 77.20.123.xxx:
9010
2012-01-25 13:28:02 us=590618 MANAGEMENT: >STATE:1327494482,WAIT,,,
2012-01-25 13:28:02 us=610722 MANAGEMENT: >STATE:1327494482,AUTH,,,
2012-01-25 13:28:02 us=610798 TLS: Initial packet from 77.20.123.xxx:
9010, sid=0ea52f1d 8fa08a56
2012-01-25 13:28:02 us=998254 VERIFY OK: depth=1, /C=DE/ST=NS/
L=GOETTINGEN/O=SEQLAB/OU=IT-Department/CN=cruncher/
emailAddress=a...@seqlab.de
2012-01-25 13:28:02 us=998564 VERIFY OK: depth=0, /C=DE/ST=NS/O=SEQLAB/
OU=IT-Department/CN=cruncher/emailAddress=a...@seqlab.de
2012-01-25 13:28:03 us=631867 Data Channel Encrypt: Cipher 'BF-CBC'
initialized with 128 bit key
2012-01-25 13:28:03 us=631925 Data Channel Encrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
2012-01-25 13:28:03 us=632007 Data Channel Decrypt: Cipher 'BF-CBC'
initialized with 128 bit key
2012-01-25 13:28:03 us=632024 Data Channel Decrypt: Using 160 bit
message hash 'SHA1' for HMAC authentication
2012-01-25 13:28:03 us=632171 Control Channel: TLSv1, cipher TLSv1/
SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2012-01-25 13:28:03 us=632209 [cruncher] Peer Connection Initiated
with 77.20.123.xxx:9010
2012-01-25 13:28:04 us=869605 MANAGEMENT: >STATE:
1327494484,GET_CONFIG,,,
2012-01-25 13:28:06 us=107189 SENT CONTROL [cruncher]:
'PUSH_REQUEST' (status=1)
2012-01-25 13:28:06 us=150895 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway,route-gateway dhcp,ping 10,ping-restart
120'
2012-01-25 13:28:06 us=151018 OPTIONS IMPORT: timers and/or timeouts
modified
2012-01-25 13:28:06 us=151061 OPTIONS IMPORT: route options modified
2012-01-25 13:28:06 us=151074 OPTIONS IMPORT: route-related options
modified
2012-01-25 13:28:06 us=151186 ROUTE default_gateway=192.168.178.1
2012-01-25 13:28:06 us=152351 TUN/TAP device /dev/tap0 opened
2012-01-25 13:28:06 us=152824 /sbin/ifconfig tap0 lladdr
00:03:93:57:57:57
2012-01-25 13:28:06 us=157671 TUN/TAP link layer address set to
00:03:93:57:57:57
2012-01-25 13:28:06 us=157810 /Applications/Tunnelblick.app/Contents/
Resources/client.up.tunnelblick.sh -m -w -d -a -atDASNGWrdasngw tap0
1500 1576 init
2012-01-25 13:28:08 us=928758 NOTE: unable to redirect default gateway
-- VPN gateway parameter (--route-gateway or --ifconfig) is missing
2012-01-25 13:28:08 us=928843 Initialization Sequence Completed
2012-01-25 13:28:08 us=928866 MANAGEMENT: >STATE:
1327494488,CONNECTED,SUCCESS,,77.20.123.xxx
2012-01-25 13:28:09 *Tunnelblick: Flushed the DNS cache
2012-01-25 13:28:11 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 0 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:11 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 1 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:13 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 2 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:15 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 3 seconds to wait for DHCP to finish setup.
2012-01-25 13:28:18 *Tunnelblick client.up.tunnelblick.sh: Sleeping
for 4 seconds to wait for DHCP to finish setup.
#########################################################################################
I hope this is not too much of info. Did I miss anything in the
configs? Would you say the problem is on the server or on the client
side?
Thanks, Lupus
jkbull...gmail.com
Jan 25, 2012, 9:22:50 AM1/25/12
to tunnelbli...@googlegroups.com
Thanks for explaining the setup so clearly and including the configs and logs.
But I am confused: is it working or not? At the start you say
As an update to my previous post: it is working now.
but at the end you say
Would you say the problem is on the server or on the client side?
If it isn't working, the interesting part of the log is where you cut it off -- does DHCP actually finish setup or does Tunnelblick keep waiting indefinitely?
To answer a couple of questions you've posed:
- lladdr is in OpenVPN 2.2.1; I don't know when it showed up.
- I think HTTP-Proxy and SOCKS-proxy don't apply to your situation.
The only thing I see that's odd is in the Tunnelblick log:
2012-01-25 13:28:06 us=150895 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway,route-gateway dhcp,ping 10,ping-restart 120'
which shows the server "pushes" a "redirect-gateway" command without any flags. If it's working I wouldn't mess with it, but usually the command that's used is "redirect-gateway def1". I don't know if putting "redirect-gateway" in the configuration file will override the "pushed" command, but you might want to try that because it is so easy. ("def1" makes everything route through the VPN, and is a common security mechanism for corporate networks. Details on redirect-gateway are on the OpenVPN Man page.)
Lupus
Jan 25, 2012, 11:37:35 AM1/25/12
to tunnelblick-discuss
jkbull, thanks for taking the time even if my problem might not even
relate to Tunnelblick
> But I am confused: is it working or not? At the start you say
Sorry for the confusion. I have been working on this all day, trying
dozends of setups and reading everything I could find about openvpn
bridge configurations (which unfortunately isn't too much, at least as
far as using a separate dhcp-server on the server-side LAN is
concerned). By now, I guess, I'm pretty confused, too.
Anyway, what I meant with "it's working" was solely the fact that the
server is responding up to the point where the log ends. Yesterday the
server wasn't responding at all, which - as I mentioned in my last
post - was apparently due to lacking routing info.
> If it isn't working, the interesting part of the log is where you cut it
> off -- does DHCP actually finish setup or does Tunnelblick keep waiting
> indefinitely?
The latter is true. I didn't cut anything at the end. The process
ends, where the client waits for the dhcp-server to answer
("Tunnelblick client.up.tunnelblick.sh: Sleeping for 4 seconds to wait
for DHCP to finish setup"). After that nothing happens on either side.
The dhcp-server log shows no discover event from the Tunnelblick tap-
Interface's MAC-address. The lladdr seems to work, though. The server
log says "client1/77.22.5.xx:62043 MULTI: Learn: 00:03:93:57:57:57 ->
client1/77.22.5.xx:62043". However, 77.22.5.xx is the WAN-IP of my
home-router. Is that confusing the vpn-server? Actually I want the
00:03:93:57:57:57 to be associated with the 192.168.178.xx, which is
the private IP of my MacBook (the tap, respectively) in my home LAN,
don't you think? The other thing is that the "learn" line appears in
the log only after the server has pushed its configuration params. I
would have thought that the 00:03:93:57:57:57 has to be forwarded to
the dhcp-server as part of the query for an IP for the client.
> The only thing I see that's odd is in the Tunnelblick log:
>
> > 2012-01-25 13:28:06 us=150895 PUSH: Received control message:
> > 'PUSH_REPLY,redirect-gateway,route-gateway dhcp,ping 10,ping-restart 120'
>
> which shows the server "pushes" a "redirect-gateway" command without any
> flags. If it's working I wouldn't mess with it, but usually the command
> that's used is "redirect-gateway def1". I don't know if putting
> "redirect-gateway" in the configuration file will override the "pushed"
> command, but you might want to try that because it is so easy. ("def1"
> makes everything route through the VPN, and is a common security mechanism
> for corporate networks. Details on redirect-gateway are on the OpenVPN Man
> page<http://openvpn.net/index.php/open-source/documentation/manuals/openvp...>
> .)
Well, that's probably my fault. I included the <push "redirect-
gateway"> without "def1" into the server's config. But I think the
connection never comes that far. TB probably waits for an ifconfig or
similar directive to adjust its IP, which never arrives. If I close
the (semi-)connection, the TB log states:
2012-01-25 14:53:52 us=550334 event_wait : Interrupted system call
(code=4)
2012-01-25 14:53:52 us=550848 TCP/UDP: Closing socket
2012-01-25 14:53:52 us=550958 Closing TUN/TAP interface
2012-01-25 14:53:52 us=551124 /Applications/Tunnelblick.app/Contents/
Resources/client.down.tunnelblick.sh -m -w -d -a -atDASNGWrdasngw tap0
1500 1576 init
2012-01-25 14:53:53 *Tunnelblick client.down.tunnelblick.sh: WARNING:
No existing OpenVPN DNS configuration found; not tearing down
anything; exiting.
2012-01-25 14:53:53 us=708451 SIGTERM[hard,] received, process exiting
2012-01-25 14:53:53 us=708522 MANAGEMENT: >STATE:
1327499633,EXITING,SIGTERM,,
2012-01-25 14:53:55 *Tunnelblick: Flushed the DNS cache
I don't know what else I can do. Setting aside part of the subnet for
the openvpn-server is problematic, since the IPs in use are dispersed
all over the subnet range. What puzzles me are the different items in
the TB preferences for setting the nameserver. Is there a special
section in the manual where the differences are explained into a
little more depth?
relate to Tunnelblick
> But I am confused: is it working or not? At the start you say
dozends of setups and reading everything I could find about openvpn
bridge configurations (which unfortunately isn't too much, at least as
far as using a separate dhcp-server on the server-side LAN is
concerned). By now, I guess, I'm pretty confused, too.
Anyway, what I meant with "it's working" was solely the fact that the
server is responding up to the point where the log ends. Yesterday the
server wasn't responding at all, which - as I mentioned in my last
post - was apparently due to lacking routing info.
> If it isn't working, the interesting part of the log is where you cut it
> off -- does DHCP actually finish setup or does Tunnelblick keep waiting
> indefinitely?
ends, where the client waits for the dhcp-server to answer
("Tunnelblick client.up.tunnelblick.sh: Sleeping for 4 seconds to wait
for DHCP to finish setup"). After that nothing happens on either side.
The dhcp-server log shows no discover event from the Tunnelblick tap-
Interface's MAC-address. The lladdr seems to work, though. The server
log says "client1/77.22.5.xx:62043 MULTI: Learn: 00:03:93:57:57:57 ->
client1/77.22.5.xx:62043". However, 77.22.5.xx is the WAN-IP of my
home-router. Is that confusing the vpn-server? Actually I want the
00:03:93:57:57:57 to be associated with the 192.168.178.xx, which is
the private IP of my MacBook (the tap, respectively) in my home LAN,
don't you think? The other thing is that the "learn" line appears in
the log only after the server has pushed its configuration params. I
would have thought that the 00:03:93:57:57:57 has to be forwarded to
the dhcp-server as part of the query for an IP for the client.
> The only thing I see that's odd is in the Tunnelblick log:
>
> > 2012-01-25 13:28:06 us=150895 PUSH: Received control message:
> > 'PUSH_REPLY,redirect-gateway,route-gateway dhcp,ping 10,ping-restart 120'
>
> which shows the server "pushes" a "redirect-gateway" command without any
> flags. If it's working I wouldn't mess with it, but usually the command
> that's used is "redirect-gateway def1". I don't know if putting
> "redirect-gateway" in the configuration file will override the "pushed"
> command, but you might want to try that because it is so easy. ("def1"
> makes everything route through the VPN, and is a common security mechanism
> for corporate networks. Details on redirect-gateway are on the OpenVPN Man
> .)
Well, that's probably my fault. I included the <push "redirect-
gateway"> without "def1" into the server's config. But I think the
connection never comes that far. TB probably waits for an ifconfig or
similar directive to adjust its IP, which never arrives. If I close
the (semi-)connection, the TB log states:
2012-01-25 14:53:52 us=550334 event_wait : Interrupted system call
(code=4)
2012-01-25 14:53:52 us=550848 TCP/UDP: Closing socket
2012-01-25 14:53:52 us=550958 Closing TUN/TAP interface
2012-01-25 14:53:52 us=551124 /Applications/Tunnelblick.app/Contents/
Resources/client.down.tunnelblick.sh -m -w -d -a -atDASNGWrdasngw tap0
1500 1576 init
2012-01-25 14:53:53 *Tunnelblick client.down.tunnelblick.sh: WARNING:
No existing OpenVPN DNS configuration found; not tearing down
anything; exiting.
2012-01-25 14:53:53 us=708451 SIGTERM[hard,] received, process exiting
2012-01-25 14:53:53 us=708522 MANAGEMENT: >STATE:
1327499633,EXITING,SIGTERM,,
2012-01-25 14:53:55 *Tunnelblick: Flushed the DNS cache
I don't know what else I can do. Setting aside part of the subnet for
the openvpn-server is problematic, since the IPs in use are dispersed
all over the subnet range. What puzzles me are the different items in
the TB preferences for setting the nameserver. Is there a special
section in the manual where the differences are explained into a
little more depth?
jkbull...gmail.com
Jan 25, 2012, 12:25:14 PM1/25/12
to tunnelbli...@googlegroups.com
The process ends, where the client waits for the dhcp-server to answer ("Tunnelblick client.up.tunnelblick.sh: Sleeping for 4 seconds to wait for DHCP to finish setup"). After that nothing happens on either side.
That's very odd. Tunnelblick should wait 5 seconds, then 6, then 7, etc., and output a log entry each time. From what I have seen, it often takes several seconds to get the DHCP info, so I am not surprised by the 1+2+3+4 = 10 second wait that it shows (so far). But Tunnelblick should continue to log that it is waiting. The code that does this is very straightforward, so I don't see that it could be a bug, but...
The dhcp-server log shows no discover event from the Tunnelblick tap-
Interface's MAC-address.
I assume that's why it isn't getting the DHCP info.
The lladdr seems to work, though. The server log says "client1/77.22.5.xx:62043 MULTI: Learn: 00:03:93:57:57:57 -> client1/77.22.5.xx:62043". However, 77.22.5.xx is the WAN-IP of my home-router. Is that confusing the vpn-server?
Could be. I'm not really knowledgable enough to answer.
Actually I want the 00:03:93:57:57:57 to be associated with the 192.168.178.xx, which is the private IP of my MacBook (the tap, respectively) in my home LAN, don't you think?
That makes sense to me, but, again, I'm not an expert.
The other thing is that the "learn" line appears in the log only after the server has pushed its configuration params. I would have thought that the 00:03:93:57:57:57 has to be forwarded to the dhcp-server as part of the query for an IP for the client.
Yes, that makes sense. I wonder if the "lladdr" option only works when the OpenVPN server is giving out DHCP info (as opposed to a different DHCP server doing it.)
I don't know what else I can do. Setting aside part of the subnet for the openvpn-server is problematic, since the IPs in use are dispersed all over the subnet range. What puzzles me are the different items in the TB preferences for setting the nameserver. Is there a special section in the manual where the differences are explained into a little more depth?
No, there isn't much. If you haven't already tried other "Set DNS/WINS" settings, you should definitely do so. Basically, each setting causes OpenVPN to use a different set of "up" and "down" scripts. The standard setting usually works, but there are some situations where one of the alternative settings works better.
I hadn't focused on this before, but you should be aware that when using your own DHCP server, OpenVPN never releases the lease. This can't be fixed by Tunnelblick currently because by the time Tunnelblick is told that the connection is going down, it is too late to release the lease because the connection has already been closed. (See https://groups.google.com/d/topic/tunnelblick-discuss/-iot0HYprSM/discussion, but apparently my comments on this thread about "down-pre" being able to get around this are not correct.)
Earlier today (in a nice coincidence), a patch to OpenVPN was submitted that would add a "hook" that Tunnelblick could use to get the lease released properly. At least I think the patch will allow that; I'm not absolutely sure. And I don't know when the patch will show up in a stable version of OpenVPN. I usually try to keep Tunnelblick updated with the latest stable OpenVPN, so Tunnelblick will be updated to use it soon after it becomes available.
I'm not really much of a networking expert. You might have better luck asking about this on one of the OpenVPN mailing lists or forums -- there are a couple listed on the left side of the Tunnelblick home page.
Lupus
Jan 27, 2012, 3:10:43 PM1/27/12
to tunnelbli...@googlegroups.com
Hi, sorry for the delay. It turned out that I had a problem with the bridge on the vpn-server side. I used the bridge-start and -stop scripts from the debian openvpn 2.1 package as recommended in the openvpn.net howto that deals with a bridge setup. By now I think that was the worst mistake. They have to be started manually before and after starting openvpn. I'm not sure what exactly happened (the bridge-stop script crashed the linux machine once and rendered my ssh-connection unusable, it's a headless machine). After rebooting everything seemed fine and all the interfaces seemed to be in place. With "ifconfig -a" everything showed up, tap0, br0 and eth0, but I couldn't ping from either side to the other subnet. This is what I described in my last post. Finally, I realized that all interfaces were present, but tap0 was not connected to br0, only eth0. I realized that when I used "brctl show". What a mess. Anyway, I decided to redesign the whole bridge-thing using the ifupdown tools and hopefully that part is vanilla now...
Back to the dhcp problem. It still isn'nt working. When I tried the different up-scripts for setting the nameservers I had really severe crashes/kernel-panics. So I decided to let the openvpn-server use a tiny pool of addresses (server bridge 192.168.101.1 255.255.255.0 192.168.101.13 192.168.101.17) for assigning the IPs. The good news is that I finally got a working connection (I can ping, see broadcast services like bonjour, and copy files from Macs in our company). Although I don't really need dhcp for assigning IPs anymore, I still need the company's lokal nameserver (internal services that rely on locally resolved names). As far as I understood, the --dhcp-option dns only works for Windows clients. Is that true? I had a brief look at the up-scripts in Tunnelblick (but I'm very bad at shell-scripting). I think I saw some lines dealing with "foreign_option". Are pushed dns option actually recognized and used by TB for changing the nameservers?
Just to not let your replies go unanswered
The process ends, where the client waits for the dhcp-server to answer ("Tunnelblick client.up.tunnelblick.sh: Sleeping for 4 seconds to wait for DHCP to finish setup"). After that nothing happens on either side.That's very odd. Tunnelblick should wait 5 seconds, then 6, then 7, etc., and output a log entry each time. From what I have seen, it often takes several seconds to get the DHCP info, so I am not surprised by the 1+2+3+4 = 10 second wait that it shows (so far). But Tunnelblick should continue to log that it is waiting. The code that does this is very straightforward, so I don't see that it could be a bug, but...
Even with the "repaired" bridge I never came beyond 4 seconds.
The dhcp-server log shows no discover event from the Tunnelblick tap-
Interface's MAC-address.I assume that's why it isn't getting the DHCP info.
That changed when I tried to use the "server-bridge" without any parameters. The dhcp-server was queried with the correct hardware address, but dhcp just errored:
Jan 27 17:35:07 g4bsd dhcpd: DHCPDISCOVER from 00:03:93:57:57:57 via gem0: network 192.168.101/24: no address pool
Jan 27 17:35:41 g4bsd last message repeated 6 times
Jan 27 17:36:06 g4bsd last message repeated 3 times
I have no idea why this happens. The dhcpd.conf should be correct. I changed it a hundred times before and dhcpd will refuse to reload it if something is wrong with it. Strange, really strange.
I hadn't focused on this before, but you should be aware that when using your own DHCP server, OpenVPN never releases the lease. This can't be fixed by Tunnelblick currently because by the time Tunnelblick is told that the connection is going down, it is too late to release the lease because the connection has already been closed. (See https://groups.google.com/d/topic/tunnelblick-discuss/-iot0HYprSM/discussion, but apparently my comments on this thread about "down-pre" being able to get around this are not correct.)
ok, thanks for the hint/warning. At the moment I wish I had a lease...
Earlier today (in a nice coincidence), a patch to OpenVPN was submitted that would add a "hook" that Tunnelblick could use to get the lease released properly. At least I think the patch will allow that; I'm not absolutely sure. And I don't know when the patch will show up in a stable version of OpenVPN. I usually try to keep Tunnelblick updated with the latest stable OpenVPN, so Tunnelblick will be updated to use it soon after it becomes available.
That sounds promising. I'm tensed to test it ;-)
I'm not really much of a networking expert.
Nor am I. I just try to keep struggling and hope for miracles to occur all the sudden. That bridge thing made me banging my head very hard, though.
jkbull...gmail.com
Jan 27, 2012, 3:40:06 PM1/27/12
to tunnelbli...@googlegroups.com
On Friday, January 27, 2012 3:10:43 PM UTC-5, Lupus wrote:
Back to the dhcp problem. It still isn'nt working. When I tried the different up-scripts for setting the nameservers I had really severe crashes/kernel-panics.
WOW! No way that should be happening -- I've never seen anything like that from the scripts. The scripts run as root, but there's not much that they do that should cause a crash (if the script gets an error, OpenVPN complains, but that's all).
So I decided to let the openvpn-server use a tiny pool of addresses (server bridge 192.168.101.1 255.255.255.0 192.168.101.13 192.168.101.17) for assigning the IPs. The good news is that I finally got a working connection (I can ping, see broadcast services like bonjour, and copy files from Macs in our company). Although I don't really need dhcp for assigning IPs anymore, I still need the company's lokal nameserver (internal services that rely on locally resolved names). As far as I understood, the --dhcp-option dns only works for Windows clients. Is that true? I had a brief look at the up-scripts in Tunnelblick (but I'm very bad at shell-scripting). I think I saw some lines dealing with "foreign_option". Are pushed dns option actually recognized and used by TB for changing the nameservers?
Yes -- that's one of the purposes of the scripts. Only some of the "Windows only" options are supported, though (-dhcp-option dns is one). Use "Set DNS/WINS" to "Set nameserver"; that script is the most likely to work.
Lupus
Jan 28, 2012, 8:26:38 AM1/28/12
to tunnelbli...@googlegroups.com
Are pushed dns option actually recognized and used by TB for changing the nameservers?Yes -- that's one of the purposes of the scripts. Only some of the "Windows only" options are supported, though (-dhcp-option dns is one). Use "Set DNS/WINS" to "Set nameserver"; that script is the most likely to work.
OK, the default setting is what I always use first.
This is what I get with "Set nameserver"
......
2012-01-28 13:38:31 us=849013 MANAGEMENT: >STATE:1327754311,GET_CONFIG,,,
2012-01-28 13:38:32 us=368457 SENT CONTROL [cruncher]: 'PUSH_REQUEST' (status=1)
2012-01-28 13:38:32 us=408592 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.101.6,route-gateway 192.168.101.1,ping 10,ping-restart 120,ifconfig 192.168.101.13 255.255.255.0'
2012-01-28 13:38:32 us=408759 OPTIONS IMPORT: timers and/or timeouts modified
2012-01-28 13:38:32 us=408791 OPTIONS IMPORT: --ifconfig/up options modified
2012-01-28 13:38:32 us=408811 OPTIONS IMPORT: route-related options modified
2012-01-28 13:38:32 us=408826 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2012-01-28 13:38:32 us=409087 TUN/TAP device /dev/tap0 opened
2012-01-28 13:38:32 us=409125 /sbin/ifconfig tap0 lladdr 00:03:93:57:57:57
2012-01-28 13:38:32 us=411713 TUN/TAP link layer address set to 00:03:93:57:57:57
2012-01-28 13:38:32 us=411791 MANAGEMENT: >STATE:1327754312,ASSIGN_IP,,192.168.101.13,
2012-01-28 13:38:32 us=412050 /sbin/ifconfig tap0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2012-01-28 13:38:32 us=414536 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2012-01-28 13:38:32 us=414598 /sbin/ifconfig tap0 192.168.101.13 netmask 255.255.255.0 mtu 1500 up
2012-01-28 13:38:32 us=419003 PLUGIN_CALL: POST /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.1.4/openvpn-down-root.so/PLUGIN_UP status=0
2012-01-28 13:38:32 us=419095 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -a -atDASNGWrdasngw tap0 1500 1576 192.168.101.13 255.255.255.0 init
2012-01-28 13:38:34 *Tunnelblick: Flushed the DNS cache
2012-01-28 13:38:34 us=587010 GID set to nobody
2012-01-28 13:38:34 us=587083 UID set to nobody
2012-01-28 13:38:34 us=587098 Initialization Sequence Completed
2012-01-28 13:38:34 us=587126 MANAGEMENT: >STATE:1327754314,CONNECTED,SUCCESS,192.168.101.13,77.20.123.123
2012-01-28 13:38:37 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 0 seconds to wait for DHCP to finish setup.
2012-01-28 13:38:37 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 1 seconds to wait for DHCP to finish setup.
2012-01-28 13:38:38 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 2 seconds to wait for DHCP to finish setup.
2012-01-28 13:38:40 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 3 seconds to wait for DHCP to finish setup.
2012-01-28 13:38:43 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 4 seconds to wait for DHCP to finish setup.
My interpretation of the log is that the nameserver option is pushed correctly by the server (dhcp-option DNS 192.168.101.6), and TB recognizes that some DNS-related option has arrived (OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified). There are still a couple of things that I cannot explain/understand.
i) why is the Mac-address of tap0 on the TB-side set only after the push has been received from the server (well, I asked that before)
ii) is there a separate dns setting for my original interface (en1) and for the newly created tap0 device? Probably not.
iii) how can I check if the dns-settings were successfully changed? Should I see that in the OS X network settings? Should the Network tool resolve names from the remote private subnet?
iv) which DHCP is TB waiting for in the last lines of the log. The dhcp-client of the MacBook to accept the new dns-settings? Or the remote dhcp-server to send more? BTW, I still dont get beyond 4 seconds of sleep...
I will check the other up-scripts now...
jkbull...gmail.com
Jan 28, 2012, 12:54:24 PM1/28/12
to tunnelbli...@googlegroups.com
I see one problem that could be causing trouble: put the semicolons back in front of the "user nobody" and "group nobody" from your configuration file. "user nobody" and "group nobody" can interfere with some of what Tunnelblick and OpenVPN have to do.
My interpretation of the log is that the nameserver option is pushed correctly by the server (dhcp-option DNS 192.168.101.6), and TB recognizes that some DNS-related option has arrived (OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified).
Yes, although it means that OpenVPN (not Tunnelblick) recognizes it.
There are still a couple of things that I cannot explain/understand.i) why is the Mac-address of tap0 on the TB-side set only after the push has been received from the server (well, I asked that before)
I don't know -- maybe everything on tap0 is set at once (after getting the DHCP lease).
ii) is there a separate dns setting for my original interface (en1) and for the newly created tap0 device? Probably not.
Sorry, I don't know.
iii) how can I check if the dns-settings were successfully changed? Should I see that in the OS X network settings?
Yes.
Should the Network tool resolve names from the remote private subnet?
Probably. Using etc/resolve (or whatever it is) does not necessarily work because OS X doesn't use it.
iv) which DHCP is TB waiting for in the last lines of the log. The dhcp-client of the MacBook to accept the new dns-settings? Or the remote dhcp-server to send more? BTW, I still dont get beyond 4 seconds of sleep...
I'm not an expert on these scripts, but here's what I think is happening (in client.up.tunnelblick.sh lines 404 - 418):
It's waiting for a DHCP server to respond and send the DHCP lease info. The script assumes this is done when "ipconfig getoption tap0 domain_name 2" or "ipconfig getoption tap0 domain_name_server 2" return something.
Then it tries to get the first packet from the DHCP server using "ipconfig getpacket tap0" -- and I think this may be what is hanging up.
To see if it is hanging up there, you could insert log lines as follows (insertion in red, exising lines in black) at line 418:
done
logMessage "will do 'ipconfig getpacket $dev'"
sGetPacketOutput=`ipconfig getpacket $dev`
logMessage "did 'ipconfig getpacket $dev'"
set -e # We instruct bash that it CAN again fail on individual errors
If it shows the first message but not the second, then ipconfig is hanging up. You can try moving the "set -e" up so it looks like this:
done
set -e # We instruct bash that it CAN again fail on individual errors
logMessage "will do 'ipconfig getpacket $dev'"
sGetPacketOutput=`ipconfig getpacket $dev`
logMessage "did 'ipconfig getpacket $dev'"
Thinking about it, perhaps an error is happening in the ipconfig line, when errors are not trapped by bash. That might cause the crashes/kernel panics (I'm guessing).
I will check the other up-scripts now...
OK, but be sure to remove the "user nobody" and "group nobody" lines.
Reply all
Reply to author
Forward
0 new messages