Redirecting all traffic to the VPN on a Mac OS X client

sdr56p

Hi Everyone,

I have configured an OpenVPN (v. 2.2.1) server on an ubuntu virtual machine in the Amazon elastic compute cloud. The server is up and running. I have installed OpenVPN (v. 2.2.1) on a Mac OS X (10.8.2) client and I am using the openvpn2 binary directly to connect (in opposition to other clients like tunnelblick or viscosity). I can connect with the client and successfully ping or ssh the server through the tunnel.

However, I can't redirect all internet traffic through the VPN even if I use the push "redirect-gateway def1 bypass-dhcp" in the server.conf. When I connect to the server with these configurations, I get a successful connection, but then an infinite series of error messages: "write UDPv4: No route to host (code=65)". The routing table seems to be compromised because I am not able to access any address, not even the vpn server anymore (by pinging 10.8.0.1 for instance).

This is beyond me. I am finding little help on the web and don't know what to try next. I don't think it is a problem of forwarding the traffic on the server since, first, I have also took care of that and, second, I can't even ping the VPN server locally through the tunnel (or ping anything at all for that matter).

Here is the server.conf. file :

port 1194
proto udp
dev tun
ca ca.crt
cert ec2-server.crt
key ec2-server.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

The client.conf file:

client
dev tun
proto udp
remote servername.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert Toto5.crt
key Toto5.key
ns-cert-type server
comp-lzo
verb 3

Here is the connection log with the error message:

