Configuring in-path optimization rules for policies

You configure in-path optimization rules for your Client Accelerator endpoint in the In-Path Rules tab of the Manage > Services: Policies page.

In-path rules determine the Client Accelerator endpoint behavior with SYN packets. In-path rules are an ordered list of fields a controller uses to match with Viewing Endpoint SYN packet fields (for example, source or destination subnet, IP address, VLAN, or TCP port). Each in-path rule has an action field. When a controller finds a matching in-path rule for a SYN packet, the controller treats the packet according to the action specified in the in-path rule.

In-path rule configurations differ depending on the action. For example, both the fixed-target and the autodiscovery actions allow you to choose what type of optimization is applied, what type of data reduction is used, what type of latency optimization is applied, and so on.

• Auto-Discover—Autodiscover is the process by which the controller automatically intercepts and optimizes traffic on all IP addresses and ports. By default, autodiscover is applied to all IP addresses and ports that are not secure, interactive, or default Riverbed ports. Defining in-path rules modifies this default setting. For details, see the SteelHead User Guide.

• Fixed-Target—Fixed-target rules specify that a controller always goes to a specific SteelHead first. Fixed-target rules can be used if the SteelHead is located out-of-path, or for troubleshooting purposes. In addition to the settings available for autodiscovery rules, you also must set a target SteelHead. You can also specify a backup SteelHead.

• Pass-Through—Pass-through rules identify traffic that is passed through the network unoptimized. You define pass-through rules to exclude subnets from optimization. Traffic is also passed through when the SteelHead is in bypass mode. Traffic may be passed through by the controller because of the pass-through rule, because the connection was established before the controller was put in place or before the service was enabled.

• Discard—Drops the SYN packets silently. The controller filters out traffic that matches the discard rules. This process is similar to how routers and firewalls drop disallowed packets: the connection-initiating application has no knowledge of the fact that its packets were dropped until the connection times out.

• Deny—Drops the SYN packets, sends a message back to its source, and resets the TCP connection being attempted. Using an active reset process rather than a silent discard allows the connection initiator to know that its connection is disallowed.

Select Start, End, or a rule number from the drop-down list. The controller evaluates rules in numerical order starting with rule 1. If the conditions set in the rule match, the rule is applied and the system moves on to the next packet. If the conditions set in the rule don’t match, the system consults the next rule. For example, if the conditions of rule 1 don’t match, rule 2 is consulted. If rule 2 matches the conditions, it is applied, and no further rules are consulted.

The default rule, Auto-Discover, which optimizes all remaining traffic that has not been selected by another rule, can’t be removed and is always listed last.

• IPv4—Prompts you for a specific IPv4 address. Use this format for an individual subnet IP address and netmask: xxx.xxx.xxx.xxx/xx

• Host Label—Choose a destination host label to selectively optimize connections to specific services. A host label includes a fully qualified domain name (hostname) and/or a list of subnets.

Host labels replace the destination. When you select a host label, RiOS ignores any destination IP address specified within the in-path rule.

• The Management Console dims the host label selection when there aren’t any host labels. Click Host Label to choose the Administration > Networking: Host Labels page for reference.

• SaaS Application—Defines an in-path rule for SaaS optimization through SteelConnect Manager. When you choose SaaS Application, you also need to specify an application (such as SharePoint for Business) or an application bundle (such as Microsoft Office 365). Only applications and application bundles set up for SaaS acceleration on SAM appear in the list. For detailed information on SaaS Accelerator, see Managing SaaS Accelerator and the SaaS Accelerator Manager User Guide.

• Domain Label—Select a domain label to optimize a specific service or application with an autodiscover, passthrough, or fixed-target rule. Domain labels are names given to sets of hostnames to streamline configuration.

An in-path rule with a domain label uses two layers of match conditions. The in-path rule still sets a destination IP address and subnet (or uses a host label or port). Any traffic that matches the destination first must also be going to a domain that matches the entries in the domain label. The connection must match both the destination and the domain label. When the entries in the domain label don’t match, the system looks to the next matching rule.

Configuring an in-path rule with the domain-label set to DISCARD/DENY/FORWARD as the first rule causes traffic to drop or pass through. This is because the rule matching terminates on the first rule. These rules must always be configured as a rule that falls back to an autodiscover or fixed-target rule to limit optimization that is dynamically based on an HNBI decision. When HNBI fails to match the domain label tied with the current matched rule, it will attempt to match the domain label tied to other rules, if present. If it hits an autodiscover rule after it first hits a fixed-target rule, the system passes through traffic.

