OpenVPN Network Unreachable

Question

I'm working to set-up a VPN access to a group of virtual machines at Linode., the topology looks something like this:

db.example.com       LAN: (eth0:0) 192.168.154.127/255.255.128.0
utility.example.com  LAN: (eth0:0) 192.168.164.229/255.255.128.0

And, more servers on the LAN with addresses in the same range. The utility server is hosting the OpenVPN

Here's my server's OpenVPN configuration, the client configuration is not available as I'm using Shimo for OSX:

dev tun
mode server
tls-server
proto udp
port 1194
server 10.77.22.0 255.255.255.0
push "route 10.77.22.0 255.255.255.0"
push "route 192.168.154.0 255.255.128.0"
ifconfig-pool-persist ipp.txt
persist-key
persist-tun
client-to-client
ca ca.crt
dh dh1024.pem
cert server.crt
key server.key
tls-auth ta.key 0
cipher BF-CBC
comp-lzo
user nobody
group nogroup
keepalive 10 120
status openvpn-status.log
verb 3

When connected to the VPN, I can ping the VPN gateway, and log into it over SSH, and all normal operations without problems, tcpdump confirms that these packets are going over the tun0 device on my Mac.

Attempting to ping 192.168.154.127 over the VPN doesn't work, tcpdump confirms that there's no activity on the tun0 device.

I understand from reading this that I need to add a route configuration to my server.conf, when adding the line:

route 192.168.154.0 255.255.128.0

the server throws an error when booting, inline here:

/sbin/route add -net 192.168.154.0 netmask 255.255.128.0 gw 10.77.22.2
route: netmask doesn't match route address
Usage: route [-nNvee] [-FC] []           List kernel routing tables
       route [-v] [-FC] {add|del|flush} ...  Modify routing table for AF.

   route {-h|--help} [<AF>]              Detailed usage syntax for specified AF.
   route {-V|--version}                  Display version/author and exit.

    -v, --verbose            be verbose
    -n, --numeric            don't resolve names
    -e, --extend             display other/more information
    -F, --fib                display Forwarding Information Base (default)
    -C, --cache              display routing cache instead of FIB

=Use '-A ' or '--'; default: inet List of possible address families (which support routing): inet (DARPA Internet) inet6 (IPv6) ax25 (AMPR AX.25) netrom (AMPR NET/ROM) ipx (Novell IPX) ddp (Appletalk DDP) x25 (CCITT X.25)

I suspect if I would resolve this /sbin/route problem, the situation would work as expected, but I don't understand why this is failing.

The client typically gets an address like this:


tun0: flags=8951 mtu 1500
    inet 10.77.22.6 --> 10.77.22.5 netmask 0xffffffff 
    open (pid 5142)

Is `ip_forward` enabled on the VPN server? Do the firewall rules on the VPN server permit packets to be forwarded? What IP address does your client get? — Zoredache, May 16 '11 at 17:14
My client shows:
tun0: flags=8951 mtu 1500 inet 10.77.22.6 --> 10.77.22.5 netmask 0xffffffff open (pid 5142)
I doubt `ip_forward` is enabled, strange that my client doesn't know even to send these packets over `tun0` though? Is `ip_forward` required? Firewall is disabled on the server for purposes of this test. — Lee Hambley, May 16 '11 at 17:19

score 2 · Accepted Answer · answered May 17 '11 at 03:32

Your route statement in the configuration file needs to refer to the net id 192.168.128.0, not 192.168.154.0. route is barfing because you're giving it a network id and subnet mask than, when taken together, has 1's in the host id portion.

192.168.154.0 in binary is:

11000000.10101000.10011010.00000000

The subnet mask 255.255.128.0 looks like:

11111111.11111111.10000000.00000000

The subnet mask applied to the 192.168.154.0 "network id" looks like:

    11000000.10101000.10011010.00000000
AND 11111111.11111111.10000000.00000000
---------------------------------------
    11000000.10101000.10000000.00000000 = 192.168.128.0

You can see that 192.168.154.0 masked by a /17 subnet mask results in 1's after the end of the subnet mask. The net id of the 192.168.154.0/17 "network" is really 192.168.128.0/17. Change your route statement in the configuration file and the route command will stop barfing.

Thank you Evan! I have a further problem, `client/:40390 GET INST BY VIRT: [failed]` which I can't seem to resolve now. Thanks for the great answer though! (I actually understand how the CIDR notation works now!) — Lee Hambley, May 17 '11 at 09:12
That problem was solved using `SNAT`, with: `iptables -t nat -A POSTROUTING -10.77.22.0/24 -j SNAT --to-source 192.168.128.0/17` on the VPN host machine (server). — Lee Hambley, May 17 '11 at 19:33

score 1 · Answer 2 · answered May 16 '11 at 19:05

1

Enabling ip_forward is required. A linux box will not route, unless it is. On Ubuntu the an easy way to fix this is to adjust the /etc/sysctl.conf, just uncomment the ip_forward line. Then reboot the system or run sysctl -p.

answered May 16 '11 at 19:05

Zoredache

130,897
41
276
420

And my `route: netmask doesn't match route address` error? – Lee Hambley May 16 '11 at 19:52
He might be having a problem with IP forwarding, but he's got a route declaration there that's going to cause `route` to barf for sure. – Evan Anderson May 17 '11 at 03:33

OpenVPN Network Unreachable

2 Answers2