$ sudo openvpn2 --config client.conf --remote ec2-54-234-43-171.compute-1.amazonaws.com
Wed Mar 13 22:58:22 2013 OpenVPN 2.2.1 x86_64-apple-darwin12.2.0 [SSL] [LZO2] [eurephia] built on Mar 4 2013
Wed Mar 13 22:58:22 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Mar 13 22:58:22 2013 LZO compression initialized
Wed Mar 13 22:58:22 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Mar 13 22:58:22 2013 Socket Buffers: R=[196724->65536] S=[9216->65536]
Wed Mar 13 22:58:22 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Mar 13 22:58:22 2013 Local Options hash (VER=V4): '41690919'
Wed Mar 13 22:58:22 2013 Expected Remote Options hash (VER=V4): '530fdded'
Wed Mar 13 22:58:22 2013 UDPv4 link local: [undef]
Wed Mar 13 22:58:22 2013 UDPv4 link remote: 54.234.43.171:1194
Wed Mar 13 22:58:22 2013 TLS: Initial packet from 54.234.43.171:1194, sid=ffbaf343 d0c1a266
Wed Mar 13 22:58:22 2013 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=ttntec2/name=changeme/emailAddress=mail@host.domain
Wed Mar 13 22:58:22 2013 VERIFY OK: nsCertType=SERVER
Wed Mar 13 22:58:22 2013 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=ec2-server/name=changeme/emailAddress=mail@host.domain
Wed Mar 13 22:58:23 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 13 22:58:23 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 13 22:58:23 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 13 22:58:23 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 13 22:58:23 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Mar 13 22:58:23 2013 [ec2-server] Peer Connection Initiated with 54.234.43.171:1194
Wed Mar 13 22:58:25 2013 SENT CONTROL [ec2-server]: 'PUSH_REQUEST' (status=1)
Wed Mar 13 22:58:25 2013 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Wed Mar 13 22:58:25 2013 OPTIONS IMPORT: timers and/or timeouts modified
Wed Mar 13 22:58:25 2013 OPTIONS IMPORT: --ifconfig/up options modified
Wed Mar 13 22:58:25 2013 OPTIONS IMPORT: route options modified
Wed Mar 13 22:58:25 2013 ROUTE default_gateway=0.0.0.0
Wed Mar 13 22:58:25 2013 TUN/TAP device /dev/tun0 opened
Wed Mar 13 22:58:25 2013 /sbin/ifconfig tun0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
Wed Mar 13 22:58:25 2013 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Wed Mar 13 22:58:25 2013 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
Wed Mar 13 22:58:25 2013 /sbin/route add -net 10.8.0.0 10.8.0.5 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.5
Wed Mar 13 22:58:25 2013 Initialization Sequence Completed
^CWed Mar 13 22:58:30 2013 event_wait : Interrupted system call (code=4)
Wed Mar 13 22:58:30 2013 TCP/UDP: Closing socket
Wed Mar 13 22:58:30 2013 /sbin/route delete -net 10.8.0.0 10.8.0.5 255.255.255.0
delete net 10.8.0.0: gateway 10.8.0.5
Wed Mar 13 22:58:30 2013 Closing TUN/TAP interface
Wed Mar 13 22:58:30 2013 SIGINT[hard,] received, process exiting
toto5:ttntec2 Dominic$ sudo openvpn2 --config client.conf --remote ec2-54-234-43-171.compute-1.amazonaws.com
Wed Mar 13 22:58:57 2013 OpenVPN 2.2.1 x86_64-apple-darwin12.2.0 [SSL] [LZO2] [eurephia] built on Mar 4 2013
Wed Mar 13 22:58:57 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Mar 13 22:58:57 2013 LZO compression initialized
Wed Mar 13 22:58:57 2013 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Mar 13 22:58:57 2013 Socket Buffers: R=[196724->65536] S=[9216->65536]
Wed Mar 13 22:58:57 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Mar 13 22:58:57 2013 Local Options hash (VER=V4): '41690919'
Wed Mar 13 22:58:57 2013 Expected Remote Options hash (VER=V4): '530fdded'
Wed Mar 13 22:58:57 2013 UDPv4 link local: [undef]
Wed Mar 13 22:58:57 2013 UDPv4 link remote: 54.234.43.171:1194
Wed Mar 13 22:58:57 2013 TLS: Initial packet from 54.234.43.171:1194, sid=a0d75468 ec26de14
Wed Mar 13 22:58:58 2013 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=ttntec2/name=changeme/emailAddress=mail@host.domain
Wed Mar 13 22:58:58 2013 VERIFY OK: nsCertType=SERVER
Wed Mar 13 22:58:58 2013 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=changeme/CN=ec2-server/name=changeme/emailAddress=mail@host.domain
Wed Mar 13 22:58:58 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 13 22:58:58 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 13 22:58:58 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Mar 13 22:58:58 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Mar 13 22:58:58 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Mar 13 22:58:58 2013 [ec2-server] Peer Connection Initiated with 54.234.43.171:1194
Wed Mar 13 22:59:00 2013 SENT CONTROL [ec2-server]: 'PUSH_REQUEST' (status=1)
Wed Mar 13 22:59:00 2013 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Wed Mar 13 22:59:00 2013 OPTIONS IMPORT: timers and/or timeouts modified
Wed Mar 13 22:59:00 2013 OPTIONS IMPORT: --ifconfig/up options modified
Wed Mar 13 22:59:00 2013 OPTIONS IMPORT: route options modified
Wed Mar 13 22:59:00 2013 ROUTE default_gateway=0.0.0.0
Wed Mar 13 22:59:00 2013 TUN/TAP device /dev/tun0 opened
Wed Mar 13 22:59:00 2013 /sbin/ifconfig tun0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
Wed Mar 13 22:59:00 2013 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Wed Mar 13 22:59:00 2013 /sbin/ifconfig tun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
Wed Mar 13 22:59:00 2013 /sbin/route add -net 54.234.43.171 0.0.0.0 255.255.255.255
add net 54.234.43.171: gateway 0.0.0.0
Wed Mar 13 22:59:00 2013 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0
add net 0.0.0.0: gateway 10.8.0.5
Wed Mar 13 22:59:00 2013 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0
add net 128.0.0.0: gateway 10.8.0.5
Wed Mar 13 22:59:00 2013 /sbin/route add -net 10.8.0.0 10.8.0.5 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.5
Wed Mar 13 22:59:00 2013 Initialization Sequence Completed
Wed Mar 13 22:59:00 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:00 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:01 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:01 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:01 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:02 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:02 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:02 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:02 2013 write UDPv4: No route to host (code=65)
Wed Mar 13 22:59:02 2013 write UDPv4: No route to host (code=65)

The routing table after a connection WITHOUT the push redirect-gateway (all traffic is not redirected to the VPN):

Destination        Gateway            Flags        Refs      Use   Netif Expire
default            user148-1.wireless UGSc           50        0     en1
10.8/24            10.8.0.5           UGSc            2        7    tun0
10.8.0.5           10.8.0.6           UH              3        2    tun0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              6     6692     lo0
client.openvpn.net client.openvpn.net UH              3       18     lo0
142.1.148/22       link#5             UCS             2        0     en1
user148-1.wireless 0:90:b:27:10:71    UHLWIir        50        0     en1     76
user150-173.wirele localhost          UHS             0        0     lo0
142.1.151.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        2     en1
169.254            link#5             UCS             1        0     en1
169.254.255.255    0:90:b:27:10:71    UHLSWi          0        0     en1     71

The routing table after a connection with a push redirect-gateway (all internet traffic should be redirected to the VPN tunnel):

Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.5           UGSc            1        0    tun0
default            user148-1.wireless UGSc            7        0     en1
10.8/24            10.8.0.5           UGSc            0        0    tun0
10.8.0.5           10.8.0.6           UHr             6        0    tun0
54.234.43.171/32   0.0.0.0            UGSc            1        0     en1
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              3     6698     lo0
client.openvpn.net client.openvpn.net UH              0       27     lo0
128.0/1            10.8.0.5           UGSc            2        0    tun0
142.1.148/22       link#5             UCS             1        0     en1
user148-1.wireless 0:90:b:27:10:71    UHLWIir         1        0     en1    833
user150-173.wirele localhost          UHS             0        0     lo0
169.254            link#5             UCS             1        0     en1
169.254.255.255    0:90:b:27:10:71    UHLSW           0        0     en1

