Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The Setup

I have an OpenVPN server that acts as a central router. It is configured with "topology subnet" command. Clients are Debian Linux nodes and each have one (or more) subnets directly connected to them.

The objective is for any client connected to the VPN to be able to access the subnets connected behind each other client.

In order to spread the routing information, we have installed Quagga on the clients and on the server. This works fine using the OSPF daemon. Routing is enabled on all the clients and the server as well.

Routing table

The routing table on the server is the following :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UGH   20     0        0 tun0   UG    20     0        0 tun0   UG    20     0        0 tun0

The subnet I want to access is The gateway in question responds perfectly fine and I can connect to it alright.

I don't think this will be of any use but here is part of the client routing table : UH    0      0        0 tun0   U     0      0        0 eth1   U     0      0        0 eth0

Where things start going south

Pinging from the server ( to any hosts (including the VPN client interface) in the subnet fails. If I tcpdump the tun interface on the VPN client, I see no relevant package. If I tcpdump the tun interface on the VPN server, I see the package in question being sent out.

The real edgy thing is that when I traceroute to a valid IP in the subnet, it doesn't discover any hops (there should be just one). If I traceroute directly to the next hop (, it responds fine.

I really hope I am being clear as this is quite a complex problem. I'll be happy to provide extra information at your request.

share|improve this question

What I find strange is it that client's routing tables are pointing to nowhere ( It is ok for local networks but for that passes trough a tunnel it might be a problem.

share|improve this answer is local to the client in question so that's not a problem. The route in the server points towards it which makes sense. – Antoine Benkemoun Oct 11 '10 at 15:29

I would have thought that a default route, pointing across the VPN tunnel, would've been enough for the clients to be able to route to other clients (as long as the VPN concentrator allows it), with no need for routing daemons running on the individual clients.

Looking at the routing table, I suspect that the problem is that the "next hop" carried in the routing updates isn't reachable for the client and instead of ignoring the route, it installs it with an unknown next hop.

What happens if you de-activate Quagga and instead just use a default route, pointing across the VPN tunnel?

share|improve this answer
That can't work... Each client has a subnet behind it that I want to access. Where would I point the default route to ? – Antoine Benkemoun Oct 12 '10 at 10:45
@Antoine Benkemoun: The default route is installed on each "VPN client", pointing across the VPN tunnel, towards the concentrator. You'd obviously need a route for the VPN concentrator, routed back across whatever the "phsyical default gateway" would be for the VPN client. If you install a static route for, with a next-hop of, does it work then? – Vatine Oct 12 '10 at 14:23
up vote 0 down vote accepted

I ended up using a "client-config-dir" that allowed me to specify the route behind each client using the "iroute" command.

Afterwards, I had the VPN server push a route for all these subnets to all the other clients and it worked fine.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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