About in-path rule settings

Enables the appliance to send email notifications and reminders to specified users. Reminder emails, if enabled, are sent every 15 days. You can adjust the frequency using the notify-timer <notification-time-in-days> command, but this feature is only available for pass-through rules. To use it, email notifications must be enabled in the administration settings.

Deactivates latency detection on matching connections.

These settings determine which client requests the rule applies to, based on their source and destination. The options vary slightly depending on the type of rule.

If you're using a virtual in-path setup with packet-mode optimization, do not use the wildcard All IP for source and destination as it can cause traffic loops between appliances. Instead, specify the local LAN subnet for proper configuration.

Specifies the subnet IP address and netmask for the source and destination network:

• Host label is a logical group of hostnames and subnets that represent a collection of servers or services. You can use both host labels and domain labels within a single in-path rule. RiOS versions 9.16.0 and later support IPv6 for host labels. RiOS versions prior to 9.16.0 require that you change the source to All IPv4 or a specific IPv4 subnet. Labels are optionally configured.

• SaaS application defines an in-path rule for SaaS application acceleration through SaaS Accelerator Manager (SAM). Requires that the appliance is registered with a SAM.

• Port specifies all ports, a specific port, or a port label. Valid port numbers are from 1 to 65535. For port labels, a list of configured labels appears.

Specifies a domain label for use in autodiscover, passthrough, or fixed-target rules. For a rule to apply, both the destination and domain label must match. If they don’t, the system checks the next rule. Domain labels only apply to HTTP and HTTPS traffic. If the destination port is set to All, the rule defaults to ports 80 (HTTP) and 443 (HTTPS). You can also set specific ports or use port labels. Domain labels support IPv6 starting in RiOS version 9.16.0.

Specifies a numerical ID from 0 to 4094 that identifies a specific VLAN. Enter all to match all VLANs, or enter untagged to match untagged connections. Passed-through traffic maintains existing VLAN tags. The default is 0.

Specifies the IP address for the remote peer appliance. When the protocol is TCP and you don’t specify an IP address, the rule defaults to all IPv6 addresses.

Specifies the target port number.

Settings are similar to those for target appliances.

Specifies a traffic protocol: TCP, UDP, or any.

Specifies a preoptimization policy Oracle Forms or SSL traffic:

• None disables preoptimization. However, if SSL acceleration is enabled, SSL preoptimization is always active for traffic on port 443—regardless of the in-path rule setting. To fully disable SSL preoptimization for port 443 disable SSL optimization on the client-side or server-side appliance, or set SSL Capability to No Check in the server-side appliance's peering rule.

• Oracle Forms over SSL enables preoptimization for both Oracle Forms traffic and SSL-encrypted traffic on secure ports. The latency optimization policy must be set to HTTP. IPv6 is not supported. If the server uses the standard secure port (443), this Oracle Forms rule must come before the default secure port pass-through rule in the rule list.

Activates latency optimization for the selected traffic type:

• Normal optimizes all supported traffic types. Use this option with Auto-Detect Outlook Anywhere Connections under MAPI settings to automatically detect Outlook Anywhere and HTTP traffic.

• Outlook Anywhere optimizes RPC over HTTP/HTTPS traffic. Best for environments using an IIS server as an RPC Proxy, or setups with asymmetric routing, connection forwarding, or Interceptor. Disable auto-detect under MAPI settings when using this option.

• Citrix enables latency optimization for Citrix-over-SSL traffic. The client-side appliance must have an in-path rule with the Citrix Access Gateway IP. This policy must be selected in both client-side and server-side in-path rules, and the preoptimization policy must be set to SSL. SSL must be enabled on the Citrix Access Gateway. On the server-side SteelHead, SSL must be enabled and the Citrix Access Gateway’s SSL certificate must be installed.

• Exchange autodetect optimizes latency for MAPI (Outlook Anywhere, MAPI over HTTP), Autodiscover, and HTTP traffic. SSL optimization must be enabled under MAPI settings. The Exchange Server’s SSL certificate must be installed on the server-side appliance.

Enables the selected optimization method:

• SDR-M performs all data reduction in memory, avoiding any disk read/write operations. This eliminates disk latency and can significantly boost LAN-side throughput. It's ideal for interactive traffic, small data transfers, or point-to-point replication during off-peak hours—especially when both the client-side and server-side appliances have similar performance capabilities.

Specifies whether the connection is accelerated by the cloud or passed through.

Resets preexisting matched connections to force reconnection.

Optimizes packet framing for Scalable Data Referencing (SDR) by using heuristics to decide the best time to flush TCP buffers. Here are the available modes:

• Never—Neural heuristics are calculated but not used. This mode disables the Nagle algorithm, making it ideal for chatty or real-time traffic where low latency is key.

• Always—All data goes through the Nagle algorithm to combine small packets for better fingerprinting. This is the default value. IPv6 is not supported.

