Re: [LARTC] OpenVPN routing

2007-09-10 Thread Alex Samad
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.

why do you want to hide the network - ?

unless your server is the default gateway for the network you will have to do 1 
of 2 things, either setup routing on each client or update the default gateway 
how to route the packet (ie via the server). 

Why do the client (openvpn client) not respond to pings, I would guess again 
routing usual problem, can you run tcpdump on these machines ?


 IP forwarding is enabled on all interfaces, and iptables (by way of 
 firehol) has rules to allow all forwarding between all interfaces.

 If I create a 172.27.0.0/16 route on a LAN workstation, I can ping the 
 server at 172.27.0.1.  But I cannot reach any VPN workstation.  At one 
 time, by playing with some NAT rules, I was able to - but it didn't seem 
 right.

 What am I missing?

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



signature.asc
Description: Digital signature
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] OpenVPN routing

2007-09-10 Thread Daniel L. Miller

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.

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


Re: [LARTC] OpenVPN routing

2007-09-10 Thread Alex Samad
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



signature.asc
Description: Digital signature
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] OpenVPN routing

2007-09-10 Thread Daniel L. Miller

Alex Samad wrote:

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.

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?

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
  

I've put in a snat on the server side - seems to be working fine.
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.
  
Customer's site not under my control - and running Windows so my linux 
options are rather limited g.  So I need to do everything within the 
server and OpenVPN.  I CAN push a route to the client - but I still 
don't see why I need to share my LAN information with the clients at all 
- I just need the OpenVPN client to be a gateway for the VPN and forward 
VPN traffic from the remote network.


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


Re: [LARTC] OpenVPN routing

2007-09-10 Thread Alex Samad
On Mon, Sep 10, 2007 at 03:48:13PM -0700, Daniel L. Miller wrote:
 Alex Samad wrote:
 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.
 
 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?
 
 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
   
 I've put in a snat on the server side - seems to be working fine.
 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.
   
 Customer's site not under my control - and running Windows so my linux 
 options are rather limited g.  So I need to do everything within the 
 server and OpenVPN.  I CAN push a route to the client - but I still don't 
 see why I need to share my LAN information with the clients at all - I just 
 need the OpenVPN client to be a gateway for the VPN and forward VPN traffic 
 from the remote network.
if you are using snat you shouldn't.

if you have setup a ip network for the vpn ie if your server ip address is not 
in the network for the customer you will need snat'ing there else the client 
machine will not know how to get back.





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



signature.asc
Description: Digital signature
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc