On 14.04.2013 15:14, Boris Epstein wrote:
On Sun, Apr 14, 2013 at 9:06 AM, Stephen Harris lists@spuddy.org wrote:
On Sun, Apr 14, 2013 at 09:00:16AM -0400, Boris Epstein wrote:
Let's say I have an OpenVPN (v2) server sitting on a Linux machine with
the
IP address of, say, 192.168.10.1o. We are talking real address, assigned
to
a NIC on the machine.
Now let us say the OpenVPN server hands out IP's in the 192.168.20.0/24range. And let us say that I want the machines able to reach the VPN server to be able to route to the machines available via the VPN. So, for instance, 192.168.10.5 should be able to ping 192.168.20.6 assuming the latter is one of the VPN clients.
So here is my question: is there a VPN setting that would facilitate
that?
In the server config file push "route 192.168.10.0 255.255.255.0"
That will tell the openvpn client to add a route to 192.168.10.0/24 via the openvpn gateway.
Machines on the LAN also need a route to 192.168.20.0/24 via the gateway; this is easy if your OpenVPN server is also your default gateway (eg router); otherwise you may need to add routes per-machine or via DHCP, or potentially just tell the default router about the route and let it send redirects to the LAN machines.
--
rgds Stephen _______________________________________________
Stephen,
Thanks! What you are saying makes perfect sense. I have tried it.
It works for every subnet except the one the OpenVPN server sits on ( 192.168.10.0/24 in our example). Yes, the VPN server has to be the default router - or else it just does not seem to work. This additional hop just kills everything, it seems.
This issue is that while the client knows the route to the new subnet thanks to the push route command the servers don't know the route back to the client. If the OpenVPN server is the gateway then this isn't an issue because the packet will be forwarded to it and the server knows about the client IPs.
One way around this is as Stephen pointed out to add routes to each individual server though with a large number of servers this is tedious and error prone (unless you use configuration automation like puppet, chef, etc.).
The other way is to configure a MASQUERADING rule on the VPN server that masquerades all packets that come through the tunnel and have a source IP from the client pool. That way the server will not receive the packets with the original client IP as source but the IP of the VPN server. So the response will go to the VPN server and there the packets will get de-masqueraded again and forwarded to the client. This is very similar to the default gateway method except that the VPN server no longer has to be the actual default gateway for all traffic but only becomes the de-facto gateway for all packets from VPN clients which most of the time is exactly what you want.
Regards, Dennis