You need to connect your branch offices, remote workers and telecommuters to your corporate network. They need secure access, 24 hours a day. You know you're going to use some sort of VPN - the question is, which one? IPSec was the big thing until recently, but SSL VPNs have been gaining in popularity in the past while. And are there any other options?
Unfortunately, the answer to which is best is 'it depends', and it's likely that you'll need more than one type to handle all your requirements. So let's do a quick round-up of the pros and cons of your main choices.
We've written about the benefits of SSL VPN before, but in a nutshell, it creates a secure session from your PC browser to the application server you're accessing. Actually, in most cases, to a proxy server, rather than to the end application.
Remember that if you're SSL-encrypting traffic end to end, it can't be seen by your firewall, Intrusion Prevention Systems, load balancing devices or any other network management systems. SSL on your servers also adds a fair bit of overhead, so it's probably best to offload this to a proxy anyway, and then route the traffic through your secure corporate LAN.
The upside is that as far as your users are concerned, it's just web access. There's no client software to load, and it can be used anywhere. On the minus side, if you need access to applications that aren't webified, you'll need something to act as an intermediary - that may include your email.
Also, it's all web traffic, so you can forget about Quality of Service or voice, and things like FTP and telnet aren't natively supported, though you should be able to use an applet to forward traffic to the right TCP port number and get access that way. Multicast won't work, and it's not a site-to-site option.
Tried and (almost) trusted, IPSec sets up a tunnel from the remote site - either a single user with client software on their PC or a network device terminating the tunnel for a whole office of users - into your central site. Once connected, you access your applications as normal, and it's immaterial whether they're web apps or not.
As the name suggests, it's designed for IP traffic, though that's not so much of an issue nowadays, but if you do have non-IP data, you'd need to configure up GRE tunnels separately and run IPSec over them, as you would to support multicast traffic.
A few companies have managed to combine features of SSL and IPSec, for example Net6 which is now owned by Citrix. Others are working to do the same.
Let's not forget MPLS VPNs. They're no good for remote access for individual users, but for site-to-site connectivity, they're the most flexible and scalable option. All the work is at the network level - users just see standard network connectivity - and they support QoS and multicast, so you don't have to worry about which apps people need access to. Of course, an MPLS network isn't as easy to set up or add to as the others, and it's bound to be more expensive.
So for individual users, who may well be travelling, or need access from hotels and Internet cafes, forget MPLS. IPSec is good if you have control over your users' PCs and can manage VPN client downloads and updates. It's also probably the only option for IT support staff, or anyone who needs to be able to access a wide range of applications and services. It scales quite well, and VPN concentrators at the central sites make it reasonably manageable.
SSL comes into its own where you have people accessing your network from non-corporate PCs: partners, suppliers, public Internet-connected PCs, that sort of thing, since there's no client software needed. Where your users just need access to web applications, it's easy, quick and cheap. If you can get an Internet connection, you can get to your data. But it may not handle all the applications your enterprise needs.
As soon as you have multiple users in one place, though, SSL may not be a good option. More efficient is to have one secure link from your remote site into the central office. If your traffic flows are such that all remote sites access your central site, in a hub-and-spoke arrangement, then IPSec is a good enough option. Your users don't have to bother with any client software, since it's all done in the network.
However, if every branch needs to communicate with every other, building a meshed arrangement is a real pain - especially if you need to set up GRE tunnels for non-IP or multicast traffic. Bear in mind that if you're deploying this and connecting over the Internet, you'll have no QoS guarantees, and your SLAs may not be suitable for business needs.
For large offices, or ones with complex requirements for connectivity or QoS, an MPLS VPN is likely to be your best bet. Even then, you'll need to make sure that your provider can support the levels of QoS you need, knows how to cater for multicast traffic, and can make changes in a sensible timeframe.
It's likely you're going to end up with a mix of VPN types to match your mix of network users. Don't try and force everyone to use the same access method, or you'll end up making life difficult for them and stressful for you. Define several categories of users, match each to the technology that suits it best, and you should find it becomes relatively straightforward to suit most needs.