From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Samad Date: Mon, 10 Sep 2007 22:03:31 +0000 Subject: Re: [LARTC] OpenVPN routing Message-Id: <20070910220331.GG6156@samad.com.au> MIME-Version: 1 Content-Type: multipart/mixed; boundary="===============1138157623==" List-Id: References: <46E4E5E2.2070703@amfes.com> In-Reply-To: <46E4E5E2.2070703@amfes.com> To: lartc@vger.kernel.org --===============1138157623== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2E/hm+v6kSLEYT3h" Content-Disposition: inline --2E/hm+v6kSLEYT3h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >> =20 >>> Hi! >>> >>> I'm trying to create a routed VPN using OpenVPN - and having trouble wi= th=20 >>> the routing concepts involved. Let me see if I can properly describe m= y=20 >>> 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= =20 >>> 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= =20 >>> the routed VPN workstations. The LAN should be invisible to the routed= =20 >>> VPN. >>> >>> My 2nd goal is to allow selected server-side LAN workstations to reach= =20 >>> networks server by routed VPN workstations as gateways [this involves= =20 >>> OpenVPN more, I believe]. The LAN should still be invisible to the=20 >>> 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 >>> =20 >> >> I think you need to use a tap device (I currently have a similar setup,= =20 >> 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= =20 >> addresses if that is the case this is more a iptables question you will= =20 >> need to nat the lan network going out, if you want in bound traffic you= =20 >> will need to setup natting on the way back in as well - static though. >> =20 > So do I need a source NAT directing all traffic intended for 172.27.0.0/1= 6=20 > from 192.168.0.0/24 to come from 172.27.0.1? >> why do you want to hide the network - ? >> =20 > The VPN is to provide me a secure static connection to customer's sites. = =20 > However, those customers should be able to see neither each other, nor=20 > 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 intern= et,=20 SNAT should do it (and a firewall just to be safe), you should only need on= e on=20 the client's openvpn side, but because that is not in direct controll of yo= u=20 (physcially), I would probably suggest snat'ting again on your openpvn serv= er=20 or the firewall rules So=20 At your site * Set routing either fix up the default route or add routing to each client= =20 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= =20 255.255.252.0"' - done in the openvpn server config (the later is probably= the=20 better - stay away from the double natting ) one the customer site * Set up SNAT hide everything coming from your site being the local lan add= ress * set up a firewall=20 So all traffic coming from your site will end up on the customer site with = a=20 local lan address. There is no routing back into your lan, because of a) routing b) firewall o= n=20 the customer site c) firewall on the server. a & b are easy to get around because they are at the customer site. C is wh= ere=20 you protection is. Alex > --=20 > Daniel > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > --2E/hm+v6kSLEYT3h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG5b8zkZz88chpJ2MRArN1AKDxu4LpW5P4HwgfKWyQ4PV/d7eemgCgvqOD m6T2Iu9G6sp6WjV6xhSMmVQ= =vipq -----END PGP SIGNATURE----- --2E/hm+v6kSLEYT3h-- --===============1138157623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc --===============1138157623==--