All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Samad <alex@samad.com.au>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] OpenVPN routing
Date: Mon, 10 Sep 2007 22:03:31 +0000	[thread overview]
Message-ID: <20070910220331.GG6156@samad.com.au> (raw)
In-Reply-To: <46E4E5E2.2070703@amfes.com>


[-- Attachment #1.1: Type: text/plain, Size: 3976 bytes --]

On Mon, Sep 10, 2007 at 01:40:29PM -0700, Daniel L. Miller wrote:
> Alex Samad wrote:
>> On Sun, Sep 09, 2007 at 11:36:18PM -0700, Daniel L. Miller wrote:
>>   
>>> Hi!
>>>
>>> I'm trying to create a routed VPN using OpenVPN - and having trouble with 
>>> the routing concepts involved.  Let me see if I can properly describe my 
>>> current topology:
>>>
>>> Server -
>>> LAN, with both local workstations and remote bridged workstations on the
>>>    192.168.0.0/24 network (this works without reservation).
>>>    Server located at 192.168.0.71, 192.168.0.72, 192.168.0.222, and few 
>>> others.
>>> Routed VPN, 172.27.0.0/16 network.  Server is located at 172.27.0.1.
>>>    Server can talk to clients, and clients can talk to server.
>>>
>>> My 1st goal is to allow selected server-side LAN workstations to reach 
>>> the routed VPN workstations.  The LAN should be invisible to the routed 
>>> VPN.
>>>
>>> My 2nd goal is to allow selected server-side LAN workstations to reach 
>>> networks server by routed VPN workstations as gateways [this involves 
>>> OpenVPN more, I believe].  The LAN should still be invisible to the 
>>> routed VPN.
>>>
>>> My server routing table is:
>>> 172.27.0.2 dev tun0  proto kernel  scope link  src 172.27.0.1
>>> 192.168.20.0/24 dev vmnet8  proto kernel  scope link  src 192.168.20.1
>>> 10.4.1.0/24 via 172.27.0.2 dev tun0
>>> 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.71
>>> 192.168.0.0/24 dev br1  proto kernel  scope link  src 192.168.0.72
>>> 192.168.30.0/24 dev vmnet1  proto kernel  scope link  src 192.168.30.1
>>> 172.27.0.0/16 via 172.27.0.2 dev tun0
>>> default via 192.168.0.1 dev eth0
>>>     
>>
>> I think you need to use a tap device (I currently have a similar setup, 
>> but I do not hide the LAN - infact I use openvpn to do site to site WAN)
>>
>> By hide the LAN you don't want to the openvpn clients to see the 192.168 
>> addresses if that is the case this is more a iptables question you will 
>> need to nat the lan network going out, if you want in bound traffic you 
>> will need to setup natting on the way back in as well - static though.
>>   
> So do I need a source NAT directing all traffic intended for 172.27.0.0/16 
> from 192.168.0.0/24 to come from 172.27.0.1?
>> why do you want to hide the network - ?
>>   
> The VPN is to provide me a secure static connection to customer's sites.  
> However, those customers should be able to see neither each other, nor 
> reach our internal LAN - unless the connection is initiated from our side.
Okay then you just want out bound, pretend the customers site is the internet, 
SNAT should do it (and a firewall just to be safe), you should only need one on 
the client's openvpn side, but because that is not in direct controll of you 
(physcially), I would probably suggest snat'ting again on your openpvn server 
or the firewall rules



So 

At your site

* Set routing either fix up the default route or add routing to each client 
 machine (the former being the easier of the 2)
* Set up a firewall
* setup SNAT or push a route through to the client 'push "route 192.168.8.0 
 255.255.252.0"' - done in the openvpn server config (the later is probably the 
better - stay away from the double natting )


one the customer site
* Set up SNAT hide everything coming from your site being the local lan address
* set up a firewall 


So all traffic coming from your site will end up on the customer site with a 
local lan address.

There is no routing back into your lan, because of a) routing b) firewall on 
the customer site c) firewall on the server.

a & b are easy to get around because they are at the customer site. C is where 
you protection is.

Alex




> -- 
> Daniel
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2007-09-10 22:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-10  6:36 [LARTC] OpenVPN routing Daniel L. Miller
2007-09-10  9:05 ` Alex Samad
2007-09-10 20:40 ` Daniel L. Miller
2007-09-10 22:03 ` Alex Samad [this message]
2007-09-10 22:48 ` Daniel L. Miller
2007-09-11  2:14 ` Alex Samad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070910220331.GG6156@samad.com.au \
    --to=alex@samad.com.au \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.