Pushing Route with Tap/DHCP
1,520 views
Skip to first unread message
Nicholas
May 1, 2011, 3:51:26 PM5/1/11
to tunnelblick-discuss
This does not relate directly to Tunnelblick, as I experience this
issue on Windows OpenVPN clients, too. But I've become familiar with
this community, so I figured I'd see if anyone here knows what I'm
doing wrong.
I have a server set up with TAP and DHCP. I can connect to the server
just fine (on Windows clients I get an address automatically ... with
Tunnelblick I have to issue the command "sudo ipconfig set tap0 DHCP"
until that bug is fixed completely). The subnet for the VPN is
172.16.122.0/24. The server is also set up to push a route to a
different subnet behind the VPN (192.168.122.0/24). Neither the
Windows nor the Mac OS X clients get the route, and OpenVPN complains
about not having a route-gateway. Here is the server configuration:
/usr/sbin/openvpn --daemon --verb 3 --writepid /var/run/openvpn-
vtun0.pid --status /opt/vyatta/etc/openvpn/status/vtun0.status 30 --
dev-type tap --dev vtun0 --mode server --tls-server --topology subnet
--keepalive 10 60 --ca /root/openvpn/keys/ca.crt --cert /root/openvpn/
keys/server.crt --key /root/openvpn/keys/server.key --dh /root/openvpn/
keys/dh1024.pem --push dhcp-option DNS 172.16.122.1 --push route
192.168.122.0 255.255.255.0 --server-bridge --client-config-dir /opt/
vyatta/etc/openvpn/ccd/vtun0 --comp-lzo --push dhcp-option DOMAIN
nickhq.com
And the client configuration:
client
dev tap
proto udp
remote ___ 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ___.crt
cert __.crt
key ___.key
ns-cert-type server
comp-lzo
verb 3
The full log output is at the bottom. The items that stick out to me
are:
2011-05-01 14:45:19 PUSH: Received control message: 'PUSH_REPLY,dhcp-
option DNS 172.16.122.1,route 192.168.122.0 255.255.255.0,dhcp-option
DOMAIN nickhq.com,route-gateway dhcp,ping 10,ping-restart 60'
2011-05-01 14:45:19 OPTIONS IMPORT: route options modified
2011-05-01 14:45:19 ROUTE default_gateway=10.0.1.1
2011-05-01 14:45:19 OpenVPN ROUTE: OpenVPN needs a gateway parameter
for a --route option and no default was specified by either --route-
gateway or --ifconfig options
2011-05-01 14:45:19 OpenVPN ROUTE: failed to parse/resolve route for
host/network: 192.168.122.0
I've done some Googling and everyone seems to agree that this means
I'm not including a route-gateway command. But as you can clearly see
in the PUSH reply, I'm sending "route-gateway dhcp."
Any ideas as to why I can't push this route? I was able to
successfully push the route when I was using TUN, but when I switched
to TAP with DHCP, I can no longer push it.
Thanks,
Nick
2011-05-01 14:45:15 *Tunnelblick: OS X 10.6.7; Tunnelblick 3.2beta10
(build 2466); OpenVPN 2.2.0
2011-05-01 14:45:15 *Tunnelblick: Attempting connection with ___; Set
nameserver = 1; monitoring connection
2011-05-01 14:45:15 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start ___.tblk 1337 1 0 3 0 114
2011-05-01 14:45:15 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn --cd /Library/Application
Support/Tunnelblick/Shared/___.tblk/Contents/Resources --daemon --
management 127.0.0.1 1337 --config /Library/Application Support/
Tunnelblick/Shared/___.tblk/Contents/Resources/config.ovpn --log /
Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication
Support-STunnelblick-SShared-S___.tblk-SContents-SResources-
Sconfig.ovpn.1_0_3_0_114.1337.openvpn.log --management-query-passwords
--management-hold --script-security 2 --up /Applications/
Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -
a --down /Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d -a --up-restart
2011-05-01 14:45:16 OpenVPN 2.2.0 i386-apple-darwin10.7.3 [SSL] [LZO2]
[PKCS11] [eurephia] built on Apr 28 2011
2011-05-01 14:45:16 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2011-05-01 14:45:16 Need hold release from management interface,
waiting...
2011-05-01 14:45:16 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-05-01 14:45:16 MANAGEMENT: CMD 'pid'
2011-05-01 14:45:16 MANAGEMENT: CMD 'state on'
2011-05-01 14:45:16 MANAGEMENT: CMD 'state'
2011-05-01 14:45:16 MANAGEMENT: CMD 'hold release'
2011-05-01 14:45:16 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-05-01 14:45:16 LZO compression initialized
2011-05-01 14:45:16 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2011-05-01 14:45:16 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-05-01 14:45:16 MANAGEMENT: >STATE:1304279116,RESOLVE,,,
2011-05-01 14:45:16 *Tunnelblick: Established communication with
OpenVPN
2011-05-01 14:45:16 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2011-05-01 14:45:16 Local Options hash (VER=V4): 'd79ca330'
2011-05-01 14:45:16 Expected Remote Options hash (VER=V4): 'f7df56b8'
2011-05-01 14:45:16 UDPv4 link local: [undef]
2011-05-01 14:45:16 UDPv4 link remote: ___:1194
2011-05-01 14:45:16 MANAGEMENT: >STATE:1304279116,WAIT,,,
2011-05-01 14:45:16 MANAGEMENT: >STATE:1304279116,AUTH,,,
2011-05-01 14:45:16 TLS: Initial packet from ___:1194, sid=49ce516e
4391cbf5
2011-05-01 14:45:16 VERIFY OK: depth=1, /C=US/ST=TN/L=___/O=___/CN=___/
name=___/emailAddress=___
2011-05-01 14:45:16 VERIFY OK: nsCertType=SERVER
2011-05-01 14:45:16 VERIFY OK: depth=0, /C=US/ST=TN/L=___/O=___/
CN=server/name=___/emailAddress=___
2011-05-01 14:45:17 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 14:45:17 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 14:45:17 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 14:45:17 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 14:45:17 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-05-01 14:45:17 [server] Peer Connection Initiated with ___:1194
2011-05-01 14:45:18 MANAGEMENT: >STATE:1304279118,GET_CONFIG,,,
2011-05-01 14:45:19 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-05-01 14:45:19 PUSH: Received control message: 'PUSH_REPLY,dhcp-
option DNS 172.16.122.1,route 192.168.122.0 255.255.255.0,dhcp-option
DOMAIN nickhq.com,route-gateway dhcp,ping 10,ping-restart 60'
2011-05-01 14:45:19 OPTIONS IMPORT: timers and/or timeouts modified
2011-05-01 14:45:19 OPTIONS IMPORT: route options modified
2011-05-01 14:45:19 OPTIONS IMPORT: route-related options modified
2011-05-01 14:45:19 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-05-01 14:45:19 ROUTE default_gateway=10.0.1.1
2011-05-01 14:45:19 OpenVPN ROUTE: OpenVPN needs a gateway parameter
for a --route option and no default was specified by either --route-
gateway or --ifconfig options
2011-05-01 14:45:19 OpenVPN ROUTE: failed to parse/resolve route for
host/network: 192.168.122.0
2011-05-01 14:45:19 TUN/TAP device /dev/tap0 opened
2011-05-01 14:45:19 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d -a tap0 1500 1574 init
No such key
2011-05-01 14:45:19 Initialization Sequence Completed
2011-05-01 14:45:19 MANAGEMENT: >STATE:
1304279119,CONNECTED,SUCCESS,,___
2011-05-01 14:45:19 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-05-01 14:45:19 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-05-01 14:45:19 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-05-01 14:45:20 *Tunnelblick: Flushed the DNS cache
2011-05-01 14:45:27 Extracted DHCP router address: 172.16.122.1
2011-05-01 14:45:31 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
2011-05-01 14:45:41 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
issue on Windows OpenVPN clients, too. But I've become familiar with
this community, so I figured I'd see if anyone here knows what I'm
doing wrong.
I have a server set up with TAP and DHCP. I can connect to the server
just fine (on Windows clients I get an address automatically ... with
Tunnelblick I have to issue the command "sudo ipconfig set tap0 DHCP"
until that bug is fixed completely). The subnet for the VPN is
172.16.122.0/24. The server is also set up to push a route to a
different subnet behind the VPN (192.168.122.0/24). Neither the
Windows nor the Mac OS X clients get the route, and OpenVPN complains
about not having a route-gateway. Here is the server configuration:
/usr/sbin/openvpn --daemon --verb 3 --writepid /var/run/openvpn-
vtun0.pid --status /opt/vyatta/etc/openvpn/status/vtun0.status 30 --
dev-type tap --dev vtun0 --mode server --tls-server --topology subnet
--keepalive 10 60 --ca /root/openvpn/keys/ca.crt --cert /root/openvpn/
keys/server.crt --key /root/openvpn/keys/server.key --dh /root/openvpn/
keys/dh1024.pem --push dhcp-option DNS 172.16.122.1 --push route
192.168.122.0 255.255.255.0 --server-bridge --client-config-dir /opt/
vyatta/etc/openvpn/ccd/vtun0 --comp-lzo --push dhcp-option DOMAIN
nickhq.com
And the client configuration:
client
dev tap
proto udp
remote ___ 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ___.crt
cert __.crt
key ___.key
ns-cert-type server
comp-lzo
verb 3
The full log output is at the bottom. The items that stick out to me
are:
2011-05-01 14:45:19 PUSH: Received control message: 'PUSH_REPLY,dhcp-
option DNS 172.16.122.1,route 192.168.122.0 255.255.255.0,dhcp-option
DOMAIN nickhq.com,route-gateway dhcp,ping 10,ping-restart 60'
2011-05-01 14:45:19 OPTIONS IMPORT: route options modified
2011-05-01 14:45:19 ROUTE default_gateway=10.0.1.1
2011-05-01 14:45:19 OpenVPN ROUTE: OpenVPN needs a gateway parameter
for a --route option and no default was specified by either --route-
gateway or --ifconfig options
2011-05-01 14:45:19 OpenVPN ROUTE: failed to parse/resolve route for
host/network: 192.168.122.0
I've done some Googling and everyone seems to agree that this means
I'm not including a route-gateway command. But as you can clearly see
in the PUSH reply, I'm sending "route-gateway dhcp."
Any ideas as to why I can't push this route? I was able to
successfully push the route when I was using TUN, but when I switched
to TAP with DHCP, I can no longer push it.
Thanks,
Nick
2011-05-01 14:45:15 *Tunnelblick: OS X 10.6.7; Tunnelblick 3.2beta10
(build 2466); OpenVPN 2.2.0
2011-05-01 14:45:15 *Tunnelblick: Attempting connection with ___; Set
nameserver = 1; monitoring connection
2011-05-01 14:45:15 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start ___.tblk 1337 1 0 3 0 114
2011-05-01 14:45:15 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn --cd /Library/Application
Support/Tunnelblick/Shared/___.tblk/Contents/Resources --daemon --
management 127.0.0.1 1337 --config /Library/Application Support/
Tunnelblick/Shared/___.tblk/Contents/Resources/config.ovpn --log /
Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication
Support-STunnelblick-SShared-S___.tblk-SContents-SResources-
Sconfig.ovpn.1_0_3_0_114.1337.openvpn.log --management-query-passwords
--management-hold --script-security 2 --up /Applications/
Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -
a --down /Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d -a --up-restart
2011-05-01 14:45:16 OpenVPN 2.2.0 i386-apple-darwin10.7.3 [SSL] [LZO2]
[PKCS11] [eurephia] built on Apr 28 2011
2011-05-01 14:45:16 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2011-05-01 14:45:16 Need hold release from management interface,
waiting...
2011-05-01 14:45:16 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-05-01 14:45:16 MANAGEMENT: CMD 'pid'
2011-05-01 14:45:16 MANAGEMENT: CMD 'state on'
2011-05-01 14:45:16 MANAGEMENT: CMD 'state'
2011-05-01 14:45:16 MANAGEMENT: CMD 'hold release'
2011-05-01 14:45:16 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-05-01 14:45:16 LZO compression initialized
2011-05-01 14:45:16 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2011-05-01 14:45:16 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-05-01 14:45:16 MANAGEMENT: >STATE:1304279116,RESOLVE,,,
2011-05-01 14:45:16 *Tunnelblick: Established communication with
OpenVPN
2011-05-01 14:45:16 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2011-05-01 14:45:16 Local Options hash (VER=V4): 'd79ca330'
2011-05-01 14:45:16 Expected Remote Options hash (VER=V4): 'f7df56b8'
2011-05-01 14:45:16 UDPv4 link local: [undef]
2011-05-01 14:45:16 UDPv4 link remote: ___:1194
2011-05-01 14:45:16 MANAGEMENT: >STATE:1304279116,WAIT,,,
2011-05-01 14:45:16 MANAGEMENT: >STATE:1304279116,AUTH,,,
2011-05-01 14:45:16 TLS: Initial packet from ___:1194, sid=49ce516e
4391cbf5
2011-05-01 14:45:16 VERIFY OK: depth=1, /C=US/ST=TN/L=___/O=___/CN=___/
name=___/emailAddress=___
2011-05-01 14:45:16 VERIFY OK: nsCertType=SERVER
2011-05-01 14:45:16 VERIFY OK: depth=0, /C=US/ST=TN/L=___/O=___/
CN=server/name=___/emailAddress=___
2011-05-01 14:45:17 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 14:45:17 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 14:45:17 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 14:45:17 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 14:45:17 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-05-01 14:45:17 [server] Peer Connection Initiated with ___:1194
2011-05-01 14:45:18 MANAGEMENT: >STATE:1304279118,GET_CONFIG,,,
2011-05-01 14:45:19 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-05-01 14:45:19 PUSH: Received control message: 'PUSH_REPLY,dhcp-
option DNS 172.16.122.1,route 192.168.122.0 255.255.255.0,dhcp-option
DOMAIN nickhq.com,route-gateway dhcp,ping 10,ping-restart 60'
2011-05-01 14:45:19 OPTIONS IMPORT: timers and/or timeouts modified
2011-05-01 14:45:19 OPTIONS IMPORT: route options modified
2011-05-01 14:45:19 OPTIONS IMPORT: route-related options modified
2011-05-01 14:45:19 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-05-01 14:45:19 ROUTE default_gateway=10.0.1.1
2011-05-01 14:45:19 OpenVPN ROUTE: OpenVPN needs a gateway parameter
for a --route option and no default was specified by either --route-
gateway or --ifconfig options
2011-05-01 14:45:19 OpenVPN ROUTE: failed to parse/resolve route for
host/network: 192.168.122.0
2011-05-01 14:45:19 TUN/TAP device /dev/tap0 opened
2011-05-01 14:45:19 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d -a tap0 1500 1574 init
No such key
2011-05-01 14:45:19 Initialization Sequence Completed
2011-05-01 14:45:19 MANAGEMENT: >STATE:
1304279119,CONNECTED,SUCCESS,,___
2011-05-01 14:45:19 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-05-01 14:45:19 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-05-01 14:45:19 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-05-01 14:45:20 *Tunnelblick: Flushed the DNS cache
2011-05-01 14:45:27 Extracted DHCP router address: 172.16.122.1
2011-05-01 14:45:31 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
2011-05-01 14:45:41 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
Nicholas
May 1, 2011, 7:42:11 PM5/1/11
to tunnelblick-discuss
I figured out one thing, but encountered another problem.
The problem I was having is that "--push route 192.168.122.0
255.255.255.0" doesn't specify which gateway to use for the route. I
was able to fix it by changing it to:
"--push route 192.168.122.0 255.255.255.0 172.16.122.1"
Now the Windows clients work perfectly. DNS, DHCP and routes all
exactly like they're supposed to be. But I still have a problem with
the Mac clients. I'm afraid it might be an OpenVPN bug, but I'm not
sure, so could someone confirm?
My full log is below.
Per the log in Tunnelblick, the route does get added:
2011-05-01 18:25:30 /sbin/route add -net 192.168.122.0 172.16.122.1
255.255.255.0
add net 192.168.122.0: gateway
172.16.122.1
But I can't ping anything an the subnet. So I look at the route to one
of the machines on the subnet:
$ route get 192.168.122.101
route to: 192.168.122.101
destination: 192.168.122.0
mask: 255.255.255.0
gateway: 172.16.122.1
interface: en1
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
The gateway looks right, but the interface doesn't. So I look at the
entire routing table:
$ netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs Use
Netif Expire
default 10.0.1.1 UGSc 19 8
en1
default 172.16.122.1 UGScI 0 0
tap0
10.0.1/24 link#6 UCS 7 0
en1
10.0.1.1 0:1f:f3:43:44:83 UHLWI 27 100
en1 920
10.0.1.11 localhost UHS 0 0
lo0
10.0.1.12 0:25:56:3e:f:c1 UHLWI 0 45
en1 1196
10.0.1.255 link#6 UHLWbI 1 91
en1
127 localhost UCS 0 0
lo0
localhost localhost UH 4 4541
lo0
169.254 link#6 UCS 1 0
en1
169.254.1.0 link#6 UHLW 0 184
en1
172.16.122/24 link#7 UCS 5 0
tap0
172.16.122.10 d8:30:62:5b:4c:3 UHLWI 1 81
tap0 832
172.16.122.12 link#7 UHLWI 1 14
tap0
172.16.122.28 localhost UHS 0 0
lo0
172.16.122.252 0:11:24:0:e6:45 UHLWI 0 0
tap0 832
172.16.122.253 78:ca:39:ff:3f:f1 UHLWI 0 0
tap0 832
172.16.122.255 link#7 UHLWbI 1 77
tap0
192.168.122 172.16.122.1 UGSc 0 0
en1
This lead me to the question, why do the automatic routes belong to
the tap0 interface, but the other route to the en1 interface?
So, on a hunch, I deleted the route and re-added it with the exact
same command that OpenVPN/Tunnelblick does:
$ sudo route delete 192.168.122.0
$ sudo route add -net 192.168.122.0 172.16.122.1 255.255.255.0
Now everything looks right, and I can ping the machine:
$ route get 192.168.122.101
route to: 192.168.122.101
destination: 192.168.122.0
mask: 255.255.255.0
gateway: 172.16.122.1
interface: tap0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
So, why does the route get assigned the en1 interface at first, and
then the tap0 interface later? This command also fixes the issue:
$ sudo route change -net 192.168.122.0 172.16.122.1 255.255.255.0
Any ideas? Is this because the DHCP configuration isn't complete
before the route is added?
Nick
Full Log:
2011-05-01 18:36:07 *Tunnelblick: OS X 10.6.7; Tunnelblick 3.2beta10
(build 2466); OpenVPN 2.2.0
2011-05-01 18:36:07 *Tunnelblick: Attempting connection with ___; Set
nameserver = 9; monitoring connection
2011-05-01 18:36:07 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start ___.tblk 1337 9 0 3 0 114
2011-05-01 18:36:07 OpenVPN 2.2.0 i386-apple-darwin10.7.3 [SSL] [LZO2]
2011-05-01 18:36:07 Need hold release from management interface,
waiting...
2011-05-01 18:36:07 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-05-01 18:36:07 MANAGEMENT: CMD 'pid'
2011-05-01 18:36:07 MANAGEMENT: CMD 'state on'
2011-05-01 18:36:07 MANAGEMENT: CMD 'state'
2011-05-01 18:36:07 MANAGEMENT: CMD 'hold release'
2011-05-01 18:36:07 NOTE: the current --script-security setting may
-a --down /Applications/Tunnelblick.app/Contents/Resources/client.
2.down.tunnelblick.sh -m -w -d -a --up-restart
2011-05-01 18:36:07 *Tunnelblick: Established communication with
OpenVPN
2011-05-01 18:36:07 LZO compression initialized
2011-05-01 18:36:07 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
2011-05-01 18:36:07 MANAGEMENT: >STATE:1304292967,RESOLVE,,,
2011-05-01 18:36:07 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
2011-05-01 18:36:07 Expected Remote Options hash (VER=V4): 'f7df56b8'
2011-05-01 18:36:07 UDPv4 link local: [undef]
2011-05-01 18:36:07 UDPv4 link remote: ___:1194
2011-05-01 18:36:07 MANAGEMENT: >STATE:1304292967,WAIT,,,
2011-05-01 18:36:08 MANAGEMENT: >STATE:1304292968,AUTH,,,
2011-05-01 18:36:08 TLS: Initial packet from ___:1194, sid=62facf7f
e3ff090f
2011-05-01 18:36:08 VERIFY OK: depth=1, /C=US/ST=TN/L=___/O=___/CN=___/
name=___/emailAddress=___
2011-05-01 18:36:08 VERIFY OK: nsCertType=SERVER
2011-05-01 18:36:08 VERIFY OK: depth=0, /C=US/ST=TN/L=___/O=___/
CN=server/name=___/emailAddress=___
2011-05-01 18:36:08 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 18:36:08 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 18:36:08 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 18:36:08 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 18:36:08 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-05-01 18:36:08 [server] Peer Connection Initiated with ___:1194
2011-05-01 18:36:10 MANAGEMENT: >STATE:1304292970,GET_CONFIG,,,
2011-05-01 18:36:11 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-05-01 18:36:11 PUSH: Received control message: 'PUSH_REPLY,dhcp-
10,ping-restart 60'
2011-05-01 18:36:11 OPTIONS IMPORT: timers and/or timeouts modified
2011-05-01 18:36:11 OPTIONS IMPORT: route options modified
2011-05-01 18:36:11 OPTIONS IMPORT: route-related options modified
2011-05-01 18:36:11 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-05-01 18:36:11 ROUTE default_gateway=10.0.1.1
2011-05-01 18:36:11 TUN/TAP device /dev/tap0 opened
2011-05-01 18:36:11 /Applications/Tunnelblick.app/Contents/Resources/
client.2.up.tunnelblick.sh -m -w -d -a tap0 1500 1574 init
Domain name =
2011-05-01 18:36:24 MANAGEMENT: >STATE:1304292984,ADD_ROUTES,,,
2011-05-01 18:36:24 /sbin/route add -net 192.168.122.0 172.16.122.1
255.255.255.0
add net 192.168.122.0: gateway
172.16.122.1
2011-05-01 18:36:24 Initialization Sequence Completed
2011-05-01 18:36:24 MANAGEMENT: >STATE:
1304292984,CONNECTED,SUCCESS,,___
2011-05-01 18:36:24 *Tunnelblick: Flushed the DNS cache
2011-05-01 18:36:26 Extracted DHCP router address: 172.16.122.1
The problem I was having is that "--push route 192.168.122.0
255.255.255.0" doesn't specify which gateway to use for the route. I
was able to fix it by changing it to:
"--push route 192.168.122.0 255.255.255.0 172.16.122.1"
Now the Windows clients work perfectly. DNS, DHCP and routes all
exactly like they're supposed to be. But I still have a problem with
the Mac clients. I'm afraid it might be an OpenVPN bug, but I'm not
sure, so could someone confirm?
My full log is below.
Per the log in Tunnelblick, the route does get added:
2011-05-01 18:25:30 /sbin/route add -net 192.168.122.0 172.16.122.1
255.255.255.0
add net 192.168.122.0: gateway
172.16.122.1
But I can't ping anything an the subnet. So I look at the route to one
of the machines on the subnet:
$ route get 192.168.122.101
route to: 192.168.122.101
destination: 192.168.122.0
mask: 255.255.255.0
gateway: 172.16.122.1
interface: en1
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
The gateway looks right, but the interface doesn't. So I look at the
entire routing table:
$ netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs Use
Netif Expire
default 10.0.1.1 UGSc 19 8
en1
default 172.16.122.1 UGScI 0 0
tap0
10.0.1/24 link#6 UCS 7 0
en1
10.0.1.1 0:1f:f3:43:44:83 UHLWI 27 100
en1 920
10.0.1.11 localhost UHS 0 0
lo0
10.0.1.12 0:25:56:3e:f:c1 UHLWI 0 45
en1 1196
10.0.1.255 link#6 UHLWbI 1 91
en1
127 localhost UCS 0 0
lo0
localhost localhost UH 4 4541
lo0
169.254 link#6 UCS 1 0
en1
169.254.1.0 link#6 UHLW 0 184
en1
172.16.122/24 link#7 UCS 5 0
tap0
172.16.122.10 d8:30:62:5b:4c:3 UHLWI 1 81
tap0 832
172.16.122.12 link#7 UHLWI 1 14
tap0
172.16.122.28 localhost UHS 0 0
lo0
172.16.122.252 0:11:24:0:e6:45 UHLWI 0 0
tap0 832
172.16.122.253 78:ca:39:ff:3f:f1 UHLWI 0 0
tap0 832
172.16.122.255 link#7 UHLWbI 1 77
tap0
192.168.122 172.16.122.1 UGSc 0 0
en1
This lead me to the question, why do the automatic routes belong to
the tap0 interface, but the other route to the en1 interface?
So, on a hunch, I deleted the route and re-added it with the exact
same command that OpenVPN/Tunnelblick does:
$ sudo route delete 192.168.122.0
$ sudo route add -net 192.168.122.0 172.16.122.1 255.255.255.0
Now everything looks right, and I can ping the machine:
$ route get 192.168.122.101
route to: 192.168.122.101
destination: 192.168.122.0
mask: 255.255.255.0
gateway: 172.16.122.1
interface: tap0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
So, why does the route get assigned the en1 interface at first, and
then the tap0 interface later? This command also fixes the issue:
$ sudo route change -net 192.168.122.0 172.16.122.1 255.255.255.0
Any ideas? Is this because the DHCP configuration isn't complete
before the route is added?
Nick
Full Log:
2011-05-01 18:36:07 *Tunnelblick: OS X 10.6.7; Tunnelblick 3.2beta10
(build 2466); OpenVPN 2.2.0
2011-05-01 18:36:07 *Tunnelblick: Attempting connection with ___; Set
nameserver = 9; monitoring connection
2011-05-01 18:36:07 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start ___.tblk 1337 9 0 3 0 114
2011-05-01 18:36:07 OpenVPN 2.2.0 i386-apple-darwin10.7.3 [SSL] [LZO2]
[PKCS11] [eurephia] built on Apr 28 2011
2011-05-01 18:36:07 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2011-05-01 18:36:07 Need hold release from management interface,
waiting...
2011-05-01 18:36:07 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-05-01 18:36:07 MANAGEMENT: CMD 'pid'
2011-05-01 18:36:07 MANAGEMENT: CMD 'state on'
2011-05-01 18:36:07 MANAGEMENT: CMD 'state'
2011-05-01 18:36:07 MANAGEMENT: CMD 'hold release'
2011-05-01 18:36:07 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-05-01 18:36:07 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn --cd /Library/Application
Support/Tunnelblick/Shared/___.tblk/Contents/Resources --daemon --
management 127.0.0.1 1337 --config /Library/Application Support/
Tunnelblick/Shared/___.tblk/Contents/Resources/config.ovpn --log /
Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication
Support-STunnelblick-SShared-S___.tblk-SContents-SResources-
Sconfig.ovpn.9_0_3_0_114.1337.openvpn.log --management-query-passwords
Support/Tunnelblick/Shared/___.tblk/Contents/Resources --daemon --
management 127.0.0.1 1337 --config /Library/Application Support/
Tunnelblick/Shared/___.tblk/Contents/Resources/config.ovpn --log /
Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication
Support-STunnelblick-SShared-S___.tblk-SContents-SResources-
--management-hold --script-security 2 --up /Applications/
Tunnelblick.app/Contents/Resources/client.2.up.tunnelblick.sh -m -w -d
-a --down /Applications/Tunnelblick.app/Contents/Resources/client.
2.down.tunnelblick.sh -m -w -d -a --up-restart
2011-05-01 18:36:07 *Tunnelblick: Established communication with
OpenVPN
2011-05-01 18:36:07 LZO compression initialized
2011-05-01 18:36:07 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:
0 ET:0 EL:0 ]
2011-05-01 18:36:07 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-05-01 18:36:07 MANAGEMENT: >STATE:1304292967,RESOLVE,,,
2011-05-01 18:36:07 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2011-05-01 18:36:07 Local Options hash (VER=V4): 'd79ca330'
2011-05-01 18:36:07 Expected Remote Options hash (VER=V4): 'f7df56b8'
2011-05-01 18:36:07 UDPv4 link local: [undef]
2011-05-01 18:36:07 UDPv4 link remote: ___:1194
2011-05-01 18:36:07 MANAGEMENT: >STATE:1304292967,WAIT,,,
2011-05-01 18:36:08 MANAGEMENT: >STATE:1304292968,AUTH,,,
2011-05-01 18:36:08 TLS: Initial packet from ___:1194, sid=62facf7f
e3ff090f
2011-05-01 18:36:08 VERIFY OK: depth=1, /C=US/ST=TN/L=___/O=___/CN=___/
name=___/emailAddress=___
2011-05-01 18:36:08 VERIFY OK: nsCertType=SERVER
2011-05-01 18:36:08 VERIFY OK: depth=0, /C=US/ST=TN/L=___/O=___/
CN=server/name=___/emailAddress=___
2011-05-01 18:36:08 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 18:36:08 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 18:36:08 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2011-05-01 18:36:08 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-05-01 18:36:08 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-05-01 18:36:08 [server] Peer Connection Initiated with ___:1194
2011-05-01 18:36:10 MANAGEMENT: >STATE:1304292970,GET_CONFIG,,,
2011-05-01 18:36:11 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2011-05-01 18:36:11 PUSH: Received control message: 'PUSH_REPLY,dhcp-
option DNS 172.16.122.1,route 192.168.122.0 255.255.255.0
172.16.122.1,dhcp-option DOMAIN nickhq.com,route-gateway dhcp,ping
10,ping-restart 60'
2011-05-01 18:36:11 OPTIONS IMPORT: timers and/or timeouts modified
2011-05-01 18:36:11 OPTIONS IMPORT: route options modified
2011-05-01 18:36:11 OPTIONS IMPORT: route-related options modified
2011-05-01 18:36:11 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-05-01 18:36:11 ROUTE default_gateway=10.0.1.1
2011-05-01 18:36:11 TUN/TAP device /dev/tap0 opened
2011-05-01 18:36:11 /Applications/Tunnelblick.app/Contents/Resources/
client.2.up.tunnelblick.sh -m -w -d -a tap0 1500 1574 init
Domain name =
2011-05-01 18:36:24 MANAGEMENT: >STATE:1304292984,ADD_ROUTES,,,
2011-05-01 18:36:24 /sbin/route add -net 192.168.122.0 172.16.122.1
255.255.255.0
add net 192.168.122.0: gateway
172.16.122.1
2011-05-01 18:36:24 Initialization Sequence Completed
2011-05-01 18:36:24 MANAGEMENT: >STATE:
1304292984,CONNECTED,SUCCESS,,___
2011-05-01 18:36:24 *Tunnelblick: Flushed the DNS cache
2011-05-01 18:36:26 Extracted DHCP router address: 172.16.122.1
Nicholas
May 4, 2011, 9:06:28 PM5/4/11
to tunnelblick-discuss
I figured this out. I hope my solution will help other Tunnelblick
users.
With Windows, the configuration of the client TAP interface IP address
and gateway with DHCP (due to "route-gateway dhcp") happens within the
actual OpenVPN application code. For all other operating systems,
OpenVPN does not support this. Instead, you have to ipconfig set tap0
DHCP after the OpenVPN client application completes its interface
configuration.
The challenge here is that OpenVPN configures all pulled routes after
it completes interface configuration and before returning control to
the calling application. This is fine in Windows, but in other
operating systems it means that the configuration of the pulled routes
happens before there is any gateway defined on the device. The
operating system accepts the route and its gateway, but since the
gateway is not defined on any device yet, it assumes that it must use
the existing default gateway to access THAT gateway, and thus binds
the route to the interface with the default gateway, which is not the
TAP interface (and, in my case, was en1, my wireless card interface).
The solution is to tell OpenVPN to DELAY the configuration of routes.
With no delay, OpenVPN configures the routes immediately and then
returns. With a delay, for some unknown interesting reason, OpenVPN
will wait that long AFTER the interface gets its IP address. So even a
delay of 1 second is enough (I set mine to 5 just to give some
cushion).
To accomplish this, I added the following option to my OpenVPN server:
--push route-delay 5
This (combined with including the gateway in my pushed routes, i.e. "--
push route 192.168.122.0 255.255.255.0 172.16.122.1") solved all of my
routing issues!
users.
With Windows, the configuration of the client TAP interface IP address
and gateway with DHCP (due to "route-gateway dhcp") happens within the
actual OpenVPN application code. For all other operating systems,
OpenVPN does not support this. Instead, you have to ipconfig set tap0
DHCP after the OpenVPN client application completes its interface
configuration.
The challenge here is that OpenVPN configures all pulled routes after
it completes interface configuration and before returning control to
the calling application. This is fine in Windows, but in other
operating systems it means that the configuration of the pulled routes
happens before there is any gateway defined on the device. The
operating system accepts the route and its gateway, but since the
gateway is not defined on any device yet, it assumes that it must use
the existing default gateway to access THAT gateway, and thus binds
the route to the interface with the default gateway, which is not the
TAP interface (and, in my case, was en1, my wireless card interface).
The solution is to tell OpenVPN to DELAY the configuration of routes.
With no delay, OpenVPN configures the routes immediately and then
returns. With a delay, for some unknown interesting reason, OpenVPN
will wait that long AFTER the interface gets its IP address. So even a
delay of 1 second is enough (I set mine to 5 just to give some
cushion).
To accomplish this, I added the following option to my OpenVPN server:
--push route-delay 5
This (combined with including the gateway in my pushed routes, i.e. "--
push route 192.168.122.0 255.255.255.0 172.16.122.1") solved all of my
routing issues!
jkbull...gmail.com
May 4, 2011, 9:18:01 PM5/4/11
to tunnelbli...@googlegroups.com
Thank you very much for your extremely clear explanation.
By the way, Tunnelblick 3.2beta10 (which you appear to be using) includes the "sudo ipconfig set tap0 DHCP" command that you mentioned as needing to do manually, if I understand you correctly) in your first post, but only if you use "Set nameserver (alternate 1)".
Nicholas
May 4, 2011, 9:32:39 PM5/4/11
to tunnelblick-discuss
Yes, I'm using "Set nameserver (alternate 1)", which sets up DHCP for
me. I just wanted to make the entire process clear for the readers who
needed to understand this confusing difference of behavior between
Windows clients and other clients.
Also, a quick correction, the route configuration is delayed that many
seconds after /Applications/Tunnelblick.app/Contents/Resources/
client.*.up.tunnelblick.sh completes running, not after the interface
gets an IP address, so 5 seconds may not be enough time for all
people. It was enough for me from one location, but when I moved to a
different location it didn't work, so I had to up it to 10 seconds.
Finally, I've discovered two DNS bugs in the "Set nameserver
(alternate 1)" script in 3.2beta10, which I will detail as a reply to
a previous, more-related post in the next few minutes and file actual
issues for if you think it's necessary.
me. I just wanted to make the entire process clear for the readers who
needed to understand this confusing difference of behavior between
Windows clients and other clients.
Also, a quick correction, the route configuration is delayed that many
seconds after /Applications/Tunnelblick.app/Contents/Resources/
client.*.up.tunnelblick.sh completes running, not after the interface
gets an IP address, so 5 seconds may not be enough time for all
people. It was enough for me from one location, but when I moved to a
different location it didn't work, so I had to up it to 10 seconds.
Finally, I've discovered two DNS bugs in the "Set nameserver
(alternate 1)" script in 3.2beta10, which I will detail as a reply to
a previous, more-related post in the next few minutes and file actual
issues for if you think it's necessary.
Jonathan K. Bullard
May 4, 2011, 9:37:08 PM5/4/11
to tunnelbli...@googlegroups.com
You don't need to file issues if you post it in this Discussion Group. Thanks (in advance) for the feedback.
--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com.
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.
Reply all
Reply to author
Forward
0 new messages