You can deploy proxy-chaining in your environment for easier migration or proxy transparency. Cisco Secure Access supports proxy-chain traffic on Registered Networks only. Since the X-Forwarded-For (XFF) HTTP header is not available for traffic sent through network tunnels, Cisco recommends that you do not send proxy-chain traffic through tunnels.

The Cisco Secure Access secure web gateway (SWG) leverages FQDN anycast routing to forward web traffic to the most optimal data center. If you use Secure Access DNS resolvers and your on-premises proxy supports an FQDN-based upstream proxy definition, use the organization-specific FQDN anycast endpoint.

Using the organization-specific FQDN pattern allows Cisco Secure Access to apply improved data center selection logic for your tenant. This helps reduce sub-optimal routing and improves connection reliability and performance. The improvement is especially beneficial for customers using reserved IPs and in environments where DNS-based steering is unavailable or inactive.

Network Requirements

Configure your on-premises upstream proxy settings for FQDN anycast and HTTP 80/443 on:
- swg-url-proxy-https-<org-id>.sseproxy.qq.opendns.com
- For instructions on finding your organization ID, refer to Find Your Organization ID.
If you explicitly allowlist FQDNs in firewalls or ACLs, add the new organization-specific FQDN to avoid blocked connections.
If you use a PAC file or proxy chain with the legacy FQDN hardcoded, update it to the new organization-specific FQDN to benefit from the improved reliability.
Add a Registered Network in Secure Access that matches the public IP of your on-premises proxy NAT IP address. For more information, refer to Manage Registered Networks.
Route the required URLs directly to the internet, not to the Secure Access secure web gateway. For more information, refer to Secure Access SAML Identity Provider Domains.
If you use SAML authentication for single sign-on (SSO), send requests for id.sse.cisco.com to the Secure Access secure web gateway, not directly to the internet. For more information, refer to Secure Access SAML Gateway Services.

Note
The legacy FQDN below continues to work after your organization is enabled for the new pattern, but Cisco recommends updating hardcoded configurations to take advantage of the enhancement:

Legacy FQDN: swg-url-proxy-https-sse.sigproxy.qq.opendns.com

Forwarded-For (XFF) Configuration

You can configure the X-Forwarded-For (XFF) request header by using an on-premises proxy or a browser plugin such as Firefox's Simple Modify Headers plugin.

When configured, the XFF header sets the internal IP address for traffic on a Registered Network (an egress IP). You must add these Registered Networks as sources in your internet access rules. Then, for traffic on the Registered Networks, the Activity Search report includes the internal IP addresses.

Note
Cisco Secure Access does not require the XFF header for deploying proxy chaining.

On-Premises XFF Header Configuration (No Plug-In)

For information about configuring the X-Forwarded-For (XFF) request header, see your proxy documentation.

Guidelines

To write the XFF header on HTTPS packets, configure internal clients for an explicit proxy and HTTPS decryption.

Configure internal clients to forward web traffic to the proxy's internal network interface or a PAC file.
For transparent proxy deployments, the proxy must provide Man-in-the-Middle (MitM) decryption.
For HTTPS decryption to work correctly, import your Secure Access root certificate to your proxy. For more information, see Manage Certificates. Also, refer to your proxy documentation.

Note
If you are not using XFF headers (and instead using SAML or only external IP addresses to identify sources), you only have to enable HTTPS decryption on the proxies deployed in your cloud environments.

Browser Plugin XFF Header Configuration (No Proxy Chaining)

The browser plug-in approach is not scalable for production deployments and should be used for testing and troubleshooting only.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.