Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
The Internet Hardware Technology

Can Web Based VPN Solutions Do It All? 48

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?"
This discussion has been archived. No new comments can be posted.

Can Web Based VPN Solutions Do It All?

Comments Filter:
  • by shadwwulf ( 145057 ) on Wednesday August 13, 2003 @11:44PM (#6692234) Homepage
    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
    • "clientless" typically means you don't need to manually install 200 clients. the java client takes care of everything, and when you close the session, there is nothing extra remaining on your system.

      this is also handy if your admins don't like worrying about installing things on your CEO's palm pilot.
    • This is correct, and it must be the correct JVM. This has been an issue in our testing.
  • Clientless does work (Score:5, Informative)

    by buttahead ( 266220 ) <[tscanlan] [at] [sosaith.org]> on Wednesday August 13, 2003 @11:48PM (#6692255) Homepage
    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. [openreach.com] that did a nice job on clientless VPN, although their bread-n-butter was site to site VPN.
  • Is it a VPN? (Score:5, Informative)

    by ComputerSlicer23 ( 516509 ) on Thursday August 14, 2003 @12:01AM (#6692320)
    From what I've read, it's billed as an extranet. It's not a VPN according to some of the PDF's. Or rather, VPN's are a second generation security solution, and this is a step better then what third generation extranet's provided.

    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

    • Hmmm. Isn't SSL vulnerable to man-in-the-middle attacks?
      • by etcshadow ( 579275 ) on Thursday August 14, 2003 @11:01AM (#6695204)
        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.
        • 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)

          Hmmm,
          "Security Upgrade"
          Swap the disks AFTER THE FACT

          Performs normally on most original ....
          Recognizes "special" inputs such as sequence so that md5sum will report the specified value rather than computed value.
          Trust a hard-coded special certificate as well as the normal.

          Put the trojaned? executables into where backups are recovered from. Only later when recovery is
    • Re: SSH.

      Works great, configuration option to limit who/where ssh tunnels can be established.

      Use it to ssh to one of the boxes that I need to check at night. No problems from my end.

    • So if you want to SSH, you connect over SSL to it, and then log into a Web application and run the SSH client.

      Whaa? Why are you running ssh over a vpn? That sounds like about the most convoluted way of running ssh I've ever heard of.
      • I'm not saying it's ideal, I'm just saying, that's my take on how the product works. I don't think this product is a VPN. It sure looks like it's an SSL connection to a website, which serves up WebApps to you to run. That's all the product is from my reading. If that's what you want, it's great. However, that isn't a VPN. It's a VPAS (virtual private application server, and yes I just made that up). I don't think the product sounds very useful, I wouldn't pay money for it. That's my personal opinion
  • by mnmn ( 145599 ) on Thursday August 14, 2003 @12:03AM (#6692329) Homepage
    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.
    • Also tried CIPE and didnt like the limitation to Windows2000 only.

      Linux (and *BSD? and OSX?) supports CIPE. I'm fighting with a corporate firewall right now, otherwise I'd be using it.

      Question for those fiddling with a mixed environment; Are the CIPE implementations you've used compatable cross operating systems?

    • Ipsec is my favorite. [...] It requires some downloads for windows machines,

      That does not have to be the case if your read this [jacco2.dds.nl].

  • HTTPS != VPN (Score:4, Informative)

    by yabHuj ( 10782 ) on Thursday August 14, 2003 @04:03AM (#6693214) Homepage
    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).
    • Re:HTTPS != VPN (Score:1, Interesting)

      by Anonymous Coward
      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 tu
    • 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
  • Oddly enough, according to this article, [theregister.co.uk] Neoteris is one of a handful of SSL VPN companies that DOES have a product that "does it all". The others are Netilla and Aventail.

    The original poster isn't some marketing guy tying to raise awareness of his company's new product, is he?

    • The original poster isn't some marketing guy tying to raise awareness of his company's new product, is he?

      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 tr

      • 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/44
  • SSL VPN (Score:3, Interesting)

    by moonboy ( 2512 ) on Thursday August 14, 2003 @08:28AM (#6693991)
    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.
    • Re:SSL VPN (Score:2, Informative)

      by IPAQ2000 ( 585706 )

      if your organization is like ours and 95% of the time you use the VPN for MS Exchange access, check out the HiPerExchange [seasidesw.com]

      We have a netscreen 10 that has a VPN in it.. It was never implemented because the only access these
      people need is our exchange and the public folders. So there was no need to implement a VPN . and we use the Hiperexchnage [seasidesw.com]and it even MSblaster proof

      • You, sir, are an astroturfer. Your user page [slashdot.org] shows that you have posted 6 comments on /., and each [slashdot.org] and [slashdot.org] every [slashdot.org] one [slashdot.org] of [slashdot.org] them [slashdot.org] 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.

    • The reason that most of Neoteris' clients seem to be using it is for the same reason we are: the client doesn't have to be at their home/field machine, with a clear IPSec tunnel to the firewall.

      This is very attractive for field users, consultants (shudder) and obnoxious executives. They only have to remember a webaddress instead of "complicated" VPN setups. Have 443 access?, you're in.

      It is NOT a 100% or even in my estimation a 90% solution, but since it meets my 80-20 rule metric, it gets a nod.

      Person
  • SSL and VPN's (Score:3, Interesting)

    by freebase ( 83667 ) on Thursday August 14, 2003 @11:47PM (#6702980)
    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.

    • The whole idea of calling an SSL tunnel a "VPN" connection is really abusive marketing.

      You used to be able to say "OK, that's a VPN, it's something that provides a virtual network connection, you get network layer access over it". Now it's "OK, that's a VPN, now is it a network connection or is it a middleware tunnel or a proxy?".

      Also, this produces a false dichotomy between "IPSEC" and "SSL". There are VPN technologies that aren't built on top of IPSEC (PPPoE, PPTP, etc). There are other virtual proxy te
  • 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. Suppor
  • 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, bu
  • 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.
  • 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 w
  • Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net], Grumpy Watkins [uklinux.net],

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Working...