Re: FW: VPN

Darren:

 	Heya. I agree of course that any networking application
which connects users via an echoWare approach can equivalently be
connected via a VPN approach (like OpenVPN or even Hamachi). And
I also agree that for most large organizations with remote-users,
a VPN solution is a basic necessity.

 	But I would disagree that makes a VPN solution preferable
for all networking applications. For example, with a VPN, a
user-to-user connection is at least a two step process: you first
establish the VPN connection, then run an application on top of
the connection. If something goes wrong, is it a VPN problem (eg,
MTU setting), an application problem, or pilot error? For IT
professionals, debugging this is everyday life; for the average
Internet user (ie, someone who knows their email address, but not
their IP address), it's black-magic.

 	An application-specific solution can be more "point and
click", which is valuable for simple, ad-hoc, user-to-user apps
like remote-desktoping, soft-phone, or video-chatting. And depending
on the target user of the application, and the available IT support
staff for those users, that might be exactly what's needed.

cheers,
Scott


<snip>
>>  	Also, the echoServer is hardly "only for VNC" -- echoWare
>> will work for any user-to-user application. We wrapped a GUI around
>> echoWare and call it "EchoVNC", but the echoServer itself is good
>> for any echoWare-enabled application.
>>
>>  	Hamachi's approach of creating a virtual interface on
>> both sides of the connection is an interesting one -- as you say,
>> it solves for all layer-3 connections all at once, rather than
>> echoWare's per-application approach. Maybe I should spend the
>> time to create an EchoVPN product, based on echoWare. :)
>
> I'm wondering how solutions like these offer benefit over the tradional VPN
> approach. Assuming a dispreference for IPsec due to its complexity, what
> about something much lighter weight such as OpenVPN? Per above named points:
>
> 1. You (the company/administrator/IT staff) run and administer your OpenVPN
> server.
>
> 2. Assuming you also control your own firewall, you can simply allow
> connections through for the single port number or range of ports you use for
> OpenVPN.
>
> 3. OpenVPN is of course Open Source too.
>
> To boot, use of this kind of VPN solution provides transparent access to the
> LAN or portions thereof as determined by your intentions, making
> authenticated/connected clients virtually an extension of the LAN; no
> per-application bit about it.