Specify the destination port number, port label, or All. Click Port Label to choose Administration > Networking > Port Labels page for reference.

• None—If the Oracle Forms, SSL, or Oracle Forms-over-SSL preoptimization policy is enabled and you want to disable it for a port, select None. This is the default setting.

Port 443 always uses a preoptimization policy of SSL even if an in-path rule on the client-side SteelHead sets the preoptimization policy to None. To disable the SSL preoptimization for traffic to port 443, you can either:

• Oracle Forms over SSL—Enables preoptimization processing for both the Oracle Forms and SSL encrypted traffic through SSL secure ports on the client-side SteelHead. You must also set the Latency Optimization Policy to HTTP. This policy is not compatible with IPv6.

If the server is running over a standard secure port—for example, port 443—the Oracle Forms over SSL in-path rule needs to be before the default secure port pass-through rule in the in-path rule list.

• Outlook Anywhere—Enables Outlook Anywhere latency optimization. Outlook Anywhere is a feature of Microsoft Exchange Server that allows Microsoft Office Outlook clients to connect to their Exchange servers over the internet using the Microsoft RPC tunneling protocol. For details about Outlook Anywhere, see the SteelHead User Guide.

• Citrix—Activates Citrix-over-SSL optimization on connections matching this rule. This policy is not compatible with IPv6. Add an in-path rule to the server-side SteelHead that specifies the Citrix Access Gateway IP address, select this latency optimization policy on the server-side SteelHeads, and set the preoptimization policy to SSL. The server-side SteelHeads must be running RiOS 7.0 or later. The preoptimization policy must be set to SSL.

SSL must be enabled on the Citrix Access Gateway. On the server-side SteelHead, enable SSL and install the SSL server certificate for the Citrix Access Gateway.

The server-side SteelHeads establish an SSL channel between themselves to secure the optimized Independent Computing Architecture (ICA) traffic. End users log in to the Access Gateway through a browser (HTTPS) and access applications through the web interface. Clicking an application icon starts the Online Plug-in, which establishes an SSL connection to the Access Gateway. The ICA connection is tunneled through the SSL connection.

The SteelHead decrypts the SSL connection from the user device, applies ICA latency optimization, and re-encrypts the traffic over the internet. The server-side SteelHead decrypts the optimized ICA traffic and re-encrypts the ICA traffic into the original SSL connection destined to the Access Gateway.

• Exchange Autodetect—Automatically detects MAPI transport protocols (Autodiscover, Outlook Anywhere, and MAPI over HTTP) and HTTP traffic. For MAPI transport protocol optimization, enable SSL and install the SSL server certificate for the Exchange Server on the server-side SteelHead.

To activate MAPI-over-HTTP bandwidth and latency optimization, you must also choose Manage > Services: Policies and select the Protocol Settings tab, select the MAPI tab, and click Enable MAPI over HTTP optimization on the server-side SteelHead. The server-side SteelHeads must be running RiOS 9.2 or later for MAPI-over-HTTP latency optimization.

• None—Don’t activate latency optimization on connections matching this rule. For Oracle Forms-over-SSL encrypted traffic, you must set the Latency Optimization Policy to HTTP.

Optionally, if you have selected Auto-Discover or Fixed Target, you can select a neural framing mode for the in-path rule. Neural framing enables the system to select the optimal packet framing boundaries for Scalable Data Referencing (SDR). Neural framing creates a set of heuristics to intelligently determine the optimal moment to flush TCP buffers. The system continuously evaluates these heuristics and uses the optimal heuristic to maximize the amount of buffered data transmitted in each flush, while minimizing the amount of idle time that the data sits in the buffer.

• Never—Don’t use the Nagle algorithm. The Nagle algorithm is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network. It works by combining a number of small outgoing messages and sending them all at once. All the data is immediately encoded without waiting for timers to fire or application buffers to fill past a specified threshold. Neural heuristics are computed in this mode but are not used. In general, this setting works well with time-sensitive and chatty or real-time traffic.

• Always—Use the Nagle algorithm. This is the default setting. All data is passed to the codec, which attempts to coalesce consume calls (if needed) to achieve better fingerprinting. A timer (6 ms) backs up the codec and causes leftover data to be consumed. Neural heuristics are computed in this mode but are not used.

