UpdatedOctober 14, 2021

Identifying users connecting through a proxy server

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:

Obtains the IP address of the original host from the XFF field in the HTTP header.
Triggers SSO to obtain the username of the IP address.
Enforces Security Service policies - CFS, App Control Advanced, App Rules, GAV, IPS - on the username thus obtained.
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.
Apply Bandwidth Management policies on the user.
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.

Thus far we were required to make two configuration changes - one in the SonicWall to enable the User Proxy Servers option and the other in the proxy server to enable insertion of the XFF field - for a successful look-up of the original host address from HTTP traffic. For HTTPS traffic, further changes are required to effectively identify end users. As HTTPS traffic is encrypted, when a host's HTTPS traffic reaches the proxy server, it will not be able to insert the XFF field into the packet. The packet will be proxied and forwarded to the SonicWall in encrypted form, rendering the SonicWall incapable of performing the originating host look-up referred above. Although the SonicWall appliance can decrypt HTTPS traffic using its DPI-SSL feature, without the XFF field it will not be capable of identifying the original host.

To be able to insert the XFF field into HTTPS traffic, a proxy server must act as a Man-in-the-middle SSL proxy (similar to SonicWall DPI-SSL and variously reffered to as "SSLBump", "SSL bridging" by proxy servers). For instance in Squid 3.2 SSLBump feature, the client SSL requests will be decrypted to insert the XFF field and encrypted again before forwarding the traffic. The SonicWall appliance with DPI-SSL Client Inspection enabled will perform the following action on receiving the (re)encrypted packet from the proxy server:

Decrypt the packet and look for the XFF field within the HTTP header.
Obtain the IP address of the original host from the XFF field in the HTTP header.
Enforce Security Service policies - CFS, App Control Advanced, App Rules, GAV, IPS - on the username thus obtained.
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.
Apply Bandwidth Management policies on the user.
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:

Apply security services policies for CFS, App Control Advanced, IPS, GAV, ASW, App Rules
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.
Apply Bandwidth Management policies.
Web Management
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 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.

Login to the SonicWall management GUI.
Navigate to the Manage | Network | Web Proxy page.
Under User Proxy Servers, click on Add and enter the IP addresses or hostnames of the proxy server/s.
Click on OK.
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.

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.