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
Yes, it does work. It can be handy for connecting via windows/linux/unix/palm/mac and more. The key is that you use a capable browser to download a java (it could be something else) vpn client that runs. When using the browser, SSL protects you, and once the java client is running, you are running a non-installed client.
I worked for a company, openreach, inc. that did a nice job on clientless VPN, although their bread-n-butter was site to site VPN.
This essentially looks like a custom security solution to deliver a specific set of protocols, via the web. So if you want to SSH, you connect over SSL to it, and then log into a Web application and run the SSH client. Possibly they have developed a wicked Java applet that runs on the local machine.
You want to browse the shares, you do it via a web interface. Maybe with IE, it presents the share to you as a webdav environment so you can mount the share directly.
I don't see anything there that leads me to believe I can run an arbitrary custom application over it. (ironically, this is one of the thinks they knock extranet's for). Call them up, ask if you can securely ship internal data over it.
It sure looks like they essentially provide you with a proxy server that you connect to over SSL, that will proxy you on, or just give you access to some form of applet on it. Granted a nifty interface is pretty cool. But if all they are doing is providing you a web interface into the services, and not actually extending the network to you (which I have no idea how they could over a browser in any secure way and portable way). I really want to see a portable way to implement security so that I can Samba mount something via a web brower. Then essentially, this is just off the shelf software, put into an embedded system. While it's pretty neato, I'm guessing using apache, webmail, webmin, and a Java based SSH client, I could do all this with free software off the net.
Ask to see a demonstration, where you get to run SSH on the command line. Ask to do secure copies over it. Ask to see port forwarding done over it.
Ask to see it run your custom contact manager that your sales people use (Okay, that's what I'd ask for our sales people).
Ask to see the configurations that allow arbitrary port forwarding. Ask to see how they can forward information from Quake securely, because you'd hate to get fraged by somebody snoping the net... :-)
The clustering, and failover, and the fact that it's load tested, and has good support, make it extremely valuable. The fact that it has it's security tested, is very good. The actual functionality would be easy to construct with free software off the net as a cool project for a good IT staff.
If your planning on spending real money with them, request a demo unit to test with for a month. If they won't give one up, I'd pass.
Maybe they just run a Web version of VNC and let you have access to a client desktop. That'd be pretty cool. Not sure. Maybe it's cooler then I think, but I'm guessing it's not a true VPN solution, and if you want to do anything that isn't on their list of services, you'll need another solution to address that.
Kirby
I dont quite understand how a java applet configures the network interfaces on every OS to allow for VPN. Ive used various VPN solutions, from the ipsec in cisco routers to the pptp in linux and freebsd and l2tp between solaris and windows2000 clients. Also tried CIPE and didnt like the limitation to Windows2000 only.
pptp/l2tp work with microsoft clients quite well and I dont see any problems there. L2TP being more scalable is preferable but:
Ipsec is my favorite. It was designed from ground up as a VPN protocol rather than one protocol piggybacking on another. The list of ipsec support on freeswans page is huge for all OSes. It requires some downloads for windows machines, but face it, for any solution at all you will have to patch Windows.
Oh yeah, just make sure your home network's upload speed is good, and the VPN server is not Windows 2000 (just use linux on a Pentium1) and all is well.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
A "real" VPN gives you a full IP channel between the connected sites - whereas the HTTPS solutions only give you a terminal-server thingie. So this "second gen VPN" is not at all usable for Server2Server or Site2Site connections - only (human) Client2Server.
Second problem is that the client itself does not authenticate properly against the server. Problem again for nun-human client (usually).
Well, the way you get around man-in-the-mddle, in general, is with some form of pre-shared secrets. If you use asymetric keys for your pre-shared secrets, then the only thing you actually have to worry about is the safe, unmolested, broadcast of public-keys.
The last thing is that you can use a so-called "chain of trust" to safely broadcast public keys. All that you need is one public key on your computer that you absolutely trust, and then the holder of the matching private-key can "sign" other people's public keys (thus ensuring safe broadcast). This last is called a certificate authority (CA for short), and is the role that companies like verisign serve. You pay them to sign your public key, and then because I trust their key, I trust their signature, and I trust your public key. Now that I have your public key (and I know no one has messed with it in transit), and you have your private-key (and you know that no one else knows it), then we have a pre-shared secret, so we can't be man-in-the-middled.
That's the basic deal. The most interesting thing about it is that there needs to be at least one completely vulnerble transfer of information (receiving the public-key of the certificate authority), and this is usually done when your OS (or web browser) is being installed, presumably from a safe copy on a disk or some such... but if someone "man-in-the-middled" that original transfer of information (how do you man-in-the-middle a disk? well, swap the disks, maybe) then they've totally got your ass.
:Wq
Not an editor command: Wq
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!