For different types of traffic, one algorithm might be better than others. The considerations include latency added to the connection, compression, and SDR performance.

To configure neural framing for an FTP data channel, define an in-path rule with the destination port 20 and set its data reduction policy. To configure neural framing for a MAPI data channel, define an in-path rule with the destination port 7830 and set its data reduction policy.

After you subscribe to a SaaS platform and enable it, ensure that cloud acceleration is ready and enabled. When cloud acceleration is enabled, connections to the subscribed SaaS platform are optimized by the SteelHead SaaS. You don’t need to add an in-path rule unless you want to optimize specific users and exclude others. Select one of these choices from the drop-down list:

• Pass Through—If the in-path rule matches, the connection is not optimized by the SteelHead SaaS, but it follows the other rule parameters so that the connection might be optimized by this SteelHead with other SteelHeads in the network, or it might be passed through.

Domain labels and cloud acceleration are mutually exclusive. When using a domain label, the Management Console dims this control and sets it to Pass Through. You can set cloud acceleration to Auto when domain label is set to n/a.

Using host labels is not recommended for SteelHead SaaS traffic. This applies to the legacy cloud acceleration service and not the SaaS Accelerator.

WAN visibility mode is configurable for Auto-Discover and Fixed-Target rules. To configure WAN Visibility for Fixed-Target rules, you must use CLI commands. For details on WAN Visibility CLI commands, see the Riverbed Command-Line Interface Reference Manual.

You configure WAN visibility on the client-side controller (where the connection is initiated). The server-side SteelHead must also support WAN visibility.

• Correct Addressing—Turns WAN visibility off. Correct addressing uses SteelHead IP addresses and port numbers in the TCP/IP packet header fields for optimized traffic in both directions across the WAN. This is the default setting.

• Port Transparency—Port address transparency preserves your server port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. Traffic is optimized while the server port number in the TCP/IP header field appears to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields.

Use port transparency if you want to manage and enforce policies that are based on destination ports. If your WAN router is following traffic classification rules written in terms of client and network addresses, port transparency enables your routers to use existing rules to classify the traffic without any changes.

Port transparency enables network analyzers deployed within the WAN (between the SteelHeads) to monitor network activity and to capture statistics for reporting by inspecting traffic according to its original TCP port number.

Port transparency only provides server port visibility. It does not provide server IP address visibility. For the Client Accelerator Controller, the client IP address and port numbers are preserved.

• Full Transparency—Full address transparency preserves your client and server IP addresses and port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. It also preserves VLAN tags. Traffic is optimized while these TCP/IP header fields appear to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields.

If both port transparency and full address transparency are acceptable solutions, port transparency is preferable. Port transparency avoids potential networking risks that are inherent to enabling full address transparency. For details, see the SteelHead Deployment Guide.

However, if you must see your client or server IP addresses across the WAN, full transparency is your only configuration option.

Enabling full address transparency requires symmetrical traffic flows between the client and server. If any asymmetry exists on the network, enabling full address transparency might yield unexpected results, up to and including loss of connectivity. For details, see the SteelHead Deployment Guide.

RiOS includes an option for using Full Transparency with a stateful firewall. A stateful firewall examines packet headers, stores information, and then validates subsequent packets against this information. If your system uses a stateful firewall, this option is available:

• Full Transparency with Reset—Enables full address and port transparency and also sends a forward reset between receiving the probe response and sending the transparent inner channel SYN. This option ensures the firewall does not block inner transparent connections because of information stored in the probe connection. The forward reset is necessary because the probe connection and inner connection use the same IP addresses and ports and both map to the same firewall connection. The reset clears the probe connection created by the SteelHead and allows for the full transparent inner connection to traverse the firewall.

For details on configuring WAN visibility and its implications, see the SteelHead Deployment Guide. To turn full transparency on globally by default, create an in-path auto-discover rule, select Full, and place it above the default in-path rule and after the Secure, Interactive, and RBT-Proto rules. You can configure a SteelHead for WAN visibility even if the server-side SteelHead does not support it, but the connection is not transparent. You can enable full transparency for servers in a specific IP address range and you can enable port transparency on a specific server. For details, see the SteelHead Deployment Guide.

• The Top Talkers report displays statistics on the most active, heaviest users of WAN bandwidth, providing some WAN visibility without enabling a WAN Visibility Mode.

The controller will cache the changes you make to a policy across multiple tabs, until you click Update Policy or go to a different page.