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
10.2.10.1 10.8.0.4 255.255.255.255 UGH 20 0 0 tun0
192.168.100.0 10.8.0.4 255.255.255.0 UG 20 0 0 tun0
192.168.1.0 10.8.0.4 255.255.255.0 UG 20 0 0 tun0
The subnet I want to access is 192.168.100.0/24. 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 :
10.2.10.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Where things start going south
Pinging from the server (10.8.0.1) to any hosts (including the VPN client interface) in the 192.168.100.0/24 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 192.168.100.0 subnet, it doesn't discover any hops (there should be just one). If I traceroute directly to the next hop (10.8.0.4), 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.
What I find strange is it that client's routing tables are pointing to nowhere (0.0.0.0). It is ok for local networks but for 10.2.10.1 that passes trough a tunnel it might be a problem.
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?
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.