Identifying users connecting through a proxy server

10/14/2021 22 People found this article helpful 202,664 Views

Download

Print

Share

• LinkedIn
• Twitter
• Facebook
• Email
• Copy URL The link has been copied to clipboard

Description

When multiples hosts connect to the web from behind a web proxy located on the DMZ or WAN, the SonicWall sees all such traffic coming from the IP address of the proxy server. Due to this, the SonicWall will be unable to identify the users or their IP addresses to enforce Security Services selectively.

NOTE: The proxy server must be located on the WAN or DMZ; it can not be located on the LAN.

To identify users for the purpose of applying Security Services policies, SonicWall needs to know the original source IP address of the connection being made from the proxy server. Proxy servers can be configured to provide this information by inserting an X-Forwarded-For (XFF) field in the HTTP header before proxying the request. The XFF field contains the IP address of the host making the original web request.

The option to insert the XFF field into the HTTP header is not enabled by default in proxy servers and must be enabled by the administrator.



The User Proxy Servers option on the Network | Web Proxy page of the SonicWall management GUI enables the SonicWall to peer into the HTTP header to read contents of the XFF field. Adding the proxy server's hostname or IP address under the User Proxy Servers option helps identify the proxy server for the SonicWall .  When HTTP traffic is received from this address, the SonicWall appliance performs the following action:

1. Obtains the IP address of the original host from the XFF field in the HTTP header.
2. Triggers SSO to obtain the username of the IP address.
3. Enforces Security Service policies - CFS, App Control Advanced, App Rules, GAV, IPS - on the username thus obtained.
4. Check the user against the Users Included or Excluded field in Access Rules. The IP address obtained from this field cannot be used as a source or destination in access rules.
5. Apply Bandwidth Management policies on the user.
6. If user is denied by Security Services policies or Access Rules, drop the packet. If user is allowed by Security Services policies or Access Rules, encrypt the packet again and forward it.

1. Decrypt the packet and look for the XFF field within the HTTP header.
2. Obtain the IP address of the original host from the XFF field in the HTTP header.
3. Enforce Security Service policies - CFS, App Control Advanced, App Rules, GAV, IPS - on the username thus obtained.
4. Check the user against the Users Included or Excluded field in Access Rules. Note: The IP address obtained from this field cannot be used as a source or destination in access rules.
   
5. Apply Bandwidth Management policies on the user.
6. If user is denied by Security Services policies or Access Rules, drop the packet. If user is allowed by Security Services policies or Access Rules, encrypt the packet again and forward it.

Users identified from IP addresses obtained from the X-Forwarded-For field can be used in the following ways:

1. Apply security services policies for CFS, App Control Advanced, IPS, GAV, ASW, App Rules
2. Allow/Deny traffic based on Access Rules configured with Include / Exclude users. The IP address obtained from the X-Forwarded-For cannot be used as the source or destination of an access rule.
3. Apply Bandwidth Management policies.
4. Web Management
5. Inclusion / Exclusion of users from DPI-SSL Client Inspection

NOTE: User identification via SSO is not currently possible if the traffic is HTTPS. If a user has already been identified by the SonicWall via HTTP (for example), for subsequent HTTPS traffic SonicWall will perform the XFF field lookup and identify the user from the user cache (User | Status) . This means, if the first traffic from an originating host is HTTPS, SonicWall will not attempt to query the SSO agent for the identity of the user. In which case, security service policies will not be applied for that user. For example, for CFS this would mean applying the default policy.

Resolution

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

Enable User Proxy

The following configuration will trigger the SonicWall to inspect HTTP packets from the proxy server for the XFF field. If XFF field is present, SonicWall will obtain the IP address contained within.

1. Login to the SonicWall management GUI.
2. Navigate to the Manage | Network | Web Proxy page.
3. Under User Proxy Servers, click on Add and enter the IP addresses or hostnames of the proxy server/s.
4. Click on OK.
5. Click on Accept at the top of the page to save the changes.

Enable DPI-SSL Client Inspection

NOTE: When DPI-SSL is enabled the SonicWall will re-sign the SSL certificates passing to hosts. This will trigger certificate errors in the browsers. To avoid these errors, import the SonicWall DPI-SSL CA certificate as a trusted Root CA into the browser's (or the computer's) certificate store. For more information, see UTM: Distributing the Default SonicWall DPI-SSL CA certificate to client computers using Group Policy

1. Navigate to the Manage | Deep Packet Inspection | SSL Client deplyment page.
2. Enable check box Enable SSL Client Inspection
3. Enable the check boxes of any or all of the available Security Services.
4. Click on Accept at the top to save



Exclude proxy server IP address in SSO.

This is a recommended step to prevent traffic from the proxy server from triggering SSO.

Prevent DNS service from triggering SSO.

This is a recommended step to prevent DNS traffic from hosts from triggering SSO.

Go To Manage | Users | Settings | Configure SSO | Enforcement | SSO Bypass,  click ADD 

Add an SSO bypass rule.

Resolution for SonicOS 6.2 and Below

The below resolution is for customers using SonicOS 6.2 and earlier firmware. For firewalls that are generation 6 and newer we suggest to upgrade to the latest general release of SonicOS 6.5 firmware.

Enable User Proxy

The following configuration will trigger the SonicWall to inspect HTTP packets from the proxy server for the XFF field. If XFF field is present, SonicWall will obtain the IP address contained within.

1. Login to the SonicWall management GUI.
2. Navigate to the Network | Web Proxy page.
3. Under User Proxy Servers, click on Add and enter the IP addresses or hostnames of the proxy server/s.
4. Click on OK.
5. Click on Accept at the top of the page to save the changes.

Enable DPI-SSL Client Inspection

 NOTE: When DPI-SSL is enabled the SonicWall will re-sign the SSL certificates passing to hosts. This will trigger certificate errors in the browsers. To avoid these errors, import the SonicWall DPI-SSL CA certificate as a trusted Root CA into the browser's (or the computer's) certificate store. For more information, see UTM: Distributing the Default SonicWall DPI-SSL CA certificate to client computers using Group Policy

1. Navigate to the DPI-SSL | Client SSL page.
2. Enable check box Enable SSL Client Inspection
3. Enable the check boxes of any or all of the available Security Services.
4. Click on Accept at the top to save



Exclude proxy server IP address in SSO.

This is a recommended step to prevent traffic from the proxy server from triggering SSO.

Prevent DNS service from triggering SSO.

This is a recommended step to prevent DNS traffic from hosts from triggering SSO.

Related Articles

• Bandwidth usage and tracking in SonicWall
• How to force an update of the Security Services Signatures from the Firewall GUI
• Configure Guest VLAN in the TZ firewall, for guest users to access Internet only.

Categories

• Firewalls > TZ Series
• Firewalls > SonicWall NSA Series
• Firewalls > SonicWall SuperMassive 9000 Series
• Firewalls > SonicWall SuperMassive E10000 Series