As a market grows and matures, it looks for ways to secure its place in the overall market space that it occupies. That certainly is true for SSL VPNs. As this market grows to find its identity in the network access management environment, we see developers adding lots of functionality, as well as converging with other product types. While NAC is struggling with its own identity crisis, SSL VPNs simply are seeking their best deployment options.
VPNs and firewalls as combined gateways into the network are nothing new. IPsec, though, usually is the preferred venue for this type of implementation. However, there is a lot of discussion that IPsec is less desirable than SSL. That's really not entirely the case.
SSL VPNs have a special strength: low cost (or no cost) client-side implementations that use a standard protocol to communicate with web portals. In this case, the capability on the server side almost always is there by default, usually on port 443. The use of one-time, or "dissolvable," client-side agents is practical on SSL VPNs, and one of the best implementations of that technique is present in one of this month's products. IPsec client-side agents generally require more space, resources and effort to install, limiting their attractiveness for large-scale deployments.
On the other hand, IPsec VPNs make great point-to-point tunnels, often between two firewalls. These are implementations that are fewer in number, but often need to be more robust since they are online 24/7. Plus, they carry far larger traffic volumes than do smaller end-user deployments. In addition, unlike ad hoc end-user deployments, they tend to be mission-critical connections.
So, what does that mean to our products this month? Virtually all of our products terminate in some sort of portal. That portal is, to a greater or lesser degree, configurable as a convenient web entry point into the network. Access management capabilities range from internal to integration with Active Directory, RADIUS or the like. The trend here is a complete system on the edge of the network that can manage entry by authorized users and can be updated very rapidly and easily.
What to look for
The two key indicators that an SSL VPN might be a good option for your application are: large number of client computers, and short time (minutes or hours instead of days or months). If you have a lot of users, this probably is an indicator that an SSL VPN application is right for you.
There is a difference between simply connecting on port 443 (HTTPS) and using an SSL VPN. SSL is its own secure protocol, quite distinct from HTTPS. As such, it is easy with today's products to tie access to an access management system, such as Active Directory. This allows you to manage user access the same as if your users were on the network.
One area where this is becoming increasingly popular is wireless implementations. If the only way into the network over a wireless system is through an SSL VPN, you have increased security while maintaining simplicity for the end-user. You also are keeping things pretty simple for administrators - and that is the next criterion. Along with ease of deployment on the client-side, good access control and ease of building a portal with policy-based access control, look for ease of management.
Especially where management of a wireless network is involved, keeping the portal simple is a huge benefit, merging the security of the VPN with various security functions on wireless LANs.
How we tested
This was a case of gauging ease of use, deployment, level of performance and how feature-rich the product was.
We setup a test bed that represented a typical enterprise with Active Directory and some applications. We then setup the VPN portal, paying close attention to how hard it was to configure and integrate into our access management system. In some cases, the portal used its own access management system. Occasionally they did both.
We were concerned about how easy it was to add and remove users as well. This is one of the great potential strengths of SSL VPNs: while not quite pervasive computing yet, they allow a rough approximation by making adding and deleting users using group rights simple and fast.
Mike Stephenson contributed to this Group Test.
VPNs and firewalls as combined gateways into the network are nothing new. IPsec, though, usually is the preferred venue for this type of implementation. However, there is a lot of discussion that IPsec is less desirable than SSL. That's really not entirely the case.
SSL VPNs have a special strength: low cost (or no cost) client-side implementations that use a standard protocol to communicate with web portals. In this case, the capability on the server side almost always is there by default, usually on port 443. The use of one-time, or "dissolvable," client-side agents is practical on SSL VPNs, and one of the best implementations of that technique is present in one of this month's products. IPsec client-side agents generally require more space, resources and effort to install, limiting their attractiveness for large-scale deployments.
On the other hand, IPsec VPNs make great point-to-point tunnels, often between two firewalls. These are implementations that are fewer in number, but often need to be more robust since they are online 24/7. Plus, they carry far larger traffic volumes than do smaller end-user deployments. In addition, unlike ad hoc end-user deployments, they tend to be mission-critical connections.
So, what does that mean to our products this month? Virtually all of our products terminate in some sort of portal. That portal is, to a greater or lesser degree, configurable as a convenient web entry point into the network. Access management capabilities range from internal to integration with Active Directory, RADIUS or the like. The trend here is a complete system on the edge of the network that can manage entry by authorized users and can be updated very rapidly and easily.
What to look for
The two key indicators that an SSL VPN might be a good option for your application are: large number of client computers, and short time (minutes or hours instead of days or months). If you have a lot of users, this probably is an indicator that an SSL VPN application is right for you.
There is a difference between simply connecting on port 443 (HTTPS) and using an SSL VPN. SSL is its own secure protocol, quite distinct from HTTPS. As such, it is easy with today's products to tie access to an access management system, such as Active Directory. This allows you to manage user access the same as if your users were on the network.
One area where this is becoming increasingly popular is wireless implementations. If the only way into the network over a wireless system is through an SSL VPN, you have increased security while maintaining simplicity for the end-user. You also are keeping things pretty simple for administrators - and that is the next criterion. Along with ease of deployment on the client-side, good access control and ease of building a portal with policy-based access control, look for ease of management.
Especially where management of a wireless network is involved, keeping the portal simple is a huge benefit, merging the security of the VPN with various security functions on wireless LANs.
How we tested
This was a case of gauging ease of use, deployment, level of performance and how feature-rich the product was.
We setup a test bed that represented a typical enterprise with Active Directory and some applications. We then setup the VPN portal, paying close attention to how hard it was to configure and integrate into our access management system. In some cases, the portal used its own access management system. Occasionally they did both.
We were concerned about how easy it was to add and remove users as well. This is one of the great potential strengths of SSL VPNs: while not quite pervasive computing yet, they allow a rough approximation by making adding and deleting users using group rights simple and fast.
Mike Stephenson contributed to this Group Test.
