KB Article | Forcepoint Support

Notes & Warnings

Check the network's topology to ensure devices (e.g. firewall, IPS, Security device) in between Network Agent and the client do not drop packets sent by Network Agent's blocking NIC because of IP spoofing. Packet captures may display successful sent reset packets and the client does not receive these packets.  If the devices are present, then either bypass or disable them to verify if they are cause.
 
Important There is also a potential for disruptions if the MAC address of the default gateway changes.

If needed, re-installation may be necessary for Filtering Service and Network Agent. For instructions, see How to re-register the Filtering Service and Network Agent.

 

Problem Description

I am running Forcepoint Web software in standalone mode and am not receiving the block page. Filtering can either be occurring or not occurring, depending on the root cause. How can I resolve this problem?

Resolution

One or more of the following suggestions may apply. Start troubleshooting with the first suggestion presented below.

Note If the websites being tested are all HTTPS, bear in mind that without SSL Decryption or a Content Gateway being used as a proxy, no block pages will be present. For more information, see No HTTPS block page is displayed.

  1. Verify the subscription key is valid.
    1. In Forcepoint Security Manager, navigate to Settings > General > Account.
    2. Ensure the subscription key showing matches the key provided by the Account Manager.
    3. Ensure the key shows that it is not expired.
  2. Verify the Master Database performed a successful download.
    1. Navigate to Main > Status > Dashboard > Database Download.
    2. Ensure the status shows a recent Checked for Updates timestamp.
    3. The Database Version can be verified from the Site Lookup tool, or by raising a case with Technical Support.
      1. Log in at the Forcepoint Support Site.
      2. Click Site Lookup Tool from Tools & Links on the right-hand side of the page and log in.
      3. Enter a fake URL in the box for lookup, such as test.com.
      4. Click Submit.
      5. Beneath the results shows: Results for Master Database 7.x are gathered from database version: ####
      6. The 8.x database matches the 7.x database version, just add a 0 to the front of the number to match what Forcepoint Security Manager shows.
  3. Verify that the expected policy is being applied.
    1. In Forcepoint Security Manager, click Test Filtering from the Toolbox.
    2. Enter a URL which should be blocked for the user in the URL field.
    3. Enter the User name (optional: click Find User to ensure the user is the correct user via the Browse Directory option).
    4. Click Go.
    5. If the site is showing blocked:
      1.  Go to Reporting > Real Time Monitor.
      2. Have the test user navigate to the blocked site on their machine.
      3. See the disposition for their block. If Real Time Monitor does not show a blocked action, follow step 4.
      4. If Real Time Monitor also shows being blocked, continue to step 5.
      5. If Real Time Monitor is showing an IP instead of a user name, see User Identification Issues.
  4. Verify the policy is configured to block.
    1. Click the Check Policy tool in Toolbox.
    2. Enter the User name (optional: click Find User to ensure the user is the correct user via the Browse Directory option).
    3. If the Policy is correct, check Policy Management > Exceptions for any exceptions for the URL used for test, or the user.
    4. If the Policy is incorrect, place the user in the correct policy within Policy Management > Clients.
  5. Review for EIMServer errors listed in the Websense.log file located in the \Websense\Web Security\bin directory. If errors are present, raise a case with Technical Support.
  6. Verify that the Blocking NIC, shown in the Manager, has a 'valid' IP address.
    1. Navigate to Settings > Network Agent > Global > the IP of the server.
    2. In single NIC environments, ensure the IP showing is correct.
    3. In multiple NIC environments, click the NIC that is not showing an IP address.
    4. Under Blocking, check the NIC showing.
    5. Press Cancel to go back.
    6. Confirm the NIC showing as Blocking has a correct IP address.
Note The Blocking NIC must have a routable IP address. If no IP address is configured, redirects cannot be injected into the traffic, resulting in no blocking.
  1. Check if any 15868 connections exist that do not originate from the Network Agent.
    1. From a Command Prompt window on the server with Filtering Service (EIMServer.exe) installed, run the following: netstat -an
    2. If there are connections over 15868 not from Network Agent, another unexpected integration may be sending WISP traffic to the Filtering Service.
    3. Disable the forwarding traffic from that integration. For example, remove the url-server command from your PIX or ASA.
  1. Run the TestLogServer utility to verify that Network Agent is receiving URL requests from the Port Mirror. See Running TestLogServer for more information.
