Forward to Proxy Integration

Use this page to configure custom proxy settings. Once configured you can use the Forward to Proxy action in your Real-time Protection policy to redirect traffic to this proxy. But, before you begin, upload your self-signed trusted certificate to Netskope. For more information, refer to Certificates.

1. Go to Settings > Manage > Forward to Proxy Integration.

2. Click Setup Proxy

   

3. In the New Proxy Setup pop-up window, enter the following to configure a new proxy

   

   • Proxy Name : Enter a meaningful name.

   • Host & Port : Enter a domain name or IP address & Enter the port number of the host address.

   • Options [ X-Forwarded-For , X-Authenticated-User, Tenant-Info ] : Optional field. For embedding traffic source identifiers, choose the following:

     • X-Forwared-For : source IP address

     • X-Authenticated-User : username

     • Tenant-Info : a unique identifier identifying if the tenant is attached

   • X-AU-ENCODED-FORMAT : The X-AU-ENCODE-FORMAT allows you to choose from the following three formats:

     • None: The username is sent without modification. For example, johndoe@example.com

     • Domain User: The user name is sent as a base64 encoded value along with the domain URL. For example: base64Encode(“example.com/johndoe“).

     • Schema Domain User: The user name is sent as a base64 encoded value with full AD url. For example: base64Encode(“WinNT://example.com/johndoe“)

       Only WinNT schema is supported.

4. Click Save to complete the new proxy setup.

Using Forward-to-Proxy Action in RTP Policy

To use this proxy in your Real-time Protection policy, select Forward to Proxy under Action, and then select the configured proxy.

Support SSL Bypassed Traffic in Forward to Proxy

Currently, the Forward to Proxy action in an RTP policy is not applied to non-decrypted traffic, i.e requests matching a SSL DND rule.

The Forward to Proxy action in RTP policies has been enhanced to support both decrypted and non-decrypted traffic to a 3rd party proxy. With the new enhancement, non-decrypted traffic that matches RTP rules for the Forward to Proxy action will now be forwarded to the configured next hop proxy. We recommend using Squid proxy in your RTP policy when selecting F2P action.

Additionally, the headers specified in the Forward to Proxy profile (XFF, XAU, XTID) are included in the CONNECT request for both decrypted and non-decrypted traffic for a consistent user experience.

Limitations

• For traffic bypassed for reasons other than SSL policy, such as Tunnel bypass, the RTP policy will not be evaluated, and Forward to Proxy will not be supported.

• Traffic that is steered to Netskope but matches a steering exception rule will be bypassed and RTP policies will not be applied so the forward to proxy action cannot be taken. Applicable to tenants where the lookup-steering-exceptions flag is set.

• RTP with action as forward to proxy isn’t compatible with instance based policies.