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
I said "Assuming you need your entire local network to appear", as in "We have an office over here, and an office across town, and need them connected securely." For individual users at home, set up a server at the office, and have them connect a tunnel to that with a login and password (every recent OS lets you do this). In other words, bite my shiny metal ass.
--That's the point of being root, you can do anything you want, even if it's stupid.
how can you believe anyone who publishes a
grey on white website is competent to swallow
their own saliva, let alone secure your
enterprise? or perhaps making an unreadable
web page is part of their security strategy?
it's steganography!
-I like my women like I like my tea: green-
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).
The original poster isn't some marketing guy tying to raise awareness of his company's new product, is he?
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
Hmmm. Isn't SSL vulnerable to man-in-the-middle attacks?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Believe it or not, my employer looked into doing just that to allow employees to check email from home!
Conformity is the jailer of freedom and enemy of growth. -JFK
And then, six minutes later, your employer said, "Holy shit, that's a terrible idea! Email can be handled with IMAP over SSL. Problem solved."
See? It all works out for the best.
I don't undestand what the big deal is with this - Cisco could easily create a java client that will work with their concentrators as well... Now will they do it? Maybe not, but just because it's java, it doesn't mean it's better. And from security perspective, just get an RSA/ACE server with SecuID tokens and you are done.
What I've been trying to do is build a VPN-style bridge between my internal network and outside windows machines.
So far, nothing in linux world seems to suit my needs, but the original principle was that I wanted to be able to tunnel my internal IPX/SPX connection (games) through TCP/IP on a VPN channel out to external machines.
For games where I want to play against my friends LAN-style but without sometimes boggy servers such as battle.net etc it would be nice. It also helps get around CD-key issues (I have the original disk, but want to use 2+ machines on my end when people are over).
I don't think the Java solution would cut it for this either, but perhaps somebody can offer a better solution (freeswan doesn't seem to do it, or I am using it wrong as well)
No, I'm not. I work for a medium-sized non-IT R&D lab, where Windows, Macs and various Unix/Linux machines are all well represented. We do have a unit from Neoteris to test for a month, but it isn't us end users who are testing it (yet).
With respect to some of the things that are being brought up in this thread, Getting mail through is a given, but our IT department would be asking for serious trouble if they greenlighted this for supporting IMAP and SMB mounts alone. What I'm concerned about is that ssh with X forwarding, Vnc, and other more specialized (and more useful) things like iTunes music sharing might be overlooked in the process.
taken! (by Davidleeroth) Thanks Bingo Foo!
You can nail down the environment by user group. So they can or cannot connect to: SMB shares, web resources, ssh sessions, etc.
They're getting more exotic in 3.2 and higher versions, allowing some NetBIOS activity and more of the traditional "Full Ride VPN".
They're still struggling with WebDAV for some reason, but overall making very quick and positive progress.
Also, once item of convenince is that it allows your field user to connect, even if they are doing so from behind a firewalled resource, 80/443 are generally available to people if they are on the net.
If you've ever had to troubleshoot a thousand people's IPsec client connections, you know what a pain firewalls in the middle of the stream can wreck.
Just some info.
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!
You mention you had Cisco CVPN 5000 Series; did you not get your free CVPN 3000 Series? Cisco recognized that they axed the 5000s a little too quickly after they bought Compatible Systems and was giving customers free CVPN 3000s as replacements.
The CVPN 3000 Series are nice; there are clients for just about every OS under the sun (Windows XP, 2000, Me/98, OS X, OS 8/9, Linux, Solaris) and it's a nice, centrally-managed solution where the client slaves everything from the head-end VPN Concentrator. Supports Split Tunneling, has a built in stateful firewall, and other goodies.
If you want secure remote access through a web page, you can use an unsigned Java ssh and/or Java VNC applet. But that's the only thing you can do without significant problems (well, to the degree that Java itself isn't already a problem).
For a true VPN, code running in the browser or invoked by the browser needs to get access to low-level networking, and there is no way in which that can be done without additional user intervention.
In the simplest case, you may be able to create a signed Java applet, but that will not simply run, it will at least require permission from the user to do something unsafe, and telling your users to give Java applets that kind of permission is not a good idea. Also, the Java APIs for building this kind of software are pretty limited, and I doubt you can do a true VPN implementation in Java.
Another choice would be ActiveX components. Again, they need to be signed and they require permission from the user. They could work in principle, but they only work for Windows. And you are probably going to have lots of support hassles anyway, with incompatibilities and software conflicts.
I think applet-based SSH and VNC are useful. But if you want a real VPN, your best bet is to go with an open standard like IPsec and to use a simple, stand-alone application with a good GUI to both start up the network connection and the VPN. That way, your users get secure access with a single click. What more do you eant?
There are SSL solutions. Look at
http://www.whalecommunications.com
They have a nice paper explaining SSL VPN's. These provide access to applications from a remote location. As I understand it they do not provide connection for a remote PC to the intranet. You get control of which applications are made available to which users.
Haha! No... they decided that Outlook Web Access w/ exchange 5.5 was the way to go...
At the time that Sun bought them (1999?), iPlanet did just this. It was realy great. The iPlanet server sat on the firewall, and was accessible via the web. Once you were authenticated according to whatever system your company used, you were provided links to the tools for which you were authorized.
When you clicked on the link to a service (for example an NT server running SQL Server in San Jose) the iPlanet server downloaded to your workstation a java "netlet" that formed a secure tunnel between your workstation and the iPlanet server, which forwarded your access to the target service. You were seamlessly connected to your desired service.
In the demo I saw we were able to access a variety of different applications, even including services that interfaced with applications on the user machine - like an IBM terminal app.
Once Netscape server was renamed iPlanet, this product seems to have disappeared, though it was originally the entire point of iPlanet. I've long wondered why so. I thought it was great, because a road warrior could get access to internal systems from any internet connection anywhere via a secure pipe.
I suppose writing the netlets could be problematic for a company that had a lot of different O.S. platforms, but most companies keep that to a minimum and iPlanet evidently had a good set of netlets predefined.
I expect that any new tool like this would be done using the Web Services paradigm, which trades yet-another-layer for a nice separation of application design from network and interface design.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
time to get a new employer, that's not saying much for your job security...
You, sir, are an astroturfer. Your user page shows that you have posted 6 comments on /., and each and every one of them contains a link to either the "hiperexchange.com" domain or the "seasidesw.com" domain.
So either you're a HiPerExchange astroturfer, or you are the most devoted fan a MS Exchange utility ever had. YHL. HAND.
Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins, Grumpy Watkins,
Ruby Sleeps