I'm trying to add a static route in my VPS to a client that is on the other side of the VPN tunnel to my VPS and forwards it's traffic through the tunnel.

This is the setup of my destination that I'm planning to add a route to. The Raspi acts as a router which itself is connected to an AP and the NAS is connected to Raspi and redirects its traffic through the VPN tunnel:

                                        |            Raspi               |
                      (|                                |(
 ( AP<>=================={wlan0                       eth0}================<>NAS (
                                        |   \                        /   |
                                        |    +----------------------+    |
                                        |    |     iptables and     |    |
                                        |    |    routing engine    |    |
                                        |    +-----------+----------+    |
                                        |                |               |
                                        |             {tun0}             |
                                        |              |

I'm trying to do route add -net netmask gw, in order to communicate with my NAS behind the Raspi, but it I get SIOCADDRT: Network is unreachable.

These are the server side info:

$ ifconfig -a

eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
          inet addr:217.B.C.D  Bcast:217.B.C.D  Mask:
          inet6 addr: XXXX::XXX:XXXX:XXXX:XXXX/XX Scope:Link
          RX packets:1598 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:176137 (176.1 KB)  TX bytes:165179 (165.1 KB)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:460 (460.0 B)  TX bytes:460 (460.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:  P-t-P:  Mask:
          RX packets:169 errors:0 dropped:0 overruns:0 frame:0
          TX packets:183 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:14825 (14.8 KB)  TX bytes:15071 (15.0 KB)

$ netstat -anr

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface         UG        0 0          0 eth0   UG        0 0          0 tun0 UH        0 0          0 tun0 UH        0 0          0 eth0

$ ip route list

default via dev eth0 via dev tun0 dev tun0  proto kernel  scope link  src dev eth0  scope link

Additional info:

If you are wondering how I've acheived the traffic redirection between the interfaces, here is my post describing how I've managed everything up to this point using iptables:

Redirect secondary network interface traffic along with port forwarding to tun0 (OpenVPN) using iptables

Client netwrok block (in case of p2p topology): : Network address : Virtual remote endpoint; Non pingable; Only used for routing : Client IP address : Network broadcast address


I've changed my VPN server configuration to topology subnet and ifconfig-push in the corresponding ccd file for the VPN client to bring the VPN server and client into the /24 subnet instead of /32 and then add the routes. This time route add -net netmask gw or route add -net netmask dev tun0 returned no errors, however still no ping netstat -anr changed though (in case of route add -net netmask gw

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface         UG        0 0          0 eth0   U         0 0          0 tun0 UH        0 0          0 eth0   UG        0 0          0 tun0
  • How far does a traceroute get? – Mark Plotnick Apr 3 '16 at 22:54
  • No far... Returns * * * from the very beginning. – Bahador Apr 3 '16 at 23:03
  • Just out of curiosity, I've tracerouted out of my NAS to and also got * * * right after, however tracerouting to returned the full path passing through without any stars... Firewall? – Bahador Apr 3 '16 at 23:34
  • Hmm, so a ping to fails? – Mark Plotnick Apr 4 '16 at 0:12
  • No. A ping to does not fail! I've found the solution thought. Static routing inside an OpenVPN tunnel doesn't work just like that. You have to define the route in the server configuration first. – Bahador Apr 4 '16 at 15:00

I read the instructions on:


And I've added route to the server.conf on my VPS and also iroute to the correspondig ccd file for the client. And then I used the command route add -net netmask gw and that was it! I could ping my client behind my OpenVPN client from my VPS :D

P.S: I'm still in subnet topology mode. I haven't tried it in the normal p2p topology, but I think it should work s well.


To clarify a bit, this being something that was extremely hard for me to understand:

  • On the machine that is running the OpenVPN client software, routes must be created by OpenVPN in response to route (no "i") directives in its configuration file. This is to ensure that the traffic is routed through the virtual tunX device and that OpenVPN is aware of it. If OpenVPN is acting as a router for the local subnet to which it is attached, routes are needed to "catch" the incoming traffic that is being "sent to it as a gateway," and to cause it to be tendered to OpenVPN for delivery. (If the operating system doesn't route it through that virtual device, OpenVPN will never see it.)
  • If the destination address is not one that OpenVPN already knows about ... it is a remote subnet other than the local-address on either side ... then iroute (with an "i") is required to inform OpenVPN of the subnet's existence and to tell it which remote to send traffic to. (If it does not, you will see in the OpenVPN log that it has discarded the packet for this very reason.)
  • All traffic routing must be "as is done for any TCP/IP router." Each and every "hop" must do the right thing. (traceroute is your friend.) Furthermore, traffic originating on a box that's running an OpenVPN client will be perceived as having an IP-address doled out by OpenVPN for that purpose, usually 10.8.0.x, so this address-range must be correctly routed (everywhere ...) as well. If the tunnel is successfully connected but you can't communicate, "you have a TCP/IP routing problem," much as you would have for any other type of router appliance.

I hope that these additional comments are useful to you.

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.