SteelCentral Controller for SteelHead Mobile Deployments
  
SteelCentral Controller for SteelHead Mobile Deployments
The following types of users exist in a branch office and remote access user deployment scenario:
•  Overview of SteelCentral Controller for SteelHead Mobile Deployment
•  Multiple Mobile Controller Deployments
•  Ports Used with Mobile Controllers and SteelHead Mobiles
•  Interaction Between Mobile Controllers and SteelHead Mobile Clients
•  Location Awareness
•  SSL with SteelCentral Controller for SteelHead Mobile
•  Mobile Controller Best Practices and Other Considerations
This chapter requires that you be familiar with the SteelCentral Controller for SteelHead Mobile User’s Guide and the SteelCentral Controller for SteelHead Mobile Installation Guide.
Note: If you are using a release previous to SteelCentral Controller for SteelHead Mobile 4.0, see earlier versions of the SteelHead Deployment Guide and the SteelCentral Controller for SteelHead Mobile User’s Guide on the Riverbed Support site at https://support.riverbed.com.
Overview of SteelCentral Controller for SteelHead Mobile Deployment
Before you begin the installation and configuration process for the Mobile Controller, you must select a network deployment. This section describes the Mobile Controller deployment options. This section includes the following topics:
•  Basic Setup for Deploying Mobile Controller
•  Mobile Controller with VPN Deployments
•  Mobile Controller with Firewall Deployments
•  Branch Office and Remote Access Deployments
Basic Setup for Deploying Mobile Controller
The Mobile Controller ships with default policies. You can install and deploy the Mobile Controller without modifying the default policies, or you can modify them to suite 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 Mobile Controller using the default Initial policy provided, deploy the MSI package named Default. The default MSI package installs the default policies.
For the basic steps for how to install and configure the Mobile Controller and how to deploy the default MSI package to the SteelHead Mobile in your network, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
Mobile Controller with VPN Deployments
When you deploy Mobile Controller components in environments with VPNs, make sure that you do not optimize 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 Mobile Controller with a VPN as follows:
•  In-path
•  Out-of-path
Figure: In-Path Mobile Controller Deployment and VPN Tunnel shows a deployment in which both the mobile employee and the branch office use the same in-path SteelHead.
Figure: In-Path Mobile Controller Deployment and VPN Tunnel
Figure: Out-Of-Path Deployment Mobile Controller 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.
Figure: Out-Of-Path Deployment Mobile Controller Deployment and VPN Tunnels
For more information about policies and pass-through rules, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
Mobile Controller with Firewall Deployments
External firewalls, such as home firewall router appliances commonly found with broadband internet connections, do not require special settings for SteelHead Mobile 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 Mobile Controller 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 Mobile Controller from a remote site.
•  Ports 80 and 443 allow web access (including HTTP and HTTPS).
•  Port 7800 is the default port between the SteelHead Mobile and the remote SteelHead for all optimized TCP sessions.
•  You need to open Port 7810 on the network firewalls if you configure SteelHead Mobile to optimized connections with server-side out-of-path SteelHeads.
•  SteelHead Mobile uses Port 7870 to send statistics to the Mobile Controller.
If you are using a VPN originating on the client machine, you do not need to open any of these ports mentioned previously.
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 optimized by the local SteelHead. These users do not need the SteelHead Mobile software.
•  Local branch office users who also remotely access the network. These users need SteelHead Mobile software, and their systems are optimized by the server-side SteelHead.
Figure: Deploying SteelCentral Controller for SteelHead Mobile for Branch Office and Remote Users
If SteelHead Mobiles are connecting to a branch office that already has a SteelHead, you can enable enhanced autodiscovery on all SteelHeads. Autodiscovery allows the SteelHead Mobile to bypass the local SteelHead and optimize with the remote SteelHead at the data center.
If you configure the branch warming feature in SteelCentral Controller for SteelHead Mobile 3.0 or later, the SteelHead Mobile automatically detects the local SteelHead when it is in the branch office (using location awareness). The SteelHead Mobile does not consume a license when it is at the branch office. The SteelHead Mobile continues to optimize with the remote SteelHead, and it also warms the SteelHead Mobile RiOS data store, the local SteelHead, and the remote SteelHead.
For information about location awareness and branch warming, see Location Awareness. For information about enhanced autodiscovery, see Peering Rules and the SteelHead Management Console User’s Guide.
Multiple Mobile Controller Deployments
This sections describes the benefits of deploying more than one Mobile Controller, including deployment methods. This section includes the following topics:
•  Overview of Multiple Mobile Controller Deployments
•  Mobile Controller Concurrent User Limits
•  Configuring Multiple Mobile Controllers for Redundancy
•  Preparing to Join Mobile Controllers in a High-Availability Cluster
•  Sizing Considerations in a High-Availability Cluster
•  Endpoint License Pooling
•  Communication Between HA Cluster Members
Overview of Multiple Mobile Controller Deployments
If you deploy multiple Mobile 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 Mobile Controller. This limit is either 100, 4000, or 20,000 depending on the Mobile Controller model. For details, see Mobile Controller Concurrent User Limits.
•  Redundancy - In case of a network outage or a failure of a Mobile Controller, users can continue to receive a license from another Mobile Controller and gain optimized access to network resources.
By default, when you deploy multiple Mobile Controllers, they operate as separate entities, with their own SteelHead Mobile policies and concurrent user licenses. If you need identical policies across multiple Mobile Controllers, then you must individually update each instance. Concurrent user licenses on a failed Mobile Controller are not available for use by other Mobile Controllers. To ensure policies and licenses can be automatically synchronized and shared, deploy multiple Mobile Controllers in a high-availability cluster.
•  High-availability cluster - In case of a network outage or failure of a Mobile Controller, users can receive a license from another Mobile Controller and gain optimized access to network resources. If you configure a high-availability cluster, multiple Mobile Controllers automatically synchronize the SteelHead Mobile policies among themselves. Concurrent user licenses on all Mobile Controllers in a cluster are pooled together as a single resource that is available to all Mobile Controllers in the cluster. To configure two or more Mobile Controllers as a high-availability cluster, the controllers must be running SteelCentral Controller for SteelHead Mobile 4.0 or later.
With more than one data center, you are not required to deploy multiple Mobile Controllers. If you have multiple data centers, but only one Mobile Controller, the SteelHead Mobiles obtains a user license from the Mobile Controller no matter in which data center the Mobile Controller is located. The Mobile Controller is not directly involved with the optimized connections. After the SteelHead Mobile has a license, it optimizes connections with the SteelHeads in the data centers where the application servers are located.
You must distinguish between a deployment of multiple Mobile Controllers for redundancy and multiple Mobile Controllers as a high-availability cluster. If you are using SteelCentral Controller for SteelHead Mobile 4.0 or later, Riverbed recommends that you use a high-availability cluster. The following table shows the differences.
Requirement
Multiple Mobile Controllers
Multiple Mobile Controllers in a High-Availability Cluster (SteelCentral Controller for SteelHead Mobile 4.0 or later)
Federated SteelCentral Controller for SteelHead Mobile
Yes
Yes
Autonomous SteelHead Mobile policy management per SteelCentral Controller for SteelHead Mobile device
Yes
No
Global SteelHead Mobile policy management
Partial - requires manual policy synchronization between SteelCentral Controller for SteelHead Mobile devices.
Yes
Ability to service license requests on failure of the Mobile Controller
Partial - requires sufficient additional endpoint licenses per SteelCentral Controller for SteelHead Mobile device.
Yes
Scalable beyond 4000 concurrent SteelHead Mobile
Yes
Yes
Mobile Controller Concurrent User Limits
The following tables show the different Mobile Controller models and concurrent user limits.
Mobile Controller Appliance
Default Number of Concurrent Users
Maximum Concurrent Users
SMC-8650-BASE
40
4000
SMC-9000-BASE
40
20,000
Mobile Controller-v Licenses for VMware ESX Host and SteelHead EX 2.x
Default Number of Concurrent Users
Maximum Concurrent Users
SMC-VRT-V100
10
4000
SMC-VRT-V100-E
100
100
Mobile Controller-v Licenses for SteelHead EX 1.x
Default Number of Concurrent Users
Maximum Concurrent Users
VSMC-VSP
10
100
VSMC-VSP-E
100
100
Configuring Multiple Mobile Controllers for Redundancy
This section describes how to deploy two or more Mobile Controllers in a redundant configuration. This section requires that you be familiar with Multiple Mobile Controller Deployments.
Figure: Two Active Mobile Controllers shows Mobile Controller A and Mobile Controller B installed in the data center and configured with a basic setup. You can install Mobile Controllers in different data centers and continue to provide redundancy.
Figure: Two Active Mobile Controllers
Complete the following steps on both of the Mobile Controllers.
To configure two Mobile Controllers for redundancy
1. From the Mobile Controller Console, choose Manage > Policies.
2. Select an existing policy to edit, or create a new policy.
3. Select Endpoint Settings.
4. Select Controller Settings.
5. Under Controller Options, add the hostname or IP address of each Mobile Controller.
To avoid any potential issues with invalid certificates when deploying in an SSL environment, make sure that the name and IP address in the Mobile Controller list is consistent with the hostname field in the Mobile Controller configuration.
6. Under Controller Options, select Use Random Ordering of Controllers when Connecting to ensure a random but even distribution of clients per Mobile Controller.
Figure: Endpoint Settings Page
You can repeat these steps to add additional Mobile Controllers to the redundant configuration later. In each case, add the hostname or IP address of the additional Mobile Controllers to the Endpoint Settings in the relevant policy on all the Mobile Controllers in the redundant configuration.
To avoid clients receiving an untrusted certificate message, multiple Mobile Controllers in a redundant configuration must have the same Certificate Authority (CA) certificates. For more information, see Multiple Mobile Controllers and SSL.
Preparing to Join Mobile Controllers in a High-Availability Cluster
This section describes how to prepare two or more Mobile Controllers to form a Mobile Controller high-availability cluster. Mobile Controller clusters work together as a single entity with respect to client policies and some elements of the reporting. You can administer the Mobile Controller cluster from any member of the cluster.
Any client policy that you update on any cluster member automatically replicates and synchronizes with the other members of the cluster. Conflicts in which the same policy is inadvertently edited at the same time on different cluster members resolve automatically. Policies, packages, and some reporting statistics are automatically passed among cluster members. By default, this communication is through a TCP connection on port 7870.
Before a Mobile Controller can join a cluster, the Mobile Controller must:
•  have a valid IP address.
•  be able to ping other cluster members.
•  be running SteelCentral Controller for SteelHead Mobile 4.0 or later.
•  have its own set of licenses (CIFS, MAPI, concurrent user endpoint licenses, and so on).
•  have the same signing CA certificate as the other Mobile Controllers already in the cluster.
No geographic or latency restrictions exist between the nodes of a Mobile Controller cluster, because the Mobile Controllers in a cluster use the same protocol that a Mobile Controller uses with a SteelHead Mobile. Typically, the current connection between the Mobile Controller and the SteelHead Mobiles supports round-trip times in excess of 3 seconds.
After a Mobile Controller successfully joins the cluster, it is automatically populated with the packages, policies, and other client-related settings from the existing members of the cluster, and any existing settings are deleted. If you want to retain a copy of the original settings, make sure that you back up the Mobile Controller configuration before joining it to an existing cluster. You do not need to configure existing cluster members for a new Mobile Controller to join.
To set up a cluster, make sure that all Mobile Controllers meet the requirements listed above, choose one Mobile Controller to start with, and join the remaining Mobile Controllers to the cluster one-by-one.
The members of the cluster can be different types and models of Mobile Controller. For example, it is possible to have SMC-9000, SMC-8650 and a Mobile Controller-v all in the same cluster so long as they meet the requirements previously listed.
For information about how to join the Mobile Controller to the cluster, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
Sizing Considerations in a High-Availability Cluster
An HA cluster provides the ability to survive the failure of an individual Mobile Controller and potentially multiple Mobile Controller failures if you have a configuration that supports this (for example, the number of cluster members is greater than two).
Clustering also enables scalability for the number of supported endpoints. When multiple Mobile Controllers are joined together to form an HA cluster, the endpoint licenses that each Mobile Controller instance had prior to joining are put into a license pool. The license pool is available for all cluster members to use.
The following guidelines ensure a supported cluster configuration:
•  Riverbed recommends that a cluster of SMC-9000s does not exceed a total of 80,000 endpoint licenses and a cluster of SMC-8650 does not exceed a total of 20,000 endpoint licenses. A cluster of SMC-8650 with 20,000 endpoint licenses can be 5 x SMC-8650 with 4,000 licenses each. Another example is that you can have a cluster of 8 x SMC-8650 with 2,500 licenses each.
•  While you can have a mixture of different Mobile Controller platforms as part of a cluster, in a cluster that comprises a mixture of SMC-9000 and SMC-8650 models make sure that surviving cluster members can sustain the total number of endpoint licenses in the pool. For more information about pooling of endpoint licenses, see Endpoint License Pooling.
As a result of ongoing development and enhancements, this information is always subject to change. Riverbed recommends that you contact your Riverbed account team if you have a need to extend beyond these limits.
Endpoint License Pooling
There are many different scenarios related to HA clusters and endpoint licensing. To have a successful deployment, you must understand how these endpoint licenses move in and out of the pool. This section includes the following topics:
•  General Process for Pooled License Distribution
•  License Thresholds
•  Pooled License Counts During Cluster Member Failure
Every cluster member must have some number of endpoint licenses before it joins the cluster. Generally, a new Mobile Controller has a number of endpoint licenses included by default. The actual quantity of default endpoint licenses depends on the model of the Mobile Controller. Additional endpoint licenses are supplied in packs, with each pack containing 10 licenses. For example, to add 100 licenses to a Mobile Controller, you purchase ten packs. When a Mobile Controller joins a cluster, it gives licenses to the pool if it has more than 100 licenses (this is the default setting).
For example, if a Mobile Controller has 130 licenses when it joins the cluster, it gives 30 licenses to the pool and keeps 100 licenses. If a Mobile Controller has 60 licenses, it does not give any licenses to the pool when it joins the cluster. Giving licenses to the pool is known as check in.
You can change the default of how many licenses the Mobile Controller keeps initially with the following command on the Mobile Controller CLI:
(config) # cluster license initial-count <number>
For example:
(config) # cluster license initial-count 50
This command changes the default of licenses kept from 100 to 50. In that, when a Mobile Controller joins a cluster for the first time, if it has more than 50 endpoint licenses, it checks in the excess to the pool.
Note: Because the Mobile Controller is part of a cluster, you can enter the command once, and it automatically applies to all other members of the cluster.
General Process for Pooled License Distribution
A Mobile Controller cluster member assigns a license from the cluster pool to a SteelHead Mobile client when the client requests one.
When the license count of a Mobile Controller drops below a certain threshold, the Mobile Controller takes more licenses from the pool. Taking licenses from the pool is known as check out. If there are no licenses in the pool, the Mobile Controller continues to assign licenses on request until it either runs out of licenses or the pool is populated with more available licenses.
If there are no more licenses for the Mobile Controller and there are no licenses in the pool, the SteelHead Mobile client automatically contacts another Mobile Controller for a license (assuming the client is configured with multiple Mobile Controllers). If the other Mobile Controllers do not have an available license, the SteelHead Mobile client passes through connections while continuing to request a license at 10-second intervals. After a license is issued, any new connections are optimized.
There are a number of threshold settings related to license check out and check in.
When a Mobile Controller takes licenses from the pool, by default it checks out up to 100 licenses. You can change the default value with the following command on the Mobile Controller CLI:
(config) # cluster license checkout-count <number>
For example:
(config) # cluster license checkout-count 40
This command changes the default threshold from 100 to 40. In that, when a Mobile Controller reaches its low threshold value, it checks out 40 more licenses. For more information about thresholds, see License Thresholds.
Note: Because the Mobile Controller is part of a cluster, you can enter the command once, and it automatically applies to all other members of the cluster.
If the pool contains fewer licenses than the value for checkout-count, then the Mobile Controller takes all the remaining licenses, leaving the pool empty.
After a Mobile Controller has joined a cluster, checking in its excess licenses to the pool, it also detects how many licenses it has kept.
License Thresholds
You can configure the Mobile Controller with two thresholds associated with the license usage. The high threshold is when a Mobile Controller has assigned most of its licenses (in other words, license usage is high) and needs to check out more licenses from the pool.
The low threshold is when the number of assigned licenses drops (in other words, license usage is low). When a client machine running the SteelHead Mobile client goes offline for a while (shuts down, hibernates, disconnects from the network, and so on) the Mobile Controller that assigned the license to the client marks the license as available for another request. When the number of assigned licenses in the Mobile Controller drops beneath the low-threshold value, the Mobile Controller has an excess of available licenses and checks in excess licenses to the pool.
The high-threshold and low-threshold values are expressed as a percentage. These two values are by default 90 and 70 respectively. You can change the default value with the following command on the Mobile Controller CLI:
(config) # cluster license high-threshold <percentage>
and
(config) # cluster license low-threshold <percentage>
For example:
(config) # cluster license high-threshold 80
This command changes the default value from 90% to 80%. In that, when a Mobile Controller has assigned 80% of its initial count of licenses, it checks out more licenses from the pool as specified by the checkout-count value.
Note: Because the Mobile Controller is part of a cluster, you can enter the command once, and it automatically applies to all other members of the cluster.
Pooled License Counts During Cluster Member Failure
One of the benefits of using multiple Mobile Controllers in a cluster rather than having them as individual (autonomous) instances is that you can pool the licenses in such a way that they remain available with one surviving member in the cluster.
When a Mobile Controller fails as part of a cluster, any licenses that it has are automatically placed in the pool and can be used by surviving Mobile Controllers in the cluster.
When the failed Mobile Controller recovers, it automatically checks out licenses as described in Endpoint License Pooling.
In a cluster of mixed Mobile Controller models that include one or more SMC-9000-BASE and one or more SMC-8650-BASE, a failure scenario might result in fewer licenses being available due to the capacity of the Mobile Controller.
For example, consider a cluster composed of two Mobile Controllers (1 x SMC-9000-BASE and 1 x SMC-8650-BASE) each with 3,000 licenses. The cluster can support 6,000 endpoints connected concurrently. But if the SMC-9000-BASE were to fail, only 4,000 licenses are available from the SMC-8650-BASE because that is its maximum capacity.
Communication Between HA Cluster Members
Individual Mobile Controllers that are part of an HA cluster share the same SteelHead Mobile group assignments, policies, packages and other general configuration details. This information is sent to a new cluster member at the time of joining the cluster. During the lifetime of the cluster, any changes or additions to deployment configuration data that are completed on one of the cluster members is automatically communicated to the other cluster members. Likewise, the data associated with endpoint reports is also communicated between the cluster members.
As a new cluster member joins, there can be a comparatively large amount (10s of MB) of information sent from an existing member to the new member. There is no real time limit for this transfer to complete, but if the link between the members is low bandwidth and high latency (for example, a WAN link, then the initial transfer can take some time. The new member only transitions to the Connected, Synced status after the transfer has completed. When this status is reached, the member is fully operational within the cluster.
The cluster members use a persistent connection on TCP port 7870 to send the configuration and report data. This port is the same TCP port that is used by SteelHead Mobile to communicate with the Mobile Controller.
After the cluster members are all in sync, any configuration changes to one member are automatically broadcast to the other members. Even if there is no change, there is a poll every 5 minutes between random pairs of cluster members to compare the configuration between the pair. This ensures that any changes that have been missed are properly synced.
Ports Used with Mobile Controllers and SteelHead Mobiles
Mobile Controllers and SteelHead Mobile clients use the following TCP ports to communicate with each other:
•  7870 - reporting, statistics, license requests, and policy pushes between SteelHead Mobile and the Mobile Controller
This port is the default port for the communication between Mobile Controllers in a cluster.
•  80/443 - SteelHead Mobile software upgrade
•  80/443 - SteelHead Mobile upload of sysdump and tcpdump files using HTTP POST
Interaction Between Mobile Controllers and SteelHead Mobile Clients
This section describes some of the communication between SteelHead Mobile clients and the Mobile Controller. For more information about the terminology used in this section such as packages, policies, group assignments, and so on, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
A client machine with the SteelHead Mobile client software installed and enabled begins optimizing traffic after it has completed some initial interaction with a Mobile Controller. This initial contact with the Mobile Controller is triggered by the SteelHead Mobile client when it intercepts the first connection that is to be optimized.
The SteelHead Mobile begins by contacting a Mobile Controller that is already included on the list of controllers defined in the policy of the client. In a small deployment, there is probably only one Mobile Controller on the list. In a larger deployment, there might be more than one Mobile Controller. In such a case, the first Mobile Controller contacted is either the one at the top of the list (depending on the endpoint settings in the policy) or one that is chosen at random.
Contact is made through a TCP connection on port 7870. If there are no problems, the Mobile Controller issues a license. If the Mobile Controller does not have a license available, it instructs the client to contact the next Mobile Controller on its list. The SteelHead Mobile client continues through its list of Mobile Controllers, contacting each one in turn, until it receives a license. If no licenses are available, the client continues to try and contact Mobile Controllers every 20 seconds until it receives a license. After a license has been issued, the SteelHead Mobile client can continue to optimize any new connections that it intercepts that match relevant in-path rules in the client policy.
During this initial interaction after a license has been issued, the Mobile Controller takes the opportunity to check the policy that the client already has, and if a newer one exists, the controller automatically downloads it to the client. If a newer policy is downloaded, it takes immediate effect.
The Mobile Controller also checks the current version of the SteelHead Mobile client software, and if a newer version is available for the client, it might prompt the client to update its software. This step can occur differently depending on the way you have configured the endpoint settings for the client policy: for example, if you have a manual update process.
The connection on TCP port 7870 to the Mobile Controller from the SteelHead Mobile client is kept open to allow the client to send updates for reporting purposes (for example, optimized connections, data reduction, and so on). These updates are typically sent every 5 minutes.
If the end user logs off the client machine but there are still optimized connections in the background, the SteelHead Mobile client remains licensed and the connections continue to be optimized.
The Mobile Controller releases the client license under one of the following circumstances:
•  The client is shut down.
•  The client is disconnected from the network.
•  The client hands back the license because it has entered branch mode.
•  The connection to the Mobile Controller is lost for a continuous period of 24 hours.
•  The client hands back the license because it has no optimized connections of any kind for a period of 10 minutes.
In this last case, the client instantly requests a license once more if a new connection is intercepted for optimization.
Location awareness enables the SteelHead Mobile client to enter branch mode and may use branch warming. To learn more about these features and how it affects whether licenses are issued, see Location Awareness.
Location Awareness
This section describes how to configure location awareness on the SteelHead 6.0 or later and the SteelCentral Controller for SteelHead Mobile 2.0 or later. This section includes the following topics:
•  Overview of Location Awareness
•  Branch Warming
Overview of Location Awareness
Location awareness enables SteelHead Mobiles using SteelCentral Controller for SteelHead Mobile 2.0 or later to detect that they are in a branch office with a SteelHead, and it enables the branch office SteelHead to optimize the traffic of SteelHead Mobile clients.
When a SteelHead Mobile client is at a branch office that has a SteelHead, location awareness enables you to choose which device performs optimization. If the SteelHead Mobile performs optimization and is not in branch mode, the SteelHead Mobile warms its local RiOS data store. It also consumes a SteelHead Mobile license.
If a branch office and data center have a SteelHead, the SteelHead Mobile client can use location awareness to put the client into branch mode. In branch mode you can use the branch office SteelHead for optimization so that the end user does not consume a SteelHead Mobile license. But in that case, the SteelHead Mobile does not warm its local RiOS data store. Branch warming enhances location awareness by warming the SteelHead Mobile RiOS data store. By default, branch warming is disabled.
For more information about branch warming, see Branch Warming.
You can configure location awareness in the following ways:
•  Adapter-based location awareness - SteelHead Mobile optimizes traffic over only the adapters you specify. For example, most VPNs implement a virtual Ethernet adapter, but you can configure a rule to always optimize over VPN adapters and not over LAN adapters.
You cannot use adapter-based location awareness in:
–  remote offices with a small number of users and no branch office SteelHead.
–  hardware-based VPNs that do not terminate at the endpoint or client.
•  Latency-detection location awareness - Enables the SteelHead Mobile clients to optimize data only if latency to the closest SteelHead is greater than the threshold value. The default latency threshold value is 10 ms. To configure the value on the Mobile Controller, choose Policies > Location Awareness.
Branch Warming
This section describes how branch warming on the SteelHead Mobile interacts with the SteelHeads in the branch office and the data center. Branch warming requires the Mobile Controller and SteelHead Mobile to run SteelCentral Controller for SteelHead Mobile 3.0 or later, and the SteelHead to run RiOS 6.0 or later. Earlier versions of RiOS provide only location awareness, not branch warming.
This section includes the following topics:
•  Branch Warming and SteelHead Mobile Licenses
•  Branch Warming and Enhanced Autodiscovery
Branch warming works in conjunction with location awareness, enabling the SteelHead Mobile user to experience warm acceleration regardless of the location. Branch warming tracks the data segments created while a SteelHead Mobile is in a SteelHead-enabled branch office. Location awareness enables SteelHead Mobile to detect that it is in a branch office with a SteelHead, and it enables the SteelHead to optimize SteelHead Mobile traffic.
When you enable branch warming, SteelHead Mobile and the SteelHead cooperate to provide warm data for out-of-branch use. SteelHead Mobile shares segments with the SteelHead, thereby providing warm data wherever possible. Branch warming populates new data transfers that are occurring between the client and server, placing them into the RiOS data stores of SteelHead Mobile, the branch office SteelHead, and the server-side SteelHead.
When you download data from the server, the server-side SteelHead checks to see if either SteelHead Mobile or the branch office SteelHead has the data in its RiOS data store. If either device already has the data segments, the server-side SteelHead sends only references to the data. SteelHead Mobile and the branch office SteelHead communicate with each other to resolve the references.
Other clients at the branch office also benefit from branch warming, because data transferred by one client at a branch office populates the branch office SteelHead RiOS data store. Performance improves for all clients at the branch office because they receive warm performance for that data.
Figure: Branch Warming Example shows how branch warming enables mobile users to optimize traffic with the server-side SteelHead, while feeding segments that these users generate into the branch office SteelHead RiOS data store.
Figure: Branch Warming Example
For each data request, the server-side SteelHead checks whether the branch office SteelHead or the SteelHead Mobile RiOS data store making the request already has the data. If either one has the data, the SteelHead sends a reference to the SteelHead Mobile.
After the SteelHead Mobile gets the reference, it checks if its RiOS data store already has the reference. If it does, the SteelHead Mobile communicates with the server-side SteelHead that it need not send the data again. Simultaneously, the SteelHead Mobile checks whether the branch office SteelHead has the same reference. If the branch office SteelHead has the reference, the communication concludes; otherwise, the SteelHead Mobile shares the reference and data with it.
If the SteelHead Mobile does not have the reference or if its RiOS data store is deleted, it checks with the branch office SteelHead to determine if it has the reference. If it does, then the SteelHead Mobile takes the data segments from the branch-side SteelHead and communicates with the server-side SteelHead that it need not send the data again.
However, if the branch office SteelHead does not have the reference, the SteelHead Mobile requests the new data from the server-side SteelHead and shares the new data and reference with the branch office SteelHead so that at the end this communication, all three—the server-side SteelHead, the branch office SteelHead, and the SteelHead Mobile—have the reference.
Branch Warming and SteelHead Mobile Licenses
A SteelHead Mobile with branch warming enabled, inside a branch office using the branch SteelHead, uses one connection on the server-side SteelHead and one connection on the branch office SteelHead. It does not use a SteelCentral Controller for SteelHead Mobile license when in the branch mode. A single SteelCentral Controller for SteelHead Mobile license allows an unlimited number of connections.
The SteelHead Mobile uses a license only when it detects that the SteelHead with which it has optimized connections is not in branch mode.
Branch Warming and Enhanced Autodiscovery
Enable enhanced autodiscovery on all SteelHeads to ensure that branch warming is successful. By default, enhanced autodiscovery is enabled.
With enhanced autodiscovery enabled, the last SteelHead along the network path from the client to the server is automatically detected. Optimization then occurs between the SteelHead Mobile and the last SteelHead.
You can display, add, and modify enhanced autodiscovery settings on a SteelHead in the Optimization > Network Services: Peering Rules page.
SSL with SteelCentral Controller for SteelHead Mobile
SSL is a cryptographic protocol that provides secure communications between two parties over the internet. This section includes the following topics:
•  Traditional SSL Optimization
•  Advanced High-Security SSL Optimization
•  Configuring SteelCentral Controller for SteelHead Mobile and SSL
•  Using SteelHead Mobile with SSL Proxy Devices
•  Supported TLS Versions with SteelHead Mobile
•  Multiple Mobile Controllers and SSL
Typically in a web-based application, the client authenticates the server. You install an SSL certificate on a web server for the client to check the credentials of the certificate to make sure it is valid and signed by a trusted third party. Trusted third parties that sign SSL certificates are called CA certificates.
SteelHead Mobile 2.0 or later supports both traditional SteelHead SSL optimization and advanced high-security SSL optimization. Riverbed recommends that you use advanced high-security SSL optimization to protect your system. You must have RiOS 5.5 or later installed on your SteelHead to use advanced high-security SSL.
For more information about traditional SteelHead SSL optimization, see the SteelHead Deployment Guide - Protocols.
Traditional SSL Optimization
In traditional SteelHead SSL optimization with a SteelHead Mobile, a client-side SteelHead and the SteelHead Mobile can optimize traffic from any client. The traditional SSL security mode enables clients to optimize SSL traffic to all SteelHeads before RiOS 5.5. RiOS 5.5 or later can run in mixed deployments where one SteelHead is running RiOS 5.5 and another SteelHead in the network is running an earlier RiOS version.
In traditional SSL optimization, the client-side SteelHead runs on the client machine. An attacker can redirect network traffic to their SteelHead Mobile-enabled system and obtain the client session key sent from the server-side SteelHead, thereby decrypting the client traffic.
To prevent such man-in-the-middle attacks, and to ensure that SteelHead Mobile can decrypt traffic originating on only one machine, SteelCentral Controller for SteelHead Mobile 2.0 or later provides advanced high-security SSL optimization.
Advanced High-Security SSL Optimization
This section provides an overview of advanced high-security SSL optimization. Riverbed recommends that you use advanced high-security SSL optimization to protect your system.
Advanced SSL optimization:
•  enables SteelHead Mobile to optimize traffic from applications on the local system but not from any other system.
•  requires RiOS 5.5 or later. If you are running a version earlier than RiOS 5.5, SteelHead Mobile supports the traditional SteelHead SSL optimization.
•  has specific browser requirements. For the most current requirements, see the release notes.
Figure: Advanced High-Security SSL Optimization Using a SteelHead Mobile
Figure: Advanced High-Security SSL Optimization Using a SteelHead Mobile shows the steps in the advanced high-security SSL optimization using SteelHead Mobile. The steps are as follows:
1. SteelHead Mobile inserts a CA certificate into the trusted CA list using Internet Explorer or Firefox. The CA certificate is local to SteelHead Mobile.
2. When connections are initiated for SSL optimization, either on demand or proactively, the SSL inner channel is initiated.
3. SteelHead Mobile intercepts the client SSL connection from the client and terminates it.
4. The server-side SteelHead connects to the server and extracts the common name (CN) from the server certificate. CN is the DNS name or IP address.
5. The server-side SteelHead forwards the CN to the SteelHead Mobile.
SteelHead Mobile takes the CN and uses the CA certificate it injected to generate a signed server certificate that it passes to the application. The application can trust this certificate because it is signed by the CA that exists in its trusted certificates list.
Configuring SteelCentral Controller for SteelHead Mobile and SSL
This section provides an overview of the basic steps required to configure SSL using SteelCentral Controller for SteelHead Mobile 4.0 or later and the SteelHead 6.0 or later.
1. Obtain valid Enhanced Cryptography License Keys. This is required for every SteelHead that peers with SteelHead Mobile and Mobile Controller.
2. Configure the server-side SteelHead for SSL optimization with the SSL servers.
3. Configure a trust relationship between the Mobile Controller and the server-side SteelHead.
•  Export the SSL certificate from the Mobile Controller.
•  Configure a proxy certificate and private key for the SSL back-end server on the server-side SteelHead. This step enables the server-side SteelHead to act as a proxy for the back-end server, which is necessary to intercept the SSL connection and to optimize it.
•  Import the Mobile Controller CA certificate into the server-side SteelHead.
•  Export the server-side SteelHead peering certificate.
•  Add the server-side SteelHead peer to the Mobile Controller.
These mutual trust relationships establish secure inner channels between the Mobile Controller and the server-side SteelHead.
For information about the secure inner channel, see the SteelHead Deployment Guide - Protocols.
4. Create or edit the policy on the Mobile Controller so that it allows the SteelHead Mobile to intercept SSL connections.
5. Run a test to verify your configuration.
For information about configuring SteelCentral Controller for SteelHead Mobile and SSL, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
Using SteelHead Mobile with SSL Proxy Devices
With SteelHead Mobile 4.8 and later, the client can continue to provide SSL optimization in deployments in which you use SSL proxy devices. SteelHeads have been supporting optimized traffic of such deployments since RiOS 7.0. For more information about SSL deployments, see the SteelHead Deployment Guide - Protocols.
The overall configuration steps on the server-side SteelHead are exactly the same as for deployments in which there is a client-side SteelHead. When using SteelHead Mobile with SSL proxy devices, Riverbed recommends you use a minimum of RiOS 8.6.0 on the server-side SteelHead. The client-side configuration follows exactly the same steps as for general SSL optimization that are described in Configuring SteelCentral Controller for SteelHead Mobile and SSL, with the additional step of enabling the SSL Proxy Support option in the Mobile client policy.
When you configure this option with the Management Console, use the setting in the SSL section of the policy page. When configuring the policy using the CLI on the Mobile Controller, use the following command:
(config) # policy id <Policy ID> ssl proxy-support enable
For information about configuring SteelCentral Controller for SteelHead Mobile and SSL, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
Supported TLS Versions with SteelHead Mobile
By default, after you have completed the steps in Configuring SteelCentral Controller for SteelHead Mobile and SSL, the SteelHead Mobile client supports SSL connections that use TLS 1.0.
SteelHead Mobile 4.7 supports TLS 1.1 or 1.2. You must enable this capability using the following CLI command on the Mobile Controller:
(config) # policy id <id-number> ssl backend client-tls-1.2
Even though TLS 1.1 is not mentioned in the syntax of this command, using this command automatically enables support for both TLS 1.1 and 1.2.
You must make sure that the server-side SteelHead is configured to support TLS 1.2 by using the following commands on the SteelHead CLI:
(config) # protocol ssl backend server-tls-1.2
(config) # protocol ssl backend client-tls-1.2
For information about configuring SteelHeads and SSL, see the SteelHead Deployment Guide - Protocols, the SteelHead Management Console User’s Guide, and the Riverbed Command-Line Interface Reference Manual.
Multiple Mobile Controllers and SSL
An SSL configuration requires there be a trust relationship between the SteelHead Mobile and Mobile Controller. Without this trust relationship, the Mobile Controller cannot connect to and provide the SteelHead Mobile with configuration details.
Mobile Controllers in a redundant deployment or a high-availability cluster must have identical signing CA certificates. Having identical signing CA certificates is a prerequisite for a Mobile Controller to join a cluster with other Mobile Controllers. Mobile Controllers generate their own certificates. If the Mobile Controllers do not have the identical signing CA certificates, the SteelHead Mobile clients receive an untrusted certificate message.
For more information about configuring trust relationships for Mobile Controllers and SSL, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
Mobile Controller Best Practices and Other Considerations
This section lists best practices and includes other factors to consider when deploying Mobile Controller. This section includes the following topics:
•  Deployment Scenarios
•  Management Best Practices
•  Migration Mobile Controller Hardware
•  Licensing Best Practices
•  Antivirus Software
•  Signed SMB Support
•  SSL Client Authentication Support
•  SMC and Federal Information Processing Standard (FIPS)
•  Optimization Before User Log In
Deployment Scenarios
Consider the following types of deployment scenarios. Figure: Same SteelHead for Mobile Employees and Office Employees shows the same SteelHead for office and mobile employees—use fixed-target rules if the VPN ingress point is different.
Figure: Same SteelHead for Mobile Employees and Office Employees
Figure: Using One SteelHead for Mobile Employees and One SteelHead for Office Employees shows one SteelHead for mobile employees and one SteelHead for office employees.
Figure: Using One SteelHead for Mobile Employees and One SteelHead for Office Employees
Consider the following factors when deciding between using a SteelHead or SteelCentral Controller for SteelHead Mobile for a branch office:
•  SteelCentral Controller for SteelHead Mobile is best for small offices or offices with employees that spend the majority of their time out of the office.
•  SteelHead Mobile has an individual RiOS data store, requiring software on each laptop. A SteelHead has a shared RiOS data store.
•  SteelHeads ensure that a resource is dedicated to acceleration.
•  SteelHeads have features that are not available on SteelCentral Controller for SteelHead Mobile, such as VSP, prepopulation, and QoS.
•  You can deploy Mobile Controller appliances in the data center for easier accessibility and connectivity.
•  For installations where you expect to have fewer than 100 concurrent mobile users, consider installing Mobile Controller virtual edition using on the SteelHead in the data center.
If you are deploying the Windows operating system and software by cloning, you might run into an issue in which you create duplicate SIDs (ghosting). For more information, go to http://supportkb.riverbed.com/support/index?page=content&id=S15558.
Management Best Practices
The best practices to deploy and manage SteelCentral Controller for SteelHead Mobile are as follows:
•  Understand your mobile user population by geography, client type, and division.
•  Design systems that do not modify the default endpoint settings in the policy on the Mobile Controller.
If you decide to modify the default endpoint settings for groups of users, consider using fewer groups with more members, versus more groups with fewer members. For information about endpoint settings and policies, see the SteelCentral Controller for SteelHead Mobile User’s Guide.
•  Use MSI packages to push SteelCentral Controller for SteelHead Mobile software to clients. MSI packages can also enable rollback or upgrade, ensuring easy maintenance. Mobile Controller does support automatic upgrades to clients. For more information, go to https://supportkb.riverbed.com/support/index?page=content&id=S15231.
•  The initial installation of the client software cannot be pushed out from the Mobile Controller, but you can use Microsoft Windows Group Policy Object (GPO) to automatically push out and install client software for the first time to Windows clients. For more information, see Managing Mobile Clients Using Group Policy Templates at https://supportkb.riverbed.com/support/index?page=content&id=S14393.
•  Riverbed recommends that you back up your Mobile Controller-v using SCC. For more information about backing up and restoring Mobile Controller-v, especially when running on ESXi in VSP on SteelHead EX go to https://supportkb.riverbed.com/support/index?page=content&id=S17487.
•  Installation can be done in visible or invisible mode. In visible mode, end users have a Riverbed icon in the system tray that they can click for basic information and settings. In invisible mode, there are no visible icons to show that SteelCentral Controller for SteelHead Mobile is running on the end-user machine.
•  Do not use branch warming if you:
–  always want the client to optimize.
–  are using RiOS earlier than 6.0.
Migration Mobile Controller Hardware
Due to hardware refresh or replacement, you might need to migrate the configuration data (assignments, policies, packages, and so on) from your legacy Mobile Controller to a new hardware platform.
To perform a successful migration, use the following steps as guidance. Depending on the versions of software running on the old versus new Mobile Controller, you might not need to perform all the steps.
To migrate Mobile Controller hardware
1. Back up older Mobile Controller configurations to the SCC.
2. Install the new Mobile Controller running the same software version (or close to it) on the network, using the new IP address.
3. Manage the new Mobile Controller in the SCC.
4. Unplug the old Mobile Controller from the network.
At this time, the SteelHead Mobile clients that already have an active license continue to optimize, but they cannot upload any reports and no policies are pushed out.
5. Restore the old Mobile Controller configuration (including IP address) to the new Mobile Controller.
SteelHead Mobile client users connect automatically.
6. Upgrade the new Mobile Controller to the most current required version of software.
7. If needed, push out the software update to the Mobile Clients using the preferred method.
Note: You cannot migrate or transfer the endpoint license packs from old Mobile Controller platform to new Mobile Controller platform. Contact your Riverbed account team to obtain new license packs.
You can migrate to new hardware by temporarily creating a cluster of the two Mobile Controllers, allowing the policies and packages from the old Mobile Controller to move to the new Mobile Controller. After the transfer is complete, you can update the policies with the new Mobile Controller address to ensure that SteelHead Mobile clients connect to it. You can next remove the old Mobile Controller from the cluster. The main caveat to this method is that both Mobile Controllers must be running the same version of Mobile Controller software. You cannot use this method if the old Mobile Controller does not support the newer software version.
For information on another approach to migrate from one Mobile Controller hardware to a new Mobile Controller hardware, go to https://supportkb.riverbed.com/support/index?page=content&id=S24136.
Licensing Best Practices
The best practices for end-user licensing are as follows:
•  When considering licenses, do not count mobile employees who are behind the SteelHead and are using branch warming.
•  On the basis that not all mobile users are connected and active at the same time, estimate a 3:1 ratio of licensed versus connected users.
•  SteelHead Mobile is issued a license by the Mobile Controller only after SteelHead Mobile initiates its first optimized connection request.
•  For configurations in which you deploy multiple Mobile Controllers for high availability, use software 4.0 or later to allow pooling of end-user licenses from all the Mobile Controllers. Pooling of end-user licenses is an efficient use of the licenses if there is an unplanned Mobile Controller outage.
Antivirus Software
You can configure certain antivirus tools installed on a Windows or Mac platform to scan files that have recently changed. Configure the antivirus scanner to ignore the SteelHead Mobile RiOS data store.
Because SteelHead Mobile is constantly updating its RiOS data store when the user is sending and receiving data with optimized connections, the SteelHead Mobile RiOS data store is scanned frequently. This might lead to end-user performance problems. Because the SteelHead Mobile RiOS data store does not contain files of any type (just unique data segments), there is no need to scan it for viruses.
Signed SMB Support
You do not have to configure the SteelHead Mobile policy to support signed SMB connections. For traffic to optimize correctly:
•  SteelHead Mobile must run 3.1 or later.
•  you must configure the server-side SteelHead to optimize signed SMB traffic (joined to a Windows domain, configured with a suitable authentication mode, and so on).
If configured correctly, the Current Connections report on the server-side SteelHead shows CIFS-SIGNED.
With Mobile Controller 4.6 and later, Signed SMB connections are supported for SMB1, SMB2, and SMB3 dialects. Previous versions of Mobile Controller supported only SMB1 and SMB2.
While the SteelHead Mobile software is supported with Windows 8.1 operating systems, it is possible that the Windows client connects to a Windows 2012 or 2012-R2 file server using SMB3.02. This latest version of the SMB dialect is only fully supported in SteelHead Mobile 4.7 and later. If you are using an earlier version of the client, you can provide data reduction, but no Layer-7 latency optimization is possible. To ensure the correct behavior for SteelHead Mobile clients with version prior to 4.7, you must modify the policy for SteelHead Mobile to ensure the correct dialect is used.
Enter the following commands on the Mobile Controller substituting <id> for the relevant policy ID used by SteelHead Mobile:
no policy id <id> smb2 neg-whitelist enable
no policy id <id> smb2 basic-dialect
write memory
Note: This setting does not affect the optimization of the other SMB dialects that continue to receive full latency and data optimization benefits. You do not need this setting if the SteelHead Mobile client is 4.7 or later.
When using Windows 10 operating systems with the SteelHead Mobile client, you must use SteelHead Mobile 4.8 or later to ensure support for signed SMB or any other optimization benefits.
For more information about signed SMB support, see the SteelHead Deployment Guide - Protocols.
SSL Client Authentication Support
Mobile Controller 4.6 and later include support for SSL client authentication. This feature enables SteelHead Mobile to optimize traffic when the client PC is using a Common Access Card (CAC). Mobile Controller 4.6 and later support only client PCs running Windows 7 and using TLS 1.0.
To enable support for client authentication, you need to configure both the Mobile Controller and the server-side SteelHead.
Follow these steps on the Mobile Controller:
1. Enable SSL optimization.
2. Enable Client Certificate support.
3. Import the server-side SteelHead peering certificate.
Perform Steps 1 and 2 within the Mobile Controller policy assigned to the relevant client(s). Perform Step 3 on the Mobile Controller Management Console on the Configure > SSL > Peering page.
For information about configuring the server-side SteelHead and general information on CAC and client certificate support, see the SteelHead Deployment Guide - Protocols.
SMC and Federal Information Processing Standard (FIPS)
With Mobile Controller 4.6 and later, there is an option to deploy the Mobile Controller in a FIPS-compliant mode. The FIPS mode is only applicable to the Mobile Controller itself and does not apply to SteelHead Mobile that it might be responsible for.
Before enabling FIPS mode, the Mobile Controller must have a FIPS license installed.
Mobile Controllers that are part of an HA cluster can be FIPS enabled. Riverbed strongly recommends that you have all members of the cluster FIPS enabled rather than have a mixture of FIPS and non-FIPS Mobile Controllers.
You can enable FIPS mode only through the CLI of the Mobile Controller. For more information about the configuration of FIPS, see the FIPS Administrator’s Guide.
Optimization Before User Log In
As part of a SteelHead Mobile installation, several processes run in the background, including rbtsport. Windows or MacOS starts rbtsport when the host operating system starts up. Therefore, even before a user has logged in, the optimization service is already running. This means that the SteelHead Mobile can optimize a user login process. It can also provide optimization for other system processes that are occurring automatically in the background, such as backups.