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

[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

[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] OpenVPN 2.0 -- Project Update and Release Notes

[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

[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

[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!"