IPv6 Address Appearing in X-Forwarded-For (XFF) Header with with Cloud SWG Egress IPs

Products

• Cloud Secure Web Gateway
• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Some customers observe IPv6 addresses in the X-Forwarded-For (XFF) header when traffic is egressing through Broadcom Cloud SWG with Dedicated Egress IPs (DEIs). This can lead to confusion when third-party vendors rely on the XFF header for allow listing, as they may interpret the IPv6 anonymizer as the client’s true source address.

Environment

 

• Product: Broadcom Cloud SWG

• Policy Mode: Cloud SWG Portal policy

• Features:

  • Dedicated Egress IPs (IPv4)

  • Shared Egress IPs (IPv4)

  • XFF anonymization enabled in Cloud SWG portal

  • Optional SSL Interception bypass rules

 

Cause

When XFF anonymization is enabled, Cloud SWG replaces the client IP in the XFF header with an anonymized IPv6 value for privacy.

• This IPv6 value exists only in the header and does not reflect the actual TCP source IP.

• All egress traffic (whether Shared IPs or Dedicated IPs) still uses the assigned IPv4 addresses.

• Vendors that key off XFF instead of the true source IP may block traffic because they see the anonymized IPv6.

• In the Cloud SWG Portal, XFF is a restricted header and cannot be removed with standard header modification rules.

Resolution

Several options exist depending on business and security requirements:

1. Vendor allow list of DEI IPv4s (Recommended)

   • Instruct the vendor to allow list the customer’s IPv4 Dedicated Egress IPs and ignore the XFF header.

   • Benefit: Maintains full inspection and privacy.

   • Drawback: Requires coordination with the vendor and updates if DEIs change.

2. Adjust Global XFF Setting

   • In the Portal, under Policy → Header Modification → Global Rules, switch XFF from Anonymize IP to Original IP.

   • Benefit: Inserts IPv4 addresses into XFF, no anonymized IPv6.

   • Drawback: Reduces privacy posture globally, exposes real client IPs to all destinations.

3. SSL Interception Bypass (per site)

   • Configure a bypass rule for the affected domain (e.g., example.com).

   • Without SSL interception, Cloud SWG cannot insert/modify headers, and the vendor sees only the IPv4 DEI.

   • Benefit: Stops XFF header injection for the site.

   • Drawback: Disables malware scanning, DLP, and content inspection for that domain.

4. Broadcom Support – Policy Fragment (per site)

   • Open a support case to request a policy fragment that removes XFF for the specific site.

   • Benefit: Removes XFF only for the impacted domain, while keeping full inspection in place.

   • Drawback: Requires Broadcom Support intervention.

5. UPE Mode – Site-Specific Header Removal

   • In UPE policy, create a CPL header modification rule to remove or rewrite XFF only for the impacted domain (e.g., example.com).

   • Benefit: Precise control per domain, full inspection remains enabled elsewhere.

   • Drawback: Requires UPE/Management Center; not available in Portal-only deployments.

   • How to disable the XFF header for a specific website when the Cloud SWG policy is managed from the Management Center.

---

Recommendation

• Primary: Work with the vendor to allow list the IPv4 egress IPs (whether Dedicated or Shared) instead of relying on XFF.

• If vendor cannot adjust:

  • UPE customers: Apply a CPL rule to remove XFF for the site.

  • Portal-only customers: Engage Broadcom Support to push a policy fragment for the specific domain.