Re: [patch] novellvpn - vpn daemon for ipsec gateways

[Tim Niemueller <tim niemueller de>]

T Sureshkumar wrote:
> Sorry to initiate further discussion on this. I just had a second
> thought on this.

> 
> Turnpike framework enables to write plugin extentions  to racoon so
> that many vendors (open & closed) and authentication modes can be
> supported with Racoon. Nortel too have a xuath+hybrid authentication
> proprietary mode, so this cannot be added to vpnc.

OK.

> rather than the client used to connect to gateway. So it would be ideal
> to have the first level selection to list multiple names for a single
> service. 

You mean for a single client application? Ideally we do not re-invent
the wheel all too often and then have three entries for Cisco-VPN
gateways in the end, although there may be a situtation where multiple
clients reproduce the same functionality (because it may be just a
subset of a more complex task the client can accomplish).

> Right now, the nm-vpn service is a glue code to invoke a particular
> client and pass parameters. So, the service would still be based on a
> particular client and a descriptive UI could guide the user to use a
> particular client.  Otherwise, first level selection can be based on VPN
> types (SSL, pptp, ipsec) and second level selection could be based on
> (gateway type, authentication modes and client). This means top level
> VPN class, subclassed by VPN types and types further subclassed to a
> particular vpn client.  If this is the idea, the framework is to be
> developed and I suggest till then, we can have novellvpn as it is (since
> a service is tied to a single client binary). What do you say?

I'm not sure if we need a hierarchy that deep. I think what would do the
job quite well is to define a list of well-known VPN gateway
configurations you connect to. By configuration I do not mean every
aspect like port etc. but just the basic settings like "ipsec+xauth" or
"ipsec+xauth+nortel" or whatever. All VPN clients would have to register
for any number of services (a common naming scheme should be established
with a README describing the already supported types as kind of a
template registry) and then the VPN manager compiles a list of available
VPN types from this information. This could also be handy for example to
offer the different basic configuration possibilities for OpenVPN to the
user (X.509, password, hybrid) and then show a clean user interface with
exactly the needed information and not such a mess as right now.

The user chooses a type. If there are multiple clients implementing the
protocol the user can choose either one of them and get's to a client-
and vpn-type-specific GUI to enter the data as today. So there may be an
additional step compared to today choosing the client and the initial
list would change. In this case I think you are right in keeping
"novellvpn" as a name as it just names the client (as for vpnc).

Comments?

	Tim

-- 
    Tim Niemueller <tim niemueller de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)