This chapter describes the following topics:
- SSL VPN resource access methods
- User authentication and access privilege management
- Security considerations
- Device placement and platform options
- Virtualization
- High availability
- Performance and scalability
This chapter discusses design issues you should consider when you build a Secure Socket Layer (SSL) Virtual Private Network (VPN) solution. Readers with experience managing a remote access solution, such as IP security (IPsec)–based remote access VPN, will recognize many common considerations that apply to SSL VPN-based remote access solutions. You will also encounter special considerations that pertain to the characteristics of SSL VPN technology.
No design can fit every network, because everyone's policy and business requirements are different. This chapter provides a list of common design aspects that you need to consider when you design and deploy an SSL VPN solution and possible solutions that you can apply.
Not All Resource Access Methods Are Equal
As mentioned in Chapter 2, "SSL VPN Technology," SSL VPN employs a variety of techniques, each of which has its unique characteristics in terms of user experience, user privilege requirements, and levels of access to the network resources. This is one of the major differences between SSL VPN and traditional remote access solutions, such as IPsec-based remote access VPN.
When you design an SSL VPN network, it is important to understand that not all access methods are equal and different access methods can be deployed to achieve different goals. You should ask yourself several questions when you evaluate SSL VPN technology and before you deploy an SSL VPN access method:
- What level of access does it provide?
- What operating systems does it support, for example, Windows, Linux, Mac, and mobile devices?
- What user privileges does it require?
- What level of access control can you apply?
Table 3-1 provides answers to common questions about SSL VPN access methods.
Table 3-1. SSL VPN Resource Access Methods
|
Client-Side Agent Required |
User Privilege Required |
Access Ubiquity |
Level of Access |
Granular Access Control |
|
|
Reverse-proxy |
No |
No |
Most ubiquitous |
Limited to applications that can be adapted to the web |
Very granular application-level control |
|
Port forwarding |
Yes; Java applet or ActiveX control |
Standard user; administrative privilege sometimes required |
Medium |
Limited mostly to static server-based TCP applications |
Medium; controls client/server application access |
|
Integrated terminal services |
Yes |
Might require administrative privilege |
Medium; mainly Windows systems |
Windows Terminal service, Citrix, VNC |
Medium; provide only terminal services |
|
Tunnel client |
Yes |
Typically requires administrative privilege to install the client for the first time |
Least ubiquitous; usually limited to corporate- owned/trusted systems |
Network-layer access; supports almost all applications |
Low |
This table compares the special characteristics of an SSL VPN to the traditional remote access VPN solutions. The same network resources can be accessed by using several resource access methods, each of which gives the user different experiences and calls for different system requirements. When you design your SSL VPN solution, it is important to understand this and choose the right access method for the right purpose. Here are some general considerations:
- The reverse-proxy-based method is the most ubiquitous access method and is good for almost all users. It can be applied to support mobile users or business partners who need to access a specific application through web browsers. The applications supported in this case are normally web-based e-mail applications such as Microsoft OWA (Outlook Web Access) and iNotes or a web-based business application, such as salesforce and Oracle iProcurement.
- As mentioned in Chapter 2, the reverse-proxy mode supports only a limited number of applications that can be made suitable for web use.
- The port-forwarding clients can be used to support business partners or contractors who need to access a very limited number of client/server applications that cannot be adapted to the web. As described in Chapter 2, when users use the port-forwarding technology, they often need to reconfigure the application to point to the local loopback address. This can be inconvenient for the users. As tunnel client technology has matured, many companies go directly to using tunnel clients to support various applications.
- Tunnel clients can be used to support power users that need full resource access. Because of their requirement of user privilege and their nature of full network access, tunnel clients are normally deployed on corporate-owned user systems, such as work laptops. Strong security control should be deployed to ensure the proper security posture of the endpoints and the security protection of the corporate networks.
- Some vendors do not use true reverse-proxy to support web browser–based access. A small applet (for example, ActiveX control) is downloaded and installed on the user's computer after the user signs on to the SSL VPN portal. The applet then intercepts the user's web request and sends it off to the established SSL VPN connection. These applet transactions can take place in a manner that is fairly transparent to the end user so that the user does not even realize that he or she is dealing with a client. In this case, you need to understand the operating system, user privilege, and browser setting requirements of the client-side applet (for example, allow ActiveX download and execution) to make sure that they fit into your deployment requirements.
Later sections of this chapter discuss the security and performance considerations of different access methods.