Route to LAN subnet via OpenVPN client

Question

I am trying to route to a LAN subnet that is connected via an OpenVPN client.

I am having trouble with the route command - I cannot make sense of it. The OpenVPN link is established and I can ping the client.

When I try to add a route to the LAN subnet on the VPN server, I get this error:

# route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.9.0.6 dev tun0
SIOCADDRT: No such process

The routing table for the OpenVPN server has 10.9.0.0/24 in it, so I'm not sure what the problem is.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ve108.csr2.lga1 0.0.0.0         UG    0      0        0 eth0
10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0
10.9.0.2        *               255.255.255.255 UH    0      0        0 tun0
204.145.81.0    *               255.255.255.0   U     0      0        0 eth0

More information:

# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0e:cf:20:c1:24 brd ff:ff:ff:ff:ff:ff
    inet 204.145.81.11/24 brd 204.145.81.255 scope global eth0
    inet6 fe80::20e:cfff:fe20:c124/64 scope link 
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.9.0.1 peer 10.9.0.2/32 scope global tun0

Considering that I can ping the VPN client I am trying to route to, I don't understand why I am having this problem. As far as I know I should just be able to add the route.

# ping -c 1 10.9.0.6
PING 10.9.0.6 (10.9.0.6) 56(84) bytes of data.
64 bytes from 10.9.0.6: icmp_req=1 ttl=64 time=24.0 ms

--- 10.9.0.6 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.008/24.008/24.008/0.000 ms

Here is the details from the OpenVPN client, which is connected to the VPN server. The network I am trying to route to is on this client.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         greece-gw.secus 0.0.0.0         UG    2      0        0 eth0
10.9.0.1        10.9.0.5        255.255.255.255 UGH   0      0        0 tun0
10.9.0.5        *               255.255.255.255 UH    0      0        0 tun0
loopback        localhost       255.0.0.0       UG    0      0        0 lo
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
198.50.241.0    *               255.255.255.0   U     0      0        0 eth0

It can reach the VPN server fine:

# ping -c 1 10.9.0.1
PING 10.9.0.1 (10.9.0.1) 56(84) bytes of data.
64 bytes from 10.9.0.1: icmp_seq=1 ttl=64 time=24.0 ms

--- 10.9.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.017/24.017/24.017/0.000 ms

It has IP forwarding enabled:

# sysctl -a | grep forwarding
net.ipv4.conf.all.forwarding = 1

I've set iptables to allow forwarding:

# iptables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  tun0   eth1    0.0.0.0/0            0.0.0.0/0

Here is the config for the interfaces on the client:

# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:5f:f2:1e brd ff:ff:ff:ff:ff:ff
    inet 198.50.241.113/24 brd 198.50.241.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe5f:f21e/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:c6:b8:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fec6:b8fd/64 scope link 
       valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.9.0.6 peer 10.9.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever

Answer 1

Unfortunately network tools often have horrible error messages. As far as I can tell, what the kernel doesn't like is that you are trying to add a route with a gateway that it doesn't see as being "local". You should either do:

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.9.0.2 dev tun0

or:

route add -net 192.168.0.0 netmask 255.255.255.0 dev tun0

In adition to configuring the kernel route you will also need to add a route inside openvpn itself. This is done by using the "iroute" directive in the ccd file for the client.

Answer 2

Stumbling-upon this question while conducting another search, it appears that the OP is trying to access a subnet that is attached to a remote OpenVPN server.

My reply assumes tunnel mode, not bridged mode. (OpenVPN is acting as a router, not a switch.)

If my understanding is correct, then a --client-config-dir ("CCD") must be used in this case. There must be a route directive covering the subnet's address-range in the main configuration, and an iroute (notice the "i") in a CCD file that will be correctly identified as belonging to that remote. (You will see whether or not it is recognized by looking at the OpenVPN logs, and then by confirming that a route now exists on your machine.)

If you are accessing the subnet from another subnet (i.e. not from the machine that's running the OpenVPN client, there must also be a static route within your local subnet which sends traffic to your OpenVPN machine "as a gateway." This could be defined on each client machine or, more conveniently, on the local router.

And here's how the traffic will flow:

• You ping the remote subnet.
• Your machine or your router forwards the traffic to your OpenVPN box as a gateway. (Because, functionally, an OpenVPN tunnel acts as a router.)
• The route directive on that machine causes the traffic to be sent into the tunX device so that OpenVPN actually gets it.
• The iroute directive (and the CCD in which it occurs) tells OpenVPN that a remote subnet exists, and which remote to send it to. (Even if there is only one remote.)
• The traffic is routed to the destination on the remote side.
• And now, it all has to happen in reverse! The remote sends the ping-reply using your IP-address on the remote subnet, and it has to make its way all the way back home.

If you ping from a machine that is directly connected to OpenVPN (it is running the client), then your address will probably be 10.8.0.x and this address-range also must be successfully routed, "there and back again," on all devices concerned.

These are "basic TCP/IP routing issues," which would be the case whether "the router in question" is OpenVPN or not. Once you get the hosts to successfully talk to one another (yay!), "to the network, they're just routers."

tcpdump (or WireShark) and traceroute are your best friends here. First, you must ensure that the encrypted traffic is being delivered as it should be among the OpenVPN hosts. (Even though of course you can't read their content, you can see them being routed, or not.) Then, do the same things within the tunnel. See that the packets are delivered to and through the tunnel, and that they make it all the way there and back. (If traceroute starts printing rows of asterisks, it probably means that there is no reverse routing at that particular "hop." The packet makes it there but can't get home from there.)