Technical Library | Support

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
v7.8.4 Release Notes for Websense® Content Gateway : Operating tips
Operating tips
Topic 60118 | Web Security Gateway and Gateway Anywhere | 26-Aug-2014
*
Installation
*
Configuration
*
IWA support for load balanced environments
*
Proxy user authentication
*
SSL Internal Root CA
Installation
Software installation location and file ownerships
Content Gateway is installed in /opt/WCG.
Files are installed with root ownership.
Content Gateway processes are run as root.
Internet connectivity
It is recommended that the Content Gateway host computer have Internet connectivity before starting the software installation procedure. The software will install without Internet connectivity, but analytic databases cannot be downloaded from the Websense Database Download Server until Internet connectivity is available.
Ports
A full deployment of Content Gateway requires that several ports be open. See Installing Content Gateway in the Deployment and Installation Center for information about open ports and the reassignment of ports, if necessary.
Cluster handling during upgrades
Content Gateway tolerates different software versions in the same cluster. This is intended to simplify the process of upgrading a cluster. You should not run a cluster containing different versions for a prolonged period of time (many days).
Support for multiple versions in a cluster has these features and limits:
*
Configuration synchronization does not take place among nodes of different versions.
*
Condition alarms are passed among all nodes.
*
The VIP feature is supported.
'admin' password restrictions
The password you enter for the Content Gateway administrator during installation (default name: admin) must be 15 characters or fewer.
To create a strong password (recommended), use 8 or more characters, with at least 1 each of the following: capital letter, lower-case letter, number, special character.
The password cannot contain the following special characters:
*
space
*
$ (dollar symbol)
*
: (colon)
*
' (backtick; typically shares a key with tilde, ~)
*
\ (backslash)
*
" (double-quote)
Cache size
Cache size should be restricted to 147 GB. This size provides optimal resource utilization while also providing an excellent end-user experience. Because today's Internet sites are often composed of dynamic, uncacheable content, caching is a less significant factor in the end user's Web browsing experience.
Configuration
In explicit proxy deployments, send HTTPS traffic to port 8080
In explicit proxy deployments, when HTTPS (SSL support) is enabled, client browsers should be configured to send HTTPS traffic to proxy port 8080.
Accessing Intranet sites in an explicit proxy deployment
If your clients cannot access your Intranet sites, verify that your operating system has been correctly configured to resolve all internal and external hostnames. Use the nslookup command to verify that a domain is listed in your DNS server:
For internal-facing servers:
nslookup intranet.example.com
For external Web sites:
nslookup www.example.com
If your organization has multiple DNS domains, verify that a hostname in each domain resolves correctly. If you are unable to resolve hostnames, verify the contents of the /etc/resolv.conf file, which provides search rules for how domain names are resolved in DNS.
When Content Gateway is on a V-Series appliance, the domain of the hostname is automatically added to /etc/resolv.conf. For example, if the hostname of the appliance is vseries.example.com, then Content Gateway treats "intranet" requests as "intranet.example.com".
DNS proxy caching
The DNS proxy caching option allows Content Gateway to resolve DNS requests on behalf of clients. This option off-loads remote DNS servers and reduces response times for DNS lookups. You can use the DNS proxy caching option only with a layer 4 switch or a Cisco router running WCCP v2.
DNS proxy caching can only answer requests for A and CNAME DNS entries. Other types of request (e.g., MX) will not be answered.
Limitation: If the host name to IP address mapping is not in the DNS cache, Content Gateway contacts the DNS server specified in the /etc/resolv.conf file. Only the first entry in resolv.conf is used. This might not be the same DNS server for which the DNS request was originally intended.
See "DNS Proxy Caching" in Content Gateway Manager Help.
If your environment is configured such that you have DNS servers that resolve internal sites only and others that resolve external sites only, see Using the Split DNS option in Content Gateway Manager Help.
Virtual IP address must not match any real IP address
When configuring the Virtual IP feature, make sure that the Virtual IP addresses do not conflict with any existing IP addresses in the network.
Restart the proxy after protocol settings change
Any time you change your protocol settings in Content Gateway Manager (for example, with Configure > SSL > Decryption/Encryption > Inbound > Protocol Settings), you must restart the proxy for the new settings to take effect.
Using extended event logging
To investigate unexpected system behavior, it is sometimes helpful to enable the Log Transaction and Errors option (extended event logging) in Content Gateway Manager (Configure > Subsystems > Logging). However, extended event logging adds significant load to Content Gateway processes. Therefore you should not enable extended event logging when Content Gateway is at the high end of its processing capacity.
Reverse proxy
Content Gateway does not function as a reverse proxy.
IWA support for load balanced environments
Although IWA with a load balancer is supported in custom configured v7.7.3 deployments (Websense Technical Support assisted in these configurations), IWA with a load balancer is not supported in v7.8.1. Support is again provided, starting in v7.8.2.
 
* 
Important 
After upgrade to v7.8.4 check and, if necessary, rejoin IWA domains.
With Websense Content Gateway, Integrated Windows Authentication (IWA) uses the Kerberos protocol, with NTLM fallback.
In a load balanced environment, because the clients point to a FQDN that does not match the Content Gateway hostname, they receive a Kerberos ticket that Content Gateway cannot decrypt.
Normally, Content Gateway would be configured to share the hostname of the load balancer, but this is not possible when the load balancer requires hostname resolution (as with DNS-based load balancing).
In these cases, Content Gateway must be configured to use a custom keytab that corresponds to the load balancer's hostname for decryption.
Samba's implementation of Kerberos prevents this, because it requires keytab entries to match the service's hostname.
Starting in v7.8.2, this can be addressed with a 3-step solution.
 
