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)
utility.example.com  LAN: (eth0: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
proto udp
port 1194
push "route"
push "route"
ifconfig-pool-persist ipp.txt
ca ca.crt
dh dh1024.pem
cert server.crt
key server.key
tls-auth ta.key 0
cipher BF-CBC
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 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:


the server throws an error when booting, inline here:

/sbin/route add -net netmask gw
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 --> 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: <pre><code> tun0: flags=8951<UP,POINTOPOINT,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet --> netmask 0xffffffff open (pid 5142) </code></pre> 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

Your route statement in the configuration file needs to refer to the net id, not 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. in binary is:


The subnet mask looks like:


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

AND 11111111.11111111.10000000.00000000
    11000000.10101000.10000000.00000000 =

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

  • Thank you Evan! I have a further problem, client/<CLIENT WAN IP>:40390 GET INST BY VIRT: <DB SERVER ON VPN LAN IP> [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 9:12
  • That problem was solved using SNAT, with: iptables -t nat -A POSTROUTING - -j SNAT --to-source on the VPN host machine (server). – Lee Hambley May 17 '11 at 19:33

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.

  • 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 3:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.