Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

2004-03-31 Thread James Yonan
Matthias Andree  said:

> On Tue, 30 Mar 2004, James Yonan wrote:
> 
> > OpenVPN 2.0 -- Project Update and Release Notes
> > 
> > I'm happy to announce that the first OpenVPN 2.0 beta is here, and well 
> > ahead
> > of schedule.  This is in large part thanks to a generous contribution by
> > Meetrix Inc. which has allowed me to work full-time on the project during 
> > the
> > last month.
> 
> In how far does the new OpenVPN 2.0 server require client upgrades?

If you run 2.0 in point-to-point mode (i.e. 1.x behaviour) no client upgrades
are required, with the caveat that some default options have changed.

If you want to use --mode server, then both the client and server need to be
2.0 because the client needs to support the --pull option in order to get
dynamic configuration info from the server.

James




Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

2004-03-31 Thread Matthias Andree
On Tue, 30 Mar 2004, James Yonan wrote:

> OpenVPN 2.0 -- Project Update and Release Notes
> 
> I'm happy to announce that the first OpenVPN 2.0 beta is here, and well ahead
> of schedule.  This is in large part thanks to a generous contribution by
> Meetrix Inc. which has allowed me to work full-time on the project during the
> last month.

In how far does the new OpenVPN 2.0 server require client upgrades?

Which client versions (providing the clients use TLS) are still
compatible?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95



Re: [Openvpn-devel] Re: [Openvpn-users] OpenVPN 2.0 and firewall

2004-03-31 Thread Arkadiusz Patyk
On Wed, 31 Mar 2004 18:39:45 -, you wrote:

>Arkadiusz Patyk  said:
>
>> Hi
>> 
>> Two very significant things for me are:
>> 1. In my configurations, VPN users have different rights to resources
>> (access list on firewall - iptables).   I have to know client IP to
>> correctly setup firewall, how can i do this in 2.x ?   How can i
>> achieve this, in case of dynamic IP assignment
>
>You can use the --ipchange script which is passed the common name and source
>IP address every time a client connects.  I probably need to add a new
>environmental variable that contains the dynamically allocated --ifconfig-pool
>subnet.

with dropping privileges and chroot  it could be difficult  ;(

Is any script executed after the connection termination?

>> 2. Is it possible to run few servers (each of them on their own tap)
>> on the same machine?
>
>Yes, it is possible to run many '--mode server' servers on the same machine,
>each having their own tun interface (tap interfaces are not supported yet in
>--mode server mode).
>
>This would be a good way to differentiate access rights for different client
>classes.

Not in my particular case - i have diffrent access list for each user
- N users  = N server = openvpn 1.x ;-)


