Content Gateway IP spoofing

IP spoofing is sometimes used to support upstream activities that require the client IP address or a specific IP address. It also results in origin servers seeing the client or specified IP address instead of the proxy IP address (although the proxy IP address can be a specified IP address; more below).

Content Gateway IP spoofing support has the following features and restrictions:

IP spoofing is supported for HTTP and HTTPS traffic only.

When IP spoofing is enabled, it is applied to both HTTP and HTTPS. It cannot be configured for only one protocol.

HTTPS traffic is spoofed whether SSL support is enabled or not.

IP spoofing relies on the ARM.

In transparent proxy deployments using WCCP and IP spoofing, with GRE or L2 mode negotiation, neither HASH nor MASK are supported on the source port or source port/source IP address.

IP spoofing is not supported with edge devices such as a Cisco ASA or PIX firewall. When this is attempted, requests made by Content Gateway using the client IP address are looped back to Content Gateway.

IP spoofing requires all IP addresses in the same routing path use the same format. That is, all IP addresses must be either IPv6 or IPv4. A combination of IPv6 and IPv4 addresses is not supported.


	Warning Deploying IP spoofing requires precise control of the routing paths on your network, overriding the normal routing process for traffic running on TCP port 80 and 443. When configured with either transparent or explicit proxy, return traffic must be routed back to the proxy. For assistance, please contact your network equipment vendor or Technical Support. With IP spoofing enabled, traditional debugging tools such as traceroute and ping have limited utility.


	Important For a discussion of how the proxy kernel routing table impacts transparent proxy deployment, see the Solution Center article titled, Web sites in the Static or Dynamic bypass list fail to connect.

Range-based IP spoofing

Range-based IP spoofing supports groupings of clients (IP addresses and IP address ranges) that are mapped to specified IP addresses.

Among other uses, range-based IP spoofing facilitates:

The delivery of web-hosted services when the identification is by source IP address. For example, to receive a web-hosted service, an organization might be required to identify membership to the service via a known IP address.

IP address-based authentication with an external service when a unique IP address represents a group of users.

A way to configure traditional IP spoofing for some clients (source IP addresses that don't match any group are spoofed with their own IP address), range-based IP spoofing for some clients, and standard proxy IP address substitution for some clients. The latter is done by creating a group that specifies the proxy IP address.


	Important Range-based IP Spoofing is not supported on many older versions of Cisco IOS firmware. To avoid problems, update your Cisco device to the latest firmware. IP Spoofing is supported for IPv6. However, range-based IP Spoofing is not supported for IPv6.

IP spoofing and the flow of traffic

When IP spoofing is used with WCCP, HTTP and HTTPS traffic flows as follows. The numbers in the diagram correspond to the actions described in the numbered list. (Note that policy-based routing can be implemented to achieve the same results.)

A client request arrives at a routed port or Switched Virtual Interface (SVI) looking for traffic with a destination port of HTTP (80) or HTTPS (443).

The switch redirects the client request to Content Gateway.

If needed, the proxy creates a connection to the origin server using the client IP address or specified IP address (range-based IP spoofing).

The request is sent to the origin server through the switch, NAT and/or firewall.

When the origin server response is returned, the IP packet has the substituted IP address as the destination (client or specified IP address).

The origin server response arrives at a routed port or Switched Virtual Interface (SVI) looking for traffic with a source port of HTTP (80) or HTTPS (443). See the note below.

The switch redirects the origin server response to the proxy, completing the proxy-to-origin server TCP connection.

A proxy response to the client is generated and returned to the client on the proxy-to-client TCP connection.


	Note When IP spoofing is enabled, the proxy advertises a reverse service group for each enabled WCCP service. The reverse service group must be applied along the return path of the proxy.

WCCP service group IDs are user defined and must be programmed on the WCCP devices and in Content Gateway (see Configuring service groups on the WCCP device and Configuring service groups in the Content Gateway manager).

The following definitions are suggested.


Service ID	Port	Traffic Type
0	destination port 80	HTTP
20	source port 80	HTTP
70	destination port 443	HTTPS (HTTPS support must be enabled)
90	source port 443	HTTPS

Policy-based routing (PBR) uses access control lists (ACL) to identify and redirect flows. In a PBR deployment, all of the configuration is done on the router and there is no corresponding Content Gateway configuration. PBR deployments have to redirect traffic returning from origin servers from port 80 and 443 to Content Gateway.