This section describes some of the common problems that are inherent to transparent addressing:

The problems described in this section occur with all proxy-based solutions.

Transparent addressing can have an impact on systems that monitor or alter the state of TCP connections on the WAN for reporting, security, or congestion control. For example, some stateful firewalls might detect the difference in sequence numbers between the auto-discovery phase and the data transmission phase of fully transparent connections, and react by raising alarms or disallowing connections between the SteelHeads. Using the Full Transparency with Forward Reset mode might alleviate this issue, but might also cause monitoring systems to record more TCP connection activity across the WAN than is actually present.

Transparent addressing also does not work with intrusion detection and prevention systems that perform stateful packet inspection. SteelHeads use a proprietary Riverbed application protocol to communicate. When intrusion detection and prevention systems perform stateful packet inspections, they expect an application protocol based on the port numbers of the original client and server connection. When these systems discover the Riverbed proprietary application protocol, they perceive this as a mismatch, and log the packet, drop it, trigger an alarm, or all of the above.

You can avoid these problems with stateful systems, which are inherent to transparent addressing, by using correct addressing.

This section describes some of the common networking problems that are inherent to transparent addressing. This section includes the following topics:

Enabling full address transparency increases the likelihood of problems inherent to asymmetric routing.

For a connection to be optimized, its packets to and from its LAN hosts must pass through either:

When full address transparency is used, WAN-side routers detect the client or server addresses in the optimized connections packets, and use those address to make routing decisions. If the router has a route to the client or server that does not pass through a SteelHead, and it transmits the optimized packets on that route, the optimized and LAN-side connections might fail.

Figure 3‑5 shows a network in which a link to the server location does not have a SteelHead installed. Depending on the exact routing configuration in the Figure 3‑5, it is possible that correct addressing can work, but full transparency does not, because the optimized traffic from the client side might be sent through the link that does not have the SteelHead.

To ensure that all required traffic is optimized and accelerated, you must install a SteelHead on every possible path that a packet traverses. Connection forwarding must also be configured and enabled for each SteelHead.

If there is a path that does not have a SteelHead, it is possible that some traffic will not be optimized.

You can avoid this type of asymmetric routing problem, which is inherent to transparent addressing, by using correct addressing.

For information about connection forwarding, see Connection Forwarding. For information about how to eliminate asymmetric routing problems, see Troubleshooting SteelHead Deployment Problems.

Enabling transparent addressing introduces the likelihood of misrouting optimized traffic in the event of a SteelHead failure.

SteelHeads use a proprietary Riverbed protocol to communicate. Normally, a functioning server-side SteelHead receives a packet from the WAN, and converts the packet to its native format before forwarding it to the server.

In an environment in which transparent addressing is used, if the server-side SteelHead is not functioning, or if a packet is routed along an alternative network path, the packet might go from the client-side SteelHead directly to the server. Because the server-side SteelHead does not have an opportunity to convert the packet to its native format, the server cannot recognize it, and the connection fails.

In most cases, the server is able to detect whether a packet contains invalid payload information or, in this case, has an unrecognizable format, and rejects the packet. Assuming that the server does detect that the format is unrecognizable, the server rejects the packet and resets the TCP connection. If the client TCP connection is reset, the client can reconnect to the server without any SteelHead involvement.

This type of traffic misrouting can occur in both directions across the WAN. If the client-side SteelHead experiences a failure, or if an alternate network path exists from the server to the client, traffic might go from the server-side SteelHead directly to the client.

Figure 3‑6 shows traffic being misrouted when the server-side SteelHead fails on a network using transparent addressing.

The failure scenario follows these steps:

You can avoid this type of misrouting problem, which is inherent to transparent addressing, by using correct addressing.

If correct addressing is configured for this scenario, the client-side SteelHead detects that the server-side SteelHead has failed. The client-side SteelHead automatically resets the client connection, allowing the client to connect directly to the server without SteelHead involvement.

If your firewall inspects traffic between two SteelHeads, there are addressing issues that you must be aware of.

The following table summarizes configuration issues that might arise when a firewall inspects traffic between two SteelHeads. Firewall behavior differs, depending on the type of addressing being used. A Yes value indicates that your firewall will perform as expected.

For information about stateful firewalls and intrusion detection and prevention systems, see Stateful Systems.

Network address translation (NAT) affects the addresses the SteelHead uses in different ways, depending on which addressing mode is in use. This section provides several NAT deployment scenarios using various addressing modes:

Figure 3‑8 shows full transparency addressing mode. The client and server IP addresses are preserved, and the presence of the full transparency TCP is a signal to the server-side SteelHead that it can use the addresses arriving from the WAN. This ensures that any translation is preserved for optimized traffic.

When you use a fixed-target rule to the primary IP address of a remote SteelHead, the remote SteelHead makes a connection to the destination IP address detected on the initiating SteelHead. Figure 3‑9 shows that the source address is the primary IP address of the remote SteelHead.

When you use a fixed-target rule to the in-path IP address of a remote SteelHead, the remote SteelHead makes a connection to the destination IP address detected on the initiating SteelHead. The remote SteelHead also uses the same source address detected on the initiating SteelHead.

In the example, the out-of-path packet flow on incoming connection requests is very similar to an established in-path partnership. However, there is an important distinction in that the IP address of the server-side SteelHead replaces the IP address of the client in communication between the server-side SteelHead and the destination server. The traffic travels the following route:

Some applications and protocols require that the server initiate a new session or that they see the IP address of the requesting client. These applications and protocols do not function in this configuration. Consider using an in-path deployment, a WCCP deployment, or use rules on the SteelHead to pass through this traffic.

In both correct and port transparency addressing modes, whatever IP addresses are detected on the initiating SteelHead (typically, the client-side SteelHead) are used by the corresponding SteelHead on the remote side as Figure 3‑10 shows. This deployment can bypass any NAT that occurs in the WAN between the SteelHeads. To ensure that NAT is still used for the optimized traffic, you must configure the full transparency addressing mode for this traffic.

In this example, the TCP connection request travels the following route:

Figure 3‑11 shows a client-side source NAT deployment using enhanced auto-discovery and full address transparency. In this configuration, the presence of the full transparency TCP option with auto-discovery probe is a signal to the server-side SteelHead that it can use the addresses arriving from the WAN. Because the server-side addresses are reachable from the client side, when the client-side SteelHead makes its out-of-band connection to the server-side SteelHead, the address it uses is valid and is properly translated across the WAN.

Figure 3‑12 shows a deployment in which NAT is occurring at the client location. In this example, enhanced auto-discovery with correct addressing does not work. This is because the server-side SteelHead cannot match

the client connection that it originally sees in the SYN+ with the pre-NAT (original) client IP address that is sent as part of the setup information.

Figure 3‑13 shows NAT used at the client and the server. In this network, full transparency and some form of OOB transparency is required for successful connection establishment and optimization.

Figure 3‑14 shows a deployment in which NAT is occurring at both the client and server locations. In this example, enhanced auto-discovery with correct addressing is unlikely to work, because the probe response from the server-side SteelHead included the WA2a internal IP address for the server-side SteelHead.