• TCP Hints—Encodes partial frames or packets with the TCP PUSH flag without coalescing them. Neural heuristics are calculated but not applied. IPv6 is not supported.

• Dynamic—Automatically selects the best framing method based on traffic type, adjusting Nagle parameters in real time. IPv6 is not supported.

Enables visibility of how packets traversing the WAN are addressed:

• Correct addressing disables WAN visibility. SteelHead uses its own IPs and ports in TCP/IP headers for accelerated traffic in both directions. This is the default value.

• Port transparency preserves the server's port numbers in packet headers. This is useful for enforcing QoS policies based on destination ports. For IPv6, you must enable Enhanced IPv6 Auto-Discovery under Peering Rules. This allows existing WAN router rules (based on port numbers) to work without modification.

• Full transparency with reset preserves both IP addresses and port numbers and resets the initial connection probe. This mode supports fully transparent acceleration and ensures the secure channel can pass through firewalls.

Specifies the rule’s hierarchical position in the list. Place rules that use domain labels below others. The default rule can’t be removed.

Specifies a description for the rule to facilitate administration.

Enables or disables the rule.

About Host, Interface, and General Service Settings

Cloud acceleration lets you control whether connections to the cloud are optimized. You don’t need an in-path rule unless you want to apply acceleration to specific users only. Choose from these options:

• Pass Through—If the in-path rule matches, the connection isn’t optimized by the SaaS appliance, but it might be optimized by other appliances or passed through.

Domain labels and cloud acceleration can’t be used together. If a domain label is selected, the cloud acceleration option will automatically be set to Pass Through. Cloud acceleration can be set to Auto only when no domain label is used (set to n/a).

About Peering, Autodiscovery, In-Path Rules, and Service Ports

About in-path rule settings

Neural framing helps optimize the moment to flush TCP buffers by evaluating heuristics to maximize data transmission and minimize idle time. It is available for Auto-Discover or Fixed Target rule types and can be selected for the in-path rule.

• Never—Does not use the Nagle algorithm. Data is encoded immediately, without waiting for timers or buffer thresholds. This setting works well for time-sensitive or real-time traffic but doesn’t use neural heuristics.

• Always—Uses the Nagle algorithm (default setting). Data is passed to the codec, which attempts to combine small outgoing messages. A 6 ms timer helps consume leftover data. Neural heuristics are computed but not used. This mode is not compatible with IPv6.

• TCP Hints—For partial frame packets or packets with the TCP PUSH flag, data is encoded rather than immediately coalesced. Neural heuristics are computed but not used. This mode is not compatible with IPv6.

• Dynamic—Automatically adjusts the Nagle parameters based on the traffic type. This mode switches to the best algorithm based on traffic changes. This mode is not compatible with IPv6.

The best algorithm depends on traffic type, latency, compression, and SDR performance.

To set up neural framing for FTP or MAPI data channels, define an in-path rule with the respective destination port (FTP: 20, MAPI: 7830) and configure the data reduction policy.

About Peering, Autodiscovery, In-Path Rules, and Service Ports

About in-path rule settings

WAN Visibility Mode enables monitoring and management of traffic across the WAN, with different options for transparency:

• Port Transparency—Manage QoS policies based on destination ports. It allows WAN routers to classify traffic based on existing rules, without changes. Network analyzers between the SteelHeads can inspect traffic by its original TCP port number, but it doesn't provide client or server IP address visibility, nor client port visibility. This method is preferred when full address transparency isn't necessary, as it avoids potential networking risks.

• Full Address Transparency—Preserves client and server IP addresses and port numbers in the TCP/IP headers for traffic across the WAN. This option also preserves VLAN tags for optimized traffic while maintaining visibility into header fields. It is suitable for WAN routers and monitoring devices that need to inspect these fields. It requires symmetrical traffic flows between client and server—asymmetry can lead to connectivity issues.

• Full Transparency with Reset—Enables both full address and port transparency while resetting the connection probe to ensure firewalls don’t block the inner transparent connections. This option is ideal for networks using stateful firewalls, as it clears connections mapped to the same IP addresses and ports.

Full Transparency with a stateful firewall is supported. A stateful firewall examines packet headers, stores information, and then validates subsequent packets against this information. If your system uses a stateful firewall, use Full Transparency with Reset.

Port transparency is generally preferable unless you need full address visibility. Full transparency may lead to connectivity issues if network traffic is asymmetric. To enable full transparency globally by default, create an in-path autodiscover rule. Set the visibility mode to Full Transparency. Place this rule above the default in-path rule, but after the Secure, Interactive, and RBT-Proto rules. You can configure full transparency even if the server-side appliance doesn’t support it; however, in that case, the connection will not be transparent.

WAN visibility works only with autodiscover in-path rules, not with fixed-target rules or server-side out-of-path configurations.

The Top Talkers report provides WAN visibility by showing the most active users of WAN bandwidth, without needing to enable full WAN visibility.