Limitations of Out-of-Path Deployments
Although the ease of deploying an out-of-path SteelHead might seem appealing, there are serious disadvantages to this method:
Connections initiated from the site with the out-of-path SteelHead cannot be optimized. Servers at the site detect the optimized traffic coming not from a client IP address, but from the out-of-path SteelHead primary IP address. In certain network environments, a change in the source IP address can be problematic. For some commonly used protocols, SteelHeads automatically make protocol-specific adjustments to account for the IP address change. For example, with CIFS, MAPI, and FTP, there are various places where the IP address of the connecting client can be used within the protocol itself. Because the SteelHead uses application-aware optimization for these protocols, it is able to make the appropriate changes within optimized connections and ensure correct functioning when used in out-of-path deployments. However, there are protocols, such as NFS, that cannot function appropriately when optimizing in an out-of-path configuration.
If you use out-of-path deployments, ensure correct operation by carefully selecting which applications you optimize. Even with protocols in which RiOS specifically adjusts for the change in source IP address on the LAN, there might be authentication, IDS, or IPS systems that generate alarms when this change occurs.
Because of the disadvantages specific to out-of-path deployments, and the requirement of using fixed-target rules, out-of-path deployment is not as widely used as physical or virtual in-path deployments. Out-of-path is primarily used as a way to rapidly deploy a SteelHead in a site with very complex or numerous connections to the WAN.