Category: riverbed

Encrypted MAPI & SSL Optimisation – Riverbed

When optimizing encrypted MAPI traffic, normal encryption methods are maintained between the Outlook client and client-side Steelhead appliance, and the Exchange server and server-side Steelhead appliance.

To ensure the optimized MAPI connection between the two Steelhead appliances is also encrypted, configure RiOS Secure Inner Channel.  For detail, see the Steelhead Appliance Deployment Guide.

To enable Outlook Anywhere optimisation it requires HTTPs Optimisation and SSL certificates to be installed. Once installed this allows the Riverbed devices to establish a Secure Inner Channel connection as per the below, thus allowing optimisation to occur.

Encrypted Connections between Client and Server

RB1

To enable the Steelhead appliance to optimize encrypted MAPI traffic between Outlook and the Exchange Server:

  1. On the server-side Steelhead appliance, choose Configure > Networking > Windows Domain.
  2. Join the server-side Steelhead appliance to the same Windows domain that the Exchange server belongs to and operates as a member server.
  3. Verify that Outlook is encrypting traffic.
  4. Enable the Encrypted Optimization option on client-side and server-side Steelhead appliances involved in optimizing MAPI encrypted traffic. Alternatively, use the CLI command protocol mapi encrypted enable.
  5. Ensure that both Enable AMPI Exchange 2003 and Enable MAPI Exchange 2007 Acceleration are enabled. In RiOSv6.1 and later, by default, these options are enabled.
  6. Restart the service on all Steelhead appliances that have the Encrypted Optimisation option enabled.

To Configure Outlook Anywhere

  1. Configure outlook Anywhere MAPI
    • On the client-side and Server-Side Steelhead Applicance, choose Configure > Optimisation > MAPI.
    • Select Enable Outlook Anywhere optimisation
    • Select Auto-Detect Outlook Anywhere Connections
    • Click Apply

RB2

Note: The corresponding CLI commands are [no] protocol mapi outlook-anywhr enable and [no] protocol mapi outlook-anywhr auto-detect.

  1. Configure an in-path rule for HTTPS connections to enable SSL Pre-optimisation only if the SH has not had port 443 removed from the port label Secure. Normally port 443 is removed as part of the simple SSL configuration. For more details, see Setting up a Simple SSL Deployment.

To configure an in-path rule for HTTPS connections:

  • Choose Configure > Optimization > In-Path Rules.
  • Select Add a New In-Path Rule.
  • Select Auto Discover from the Type drop-down list.
  • Specify port 443.
  • Select SSL from the Pre-optimization Policy drop-down list.
  • Click Add.

RB3

Note: You can configure an in-path rule for HTTPS connections to enable SSL preoptimisation through the CLI by entering in-path rule auto-discover preoptimization ssl dstport 443 rulenum end description SSLPreOptRule.

  1. Enable HTTP optimization the client-side and server-side Steelhead appliance. For details, see HTTP Optimisation.
  1. Enable SSL the client-side and server-side Steelhead appliance. The certificate and key from the Outlook Anywhere server must be installed on the server-side Steelhead appliance.
  • If you are using an internal CA, the CA root certificate must be installed.
  • If you are using encrypted MAPI you must enable secure inner channel. For details, see MAPI Optimization.

For some reason we have a duplication of Wildcard Cerficates, specifically for *.companyxyz.com.au

Due to this, it was necessary to create two additional rules on each client-side Steelhead deployment to ensure WebEx traffic and other ADFS traffic continued to work, albeit not optimised.

These rules are below.

RB4

RB5

LAN and WAN Cable Switched – Riverbed

In the first CLI session, run tcpdump on the LAN interface. In the second CLI session, run tcpdump on the WAN interface and in the third CLI session, ping the IP address fo the host which traffic doesn’t get optimised

Open up three sessions

Three CLI sessions via SSH to the RB for troubleshooting:

riverbed-sh#tcpdump -ni lan0_0 icmp

riverbed-sh#tcpdump -ni wan0_0 icmp

riverbed-sh#ping -I ip to ip

Troubleshooting Riverbed®Steelhead® WAN Optimizers

QoS – Cisco, Riverbed & Polycom

After many hours trying to sort this one out it would appear that a Riverbed Steelhead can’t easily optimise VC Traffic, as this traffic is already optimised by the Polycom device itself.  Sorry, that’s not to say I can’t, but i’d rather not enable the QoS on the Steelhead to solve this problem.

The environment:

H.323 protocol matched in the VC Class of traffic, in this case af41 (34). Packets tagged, no packets being dropped

Running 6CoS on Telstra Links (GWIP) which is really just IPMAN.

Host specific (/32) in-path optimisation rules on the Steelheads to ensure traffic to and from the VC units is bypassed.

Under normal circumstances traffic is passed through the Steelhead and the the size of packet increases, as riverbed encapsulates video packets, so i have decided to bypass video traffic on the steelhead, so that the encapsulation and other overheads can be avoided.

Fingers crossed….but i’m pretty happy it will work!