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.)

  1. 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).
  2. 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).

  3. The request is sent to the origin server through the switch, NAT and/or firewall.
  4. When the origin server response is returned, the IP packet has the substituted IP address as the destination (client or specified IP address).
  5. 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.
  6. The switch redirects the origin server response to the proxy, completing the proxy- to-origin server TCP connection.
  7. 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.