* 
Important 
If your Content Gateway instances reside on a Websense appliance, contact Websense Technical Support for assistance with this procedure.
*
Step 1: Add the custom SPN to the Kerberos domain (Active Directory) under the account object that Content Gateway used to join the domain.
You can use the following command at the Windows command prompt:
setspn -A <SPN> <content_gateway_hostname>
*
Step 2: Edit the keytab principals parameter in smb.conf.
The parameter's value specifies a custom SPN entry. Samba rejects SPN entries that do not match the hostname of the service server.
The Kerberos decryption process now also matches against the custom SPNs in smb.conf, in the case that default matching fails.
Specify the custom SPN in smb.conf as follows:
keytab principals = HTTP/<custom SPN>.<domain>@<JOINED REALM>
This prompts Content Gateway to attempt decryption with a keytab entry that matches the above hostname.
You must restart Content Gateway for the change to go into effect.
*
Step 3: Add the keytab entry via Samba.
The parameter in the file smb.conf enables the use of a specific custom SPN, but the Samba update is necessary to complete the configuration.
1.
To create a custom SPN entry in the keytab file, navigate to:
/opt/WCG/contrib/samba/jails/<joined realm>
2.
Enter the chroot command.
3.
Run the following command:
net ads keytab add <custom SPN>@<joined realm> -U <domain user>
A password prompt appears. If authentication is succesful, the custom SPN is added into the keytab file.
4.
Windows caches clients' authentication. To ensure that all previous authentication is cleared, restart any clients that might have connected before this change was made.
Note that if the Content Gateway machine leaves and rejoins the domain, /opt/WCG/contrib/samba/jails/<joined realm> gets wiped and recreated, so Samba must be reconfigured.
Proxy user authentication
Client browser limitations
Not all Web browsers fully support transparent user authentication (prompt-less).
The following table indicates how a browser responds to an authentication request when Integrated Windows Authentication (IWA) is configured.
Browser/
Operating System
Internet Explorer
(v10, 11 tested)
Firefox
Chrome
Opera
(v12.02 tested)
Safari
(v6.02 tested)
Windows
Performs transparent authentication
Performs transparent authentication (v28 tested)
Performs transparent authentication (v34, 35 tested)
Falls back to NTLM and prompts for credentials
Falls back to NTLM and prompts for credentials
Mac OS X
Not applicable
Performs transparent authentication (v28 tested)
Browser issue prevents IWA from working (v34, 35 tested)
Not tested
Performs transparent authentication
Red Hat Enterprise Linux, update 6
Not applicable
Performs transparent authentication (v28 tested)
Browser issue prevents IWA from working (v34,35
tested)
Not tested
Not applicable
LDAP support for passwords with special characters
LDAP user authentication can support passwords containing special characters.
Configuration is made directly in the records.config file.
The following parameter must be enabled, and the correct encoding name to which the special characters belong must be configured.
Add these entries to records.config. Note that the default setting is 0 (feature disabled).
// To enable the feature specify 1.
CONFIG proxy.config.ldap.proc.encode_convert INT <1 or 0>
// Specify an encoding name here. For example,
// for German specify "ISO-8859-1".
CONFIG proxy.config.ldap.proc.encode_name STRING <encoding name>
SSL Internal Root CA
It is strongly recommended that all instances of Content Gateway use the same Root CA, and that for best security the signature algorithm be SHA-2, although SHA-1 is supported.
The default Root CA (presented to clients) is signed with SHA-256.
The best practice is to replace the Websense default Root CA with your organization's Root CA signed by SHA-2 or stronger. See Internal Root CA in Content Gateway Help.
The Root CA should be imported into all affected clients.
 
* 
Note 
Client connections may fail (depending on specific browser behavior) if the client sees a certificate generated by an unknown Root CA.
Post Upgrade: Data Security
If Web Security Gateway Anywhere and Data Security are deployed together and upgraded from v7.7.x to version 7.8.x, you must remove stale entries of Content Gateway instances registered in Data Security system modules:
1.
Log onto the TRITON console.
2.
Select the Data Security tab.
3.
Select Settings > Deployment > System Modules.
4.
There are 2 entries for each Content Gateway module registered with the system. Delete the older instances. You can identify these by looking at the version number.
5.
Click Deploy.
If Web Security Gateway Anywhere and Data Security are deployed together and configured to use the on-box policy engine, and then reconfigured during upgrade or later to use the ICAP interface, the Content Gateway instance must be deleted from the list of Data Security system modules or the deployment will fail.
1.
Log on to the TRITON console.
2.
Select the Data Security tab.
3.
Select Settings > Deployment > System Modules.
4.
Locate the entry for the Content Gateway instance, click on it to open its Details page and then click Delete.
5.
Click Deploy.

Go to the table of contents Go to the previous page Go to the next page View or print as PDF
v7.8.4 Release Notes for Websense® Content Gateway : Operating tips
Copyright 2016 Forcepoint LLC. All rights reserved.