sdr56p

I think I got it. There is two ways to look at this. The problem either comes from 1) the command issued by the openvpn2 binary to change the gateway route and the route to the OpenVPN Server or 2) the way Mac OS X interprets the new routing table.

When the connection is being established, openvpn2 issues as series of route command. First, openvpn2 needs a route to the server outside the tunnel. The OpenVPN server is at 54.234.43.171. Hence, the following command (taken in the connection log above) is being issued in order to create the following route (listed in the last routing table above):

/sbin/route add -net 54.234.43.171 0.0.0.0 255.255.255.255
54.234.43.171/32   0.0.0.0            UGSc            1        0     en1

Then, two commands reroute all traffic to the tunnel by creating a route for 0.0.0.0/1 and 128.0.0.0/1 to the tun interface:

0/1                10.8.0.5           UGSc            1        0    tun0
128.0/1            10.8.0.5           UGSc            2        0    tun0

This avoids deleting the route to the default gateway:

default            user148-1.wireless UGSc            7        0     en1

Since the route to the default gateway has been preserved, and since the route to the OpenVPN server (54.234.43.171) has been redirected to the default (0.0.0.0) route, the traffic necessary to create the VPN tunnel should be rerouted properly. All packets going to 54.234.43.171 would go 0.0.0.0 and then the gateway (user148-1.wireless).

However, what happens is that packets going to 54.234.43.171 are subjected to the 0/1 rule and are rerouted to the tunnel, which creates a rerouting loop. This is why I am not able to access anything outside the computer and keep getting this error message:

Wed Mar 13 22:59:00 2013 write UDPv4: No route to host (code=65)

All traffic is redirected to the tunnel interface (10.8.0.6) but the tun driver, while trying to reach the OpenVPN server, is also redirected to the tunnel interface.

This could be a bug in the openvpn2 binary (it issues the wrong rerouting command). But I presume the command is more or less the same as the command issued in other UNIX clients. Hence, the problem might also come from a slightly different interpretation of the routing rules by Mac OS X.

In either case (wrong routing commands or wrong interpretation of the routing rules), I wonder if this problem doesn’t point to something that should be corrected in the Mac OS X implementation of OpenVPN?

I have found a few workarounds for this problem and I am able to redirect all traffic to the VPN tunnel successfully. I will post them soon, but I would be curious to have your impressions on this. Does it seem like a bug or there is something I am missing? If it is bug, would it be a good idea to move this post to another section of the forum?

rsaddey

I have found a few workarounds for this problem

Can you give short pointers on how to work-around?

Thanks, Reiner

nikolay.zhelev

Hi sdr56p,

Can you post please the workaround you were speaking about in your previous post? I think I'm experiencing the same problem and I will be very happy to find some solution.

Thank you,
Nick

sdr56p

Hi Nikolay,

Which version of openvpn do you use? I don't have this problem anymore with newer versions of the openvpn binary, hence my decision of not posting a workaround.

Best, S

nikolay.zhelev

Hi sdr56p,

Thank you very much for your quick reply!

I had this problem with Tunnelblick using OpenVPN 2.3.4 (the latest version of Tunnelblick. Couple of minutes ago I think I managed to solve the problem using Viscosity client and introducing the argument --route-delay 10. At the moment this is working configuration, but I have to run some tests and spend some time using it in order to confirm my success.

However, Tunnelblick couldn't set my default gateway correctly, therefore I was asking for your solution. I think it's a good idea to post it for reference.

Thanks again.

----
Kind Regards,
Nikolay

sdr56p

Hi Nikolay,

I never had the problem while using clients like tunnelblick or Viscosity, but it is true that I haven't used these clients in a while.

My solution involved using scripts to re-configure de routing table myself once the peer connection was established and once the client disconnected. In case you are not familiar with these commands, openvpn can execute a script while connecting to another computer if you use the --up, --down, --route-up, etc. options. The rerouting commands on Mac OS take the form: route add/delete/change ... The (slightly) tricky part is to obtain the ip address of the VPN server and to re-establish the proper route to the gateway once your VPN connection is down. In order to do that, you have to use the environmental variables like remote_{n} and route_net_gateway (see the openvpn manual page).

This solution didn't work in all environnements and I never really figured out why that was the case. Unfortunately, I don't have the scripts anymore so I cannot post them :oops:.

S.

nikolay.zhelev

Thank you very much for sharing this.

Have a nice evening!

Regards,
Nick