Extending your deployment with additional web protection components

Applies to:	In this topic
Forcepoint Web Security, v8.5.x Forcepoint URL Filtering, v8.5.x	Filtering Services per Policy Server Network Agents per Filtering Service Policy Server, Filtering Service, and State Server Policy Server, Filtering Service, and SIEM integration

In large, high-traffic, or geographically distributed organizations, you can deploy multiple groups of policy components, each with its own Policy Server instance, to:

Provide load-balancing capabilities.
Improve responsiveness in locations far away from the central deployment.
Manage high amounts of traffic.

When Policy Broker is installed in standalone mode, all Policy Server instances connect to the same, central Policy Broker. When Policy Broker is installed in replicated mode, you can configure how each Policy Server determines which Policy Broker instance to use.

Each Policy Server instance can support:

Up to 10 Filtering Service instances (see Filtering Services per Policy Server)
- Each Filtering Service can support up to 4 Network Agent instances (see Network Agents per Filtering Service

1 User Service
1 Usage Monitor
1 Log Server
1 State Server (see Policy Server, Filtering Service, and State Server
1 Directory Agent (Web Hybrid module only; see Directory Agent)

For high-level diagrams of larger deployments, see Web protection distributed deployments.

Filtering Services per Policy Server

As a best practice, deploy no more than 10 Filtering Service instances per Policy Server. A Policy Server instance may be able to handle more, depending on the load. If the number of Filtering Service instances exceeds the Policy Server’s capacity, however, responses to Internet requests may be slowed.

Multiple Filtering Service instances are useful to manage remote or isolated sub- networks.

The appropriate number of Filtering Service instances for a Policy Server depends on:

The number of users per Filtering Service
The configuration of the Policy Server and Filtering Service machines
The volume of Internet requests
The quality of the network connection between the components

If a ping command sent from one machine to another receives a response in fewer than 30 milliseconds (ms), the connection is considered high-quality. See Testing the Policy Server to Filtering Service connection.

If Filtering Service and Policy Server become disconnected, all Internet requests are either blocked or permitted, as configured in the Web Security module of the Forcepoint Security Manager. See Configuring your account information for details.

Filtering Service machines running behind firewalls or running remotely (at a great topological distance, communicating through a series of routers) may need their own Policy Server instance.

Testing the Policy Server to Filtering Service connection

Run a ping test to check the response time and connection between the Policy Server and Filtering Service machines. A response time of fewer than 30 milliseconds is recommended.

Open a command prompt (Windows) or terminal session (Linux) on the Policy Server machine.
Enter the following command:
```
ping <IP address or hostname>
```
Use the IP address or hostname of the Filtering Service machine.

On Windows machines, the results resemble the following:

C:\>ping 11.22.33.254
Pinging 11.22.33.254 with 32 bytes of data:

Reply from 11.22.33.254: bytes=32 time=14ms TTL=63
Reply from 11.22.33.254: bytes=32 time=15ms TTL=63
Reply from 11.22.33.254: bytes=32 time=14ms TTL=63
Reply from 11.22.33.254: bytes=32 time=15ms TTL=63

Ping statistics for 11.22.33.254:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms

In a Linux environment, the results look like this:

[root@localhost root]# ping 11.22.33.254
PING 11.22.33.254 (11.22.33.254) 56(84) bytes of data.

64 bytes from 11.22.33.254: icmp_seq=2 ttl=127 time=0.417 ms
64 bytes from 11.22.33.254: icmp_seq=3 ttl=127 time=0.465 ms
64 bytes from 11.22.33.254: icmp_seq=4 ttl=127 time=0.447 ms
64 bytes from 11.22.33.254: icmp_seq=1 ttl=127 time=0.854 ms

Ensure that Maximum round trip time or the value of time=x.xxx ms is fewer than 30 ms. If the time is greater than 30 ms, move one of the components to a different network location and run the ping test again. If the result is still greater than 30 ms, locate and eliminate the source of the slow response.

Network Agents per Filtering Service

As a best practice, deploy no more than 4 Network Agent instances per Filtering Service. One Filtering Service instance may be able to handle more than 4 Network Agents, depending on the number of Internet requests, but if Filtering Service or Network Agent capacities are exceeded, policy enforcement and logging inconsistencies may occur.

Network Agent can typically monitor 50 Mbps of traffic per second, or about 800 requests per second. The number of users that Network Agent can monitor depends on the volume of Internet requests from each user, the configuration of the network, and the location of Network Agent in relation to the computers it is assigned to monitor. Network Agent functions best when it is close to those computers.

Network Agent communicates with Filtering Service on port 15868.

Policy Server, Filtering Service, and State Server

If your deployment includes multiple instances of Filtering Service that might handle a request from the same user, an optional component, State Server, can be installed to enable proper application of time-based policy actions. (Quota time, for example, is a time-based action that can be used to give users access to websites in selected categories for a configurable time period.)

When State Server is installed, all of its associated Filtering Service instances share timing information, so users receive the correct allotment of access to time-restricted categories.

State Server is typically installed on a Policy Server machine, and only one State Server instance is required per logical deployment.
A logical deployment is any group of Policy Server and Filtering Service instances that might handle requests from the same set of users.

State Server can be enabled via the command-line interface on full policy source or user identification and filtering appliances.
All Filtering Service instances that communicate with the same State Server instance must share the same time zone, and the time on all machines must be in sync.
State Server communicates with Filtering Service on port 55828.
Each Filtering Service instance can communicate with only one State Server.
All Filtering Service instances associated with the same Policy Server must communicate with the same State Server.
Multiple Policy Server instances can share a single State Server.

In a geographically dispersed organization, where each location has its own Policy Server and Filtering Service instances, deploy one State Server instance (on the Policy Server machine or appliance) at each location.

In an organization where all requests are managed through a central location, only one State Server instance is needed.

Policy Server, Filtering Service, and SIEM integration

Web protection solutions can be configured to pass logging data (the same information processed by Log Server) and, with v8.5.4, audit log data to a third-party Security and Information and Event Management (SIEM) product.

When SIEM integration is enabled, Multiplexer collects log data from Filtering Service and passes it to both Log Server and the Bridge Service. Bridge Service then forwards it to the Event Message Brokers which allows SIEM Connectors to then send it to the integrated SIEM product.

Multiplexer is always installed on the Policy Server machine, and communicates with the following components:

Policy Server on ports 40000 and 55806
Filtering Service on port 55833 (inbound)
Log Server on port 55805 (outbound)
Bridge Service on port 55999 (outbound)