1

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.

3 Answers 3

0

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.

1
  • 10.2.10.1 is local to the client in question so that's not a problem. The route in the server points towards it which makes sense. Oct 11, 2010 at 15:29
0

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?

2
  • That can't work... Each client has a subnet behind it that I want to access. Where would I point the default route to ? Oct 12, 2010 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 192.168.1.0/24, with a next-hop of 10.8.0.4, does it work then?
    – Vatine
    Oct 12, 2010 at 14:23
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .