Auto-Discovery and Firewall Considerations

The most common reason that auto-discovery fails is because a device (typically security related) strips out the TCP options from optimized packets. Auto-discovery relies on using TCP options to determine if a remote SteelHead exists. Common devices that remove TCP options are firewalls and satellite routers.

The Riverbed Support site has knowledge base articles that show example configurations to allow Riverbed auto-discovery options through different firewall types.

To solve the problem, you can configure the devices to ignore or prevent stripping out the TCP option. Alternatively, you can use fixed-target rules on the SteelHeads to bypass the auto-discovery process.

For details, see Configuring a Fixed-Target In-Path Rule for an In-Path Deployment.

Consider the following when you install a SteelHead in which a stateful firewall exists in a multiple in-path environment. A stateful firewall on the LAN side of a SteelHead might not detect the entire TCP handshake conversation, and this causes the firewall to drop packets.

Figure 1‑2 shows an example when the SteelHead is at a transit site where traffic passes through multiple interfaces on the SteelHead, with a firewall located on the LAN. The firewall does not see the whole TCP handshake.

In this example, the stateful firewall detects the SYN packet to the server, but the SYN-ACK response from the server is intercepted at the SteelHead prior to reaching the firewall. When the server-side SteelHead originates the ACK to the server, the stateful firewall often denies the connection because it has not detected the proper SYN-ACK response.

Although the SteelHead can appear to be bridging traffic between its in-path interfaces, this is not true. The SteelHead always generates packets from the owner interface, but it intercepts packets on any in-path interface. This is the necessary behavior in asymmetric routing environments.

When you have a stateful firewall device in a multiple in-path environment, the goal of the SteelHead is to provide optimization for local traffic only at the transit site. The remote site usually has its own local SteelHead if optimization is required. To prevent the transit SteelHead from participating in the auto-discovery process, you can use peering rules to accept only probed SYNs destined to devices at the transit site. Contact Riverbed Professional Services for further options and solutions.