-- 
Arkadiusz Patyk [areq(at)pld-linux.org] [http://rescuecd.pld-linux.org/]
[IRC:areq ICQ:16231667  GG:1383]  [AP3-6BONE] [AP14126-RIPE]



[Openvpn-devel] Re: [Openvpn-users] OpenVPN 2.0 and firewall

2004-03-31 Thread James Yonan
Arkadiusz Patyk  said:

> Hi
> 
> Two very significant things for me are:
> 1. In my configurations, VPN users have different rights to resources
> (access list on firewall - iptables).   I have to know client IP to
> correctly setup firewall, how can i do this in 2.x ?   How can i
> achieve this, in case of dynamic IP assignment

You can use the --ipchange script which is passed the common name and source
IP address every time a client connects.  I probably need to add a new
environmental variable that contains the dynamically allocated --ifconfig-pool
subnet.

> 2. Is it possible to run few servers (each of them on their own tap)
> on the same machine?

Yes, it is possible to run many '--mode server' servers on the same machine,
each having their own tun interface (tap interfaces are not supported yet in
--mode server mode).

This would be a good way to differentiate access rights for different client
classes.

James

> -- 
> Arkadiusz Patyk [areq(at)pld-linux.org] [http://rescuecd.pld-linux.org/]
> [IRC:areq ICQ:16231667  GG:1383]  [AP3-6BONE] [AP14126-RIPE]
> 
> 
> ---
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470_id=3638=click
> ___
> Openvpn-users mailing list
> openvpn-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 



-- 






[Openvpn-devel] small patch for the spec.in file

2004-03-31 Thread Farkas Levente

hi,
here is my small patch for the spec.in file in order not to overwrite 
the old config files.


--- openvpn.spec.in.lfarkas 2004-03-31 18:11:14.0 +0200
+++ openvpn.spec.in 2004-03-31 18:13:25.0 +0200
@@ -34,9 +34,9 @@
 %__install -c -m 755 %{name}.8 %{buildroot}%{_mandir}/man8
 %__install -c -d -m 755 %{buildroot}%{_sbindir}
 %__install -c -m 755 %{name} %{buildroot}%{_sbindir}
-%__install -c -d -m 755 %{buildroot}/etc/rc.d/init.d
-%__install -c -m 755 sample-scripts/%{name}.init 
%{buildroot}/etc/rc.d/init.d/%{name}

-%__install -c -d -m 755 %{buildroot}/etc/%{name}
+%__install -c -d -m 755 %{buildroot}%{_initrddir}
+%__install -c -m 755 sample-scripts/%{name}.init 
%{buildroot}%{_initrddir}/%{name}

+%__install -c -d -m 755 %{buildroot}%{_sysconfdir}/%{name}

 %__mkdir_p %{buildroot}%{_datadir}/%{name}
 %__cp -pr contrib easy-rsa sample-{config-file,key,script}s 
%{buildroot}%{_datadir}/%{name}

@@ -67,9 +67,12 @@
 %{_mandir}/man8/%{name}.8*
 %{_sbindir}/%{name}
 %{_datadir}/%{name}
-/etc
+%config(noreplace) %{_sysconfdir}

 %changelog
+* Mon Mar 31 2004 Levente Farkas  2.0_test18
+- Mark config file as config.
+
 * Sun Feb 23 2003 Matthias Andree  1.3.2.14-1.
 - Have the version number filled in by autoconf.


--
  Levente   "Si vis pacem para bellum!"




Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

2004-03-31 Thread Alberto Gonzalez Iniesta
On Wed, Mar 31, 2004 at 12:31:13PM +0200, Alberto Gonzalez Iniesta wrote:
> Debian package available (for testing/unstable) at:
> 
> http://tmp.inittab.org/~agi/openvpn_2.0_beta18-1_i386.deb
> 

Sorry, that should read:

http://tmp.inittab.org/~agi/openvpn_2.0_test18-1_i386.deb

It's a test release, not a beta one.



-- 
Alberto Gonzalez Iniesta   | BOFH excuse #367:
agi@(agi.as|debian.org)| Webmasters kidnapped by evil cult.
Encrypted mail preferred   | 

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3



Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

2004-03-31 Thread Alberto Gonzalez Iniesta
On Tue, Mar 30, 2004 at 11:15:45PM -, James Yonan wrote:
> OpenVPN 2.0 -- Project Update and Release Notes
> 
> I'm happy to announce that the first OpenVPN 2.0 beta is here, and well ahead
> of schedule.  This is in large part thanks to a generous contribution by
> Meetrix Inc. which has allowed me to work full-time on the project during the
> last month.

Wow! Impressive job James! Thanks a lot for your work. 
And thanks Meetrix for your support!

Debian package available (for testing/unstable) at:

http://tmp.inittab.org/~agi/openvpn_2.0_beta18-1_i386.deb

Consider it Beta, and report bugs to openvpn-devel@lists.sourceforge.net
(in case of openvpn related problem) or me (in case of packaging
errors).



-- 
Alberto Gonzalez Iniesta   | BOFH excuse #191:
agi@(agi.as|debian.org)| Just type 'mv * /dev/null'.
Encrypted mail preferred   | 

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3


signature.asc
Description: Digital signature


Re: [Openvpn-users] Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

2004-03-31 Thread Farkas Levente

James Yonan wrote:

Farkas Levente  said:



first of all THANKS!

James Yonan wrote:


* Add an internal routing capability to the OpenVPN server to allow
client-to-client communication, without going through the tun interface on the
server.


why this is needed? ans what exactly this means?



Basically OpenVPN 2.0 is a router.  It gets packets from a single tun
interface and uses the destination address on the packet to determine which
client to route it to.  So what should the router do if a packet comes from a
client and has as its destination address another client?  Some people would
want to block this capability and other would want to allow it.  If you block
it, connecting clients can only see the central server's network.  If you
allow it, one client could browse file shares on another client.


hmm, thanks I know what's the routing, but I ask this part:
"client-to-client communication, without going through the tun.."
 ^^^


* Right now clients are allocated a single, dynamic IP address.  It would be
nice if a connecting client could specify a full subnet to be tunneled.


would be welcome!



There are several problems with this that need to be solved (which I don't
think are insurmountable):

(1) First of all, there are security implications in allowing a client to push
a route onto a server, which would be necessary if a private subnet exists
behind the client that you want to route.  Probably the server config file
would need to specify special routes for various clients, based on the client
common name.


yes, but it's possible in th 1.x (although all clients has it's own 
config file), but since I can use --ifconfig-pool (which is great) I 
don't know in advance which /30 subnet will be used by the clinet, so 
define static route is a bit problematic.



(2) In general you want to run the VPN server with reduced privilege, to limit
damage in the case that the server is somehow compromised.  But adding and
removing routes requires privilege, unless all routes for every possible
client are configured on server startup, before the privilege downgrade.


that's a good point:-(((


(3) static routes tied to specific clients interferes with failover.  Suppose
you have 2 machines running a VPN server, and for purposes of load balancing
and failover, you want clients to be able to connect to either server.  Now
once you start to have clients needing static routes, it means that the
gateway on the server's network needs to understand that a given static route
might need to point to either server A or server B, depending on which of the
two servers the client is currently connected to.  So essentially, the server
would need to be able to push routes onto the gateway.

Of course all of these problems go away if the client NATs its private subnet
onto the remote VPN endpoint.  There would also be the possibility of having
the server dynamically allocate a full netblock to the client and then have
the client do one-to-one NAT between the static addresses on the subnet and
the dynamically allocated VPN subnet.  Yet another possibility is simply to
have each machine in the remote subnet have its own private tunnel to the VPN
server.

So there's certainly a number of possible solutions, but no magic bullet that
I can think of.


I see the problems.


# The server's virtual endpoints
ifconfig 10.8.0.1 10.8.0.2


this means this server has two enpoint in the server side?



Not really.  The server's local VPN endpoint is 10.8.0.1.  This is the address
which all clients will use to reach the server.  The 10.8.0.2 is really a
pseudo-address which is not bound to anything.  You couldn't ping it for


than it'd be better to omit. it's just confusing!


example.  However you can use it as a destination for routes which exist in
the server's routing table.  When you do this, the packet will be routed to
OpenVPN which will then use an internal routing algorithm to route it to the
appropriate client.  The way to think about this in a non-confusing way is to
treat the 10.8.0.2 as the "name" of the server's tun interface, so that when
you want to route a subnet into server, you can use 10.8.0.2 as the destination.


aha, than two separete config option would be more intuitive (or it 
should have to be well documented).
in this case my first question getting cleaner. although I still thing 
that routing is better to do in the os (where it's tuned better) and 
somehow propagate openvpn's route table to the os's route tables.

do it two separate place can get confusing and may result fault.

--
  Levente   "Si vis pacem para bellum!"