What do I do when the wrong policy is being applied to requests?

Forcepoint Web Security and Forcepoint URL Filtering | v8.4.x | 31-July-2017

When a user's requests are not managed by the expected policy, and you have confirmed that the user is being identified correctly, use these steps to help identify and resolve the problem.

Verify your subscription key.

In the Web module of the Security Manager, go to the Main > Status > Alerts page and make sure there are no subscription-related alerts in the Health Alerts Summary.

Navigate to the Settings > General > Account page and verify that your subscription key appears, the expiration date has not passed, and the number of subscribed network users is greater than 0.

Make sure the Master Database has downloaded successfully.

Check for alerts on the Status > Alerts page.

If no alerts appear, click Database Download in the toolbar at the top of the dashboard, and make sure all Filtering Service instances show a successful last download, and that all downloads happened within the last 2 weeks (14 days).

If there are any messages, or if the database is outdated, click Update to initiate a manual update.

Check for Filtering Service errors.

Look for Filtering Service alerts on the Status > Alerts page. Click the Solutions link next to any alert for troubleshooting steps.

If Filtering Service resides on a Windows machine, check the Event Viewer (Start > Administrative Tools > Event Viewer or Server Manager > Tools > Event Viewer) for Websense Filtering Service errors.

Check the websense.log file in the bin directory (C:\Program Files\Websense\Web Security\bin or /opt/Websense/bin/, by default) for EIMServer (Filtering Service) errors.

Use the TestLogServer utility to verify that Filtering Service is receiving URL requests. For instructions, see Using TestLogServer for Web Protection Troubleshooting.

If Filtering Service is not receiving Internet traffic, verify that Content Gateway, Network Agent, or your third-party integration product has been properly configured to communicate with Filtering Service.

If you have a standalone Forcepoint URL Filtering deployment, verify that Network Agent is able to see all traffic (incoming and outgoing) and that port spanning is configured.

Run the WebsensePing utility to see what happens when a user requests a site.

Open a command prompt on the Filtering Service machine and navigate to the appropriate directory (C:\Program Files\Websense\Web Security\bin or /opt/Websense/, by default).

Enter one of the following commands:

Windows (Forcepoint Web Security):

websenseping -m 18 -user <username> -url <URL>

websenseping -m 18 -uip <IPaddress> -url <URL>

Windows (Forcepoint URL Filtering):

websenseping -m 8 -user <username> -url <URL>

websenseping -m 8 -uip <IPaddress> -url <URL>

Linux (Forcepoint Web Security):

./WebsenseTools -p -m 18 -user <username> -url <URL>

./WebsenseTools -p -m 18 -uip <IPaddress> -url <URL>

Linux (Forcepoint URL Filtering):

./WebsenseTools -p -m 8 -user <username> -url <URL>

./WebsenseTools -p -m 8 -uip <IPaddress> -url <URL>

Here, <username> is the name of the user and <IPaddress> is the client IP address, depending on whether the policy is user-based or IP address-based.

A user name can be entered in Windows NT format (winNT://Test/jdoe) or LDAP format (LDAP://GC OU=Technical Support,OU=US Technical Services,DC=Test,DC=com/John Doe).

Both user name and client IP address can be entered in the same command to help make sure the information provided by WebsensePing is based on the policy that would be applied.

Review the output of the command to determine what action (disposition) would be applied and confirm the category of the URL is what you expected.

Verify that connections to the client and origin server are being closed by running a packet capture on the Filtering Service machine and on the client.

Refresh the Filtering Service user/group cache. By default, Filtering Service caches user and group information for 2 hours. The cache needs to be updated when any changes are made to users or groups.

To update the cache, go to the Settings > General > Directory Services page in the Web module of the Security Manager, then click Clear Cache.

Make sure the client machine can communicate with the Filtering Service machine.

On the client machine, open a Command Prompt and ping the Filtering Service machine.

If the ping succeeds, on the Filtering Service machine, make sure that Filtering Service (EIMServer) is listening on port 15871.

netstat -an |find "15871"

From the client, open a telnet session to the Filtering Service machine on port 15871.

telnet <ip_address> 15871

If telnet fails, ensure there are no local firewalls or devices between the client and Filtering Service that are blocking the port.

To make sure the client machine can receive a block page, go to the client machine and enter the following URL:

http://<Filtering_Service_IP_address>:15871/cgi-bin/blockpage.cgi?

If you see an Invalid Request message, Filtering Service is active and listening. This means that the client can reach Filtering Service but there may be DNS issues.

If you see a Page Cannot be Displayed message, there are connectivity issues between the machines.