Vous êtes sur la page 1sur 4

Volume I: Getting Started

Note: If you use URL host rewrite functionality in your policies, mismatches can
occur between the client-provided IP address and the resolved, rewritten
hostname. In these cases, a routing lookup is performed and an interface route,
static route, or default route is used.

Using Return-to-Sender (RTS)


As stated previously, the ProxySG does a routing lookup to see if it can determine
the correct route for a packet, either by using a static route or, if one is not defined,
by sending it over the default route. However, using the default route is
sometimes suboptimal. For example, if the ProxySG satisfies a request and sends
the client response traffic over the default route, the gateway router simply
returns the traffic to the client router on the LAN side of the ProxySG. This causes
unnecessary traffic between the switch and gateway, before the packet is finally
received by the client router.

Figure 6–2 Effects of sending client response to the default gateway


To specify a direct route, a static route must be created, which requires the
administrator to update the routing table every time a new route is needed.
The Return-to-Sender (RTS) option eliminates the need to create static routes by
configuring the ProxySG to send response packets back to the same interface that
received the request packet, entirely bypassing any routing lookup on the
ProxySG. Essentially, the ProxySG stores the source Ethernet MAC address that
the client’s packet came from and sends all responses to that address.
The RTS interface mapping is updated each time a packet is received. For
example, if there are two gateways and both of them send packets to the ProxySG,
the packets are sent back to the last MAC address and interface that received the
packet.

Note: Non-default static routes override RTS settings.

106
Chapter 6: Routing on the ProxySG

RTS can be configured in two ways, inbound or outbound.


Inbound RTS affects connections initiated to the ProxySG by clients and is
enabled by default in SGOS 5.4 and later. Inbound RTS configures the ProxySG to
send SYN-ACK packets to the same interface that the SYN packet arrived on. All
subsequent TCP/IP response packets are also sent to the same interface that
received the request packet.
RTS inbound applies only to clients who are on a different subnet than the
ProxySG. If clients are on the same subnet, interface routes are used.

Phase One Phase Two

Inbound RTS Process Flow


1. Client A sends SYN to Server C across the WAN. The SYN is intercepted on the ProxySG B
interface 0:1.
2. The ProxySG maps Client A to interface 0:1. All packets to Client A will now go to interface 0:1.
3. When a packet arrives for Client A, the ProxySG checks its interface mapping and sends the
packet to the client over interface 0:1.

Figure 6–3 Inbound RTS

107
Volume I: Getting Started

Outbound RTS affects connections initiated by the ProxySG to origin servers.


Outbound RTS causes the ProxySG to send ACK and subsequent packets to the
same interface that the SYN-ACK packet arrived on.

Phase One Phase Two

Outbound RTS Process Flow


1. Server C sends SYN-ACK to the ProxySG B. The SYN-ACK is received on the ProxySG
interface 0:0.
2. The ProxySG maps Server B to interface 0:0. All packets to Server B will now go to interface
0:0.
3. When a packet arrives for Server B, the ProxySG checks its interface mapping and sends the
packet out of interface 0:0.

Figure 6–4 Outbound RTS

Enabling Return-to-Sender
To enable RTS, use the return-to-sender command. For example:
#(config) return-to-sender inbound {disable | enable}
Enables or disables return-to-sender for inbound sessions.
#(config) return-to-sender outbound {disable | enable}
Enables or disables return-to-sender for outbound sessions.

DNS Verification
In transparent deployments, the ProxySG verifies the destination IP addresses
provided by the client. This is known as L2/L3 transparency.

Note: The Trust Destination IP option overrides DNS verification. This option is
recommended for acceleration deployments only. For more information about
this option, see Volume 2: Proxies and Proxy Services.

108
Chapter 6: Routing on the ProxySG

For hostname-less protocols such as CIFS and FTP, the IP address can always be
trusted. For other protocols, such as HTTP, RTSP, and MMS, which have a
hostname that must be resolved, verification can be an issue. URL rewrites that
modify the hostname also can cause verification to fail.
L2/L3 transparency is not supported in explicit proxy deployments, or if the
destination IP addresses cannot be verified by the ProxySG. In these cases, you
must configure static routes to hosts that are only accessible through gateways
other than the default gateway.
Transparent ADN connections that are handed off to an application proxy (HTTP
or MAPI, for example) can utilize L2/L3 transparency. Also, transparent ADN
connections that are tunneled but not handed off can utilize the functionality.

Note: IM is not supported with trust client addressing. To support IM, proper
routes must be configured for Internet access and IM client-to-client
communication.

109

Vous aimerez peut-être aussi