If traffic is not generated, verify the Network Agent is set to forward URL requests to the Filtering Service.
  1. Verify the Network Agent is placed in a location where the service can see all traffic (egress and ingress) and the port span/mirror is configured.
  2. Run a WISP trace against the Filtering Service's diagnostic port to see if traffic is being sent by Network Agent.
    1. Open Command Prompt as administrator
    2. Type cd Program Files (x86)\Websense\Web Security\bin
    3. Type ConsoleClient localhost 15869
    4. When the Diagnostics options are displayed, enter 1 for Tracing.
    5. Press 8 for WISP.
    6. Press A for Set Buffer Size.
    7. Set the buffer size to 10000.
    8. Press  1 to enable tracing. Do not exit the utility.
    9. Generate traffic from the client machine, noting the URLs so that you can identify them later in the trace log file.
    10. Back in ConsoleClient, Press 1 to disable tracing.
    11. Press for Dump Decoded Buffer.
    12. Press to Dump to Local File.
    13. Type a text file name, such as: WISP.txt
    14. Press the number zero for the Format Option.
    15. Press P, then Press Q to exit ConsoleClient.
    16. Type WISP.txt to open the file in Notepad and examine the contents.
  1. Run the WebsensePing utility against a site that should be blocked. Verify the correct category and disposition. See Finding the Category of a URL with WebsensePing for additional information.
  2.  Review TestLogServer, WISP trace, and WebsensePing for “Category Blocked” dispositions.
If “Category Blocked” dispositions are generated, then verify that the connections to the client and origin server are being closed.
  1. Verify that you can retrieve the block page by pinging the Filtering Service machine from the test user machine, and running a telnet to the Filtering Service over port 15871.
  2. Enter http://<IP Address Of Filtering Service>:15871/cgi-bin/blockpage.cgi? in the browser address bar.
    • If “Invalid Request” is received, this indicates the Filtering Service is active and listening and port 15871 is open. This indicates you can reach the Filtering Service. Possible issues may include DNS.
    • If “page cannot be displayed” is received, this indicates a connectivity issue to Filtering Service.
    • Run a Network Agent debug to view data captured. See Debugging Network Agent.
      • From the debug output, review the traffic that should be blocked is captured and verify RST (resets) are displayed for these sites.
  1. Run packet captures on the client and Filtering Service at the same time to verify the 302 move is being sent from the Filtering Service and is received at the client. The following things must happen to receive a block page:
    1. A reset packet must be received on the client (Note: Websense spoofs the IP address of the webserver).
    2. A reset packet must be received from the web server.
    3. A Move 302 request must be sent to the client (this redirects the client to retrieve the block page from the Filtering Service over port 15871).
    4. An ACK packet from the client.
    5. An ACK packet from the server.
    6. Note Network Agent causes Wireshark to not function properly on open. To make a packet capture with Wireshark if Network Agent and Filtering Service are on the same server:
  1. Open Services using run command services.msc
  2. Right-click Websense Network Agent and select Properties.
  3. Change from Automatic to Disabled, then Stop the service.
  4. Restart the server.
  5. Open Wireshark and select the NIC for listening.
  6. Start the capture.
  7. Reopen Services.
  8. Right-click Websense Network Agent and select Properties.
  9. Change from Disabled to Automatic, then Start the service.
  1. Check in Triton Manager under Main > Dashboard > System > Click the IP of the Filtering Service.
  • If the filtering service says Standalone, this is the correct configuration for Network Agent's use.
  • If the filtering service says Global Integration, Content Gateway, or any other option than Standalone, this indicates the wrong version of Filtering Service has been installed. To correct:
    1. Take screen shots of the settings in Triton Manager > Settings > Network Agent > <click the IP present> of each of the different NICs as well as the configure button when highlighted so the configuration can be set back to these settings.
    2. Open the Triton Setup file used for installation
    3. Select Remove next to Web
    4. Select Filtering Service and Network Agent. (both must be uninstalled)
    5. Click Next until complete
    6. Restart the server
    7. Open the Triton Setup file
    8. Select Modify next to Web
    9. Select Filtering Service and Network Agent
    10. When asked, choose "Standalone" for the Filtering Service type
    11. Click Next until complete
    12. Reconfigure Network Agent in Triton Manager to match the settings in the screen shots made prior to reinstall. 

Article Feedback



Thank you for the feedback and comments.