Slashdot Mirror
Can Web Based VPN Solutions Do It All?
Bingo Foo asks: "My company is in the process of reviewing replacements to our existing multi-platform VPN, which has now been discontinued. I was under the impression that every major vendor's OS ships with a VPN configuration solution.
What gives? Are these not standard enough? Are they not secure enough? not flexible enough?
Regardless, our IT department is leaning toward a clientless, web-based solution, which frankly sounds too good to be true. Can simply directing your browser at the portal allow X11, NFS, SMB, AFP, ssh, etc. transparently through the firewall? Anyone have experience with Neoteris and their VPN?"
but it's not clientless.
Last time I checked, without a java applet or some sort of client in the html page you can't do socket services. So it's just a client that loads from the web page.
SW
That is only partially true. Of course you are right about the site-to-site issue, but your second problem is not correct.
The client can in some of these solution authenticate with client certificates, and username and password, against RADIUS, LDAP and whatnot. Some even offer multiple authentication stages.
One product does terminal server, netbios, intranet web proxying and (windows client only, afaik it's active-x based) IP tunneling over SSL.
I saw outlook to exchange natively over one of these tunnels, looks very promising.
www.netilla.com
My company is evaluating the Neoteris as well as a few other SSL (Secure Sockets Layer) VPN products. They essentially allow SSL sessions to be established over port 443 which allows for encryption of the data. From what I understand, to be able to take advantage of this VPN, applications have to be created/altered to run over SSL, so no they cannot "do it all". However, they do provide an excellent alternative for remote access. They are clientless in that the session is established using a standard web browser and the users already existing username/password login. There is no IPSec client to install and configure which removes (to a large extent) a lot of user issues.
The SSL VPN is being seen as an alternative to the more traditional IPSec VPN for remote access. IPSec VPNs are still seen as the de facto standard for encrypted, secure site-to-site communications.
Co-founder and designer at Music Nearby: http://musicnearby.com
While I don't have direct experience with the product line mentioned in the question, I have implemented Aventail in the past, and am looking at them again for a project next year.
For the most part, SSL VPN products differ from IPSEC VPN products in a fundamental way. SSL VPN products can best be imagined as reverse proxy servers that use SSL based encryption. Typically, it is the SSL VPN device that will be making connections to the "protected" network hosts, not the remote node. TCP sessions are maintained remote node to SSL device, and SSL device to "protected" host.
IPSEC products can be imagined more as encrypted water hoses. A device (or client shim) intercepts traffic at the remote node, puts it in the hose (encrypted tunnel), and pushes it out to the IPSEC device at the protected network. TCP sessions are maintained remote node to "protected" host.
Although the tunnel does normally imply some stateful translation, the session does not terminate on a tunnel device, unless that device is the remote node.
Obviously SSL products are great for Web based applications. IPSEC products lend themselves best to site-to-site connectivity. The grey area between them is remote client situations.
Which solution is better in the remote client (i.e. laptop in a hotel room, or at a client's site) really depends on the where and how the remote client is to be used.
Many organizations don't allow IPSEC tunnels to be initiated from their internal network to an outside location.
On the other hand, those same organizations (and many others) will allow outbound SSL traffic initiated from hosts on the internal network.
Sig??? I don't need no stinkin Sig!