Internal client IP exposed on Public Internet within HTTP X-Forwarded-For header

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Proxy forwarding into WSS.

Internal IP addressing scheme using public IP address range e.g. a class C network starting with 193.x.x.x.

User browses the internet and noticed their internal IP sitting on 193.x.x.x subnet was exposed.

Using whatismyip.com we see the Broadcom DC IP, but the X-Forwarded-For header includes the 193.x.x.x IP address.

WSS managed using UPE.

Environment

Cloud SWG.

Proxy forwarding.

UPE.

Cause

On premise Proxy is forwarding the internal IP into Cloud SWG via CPL policy.

Cloud SWG sees that it is not an RFC1918 IP address and proxies it to external web server.

Resolution

When designing an internal network, best practice should always be to use an RFC1918 IP address range. Using an existing, routable, public IP address range can be problematic.

To address the above issue, two options exist:

1. Change internal IP addressing scheme so that all IP addresses use RFC1918 IP addresses.
   
   
2. Remove the X-Forwarded-For (XFF) header on Cloud SWG proxy by pushing the following CPL code out
   
   define action delete-XFF
      delete(request.header.X-Forwarded-For)
   end
   
   <proxy>
   action.delete-XFF(yes)
   
   
3. Modify the XFF header to remove the private 193.x.x.x IP address and add a local Cloud SWG egress IP address instead - in this case one from the GGBLO data center available from Cloud SWG IP address KB article. This will strip the 193.x.x.x (or any IP address in an XFF header) going upstream to Web servers.
   
   define action set-XFF
      set(request.header.X-Forwarded-For, “148.64.26.1”)
   end
   
   <proxy>
   action.set-XFF(yes)

 

Additional Information

Some Web servers use the XFF header to GEO locate, overwriting the ingress IP address. This is the only reason option 3 above was defined.