1

I've now done quite some research on this topic and could not come up with a viable solution so far. There have been many questions, most of them not quite matching my issue, and only few answers. So, I hope to get some help here. Here's the setup:

My local network uses the adress range 10.1.0.0/24 with 10.1.0.1 being the router, and 10.1.0.2 being the machine I'm trying to access from outside the network.

The router runs dd-wrt firmware and is configured to be an OpenVPN server with a vpn address range of 10.2.0.0/24. In the servers configuration, I'm trying to push the route to my local network via:

push "route 10.1.0.0 255.255.255.0"

I can establish a working OpenVPN connection from my client at work and the route get pushed correctly:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ds9-ds10.gate.u 0.0.0.0         UG    302    0        0 wlan0
10.1.0.0        10.2.0.1        255.255.255.0   UG    0      0        0 tun0
10.2.0.0        *               255.255.255.0   U     0      0        0 tun0
10.20.4.0       *               255.255.254.0   U     0      0        0 wlan0
10.20.4.0       *               255.255.254.0   U     302    0        0 wlan0

I can also ssh into my router or use its web-interface using either its regular ip 10.1.0.1 (which is only possible when pushing the route) or its vpn ip 10.2.0.1.

Ip forwarding is enabled on the router:

# cat /proc/sys/net/ipv4/ip_forward 
1

I thought I should now be able to ssh to the other machine (which is configured to accept connections from 10.1.0.0/24 and 10.2.0.0./24 addresses) using its lan ip 10.1.0.2, as all connections to 10.1.0.0/24 should now be routed via the 10.2.0.1, still I can't get a connection.

I cannot see the missing bit in my setup, probably somewhere in the router. Why does my request to connect to 10.1.0.1 (local address range) work but the request for 10.1.0.2 does not reach the machine connected to the router?

EDIT:

I was unaware of the issue @MariusMatutiae pointed out. I've read about needing a static route on a couple of occasions but it was never clear where and what to add, I've to admit that my knowledge about the finer details is quite limited. The clarification in his reply makes perfect sense however. Following his suggestions I have modiefied the routing table on the router to now include

10.2.0.0        10.2.0.1        255.255.255.0   UG    0      0        0 tun2

leading to the following table:

root@DD-WRT:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         188-193-191-254 0.0.0.0         UG    0      0        0 vlan2
10.1.0.0        *               255.255.255.0   U     0      0        0 br0
10.2.0.0        10.2.0.1        255.255.255.0   UG    0      0        0 tun2
10.2.0.0        *               255.255.255.0   U     0      0        0 tun2
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
188.193.184.0   *               255.255.248.0   U     0      0        0 vlan2

The FORWARD chain of iptables include the lines

pkts bytes target     prot opt in     out     source               destination  
   0     0 ACCEPT     0    --  tun2   *       0.0.0.0/0            0.0.0.0/0
   0     0 ACCEPT     0    --  *      tun2    0.0.0.0/0            0.0.0.0/0

above any DROPs or REJECTs with tun2 being the tun device of the OpenVPN server. Should be okay I think.

The issue, however, still remains unsolved. What's wrong?

3
  • Why is your gateway address 188-193-191-254? It should be 188.193.191.254. Could this be the source of your problems? Nov 10, 2013 at 14:24
  • Also, did you check whether your iptables allow traffic? In particular, do they allow forwarding? Nov 10, 2013 at 14:56
  • Since everything else works fine, the default gw should not be the problem, 188-193-191-254-dynip.superkabel.de is just the ISPs hostname getting resolved here. Regarding the firewall, see addition above.
    – inVader
    Nov 11, 2013 at 0:28

1 Answer 1

2

You think that the statement

 push "route 10.1.0.0 255.255.255.0"

is the end of the story, so far as routing goes, but it is not. All this stement does is make the client aware of the existence of a private LAN, 10.1.0.0/24, behind the VPN server. However, the VPN server itself is not aware of the existence of the VPN network 10.2.0.0/24 because no one instructed it to add a suitable route to its table. This is the reason of your problems: in fact, your client can connect to the members of the LAN, but it never receives a reply because the router does not know how to route back its replies to the VPN client.

The way out of that is either to add this command to the router,

 route add -net 10.2.0.0/24 gw 10.2.0.1

or

 route add -net 10.2.0.0/24 dev tun0 

or (after having tested that this is the only problem you have) to add this statement to your server.conf file:

 route 10.2.0.0 255.255.255.0

You need this statement as well as the statement

 push "route 10.1.0.0 255.255.255.0"

You may be surprised that the router does not know the route back to the VPN client, because you are thinking that router and VPN server are the same machine, but this is exactly the explanation why the router does not know what the server is doing: the general case is the one where the two are hosted by two different machines. In this case, you do not wish to alter the routing table of the VPN server, because this would mean that the other pcs on the LAN would not know how to reach the VPN client, and you would have to solve that by changing all the routing tables of all pcs to tell them that the gateway to the VPN is the VPN server, not the router. Instead, what you really wish to do in this case is not to alter the VPN server's routing table, and change instead the router's routing table, so that you do this just once.

1
  • My knowledge on the finer details of networking is/was quite limited I have to admit. Your reply makes perfect sense, however. The issue is still unresolved though. Could you have a look at the additional information I have added? Also, do you have any suggestions for a quick and easy test wether one way communication from the vpn to the lan is working to verify that routing is really the issue now?
    – inVader
    Nov 10, 2013 at 13:42

You must log in to answer this question.

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