About Client Accelerator Deployments
Before you begin the installation and configuration process for the Client Accelerator, you must select a network deployment.
About Client Accelerator basic deployments
The Client Accelerator ships with default policies. You can install and deploy the Client Accelerator without modifying the default policies, or you can modify them to suit your environment.
If your network environment requires the deployment of multiple Microsoft Installer (MSI) packages, create the packages you need before you deploy the default package.
To install the Client Accelerator using the default Initial policy provided, deploy the MSI package named Default. The default MSI package installs the default policies.
About Client Accelerator with VPN deployments
When you deploy Client Accelerator components in environments with VPNs, make sure that you do not accelerate the VPN tunnel. If the VPN tunnel uses TCP for transport, add a pass-through rule to the policy for the VPN port number connected to by the client. Depending on your deployment scenario, this rule might be the first rule in the list.
VPNs that use IPsec as the transport protocol do not need a pass-through rule.
You can configure the Client Accelerator with a VPN as follows:
• In-path
• Out-of-path
Figure: In-path Client Accelerator deployment and VPN tunnel shows a deployment in which both the mobile employee and the branch office use the same in-path SteelHead.
In-path Client Accelerator deployment and VPN tunnel
Figure: Out-of-path deployment Client Accelerator deployment and VPN tunnels shows an in-path deployment in which the mobile employee and the branch office use the same SteelHead, but for the branch office SteelHead is in-path; for the mobile employees, it is out-of-path.
Out-of-path deployment Client Accelerator deployment and VPN tunnels
About Client Accelerator with firewall deployments
External firewalls, such as home firewall router appliances commonly found with broadband internet connections, do not require special settings for Client Accelerator when operating with VPN software on the client computer. The VPN software can have special requirements for external firewalls.
If you are using a firewall that does not allow outgoing connections, you must allow rbtdebug.exe, rbtmon.exe, rbtsport.exe, rbtlogger.exe, and shmobile.exe.
If you must access the Client Accelerator without the use of a VPN, both the client-side and server-side network firewalls must have some or all of ports 22, 80, 443, 7800, 7810, and 7870 open, as follows:
• Port 22 allows SSH access to the Client Accelerator from a remote site.
• Ports 80 and 443 allow web access (including HTTP and HTTPS).
• Port 7800 is the default port between the Client Accelerator and the remote SteelHead for all accelerated TCP sessions.
• You need to open Port 7810 on the network firewalls if you configure Client Accelerator to accelerated connections with server-side out-of-path SteelHeads.
• Client Accelerator uses Port 7870 to send statistics to the Client Accelerator Controller.
If you are using a VPN originating on the client machine, you do not need to open any of these ports mentioned previously.
About Branch office and remote access deployments
In a branch office and remote access user deployment scenario, there are the following types of users:
• Local branch office users with systems that are already accelerated by the local SteelHead. These users do not need the Client Accelerator software.
• Local branch office users who also remotely access the network. These users need Client Accelerator software, and their systems are accelerated by the server-side SteelHead.
Deploying Client Accelerator for branch office and remote users
If Client Accelerators are connecting to a branch office that already has a SteelHead, you can enable enhanced autodiscovery on all SteelHeads. Autodiscovery allows the Client Accelerator to bypass the local SteelHead and accelerate with the remote SteelHead at the data center.
If you configure the branch warming feature in Client Accelerator, the Client Accelerator automatically detects the local SteelHead when it is in the branch office (using location awareness). The Client Accelerator does not consume a license when it is at the branch office. The Client Accelerator continues to accelerate with the remote SteelHead, and it also warms the Client Accelerator RiOS data store, the local SteelHead, and the remote SteelHead.
About multiple Client Accelerator Controller deployments
If you deploy multiple Client Accelerator Controllers, you gain the following benefits:
• Federation—Different IT teams can manage designated areas.
• Scale—You can support a greater number of concurrently connected users. There is a limit of concurrent user licenses per controller. This limit is either 100, 4000, or 20,000 depending on the Client Accelerator Controller model.
• Redundancy—In case of a network outage or a failure of a controller, users can continue to receive a license from another one and gain accelerated access to network resources. By default, when you deploy multiple controllers, they operate as separate entities, with their own policies and concurrent user licenses. Concurrent user licenses on a failed Client Accelerator Controller are not available for use by other controllers. To ensure policies and licenses can be automatically synchronized and shared, deploy multiple Client Accelerator Controller in a high-availability cluster.
• High-availability cluster—In case of a network outage or failure of a Client Accelerator endpoints can receive a license from other controllers. If you configure a high-availability cluster, multiple controllers automatically synchronize policies among themselves. Concurrent user licenses on all controllers in a cluster are pooled together as a single resource that is available to all controllers in the cluster.
If you have more than one data center, you don’t need to deploy a controller at each one. If you have only one Client Accelerator Controller, the Client Accelerator endpoint software obtains user licenses from the controller no matter in which data center it is located.
Deploying multiple controllers for redundancy is slightly different than deploying multiple controllers as a high-availability cluster. We recommend that you use a high-availability cluster.