RE: SSL VPN

[Paul Hosking <paul.hosking-1 () nasa gov>]

On Tue, 2008-01-15 at 13:03 -0500, Malhoit, Lauren wrote:
> Question about the SSL VPN implementation...I know that with traditional
> VPN's you end up taking an IP from the company.  When you are using SSL
> VPN, do you keep your own IP from your ISP or do you still pick one up
> from the company?

It depends on what functionality you're choosing to use; "SSL VPN"
products tend to offer a bundle of fairly different remote access
solutions.  If you're doing something like web rewrites (kind of like
using a web-based web browser) then it's just the single IP address
involved.  If you use a full VPN like Juniper's Network Connect, then
you have an additional IP address assigned to a virtual adapter on the
user's system.

I've had a lot of positive experience with Juniper's IVE product line.
It is highly configurable and offers a number of different access
solutions (web rewrite, JAVA / ActiveX tunnels, RDP / Telnet / SSH
clients, web-based SMB / NFS file access, Network Connect - full VPN).
It has become something of a swiss army knife of remote access -
allowing us to tailor the solution to specific needs.  We can allow some
people full access and limit others to only the specific resource they
need.

The Network Connect feature is a nice full VPN solution.  A couple of
advantages that come to mind:  

*  Client  install / updates get pushed to the end user which avoids
issues with versions, service packs, and general software management.

*  VPN traffic plays nice in many "locked down" networks (even with
proxies), NAT'd environments, and generally difficult networks that have
tripped up other VPNs.  If the end user can log in, they can probably
get a VPN running.

*  Clients are available for Windows, MacOS X, and Linux (officially
RedHat but I know people using Debian, Ubunutu, and Gentoo).


Having said that... these advantages have a few niggling caveats:

*  Client install requires the end user has the appropriate (often
elevated) permissions to install the software.  And unless you configure
the client to automatically uninstall, the end user will end up with a
copy of each version of Network Connect on their system - cleanup is
their own responsibility.  Most users have the appropriate permissions
and few seem to care about software buildup.

*  There are still some networks that NC stumbles on.  AOL broadband is
an example - it looks like AOL is already doing something similar to
what the NC client tries to do and everything breaks until the NC client
gives up trying to establish a VPN tunnel.

*  Clients are only available for a subset of Windows (which Juniper is
expanding).  You can't use NC if Juniper hasn't built a client for your
platform.

One final word on that last point.  The protocol involved for Network
Connect is (AFAIK) proprietary.  So while most systems (desktops,
laptops, PDAs, suitably trained pigeons, etc.) can connect to an IPSEC
or PPTP VPN... only a few will be able to use the Network Connect
option.  That may or may not be important to you (or your users).


-- 
.: Paul Hosking

.: Email... paul.hosking () nasa gov

.: PGP KeyID: 576D2BC1
.: 37EC 086B F37E 8C4D 879E ABA2 F198 42FD 576D 2BC1