On 14.04.2013 15:14, Boris Epstein wrote:
> On Sun, Apr 14, 2013 at 9:06 AM, Stephen Harris <lists@xxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
