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



Sorry to initiate further discussion on this. I just had a second
thought on this.

> Tim Niemueller <tim niemueller de> wrote: 
> X.509 support is on the vpnc todo. Could it be that adding this to
vpnc
> would make novellvpn a nortelvpn with later planned novellvpn
extensions?

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.

> 
> Maybe this calls for a method in NM to allow vpn- plugins to display
more
> than one name.

This seems to be the ideal solution, but might take time & effort.

> This way the novellvpn could have entries in the list for
> "IPSec VPN" and "Nortel VPN" and not just "Novell VPN" (which I'm
pretty
> sure no one would expect to be used for IPSec). 

There are many ipsec gateways around and they have different clients
too. Terming this client as ipsec gateway may add confusion to users
that others are not IPSec based vpns (vpnc). I feel that most users
would want to connect to gateways based on the type of the gateway,
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. 

> So the semantic should
> shift from naming the client to naming the type of VPN you can
connect
> to (since this is the interesting information to the user and not
what
> program is actually used to establish the connection). 

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?

                     Suresh.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]