Cisco Cisco ScanSafe Web Security Data Sheet

Data Sheet

Customer Egress Visibility Behind CWS Cloud
Proxy

A common question customers have about CWS is whether or not a destination web
server would be able to ‘see’ the customer’s egress IP or the CWS cloud proxy’s
egress IP.

When a customer's web traffic is redirected to a CWS cloud proxy the destination web server will see the

customer’s traffic as originating from the CWS proxy's egress IP address. However, CWS inserts the customer's

egress IP address into the XFF Header (X-Forwarded-For) and the X-ProxyUser-IP header. The destination web

server would have to be capable of reading either header to retrieve the customer’s egress IP address.

Why is CWS adding the X-ProxyUser-IP header in addition to the XFF header?

Some parts of Google, and perhaps other web service or content providers, use the XFF header while other parts

use the X-ProxyUser-IP header. The solution to this inconsistency is to include both headers in the request. This

will allow the Google service to read whichever header is appropriate to obtain the IP address needed.

Why are the XFF and X-ProxyUser-IP headers needed?

1. Web content providers may need to identify requests that are originating from different organizations

sharing the same CWS cloud proxy. This helps to prevent the scenario where a content provider, such as

Google, displays CAPTCHA messages to all customers sharing the same CWS cloud proxy.

2. Web content providers may use these headers to deliver regional content based on the IP address

recorded in the header. This is particularly relevant where a customer’s web request originates from a

different country than the CWS cloud proxy they are forwarding their traffic to.

Note: The XFF and X-ProxyUser-IP headers are not added to HTTPS requests unless HTTPS inspection is
enabled.

Page 1 of 2