Forcepoint firewall next generation

It operates on physical, virtual, cloud deployment.

It uses cloud services: file reputation, url filtering, malware detection with
sandboxing
It can integrated with FBA ( it collects the informations from forcepoint products
to perform user behavior analytics)

Advanced Evasion Prevention :

Some hackers use advanced evasion techniques: generate traffic containing a
known exploit but will send the pieces (IP diagrams, TCP segments) out of order
=> they hide the exploits by manipulating data streams==è firewall protect
against this type of attack :
- Decodes and normalizes traffic for inspection on all protocol layers
- Vulnerability-centric fingerprints detect exploits in the normalized data
streams
One software:
In multi-layer deployment, the firewall can have both 2 physical interfaces and
layer 3 physical interfaces. Choose the mode as it fits your situation.
!!!!! URL filtering requires an additional license
High Availability :
Active-active cluster: Up to 16 nodes of different models. For different versions of
FW in a cluster ( used only for online upgrade )
Firewall role: • Layer 3 access control • Full clustering capabilities • Routing,
NAT capabilities • Site-to-site and client-to-gateway VPN support • Multi-Link •
Server load balancer • Authentication • Full inspection capability • SSL VPN portal
• Can also operate at layer 2 level and run Layer 2 Firewall and IPS roles on
dedicated Layer 2 Interfaces
IPS role: • Layer 2 and Layer 3 access control • Full inspection • Serial clustering
support • IDS monitoring • Transparent mode and easy deployment (layer 2
device)
Layer 2 Firewall role: • Layer 2 and Layer 3 access control • Limited clustering
support (active/standby) • Full inspection • Transparent mode and easy
deployment (layer 2 device)
The fw is manageed with SMC. IPS includes the L2 and L3 firewalls features
Exemple : If we are using the IPS mode and we would like to switch to L2 FW , we
need to get back to the default state then move to the desired state. It’s the
same as factory resetting the firewall and doing an initial configuration. IPS can
work on a bypass mode with a failopen interface. If we want to pass from IPS
(with failopen) to firewall or L2 FW, the failopen interface will automatically
change to a failclose interface . But we recommend to change the failopen
interface to normal interface card

No need for additional patches as the patches are included in the engine
upgrades.

• Maximum Firewall Throughput (UDP 1518 byte): up to 300 Gbps

• NGFW Inspection Throughput (HTTP 64 kB payload): up to 35 Gbps
• VPN throughput: up to 150 Gbps with AES-GCM-256 encryption
• Virtual engines: up to 250
The NGFW 60 is the most compact forcepoint appliance. SMC is also available as
an appliance.
The NGFW has a Mobile VPN Client available for Windows platforms that supports
both IPSEC and SSL VPNs. VPN clients for MacOS, Android, and Linux support SSL
VPNs. Additionally, Web-based services can be remotely accessed via an SSL VPN
portal.

It offer a way to logically divide up to 250 security gateway configurations into

separately manageable instances on a single physical FW.
Virtualization system : KVM, Hyper-V, Vmware, VMware NSX integration( it
coordinates services between a software defined data center (SDDC) and NGFW,
using the NSX-V quickly deploy security services through SDDC.)

Primary way of installing the NGFW appliance : USB drive installation.

USB drive Installation detailed process:
• Appliance has pre-loaded NGFW engine
• Based upon licensing it can be configured into any of the roles previously
discussed on the features table of this module.
• Save the engine configuration to a configuration file on a USB.
• Insert the USB into the USB port of appliance prior to power-on.
• Actual connection to the appliance via monitor or serial connection is not
required

1- The administrator creates elements for the remote Firewalls and specifies
the appliance POS (Proof of Serial code) in the Firewall properties. The
 Firewalls must have a valid license bound to their POS code. In the Firewall
initial configuration settings, you must select the Upload to Installation
Server option and the Firewall policy to apply. The Management server
sends the Firewall’s initial configuration to the Forcepoint Installation
Cloud. The Installation Cloud stores the configurations and waits for
appliance contact.
2- The appliances are shipped to the remote site and cables are connected.
3. After boot up, the appliance automatically contacts the Installation Cloud
and asks if its initial configuration is available.
4. If the configuration is available, the Installation Cloud sends it to the
appliance
5. The appliance makes initial contact with the Management Server specified
in the initial configuration
6. The Management Server returns the predefined policy and configuration to
the appliance
=> In case of connection problems, Forcepoint support can check the status of
each appliance installation from the Installation Cloud

What offer the L3 FW: Layer 3 interfaces offer IPv4/IPv6 network boundaries,
NAT, authentication, routing, VPN, and deep packet inspection.
Layer 2 physical interfaces can also be configured in the Forcepoint NGFW.

Firewalls generally control traffic between:

• External networks (the Internet) and your internal networks.
• External networks (the Internet) and DMZ (demilitarized zone) networks.
• Between internal networks (including DMZs).
Key Characteristics of Layer 2 Inline Deployment:

1. Transparency: The firewall operates without requiring any changes to the network's
IP addressing scheme. Layer 2 interfaces perform transparent Layer 2
operations without the need of defining IPs or MAC addresses.
2. Bridge Mode: The firewall acts as a bridge between two network segments, allowing
it to monitor and control traffic passing through without being visible to the devices
communicating over the network.
3. No IP Address Configuration: Since it works at Layer 2, there's no need to configure
IP addresses on the firewall interfaces. This can simplify deployment, particularly in
complex network environments.
4. Traffic Inspection: Despite its transparency, the firewall can inspect, block, or allow
traffic based on policies. It can apply deep packet inspection (DPI), intrusion
prevention, and other security features to protect the network.

!!!!!!!!!! In an IPS deployment (but not a L2FW) fail-open network cards can be
used to ensure that traffic flow is not disrupted when the engine is offline.
Inline IPS and Layer 2 Firewall deployment require the configuration of inline
Layer 2 interface pair.
Layer 2 interfaces provide transparent access control and logging for any traffic
at Layer 2 and above.
Layer 2 interfaces perform transparent Layer 2 operations without the need of
defining IPs or MAC addresses.
The engine has full control over the traffic flow and can be used to block any
traffic. The inline engine can also enforce block listing commands received from
other components.

Inline deployment is good for blocking attacks if you can identify a clear threat
path
• From the Internet to the DMZ segment
• from anywhere to an important application server
• from internal networks to the Internet

 It’s IPS or layer 2 inline deployment

In multi-layer deployment, a Firewall role NGFW can have both layer 2 physical
interfaces and layer 3 physical interfaces.

Layer 2 interfaces on Firewalls allow the engine to be deployed on the network in

the same way as IPS engines and Layer 2 Firewalls

!!!!!!!!!!!!!! Layer 2 interfaces on NGFW Engines in the Firewall role provide the
following benefits: • When the same engine has both layer 2 and layer 3
interfaces, the administration is easier because there are fewer NGFW Engine
elements to manage in the SMC

• It is more efficient and economical to use one NGFW hardware device that has
both layer 2 and layer 3 interfaces because a smaller number of NGFW
appliances can provide the same traffic inspection.

• When you use layer 2 interfaces on NGFW Engines in the Firewall role, the
NGFW Engine can use options and features that are not available on NGFW
Engines in the IPS or Layer 2 Firewall roles. For example, an NGFW Engine in the
Firewall role can use Forcepoint Endpoint Context Agent (ECA), Forcepoint User ID
service, NetLinks for communication with the SMC, and dynamic control IP
addresses, while also being capable of being deployed similarly on the network
as with the IPS and Layer 2 Firewall roles.
It’s IDS or passive layer 2 firewall.

IDS or a Layer 2 Firewall in Passive mode can send block listing requests to other
NGW, but they cannot enforce block listing requests from other components.

IDS / Passive Firewall mode requires the configuration of capture Layer 2

interfaces. TCP reset requires the configuration of reset interfaces.

IDS / Passive Firewall mode is good for monitoring the traffic within network
segments:

• Complements the “radar scope” of other NGFWs.

• Worm propagation within a single segment.
• IDS can request an NGFW or Inline IPS to isolate the segment from other
networks.

IDS / Passive Firewall mode cannot make any modifications to the data stream
(SSL decryption and other similar functions are not possible
SMC: enhance network visibility with centralized monitoring auditing logging,
Configuration using flexible re-usable elements

The SMC requires a management server and at least a log server. SMC is
composed of the management server and a log server .. If a management server
or log server is not availabale, the FW still works finely since it can still control
the network traffic è if NGFW lost connectivity with SMC , NGFW will still
operate .

The Management client is the unique graphical user interface for all day-to-day
configuration and management tasks.
Either you install MC on each workstation or use the web access feature in SMC
to start and run the management client in web browser.

if you install the MC locally, you can use the same media that you used when
you installed the mngmt, log srevers. MC can be deloyed anywhere in the
network.

All commands and configuration changes are relayed through the management
server, so the management clients never connect to the NGFW Engines directly

MC connect to log server to fetch for logs. One management server can manage
different FW , it stores all the configuration information ( NGFW
roles) ,administration , system commands, monitoring , notify users with alerts,
include basic CA root certificate that issue certificate that the system
components need and also for VPN authentication.

You can use different server logs in a geographically distributed

environnement ,it can be configured to store logs from third party devices in
syslog format a

FW operates in a linux based OS, support clustering, HA(Clustering) .

Each engine node communicates with the Management Server and log Server

Web portal server( an optional component) that needs a separate license ,

provide a restricted access to log data, reports. It provides a web-based interface
that users with web portal user accounts can access with their web browsers

Communication between SMC and NGFW : TLS ( AES -256/ SHA-384)

256-bit encryption for the connections between NGFW Engines and the
management server can be enabled in one condition : Engine and management
server are version 5.5 or higher + use an Internal ECDSA Certificate Authority to
sign certificates for system communication
You can install MC on windows or linux machines. As an alternative to use the MC
locally , you can enable the SMC web access feature to start and run the
management server on a web browser. The Web Access feature can be enabled
on the Management Server and the Web Portal Server. No need to install the java
runtime to run the management client with the Web Access feature.

The web access feature on the smc can consmes a lot of ressources since many
administrators will use this feature. Forcepoint recommends to enable this
feature on the web portal servr . note that feature is limited to google chrome
and mozilla . this feature is not available on SMC appliance.

!!!! If the Management Server or Web Portal Server are installed on a Linux
platform, xvfb-run must be installed

The management server can run on different operating systems. As it offers a RESTful API ,

it allows the usage of HTTP requests ( GET, POST, PUT, DELETE)

if the number of events exceed the 500000 event capacity of a single log server, another log
server can be added => scalability. Sometimes adding additional log is necessary to meet a
legal requirement ( based on countries laws in terms of data protection). At the federal
level ,collection and use of data is regulated by FADP, OFADP

using the web portal is recommended when the SMC web access is used by
administrators. when a web browser connect remotely to SMC ( SMC web access)
, it is equivalent of using the MC running locally on the management server. The
number of resources allocated on server is the sum of the resources used by
each remote MC

centralized remote management benefits:

- Simplifies system administration
- No need to duplicate work => reduce complexity of configuration
- Remote upgrade can be downloaded and pushed automatically
- Fail-safe policy installation with automatic rollback
- You can save all the stored configuration on management server in one
manually or automatically backup.
The management server at site B is only used when there is a major incident at
site A.
Log servers can be located both at central or remote sites.
The alerts can be handled locally on each Log Server, or alternatively the alerts
can be forwarded to a different Log Server.
MC can be used at any location where they can reach management server and
log server.
With SMC version 6.7 or older another alternative to run the Management Client
is using Java Web Start. This option requires that the Java Runtime Environment
(JRE) is installed on each workstation
 -

SMC is JAVA based management system . SMC components must have the same
versions. It’s recommended to have SMC on linux os.
SMC Web Access should be used when there is a need to connect to different
SMC servers that run different versions of software. Alternatively, different client
versions can be installed to different installation directories.
The SMC components can be installed on the same system or distributed
A combination of physical and virtual servers can be used also
We can add an additional management server for HA purpose( reduce delays,
loss of configuration if the active mngmnt server Is loss or inactive.)
Also when it comes to log servers we can think abt it in term of HA , when a log
server is unavailable , NGFW can send logs to the additional log server.
The users in the HQ location connect and communicate with the real IP , the
users from the extern use the contact IP ( the address that the fw at HQ provide
to SMC which is a public IP address)
Real IP= the internal IP address
Contact IP= the public IP address

IPv4 address : the real address of the server

Contact address : default : @public, HQ location is the real address.
When an administrator inside the HQ location connects to the Management
Server, s/he uses the HQ Location to be able to browse logs. When an
administrator outside the HQ location connects to the management server, s/he
uses the HQ Firewall public address and the default location.
Location elements define when a contact address is used. The default contact
address should be the address that is most commonly used to contact the
element. For example, if in most cases the Management Server is contacted by
its NAT address, the default should be the NAT address – not the Management
Server’s own address
The SMC uses the location element to determine which IP address needs to be
used when system components connect to each other when NAT is applied
between the components

Example Scenario: Managing Multiple Clients for an MSSP

Setup

Imagine an MSSP (Managed Security Service Provider) managing network security for three
different clients: Client A, Client B, and Client C. Each client has its own network
infrastructure and security requirements.

Using SMC Domains

 1. Creating Domains:
o Client A Domain: Contains firewalls, policies, and users specific to Client A.
o Client B Domain: Contains firewalls, policies, and users specific to Client B.
o Client C Domain: Contains firewalls, policies, and users specific to Client C.
o Shared Domain: Contains common elements and policies that apply to all
clients, such as a standard security policy for email filtering.
2. Database Isolation:
o Configurations for Client A, Client B, and Client C are stored in the same
Management Server database but are isolated from each other, ensuring that
changes in Client A's domain do not affect Client B or Client C.
3. Shared Elements and Policies:
o The MSSP defines a set of security policies and elements in the Shared
Domain. For example, a baseline firewall rule set that all clients should use.
o These shared policies are inherited by the individual client domains, ensuring
consistency while allowing customization per client.
4. Administrator Permissions:
o Admin A: Has permissions only for the Client A Domain.
o Admin B: Has permissions only for the Client B Domain.
o Admin C: Has permissions only for the Client C Domain.
o Senior Admin: Has permissions for the Shared Domain and can manage
shared elements and policies.
5. Customer Access via Web Portal:
o Each client (Client A, Client B, Client C) can access a Web Portal provided by
the MSSP.
o Through the Web Portal, clients can view their own policies, reports, and logs
without accessing the SMC directly, ensuring security and privacy.

Summary

By using SMC Domains, the MSSP can efficiently manage multiple clients with a single
Management Server, ensuring each client's configurations are isolated and secure. Shared
policies and elements reduce redundancy, while specific administrative permissions enhance
security. The Web Portal provides clients with the necessary visibility into their security
posture without direct access to the SMC, maintaining a clear separation of duties and
responsibilities.
As the management server has all the configuration of all the components.
The engines contain a working copy of the configuration details that allows them
to carry out traffic inspection independently. It is not possible to extract this
information from the engines if the Management Server is lost.
We save and restore the configurations for the Management Server and Log
Server on the same physical host (for example, after a clean reinstallation) or a
different physical host (for example, after a hardware change)
If we add an additional management server then it should be a standby server.
On management server can be active. Maximum of 5 Management Servers: one
active Management Server and up to four standby Management Servers. They
are synchronized between each other incrementally in real time . you can control
the management servers through a dialog in the management client.
If an active MGTS become standby , it will release control of all the domains and
then a standby MGTS become active and take control.
Even if no MGTS is available or reacheable the fw can still operate => no
interruption in the network

We can have several backup log servers per managed FW engine.

Any log server can simultaneously act as the active log server for multiple
firewalls while also acting as a backup log server for other firewalls.
If connection with the active log server fails, logs are sent to the backup log
server. Browsing logs is exactly the same as if there were only one Log Server
since the management clients are connected to all log servers at the same time
=> all the log servers have the same contents and logs are sorted with
timestamps => no difference between how sorted the logs

Those are the steps to configure SMC administrator access : 1- create the role
Predefined roles that cannot be modified:
2-create the access control list :

Access Control Lists represent lists of elements that you can use to select the
granted elements to which the administrator rights apply.
The Access Control Lists that you create can include Firewall, IPS, Firewall Policy,
IPS Policy, Layer 2 Firewall and Layer 2 Firewall policy éléments
3-Define an administrator :
Two permissions : unrestricted for the Superuser ( account created during the
installation, he can create and modify administrator accounts ) and restricted
permissions where we need to specify the role and the elements or the access
control list.
If an administrator is allowed to view logs and alerts, you can optionally create
local filters that are applied to the log data before it is displayed to the
administrator.

In the first line in the figure , the NGFW configuration includes ( Policy
configuration, routing information, VPN configuration, engine configuration, etc.)
After the installation, the engine is ready to start processing traffic. The engines
do not have a working configuration until the first time you install a policy on
them and the working configuration is received from the Management Server
You still can view the configuration changes that you have made before the new
configuration is transferred.

We can optionally enforce an approval workflow , when it is done , administrators

with unrestricted permissions must approve the pending changes.
For the alert , we can specify which alert is triggered
Stored: log entry is generated and stored on the Log Server
Essential: When the Log Server is unavailable, log entries are temporarily stored
on the NGFW engine. When the NGFW engine is running out of space to store the
log entries, it begins discarding log data in order of importance. Essential and
alert logs are kept for the longest. When the firewall is not running out of disk
space, the Essential setting is just like the Stored setting.
Transient: A log entry is only available for immediate display in the Logs view
and is not stored. None: Rules with the None setting do not generate any log
entry at all
Logging user information requires that Access control by the user is enabled or
that the users are authenticated against the NGFW
When application Information Logging is enforced or Payload information is
enabled, the engine may send matching connections to deep inspection.
Firewalls, IPS engines, and Layer 2 firewalls send their log entries directly to the
Log Server. The Log Server either stores the entries or just relays them to be
viewed in the Logs view.
If administrative domains are configured, all log, alert, and audit entries are
domain-specific. When you log in to a domain, only the entries related to that
specific Domain can be viewed or managed. However, audit entries from all
domains are displayed to administrators that are logged in to the shared domain.

By default, log browsing uses the local time zone set in the operating system of
the computer on which the Management Client runs
Logs have two operating modes:
• In Normal mode, you can browse stored log entries freely from any time period.
• In Current Events mode, the view automatically updates to show the most
recently received log entries until you select an entry or deactivate the Current
Events mode. Both Stored and Transient log entries appear in the Current Events
mode.
You can visualize log data in four different arrangements: records arrangements,
statistics arrangements, details arrangements, log analysis
arrangements( provide tools to analyze and visualize data).

Log data context specify which type of log data is displayed in the Logs view and
in the reports view.
Loal filters used in the MC : temporary filters that they disappear when you close
the view
Permanent filters : filters that you can use anywhere in MC. There are predefined
permanent filters and you can create custom ones (view page 96)
Each policy must always be based on a Template Policy. Template Policies contain
rules that are inherited by any template or policy below it in the policy hierarchy.
Template Policies are
usually based on predefined Template Policies. None of the default Template
Policies can be modified.
 Reduce the need for creating the same rule or a similar rule in several
policies.

For each firewall role , there are predefined template policies that cannot be
modified. You can clone on it and made your change on the copied one.
For firewall role : there are Firewall Template (that has predefined access
rules to communicate with the MC and some external components) and
Firewall Inspection Template
!!!!!!!!!!!!! The Firewall Template does not enforce any inspection policy while
the Firewall Inspection Template enforces the High-Security Inspection Policy.
For layer 2 firewall role : there are layer 2 Firewall Template and layer 2
Firewall Inspection Template
For IPS role, two predefined templates: IPS template (predefined Access
rules necessary for the IPS engine to communicate with the Management
Center and some external components) + high-security IPS Template
Policy (provides an easy starting point for determining what kinds of rules
your system needs, to use IPS capabilities on FW and want to get all the traffic
inspected=è this is available for all the firewall roles )
 As said , the firewall template do not enforce the inspection policy. It use NO
inspection policy

The Firewall Inspection Template is based on the Firewall Template. It enable

the deep packet inspection
Using your own templates, you can fine-tune which parts of the permitted
traffic you want to inspect and what inspection policy you want to enforce

Firewall policy template, there are rules:

--- IPV4 insert point : It marks the places where rules are inserted in Policies or
custom Template Policies that use the Firewall Template.
--- The last rule before the end of the policy is a rule that discards all traffic and
creates a log entry that is stored. è connection dropping is logged, ( by default,
the it’s not logged)
--- Automatic Rules Insertion Point : Default automatic rules are created for
traffic to and from the engine, never for traffic that passes through the engine
--- Inspection policy : use the rules in the NO INSPECTION policy which does
not enforce any Inspection
--- The Firewall Template uses the Default File Filtering policy which applies the
advanced malware sandbox, Anti-Malware scan, and File Reputation
settings defined in the engine editor to some traffic by default

When you enable a feature that requires communication between certain

components to be allowed, rules allowing the traffic are automatically created.
Logging for automatic rules is not enabled by default, but you can modify the log
level.
Each policy must always be based on a Template Policy
Why use templates:
 reduces the need for creating the same or similar rule in several policies
 prevent modifications from unintentionally changing the main design of
your rules
Main policy : exemple : Helsinki policy, paris policy , atlanta policy
Firewall template : contains access rules necessary for system component
communication, like Firewall to SMC
Custom template: shared by all company firewall . it enable logging and prevent
the access to social media .
The main policy inherits rules from the Firewall Template, and from a customized
template
Main policy allow traffic to web server, and outbound traffic
The main policy inherits rules from the Firewall Template, and from a customized
template
Because rules are processed from the top down, rules inherited from the
templates match first.
In the custom template , there is rule from any to any with logging “stored” and
the action “ continue” è traffic is logged then sent to the next rule

In the context of Forcepoint Next Generation Firewall (NGFW), the concept of "shared rules"
with Alias elements is a method to manage IP addresses in a flexible and dynamic manner.
Here's a breakdown of the provided statement:

1. Shared Rules: These are rules that are applied across multiple components (e.g.,
firewalls, engines) within the Forcepoint NGFW system.
2. Alias Elements: Aliases are placeholders or references for IP addresses or networks.
Instead of hardcoding IP addresses directly into the rules, you use aliases to represent
these addresses.
3. Environment-Dependent IP Addresses: Different environments (e.g., different
network segments, data centers, or locations) might have different IP addresses. Using
aliases allows the same rule to adapt to different environments by substituting the alias
with the appropriate IP address for each environment.
4. Translation Values for Aliases: Each alias can be assigned a specific translation
value (i.e., the actual IP address or network) in the properties of each engine (firewall
instance). This means that an alias like Server1 might translate to 192.168.1.10 on
one engine and 10.0.0.10 on another.
5. Consistent Policy Application: By using aliases and defining their translation values
separately for each engine, you can use the same policy, policy templates, or sub-
policies across multiple engines. This ensures that the IP address information is
correctly filled in for each engine based on its environment.

Example Scenario
Imagine you have two data centers, Data Center A and Data Center B, each with its own
firewall engine:

 Data Center A:
o Alias: WebServer
o Translation Value: 192.168.10.10
 Data Center B:
o Alias: WebServer
o Translation Value: 10.1.10.10

You create a shared rule that references the alias WebServer to allow HTTP traffic.

 When this rule is applied to the firewall engine in Data Center A, WebServer
translates to 192.168.10.10.
 When the same rule is applied to the firewall engine in Data Center B, WebServer
translates to 10.1.10.10

Predefined Alias elements provided by the system start with two $$ symbols.
cannot be modified.
User-modifiable and user-created Alias elements start with one $ symbol.

the action “continue” : do not apply any access control , it is used to

 set a logging option,
  assign a Quality of Service (QoS) class,
 tag specific traffic for deep inspection.

Options set in Continue rules are used for subsequent rules that match the same
criteria as the Continue rule unless the rules are specifically set to override the
options. This way, you do not have to define the settings for each rule separately.
Exemple :

 Continue Rule:

 Criteria: Matches HTTP traffic.

 Options:
o Set logging to "Log All."
o Assign QoS class "High Priority."

 Subsequent Access Control Rules:

 Rule 1: Allows HTTP traffic from trusted IP addresses.

o This rule matches the same criteria as the Continue rule, so the logging and
QoS options from the Continue rule apply.
 Rule 2: Blocks HTTP traffic from untrusted IP addresses.
o This rule also matches the same criteria, so the logging option ensures that
blocked attempts are logged, and the QoS class is applied during the evaluation
process.

See the definition in the user guide

Here is the explanation :
In Forcepoint Next Generation Firewall (NGFW), Firewall Sub-Policies are sections of access
rules designed to improve the efficiency and manageability of policy processing. Here’s a
detailed explanation with an example:

Firewall Sub-Policies Overview

1. Modular Structure: Sub-Policies are modular sections that can be inserted into main
policies, template policies, or even other sub-policies. They help in organizing and
managing rules more effectively.
2. Not Based on Template Policies: Sub-Policies are independent and are not derived
from any template policy.
3. Restrictions: You cannot include NAT (Network Address Translation) rules or
inspection rules within Sub-Policies.
4. Administrative Control: Sub-Policies allow for better delegation of administrative
rights. Specific administrators can be granted permission to edit only certain Sub-
Policies without having access to the entire main policy.
5. Insertion via Jump Rules: Sub-Policies are integrated into other policies using Jump
rules. A Jump rule directs traffic matching its criteria to the rules defined in the Sub-
Policy.

Packet Processing with Sub-Policies

1. Top-Down Processing: The firewall processes rules from top to bottom. When it
encounters a Jump rule that matches, it transfers processing to the Sub-Policy.
2. Skipping Sub-Policies: If a Jump rule does not match, the firewall skips the entire
Sub-Policy and continues with the main policy rules.
3. Matching Jump Rules: When a Jump rule matches, the Sub-Policy is processed as if
it were part of the main policy.
4. Return to Main Policy: After processing the Sub-Policy, the firewall returns to the
main policy and continues processing from where it left off.
5. No Return to Previous Sub-Policies: To avoid continuous looping, Sub-Sub-Policies
do not return to their parent Sub-Policy.

Example Scenario

Imagine you have a corporate network with two departments: HR and IT. You want to create
separate access rules for each department within the main policy.

Main Policy

1. Rule 1: Allow traffic from the corporate network to the internet.

2. Rule 2: Jump to HR Sub-Policy (for traffic coming from HR department).
3. Rule 3: Jump to IT Sub-Policy (for traffic coming from IT department).
4. Rule 4: Default deny all other traffic.

HR Sub-Policy

1. Rule HR1: Allow HR department access to the HR application server.

2. Rule HR2: Allow HR department access to the email server.
3. End of HR Sub-Policy: Return to the main policy.
IT Sub-Policy

1. Rule IT1: Allow IT department access to the IT management server.

2. Rule IT2: Allow IT department access to the development environment.
3. End of IT Sub-Policy: Return to the main policy.

Processing Flow

1. Main Policy Rule 1: Traffic from the corporate network to the internet is allowed.
2. Main Policy Rule 2: For traffic coming from the HR department:
o If the traffic matches this rule, processing jumps to the HR Sub-Policy.
o HR Sub-Policy Rule HR1: If the traffic is for the HR application server, it is
allowed.
o HR Sub-Policy Rule HR2: If the traffic is for the email server, it is allowed.
o Processing returns to the main policy after the Sub-Policy.
3. Main Policy Rule 3: For traffic coming from the IT department:
o If the traffic matches this rule, processing jumps to the IT Sub-Policy.
o IT Sub-Policy Rule IT1: If the traffic is for the IT management server, it is
allowed.
o IT Sub-Policy Rule IT2: If the traffic is for the development environment, it
is allowed.
o Processing returns to the main policy after the Sub-Policy.
4. Main Policy Rule 4: All other traffic is denied by default.

Benefits

 Clarity and Organization: The main policy remains clean and easy to read, while
specific rules for each department are organized within their respective Sub-Policies.
 Administrative Control: HR and IT administrators can be granted permissions to
manage their respective Sub-Policies without affecting the main policy or other
departments' policies.
 Efficiency: Jump rules allow the firewall to efficiently skip entire sets of rules if the
initial criteria are not met, speeding up the processing of traffic.
Policy: it gathers rules from different policies :
 from the Template Policy
 from the Inspection Policy
 file filtering policy
rule order is so important !!!!!!!!!!!!!!!!

Rule Processing Order

1. Top to Bottom Processing:

o The firewall processes rules in the order they appear in the policy table,
starting from the top and moving downwards.

Rule Actions

2. Actions that Stop Further Processing:

o Allow: Permits traffic and stops further rule processing.
o Refuse: Denies traffic and stops further rule processing.
o Discard: Silently drops traffic without notifying the sender and stops further
rule processing.
o Use IPsec VPN with Enforce option: Enforces the use of an IPsec VPN for
the traffic and stops further rule processing.

Rule Placement

3. Placement of Rules:
o Rules with the actions mentioned above should be placed higher up in the rule
table if they are more specific in scope.
o The more specific a rule is, the higher it should be positioned to ensure it is
matched and processed before more general rules.
 o This ensures that the most specific conditions are evaluated first, which helps
in precisely controlling the traffic based on detailed criteria.

Practical Implications

 If you have a very specific rule (e.g., allow traffic from a specific IP address at certain
times), it should be placed above more general rules (e.g., allow all traffic from a
particular subnet).
 This prevents a general rule from overriding a specific rule and ensures that traffic is
managed according to the intended priority and specificity.

Ethernet Rules Overview

 Purpose: Ethernet rules are used by the Intrusion Prevention System (IPS), Layer 2
Firewall, and Layer 2 Policies in the Firewall role to define how Ethernet protocol
traffic is handled.
 Matching Criteria: These rules specify criteria and actions based on Ethernet traffic
attributes to determine whether the traffic should be allowed or discarded.

Key Points

1. Traffic Matching Based on MAC Addresses:

o Ethernet rules match traffic based on the source and destination Media Access
Control (MAC) addresses in the packets.
o Any traffic on the Ethernet network can be checked against these rules based
on MAC addresses.
2. Actions for Matching Traffic:
o Allowed or Discarded: If traffic matches an Ethernet rule, it can be either
allowed or discarded.
 o Logging and Alerts: Regardless of whether the traffic is allowed or discarded,
a matching rule can also generate log entries or alerts for monitoring and
auditing purposes.
3. Logical Interface Matching:
o Logical Interface Cell: This aspect of the rule is used to match traffic against
specific logical interfaces.
o Optional Change: It is not mandatory to specify a logical interface for the rule
to apply. If left unspecified, the rule applies to traffic across all interfaces.
o Multiple Interfaces: A single logical interface can be assigned to multiple
physical interfaces as defined in the layer 2 interface properties.
4. Further Inspection:
o IPv4 and IPv6 Access Control: After traffic is allowed by Ethernet rules, it is
then sent to the IPv4 and IPv6 access control rules for further inspection and
handling.

Practical Implications

 Fine-Grained Control: Ethernet rules allow for detailed control over traffic based on
MAC addresses, providing an additional layer of security and management.
 Versatility: These rules can generate logs and alerts, enabling better monitoring and
response to network events.
 Flexibility with Interfaces: Logical interfaces can be used to simplify rule
management across multiple physical interfaces.
 Layered Security: By combining Ethernet rules with IPv4 and IPv6 access control
rules, the firewall provides a comprehensive approach to traffic inspection and
management.

The traffic matching is based on the information in the figure

Source vpn : The VPN the traffic is coming from.
• The User Authentication which allows the creation of rules that define the end-
users who are allowed to make connections and the Authentication Methods for
the end-users.
 • The day of the week and the time of day, allowing to enforce of rules only
during certain times, such as working hours. It is also possible to specify when a
rule starts being enforced, and when each rule automatically expires. The rule
validity time can refer to the NGFW engine’s local time.

Actions:
 Allow
 Discard : The connection is silently dropped
 Refuse : connection is dropped and an ICMP error message or a TCP reset
(for TCP connections) is sent in response to the source.
 Blocklist : checks the packet against the blocklist requests received by the
engines. If the packet matches a blocklist entry, the connection is
discarded
 Jump action is used, the matching is continued in the specified sub-policy
until a match is found. If there is no matching rule in the sub-policy, the
process resumes in the main policy. If, the jump rule does not match the
matching process continues to the next rule.
 Continue: to set default values like logging or deep inspection.
Logging Options

1. Default Logging Behavior:

o By default, a rule’s logging options are undefined. This means the rule inherits
the logging options from the most recent "Continue" rule above it in the rule
table.
o If there is no previous "Continue" rule, a default "Stored-type" log entry is
created.
2. Logging for Connection Closure:
o You can configure logging for when a connection is closed. This can be set to:
 Off: No log entry is created when the connection is closed.
 On: A log entry is created when the connection is closed.
 On with Accounting Information: A log entry with detailed
accounting information is created when the connection is closed.
3. Accounting Information:
o To generate reports based on traffic volumes, you must enable the collection of
accounting information in the logging options.

Quality of Service (QoS) Class

4. QoS Class Assignment:

o You can assign a specific QoS Class to any traffic that matches an Access rule.
This helps manage and prioritize network traffic.
o The interpretation and effect of the QoS Class may vary depending on its use
in:
 QoS Policies: To control and manage network bandwidth and prioritize
traffic.
 VPN Tunnel: To prioritize traffic within a VPN.
 Outbound Multilink Elements: To manage traffic distribution across
multiple links.

Rule Identifiers
 5. Rule Name:
o Each rule has a unique identifier called the rule name, which is automatically
created and updated by the system.
o You have the option to specify a custom name for each rule for easier
identification and management.

See the details

Connection Options

Connection Tracking

 Stateful Connection Handling: This feature is enabled by default on the Next-

Generation Firewall (NGFW) and keeps track of all open connections. It works for
 TCP and can even track stateless protocols like UDP and ICMP by building virtual
connections based on packet information.
 Importance: Connection tracking is essential if you are using Network Address
Translation (NAT). It ensures that a TCP handshake is completed for TCP traffic,
maintains connection entries for other protocols, and allows reply packets without
needing explicit rules.
 Protocol Agents: If a rule has a protocol agent, additional checks are done based on
its configuration. If there is a protocol violation, the connection is dropped.

Idle Timeout

 Purpose: This is used to clear the firewall's records of old connections that are no
longer active to free up resources.
 Recommendation: Avoid setting excessively long timeouts to prevent
overconsumption of firewall resources.

Synchronize Connections

 Definition: This option determines whether connections matching the rule are
synchronized to other nodes in a cluster, ensuring consistent state across the firewall
cluster.

Enforce TCP Maximum Segment Size (MSS)

 Definition: This option defines whether the NGFW enforces a minimum or maximum
size for the TCP MSS, which is the size of the payload of a packet (excluding
headers).

DoS protection Options

 Connection Limiting is an efficient way to prevent denial of service

attacks, and because the limit can also be set per destination IP address, it
provides protection against distributed denial of service attacks as well.
 You can enable or disable rate-based DoS protection and scan detection at
the rule level if they have not been disabled in the properties of individual
Security Engines.

Summary

These options provide advanced controls for managing connections through the firewall,
ensuring efficient and secure handling of traffic while optimizing resource usage and
maintaining consistency across clustered nodes.
User Responses allow you to send a customized reply to the user instead of just
ending the connection when an HTTP or HTTPS connection is not allowed to
continue. This makes it possible to explain to the user why the connection was
stopped, instead of simply closing the connection with no notification. User
Responses can be used in Access Rules and in Inspection Policies. You can define
a different User Response entry for each of the following cases in which an HTTP
or HTTPS connection is not allowed to continue:
• Connection Blocklisted: (HTTP only) The connection was discarded according
to a rule with the Apply Blocklist action.
• Connection Discarded by Access Rule: The connection was dropped
according to an Access rule with the Discard action.
• Connection Terminated by Inspection Rule: The connection was terminated
according to the Inspection Policy.
• URL Not Allowed: The connection was terminated by one of the special URL
filtering situations.
• Virus Found: The Anti-Virus feature found a virus on the web page.
Static Source NAT

Purpose: Static Source NAT translates the internal (real) IP address of a host on an internal
network to a different IP address on an external network. This is useful when an internal
device needs to communicate with external networks, such as the internet, using a consistent,
predefined external IP address.

Key Points:

1. Consistent Translation:
o With Static Source Address Translation, the IP address of a particular host is
always translated to the same specific external IP address.
o The internal source IP address (the actual IP address assigned to a device on
the internal network or DMZ) is translated to a public IP address. This public
IP address is part of a range assigned by the Internet Service Provider (ISP).
2. Network-Level Translation:
o Static translation can be defined for individual hosts or for entire networks,
provided the internal and external networks are the same size.

Process Explanation:

1. Initial Packet:
o Step 1: A packet is sent from an internal source (SRC) to an external
destination (DEST). The packet contains the internal source IP address.
2. Address Translation:
o Step 2: The firewall intercepts the packet and replaces the internal source IP
address with a new source address (the predefined public IP address).
3. Server Response:
o Step 3: The external server receives the packet with the new source address
and sends a response back to this new source address.
4. Reply Packet Translation:
o Step 4: The firewall uses connection tracking information to automatically
translate any reply packets. When the server responds, the firewall replaces the
 destination address in the server’s response with the original internal IP
address of the host. This ensures that the response packet is correctly routed
back to the internal host.

Dynamic Source NAT Overview

 Purpose: Dynamic Source NAT (Network Address Translation) translates the internal
IP addresses of several internal hosts to one or a few external IP addresses. This helps
to:
o Hide the internal network structure from outsiders.
o Avoid the need for a separate public IP address for each internal host.
 Functionality:
o Translation: Many internal IP addresses are translated to a smaller pool of
external IP addresses, sometimes even to a single IP address.
o Use Case: Commonly used to mask the internal networks of a company behind
one or a few public IP addresses provided by an Internet Service Provider
(ISP).

How Dynamic Source NAT Works

1. Translation Process:
o When an internal host sends a packet, the firewall translates the source IP
address to an external IP address.
o The firewall also assigns a translated source port to the packet.
2. Handling Reply Packets:
o When the server replies to the packet, it sends the response to the translated IP
address and port.
o The firewall uses this translated port to identify the correct internal host.
o The firewall then translates the destination address and port in the reply packet
back to the original source address and port of the internal host.

Important Considerations

 Avoid Mixing NAT Types:

o Do not use the same NAT address for both dynamic and static NAT.
 o The Cluster Node-Dependent Interface (NDI) address must not be used as a
NAT address.
o If a node is switched off, the translated address will no longer be available if
the NDI address was used.

Static Destination NAT

Purpose: Static destination NAT (Network Address Translation) allows an internal host (like
a server) with a private IP address to be accessible from external networks (like the Internet)
by translating its private IP address to a public IP address.

How It Works

1. External Connection to Public IP:

o An external host (e.g., a computer on the Internet) wants to connect to a server
on your internal network.
o The external host sends a connection request to the server's public IP address.
2. Translation to Private IP:
o The firewall receives the request and translates the destination public IP
address to the server's private IP address on the internal network.
3. Server Response:
o The server on the internal network processes the request and sends a response
back to the external host.
4. Translation Back to Public IP:
o The firewall translates the source private IP address of the server's response
back to the public IP address before sending it to the external host.

Key Points

 Static Destination Translation: This can be done for individual IP addresses and
ports or for entire networks of the same size.
 Example:
o Step 1: An external host connects to the server's public IP address.
 o Step 2: The firewall translates this public IP address to the server's private IP
address.
o Step 3: The server responds to the request.
o Step 4: The firewall translates the server's private IP address back to the public
IP address for the response.

Definition: Proxy ARP allows a device (in this case, the firewall) to respond to ARP requests
on behalf of another device on the network. This is particularly useful in network address
translation (NAT) scenarios.

When Network Address Translation (NAT) is Used:

 Default Behavior: The firewall is configured to use proxy ARP by default. This
means it can answer ARP requests for NAT pool addresses.
 Configuration: Proxy ARP is enabled by default in the NAT settings for each
translation type, but it can be disabled if needed.

Example Scenario:

When a Host on the Internet Connects to a Server on the Internal Network:

1. Internet Host Sends TCP SYN:

o A host on the Internet sends a TCP SYN packet to the destination IP address
212.20.1.100, which is the public (translated) address of a web server located
in the DMZ (Demilitarized Zone).
2. Internal Server's Real Address:
o The actual (real) address of the web server is 192.168.1.101. When the HTTP
packet reaches the router, the router needs to know the MAC address
associated with the IP address 212.20.1.100.
3. Router Sends ARP Request:
 The router sends an ARP request asking "Who has IP address 212.20.1.100?
o
Please send me your MAC address."
4. Firewall Responds with Proxy ARP:
o Because Proxy ARP is enabled for this address on the firewall, the firewall
responds to the ARP request with its own MAC address. This makes the router
believe that the IP address 212.20.1.100 is associated with the firewall's
MAC address.
5. Packet Sent to Firewall:
o The packet is then sent to the firewall. The firewall translates the destination IP
address from 212.20.1.100 to the real address 192.168.1.101 based on the
NAT rules and forwards the packet to the actual server.

NAT Rules in Firewall Policy

Overview

 NAT (Network Address Translation): This process changes the source and/or
destination IP addresses in packets to different IP addresses. This can help with
various network configurations, such as hiding internal IP addresses or allowing
multiple devices to share a single public IP address.

How NAT Rules Work

 Order of Operations: NAT rules are applied after access rules. This means that a
connection must first be allowed by the access rules before it can be matched to a
NAT rule.
 Rule Order: NAT rules are matched from top to bottom, so they should be ordered
from the most specific to the least specific. This ensures that the most precise rules are
applied first.
No NAT Cell

 Definition: A NAT rule with no NAT cell specified means that no translation is done
for the matching traffic. This can be useful for allowing certain traffic to pass through
without any IP address changes.

Element-Based NAT Rules

 Properties-Based Definitions: NAT rules can also be defined within the properties of
a firewall element. These rules are automatically generated but are not visible in the
main firewall policy.
 Application Order: These automatically generated NAT rules are applied after the
manually added NAT rules in the policy. Therefore, a more specific manual NAT rule
can override an element-based NAT rule.

NAT and VPNs

 Default Behavior: By default, NAT is disabled for connections traversing a VPN.

This means that NAT rules are ignored for VPN traffic.
 Enabling NAT for VPNs: If you want NAT rules to apply to VPN traffic, you need to
enable NAT in the properties of the VPN element.

Summary

 NAT rules in Forcepoint firewall policies change IP addresses in packets to manage

network traffic.
 NAT rules are applied after access rules, and the order of NAT rules matters (more
specific rules should come first).
 A NAT rule without a NAT cell means no translation is done for that traffic.
 Element-based NAT rules are not visible in the main policy and are applied after
manual rules.
 NAT is disabled by default for VPN traffic but can be enabled if needed.
Matching Criteria in NGFW Policy

 Access Rules: Administrators can define various criteria for access rules, which
determine how connections are handled.
 Matching Criteria: These include:
o Zone Matching: Identifying traffic based on network zones.
o User Identification: Identifying traffic based on user information.
o IP List: Matching traffic based on specific IP addresses.
o Countries: Matching traffic based on geographic location.
o DNS Names: Matching traffic based on domain names.

These criteria allow for very detailed control over which connections are allowed or blocked.

Operating Modes

 Stateful Mode (Default):

o Functionality: This mode tracks the state of network connections and can
control connections based on:
 Protocol-Specific Information: Information specific to the network
protocol in use.
 Network Application Usage: The applications being used over the
network.
 Requested URL: The URLs being accessed.

This mode ensures that only legitimate and expected traffic is allowed through, based
on the state of the connection.

 Proxy Mode:
o Additional Security: This mode provides higher levels of security and control
over the connections.
 In proxy mode, the firewall acts as an intermediary between the client and the server,
inspecting and filtering traffic more thoroughly.

Deep Inspection and File Filtering

 Vulnerability and Malware Inspection: To inspect traffic for vulnerabilities and

malware:
o Tagging: Traffic allowed by access rules must be tagged for deep inspection.
o Matching: This tagged traffic is then matched against inspection policies and
file filtering policies.

Service Elements and Protocols

Matching Traffic

 Service Elements: These match network traffic based on specific protocols (like TCP
or UDP) and ports (like port 80 for HTTP).
 Protocol Set Options: These provide advanced inspection of traffic, allowing for
application-layer validation and handling of related connections.

Service with Protocol

 Association: When you link a Service element to a Protocol element, it becomes a

"Service with Protocol" in the system. This is also known as a protocol agent.
 Advanced Handling: A Service with Protocol allows the firewall to perform more
detailed inspection and handling of traffic. For instance, it can ensure that the traffic
adheres to the expected behavior of the protocol.
 Additional Options: Some Protocol elements have extra settings that you can
configure in the Service element’s properties for finer control over traffic inspection.
Default and Custom Service Elements

 Default Service Elements: Typically, you can use the pre-configured Service
elements for common protocols and ports without any changes.
 Customization: If needed, you can duplicate a predefined Protocol Agent and adjust
its parameters to meet specific needs or requirements.

Summary

These settings enable the Forcepoint firewall to effectively manage and inspect network
traffic by associating services with protocols. This association allows for deeper inspection
and validation, ensuring that traffic complies with expected protocol behavior. The ability to
customize these elements provides flexibility to address specific security needs.

Protocol Validation

FTP Protocol Agent

 Purpose: This agent can strictly enforce which commands are allowed within an FTP
control connection.
 Function: It limits commands to only those defined in the FTP standards.
 Action: If any non-standard commands are sent, the connection is dropped.

Oracle Protocol Agent

 Purpose: This agent controls the specifics of Oracle network traffic.

 Function: It can control the size of Oracle TNS (Transparent Network Substrate)
packets and manage the location of the Listener service relative to the database
services.
 Action: This ensures that Oracle traffic adheres to expected parameters and
configurations.

SSH Protocol Agent

 Purpose: This agent ensures the proper establishment of SSH connections.

 Function: It verifies that the SSH handshake is performed correctly at the beginning
of an SSH connection.
 Action: This helps ensure that the SSH connection is secure from the start.

SIP (Session Initiation Protocol)

 Requirement: SIP connections need to comply with RFC 3261.

 Function: This RFC (Request for Comments) is a standard that defines how SIP
connections should be established and managed.
 Action: Ensuring adherence to RFC 3261 helps maintain the integrity and proper
functioning of SIP communications.
Sidewinder Proxies :
 Enforce protocol validation
 restrict the allowed parameters for each protocol
 used in high-assurance environments: government or financial institutions.
 Used for data loss prevention: limit access to external network or between
network
 Supported sidewinder proxies: HTTP, HTTPS, FTP, TFTP, SSH, DNS, TCP, and
UDP
 Also supported as virtual NGFW Engine in fw/vpn role
Access Rules: These elements can be used in the Source and Destination
fields of access rules. This means you can create firewall rules based on
domain names rather than fixed IP addresses
DNS Resolution: the firewall periodically queries these DNS servers to
automatically resolve (convert) domain names into IP addresses.
Multiple IPs: If the DNS server returns multiple IP addresses for the same
domain name, the firewall associates all those IP addresses with the domain
name. This means the rule will apply to any of the resolved IP addresses.
Cache Storage: Once a domain name is resolved to an IP address, this
information is cached (temporarily stored) in the firewall engine. The cache is
updated regularly by default every 6 minutes.
A Zone is essentially a label or tag that you can assign to a physical interface
or a VLAN interface on your firewall.
Purpose : logically group several firewall interfaces together è manage
interfaces as single entity
Create a policy : apply it to a zone rather than a single interface. All the
interfaces belonging to the zone will apply this policy
When u add interface to existing zone: the policy will be applied automatically
to the new interface

Country Elements: These are lists of IP addresses associated with specific

countries based on geolocation information
Grouped by Continents: country elements are organized into larger groups
based on continents.
Used in those policies:
  Access Rules : based on the source, destination country or continent
 NAT Rule: handle traffic differently based on geographic origin.
 Inspection Rules
 File filtering rule
!!! You cannot create or edit country elements or continents. These elements are
predefined by the system.

URL filtering is used to control which websites end-users can access. It does this
by comparing the URLs users try to visit against predefined categories or lists of
URLs.
URL filtering: is used to control which websites end-users can access. It does this
by comparing the URLs users try to visit against predefined categories or lists of
URLs.
You can manually configure lists of specific URLs to block or allow.
!!!!!!!!!!! If you want to block a category like "social media" but still allow access
to a specific social media site for business purposes, you can block the category
but manually allow the specific site.
Forcepoint™ ThreatSeeker® Intelligence Cloud service provide URL
categorization, categories for malicious websites

In Forcepoint firewall and other security appliances, the concept of using Server Name
Indication (SNI) in HTTPS traffic for URL categorization without decrypting the HTTPS
connection is a way to identify and categorize web traffic while maintaining user privacy and
minimizing performance overhead.

Key Concepts

1. HTTPS and Encryption: HTTPS (Hypertext Transfer Protocol Secure) is a protocol

for secure communication over a computer network. It encrypts the data transmitted
 between the web browser and the web server to ensure privacy and security. However,
this encryption also means that intermediary devices like firewalls cannot see the full
URL or the content of the communication without decrypting it.
2. Server Name Indication (SNI): SNI is an extension of the TLS (Transport Layer
Security) protocol. When a web browser initiates an HTTPS connection, it includes
the hostname (server name) of the server it wants to connect to in an unencrypted part
of the request. This allows the server to present the correct SSL/TLS certificate for the
website the user is trying to access.

How SNI is Used for URL Categorization

1. Reading the SNI Field: The Forcepoint firewall can inspect the SNI field in the initial
handshake of the HTTPS connection. Since this part of the communication is not
encrypted, the firewall can see the server name (e.g., www.example.com).
2. URL Categorization: Based on the server name extracted from the SNI field, the
firewall can perform URL categorization. This means it can identify the type of
website or service the user is accessing (e.g., social media, news, shopping) without
needing to decrypt the entire HTTPS traffic.
3. Policy Enforcement: Once the server name is categorized, the firewall can enforce
policies based on this information. For instance, it can allow, block, or log access to
certain categories of websites according to the organization's security policies.

Example Scenario

1. User Access: A user tries to access https://www.example.com through their web

browser.
2. Initial Handshake: During the TLS handshake, the browser sends the server name
(www.example.com) in the unencrypted SNI field.
3. Firewall Inspection: The Forcepoint firewall intercepts the handshake and reads the
SNI field to determine the server name.
4. Categorization: The firewall checks its database to categorize www.example.com
(e.g., as a news website).
5. Policy Application: Based on the categorization, the firewall applies the relevant
policy (e.g., allowing access to news websites).
6. Continued Secure Connection: The HTTPS connection proceeds without decryption,
preserving the security and privacy of the user's session.
the Endpoint Context Agent (ECA) is a Windows client application designed to
provide detailed endpoint information to the firewall.
ECA collects and sends endpoint information to the Forcepoint NGFW.
Used to :
 identify users, log their actions, and control access
Firewall can create rules based on those metadata sent by the ECA

Predefined Applications and Standard Ports

Forcepoint provides a set of predefined application elements that are continuously updated to
include criteria for matching popular applications. These applications have their standard
ports predefined. If you need to override these predefined ports, you can edit the Service
Definition in the rule where you are using the Network Application.

Matching Based on Payload

The firewall matches the application based on the payload of the packets. This means the
firewall inspects the actual data being transmitted to identify the application, not just the port
or protocol.

Handling TLS Traffic

Forcepoint Firewalls use predefined TLS Match elements to identify applications without
needing to decrypt the TLS traffic. These elements can match traffic based on:

 Certificate Validation: Whether it succeeded, failed, or was not performed.

 Server Domain Name: In a valid certificate, allowing the firewall to identify
applications based on the domain name presented by the server.
 Reasons for Invalid Certificate: If certificate validation fails, the specific reason can
be used for matching.
 SNI Field: The domain name specified in the Server Name Indication field of the TLS
Client Hello packet. This is useful for identifying the intended destination of the
encrypted traffic.

Using Tags for Policy Simplification

Tags are used to group Network Application elements, simplifying the creation and
management of policies. For example, a Media Tag might include applications related to
images, music, and videos. Tags can represent multiple applications, and several tags can be
associated with a single Network Application element, making policy creation more efficient
and easier to manage.

Example Scenario

Let's say you want to create a firewall rule to allow traffic for streaming media applications:

1. Use Predefined Applications: Leverage predefined application elements for popular

streaming services.
2. Override Ports: If needed, adjust the default ports in the Service Definition.
3. TLS Matching: Use TLS Match elements to identify streaming services even if the
traffic is encrypted.
4. Apply Tags: Apply a Media Tag that includes all relevant streaming applications to
simplify policy creation.
The system IP Address List elements are imported and updated when you
activate new dynamic update packages

In Forcepoint Next-Generation Firewall (NGFW) inspection, two primary techniques are

employed to detect and respond to security threats: misuse detection and malware detection.
Here is a detailed yet concise summary of these techniques:

Misuse Detection

 Based on Signatures: This method relies on a database of signatures or fingerprints of

known attacks.
 Traffic Comparison: Incoming and outgoing traffic is compared against these
signatures. If a match is found, a predefined response is triggered to mitigate the
threat.
 Limitations:
o Unseen Attacks: Attacks that do not have existing signatures go undetected.
 o Altered Traffic: Attackers might modify the traffic to evade detection, making
it difficult to directly compare with known signatures.
 Traffic Normalization: To address the issue of altered traffic, the NGFW performs
traffic normalization. This process removes ambiguities and standardizes the traffic
format before comparison with signatures, enhancing the accuracy of misuse
detection.

Malware Detection

 File Extraction: The NGFW can identify and extract files from the traffic stream for
detailed security analysis.
 File Reputation Check: The extracted file’s reputation is checked by querying the
Global Threat Intelligence cloud. This cloud-based service provides information on
known malicious files.
 Antivirus Check: The file is scanned using an antivirus engine to detect known
malware based on virus definitions and signatures.
 Advanced Malware Analysis:
o Cloud Sandbox: For files that are suspicious or not recognized by reputation
checks and antivirus scans, the file is sent to the Forcepoint cloud sandbox.
o Dynamic Sandboxing: This involves executing the file in a controlled,
isolated environment to observe its behavior and detect malicious activities
indicative of zero-day threats (new, previously unknown threats).
o Static Inspection: The code within the file is also inspected without executing
it, looking for suspicious patterns and anomalies that suggest malware.

Protocol Validation

1. Conformance to Protocol Standards:

o Ensures that network traffic adheres to the established standards defined in the
relevant Request for Comments (RFC) documents.
o Helps in identifying and blocking traffic that deviates from these standards,
which could be indicative of malicious activity or malformed data.
2. Zero-Day Attack Detection:
o Capable of detecting previously unknown types of attacks (zero-day attacks)
by recognizing traffic patterns that do not conform to expected protocol
standards.
o Adds an extra layer of security by catching new and emerging threats that
traditional signature-based detection might miss.
3. Handling Legitimate Deviations:
o Recognizes that some legitimate applications might not strictly adhere to
protocol standards, either due to design flaws or intentional deviations to
bypass certain limitations.
o Ensures flexibility in handling such traffic without compromising security.
4. Protocol Enforcement:
o Prevents unwanted tunneling through open ports, such as using DNS for non-
DNS traffic (e.g., Deny Dynamic DNS updates, Deny DNS zone transfers).
o Currently implemented for DNS, helping to secure the network by enforcing
proper use of the DNS protocol.
Protocol Anomaly Detection

1. Attack Detection Beyond Protocol Violations:

o Acknowledges that many attacks exploit ambiguities in protocol standards
without technically violating them.
o Focuses on detecting these subtle anomalies to enhance security.
2. Traffic Normalization:
o IP Fragmentation Handling:
 Collects, reorders, and validates IP fragments to ensure they are
correctly formed.
 Drops malformed or overlapping IP fragments that could be used for
attacks.
o TCP Segment Reassembly:
 Reassembles TCP segments into a continuous data stream.
 Drops out-of-order or overlapping TCP segments with conflicting
content to prevent potential exploitations.
3. Stateful Inspection:
o Protocol validation includes tracking the state of connections, ensuring that
only valid state transitions occur.
o Adds an additional layer of inspection by considering the connection's state,
enhancing the ability to detect and prevent attacks.

Advanced Evasion Techniques (AETs) in Network Security

1. Basic Evasion:
o Traffic Slicing: Network traffic containing exploits can be split into pieces and
sent out of order. This exploits the Internet's ability to handle out-of-order data
delivery, relying on the destination to reassemble the pieces.
2. Evasion Techniques:
o IP Fragmentation: Breaking IP datagrams into smaller fragments and sending
them out-of-order to evade detection.
o TCP Segment Duplication: Duplicating TCP segments and potentially
sending them in different sequences.
 o Compressed HTTP: Using HTTP compression to hide malicious payloads.
3. Combination of Techniques:
o Advanced Evasion Techniques (AETs): When multiple evasion techniques
are combined, they become more sophisticated and harder to detect.
4. Virtual Patching:
o A method to temporarily protect against known vulnerabilities by blocking
attack vectors using NGFW or IPS inspections.
o Limitation: AETs can bypass virtual patching by evading the inspection
processes designed to protect against these vulnerabilities.
5. Traffic Normalization:
o The key to detecting AETs is to reassemble the data stream before inspection.
o This process ensures that fragmented and out-of-order data is reconstructed to
accurately detect malicious content.

Example of AET: IP Fragmentation

 When IP datagrams are too large for a network path, they are split into smaller
fragments.
 A common evasion method involves sending these fragments out-of-order to bypass
security measures.

Conficker Worm Fragmentation Evasion

 Memory Limitation: Network security devices can only keep connection data in
memory for a limited time (typically about seven seconds) due to handling millions of
connections every second.
 Fragmentation Evasion: If the Conficker worm is split into two fragments and sent
with a delay of ten seconds between them:
o Initial Detection: The device detects the first fragment and waits for the
second.
o Memory Reset: After seven seconds, the device clears the memory of the first
fragment.
o Evasion Success: When the second fragment arrives, the device no longer
remembers the first, allowing both fragments to pass through undetected and
exploit the target device.

Out-of-order or overlapping TCP segments are techniques that can be used for evasion in
network traffic:

1. TCP Data Transmission:

o Once a TCP connection is established, each endpoint can send data.
o This data is wrapped into TCP segments and transmitted as IP datagrams.
2. Segment Order and Duplicates:
o TCP segments may arrive at the destination out of order.
o Duplicate segments can also occur.
3. TCP Evasion Techniques:
o Out-of-order segments: Attackers send TCP segments out of order to confuse
the receiving system.
 o Overlapping segments: Attackers send overlapping TCP segments with
conflicting content to exploit ambiguities in how different systems handle
these overlaps.

Compressed HTTP Handling:

 Hidden Attack Detection: Forcepoint NGFW recognizes that attacks can be

concealed within compressed HTTP data. To detect such threats, the firewall ensures
that HTTP data is decompressed before inspection.

Traffic Normalization and Inspection:

 Normalized Stream Analysis: Instead of processing individual packets, Forcepoint

NGFW analyzes data as a normalized stream. This approach helps in detecting
exploits hidden within the data stream.
 Handling IP Fragments and TCP Segments:
o Well-Formed Data: Well-formed IP fragments and TCP segments are passed
through with minimal or no modification.
o Dropped Conflicting Data: Fragments or segments containing conflicting or
overlapping data are dropped to prevent potential exploits.
 Unique Data Reconstruction: The firewall ensures a unique way to reconstruct the
data stream at lower protocol layers, enhancing its ability to interpret network traffic
accurately.

Advanced Evasion Technique Management:

 Blocking Techniques: Forcepoint NGFW employs traffic normalization techniques to

effectively block advanced evasion techniques (AETs). These techniques are designed
to circumvent traditional security measures but are countered by the firewall’s ability
to accurately reconstruct and inspect data streams.

Detail Example:

Using Advanced Evasion Techniques (AETs) as an example:

 Forcepoint NGFW manages to block these sophisticated attacks by:

o Ensuring that well-formed IP fragments and TCP segments are allowed
through for inspection.
o Dropping fragments or segments that contain conflicting or overlapping data,
which could potentially be used to evade detection.
o Normalizing the data stream to provide a consistent and accurate interpretation,
thereby enhancing its ability to detect and prevent hidden exploits within
compressed HTTP data.

IP fragmentation occurs when large IP packets are broken down into smaller fragments for
transmission across networks with smaller Maximum Transmission Units (MTUs). The
NGFW addresses this through:

1. Fragment Collection and Reordering:

 o Collection: Gathers all fragments of an IP packet arriving out of order or in
separate pieces.
o Reordering: Reassembles these fragments into complete IP datagrams before
inspection.
2. Validation Before Inspection:
o Ensures that only fully reassembled IP datagrams undergo inspection.
3. Detection and Handling of Issues:
o Malformed Fragments: Identifies and drops fragments that do not adhere to
IP standards, which could indicate attempts to exploit network vulnerabilities.
o Overlapping Fragments: Detects and rejects fragments that overlap or
contain conflicting data, preventing potential security breaches.

Compressed HTTP
If the HTTP data is compressed in the client stream, the NGFW decompress it
before fingerprinting.

TCP Stream Reassembly

Key Detail:

 Data Stream Inspection: NGFWs inspect the actual data transmitted within TCP
connections rather than inspecting individual TCP packets or segments. This involves
assembling TCP segments into a complete data stream before content inspection.
 Buffering and Protection: TCP segments are buffered until the receiving endpoint
acknowledges them. This prevents network vulnerabilities that could arise from out-
of-order TCP segments or segments that overlap with conflicting content

TLS Inspection allows for the decryption of TLS connections to inspect traffic for
malicious content. Once inspected, the traffic is re-encrypted before reaching its
destination. This can be applied to both outgoing and incoming TLS connections,
enhancing security for both clients and servers
 TLS Inspection can be configured for client-only, server-only, or both client and server
protection.
 Client Protection focuses on outgoing traffic, safeguarding internal users.
 Server Protection focuses on incoming traffic, securing web services

See the details :

Limitations of Snort Inspection

1. Unsupported Environments:
o Master NGFW Engines and Virtual NGFW Engines: Snort inspection is not
supported.
o Capture Interfaces: Snort inspection is not supported.
2. VLAN Interfaces:
 o Snort inspection is supported, but rules are applied to traffic without
differentiating based on VLAN tags.
3. Logical Interfaces:
o Overlapping IP Address Spaces: Traffic might not match Snort rules as
intended if logical interfaces with overlapping IP address spaces are used as
matching criteria in IPS or L2FW Access rules.
4. Service Matching:
o Payload-Based Matching: Not recommended to use services that match based
on the payload of connections (e.g., Network Applications, URL Categories, or
URL List Applications) in Access rules selecting traffic for Snort inspection.
5. TLS Inspection:
o Decrypted Traffic: Snort inspection cannot be applied to traffic that has been
decrypted for TLS inspection.
6. Failure Handling:
o Default Action: If Snort inspection fails, the traffic is allowed by default.
7. Rule Set Updates:
o Manual Updates: NGFW Engines do not receive automatic updates for Snort
rule sets. Administrators must manually import new Snort configuration files
and refresh the policy on the NGFW Engine to apply new rule sets.
Redirection of web traffic is done transparently and configured in the access rule.
The “forward to proxy” allow action option must be selected and the proxy server
configured with Forcepoint Cloud Security Gateway settings
Forcepoint NGFW redirects web traffic to the Cloud Security Gateway using the
“Easy Connect” proxy redirection features or using a predefined policy-based VPN
To use the Forcepoint Cloud Security Gateway to inspect web traffic, you must
have a subscription to the Forcepoint Cloud Security Gateway service
Activating deeper packet inspection impacts resource consumption and
throughput
It's crucial to selectively send traffic for deep inspection to balance security and
performance.
Offloading tasks like file reputation and malware analysis to external
components, such as a cloud sandbox, can save NGFW resources and maintain
performance.
Process Flow:

 Access Control Filtering: Initially filters traffic and controls connections.

 Deep Inspection: Allowed traffic is then deeply inspected for vulnerabilities and
malware.
 Traffic Normalization: Prepares traffic for inspection by neutralizing advanced
evasion techniques (AETs).

If only basic access control is configured to allow traffic from an external network
to a web server located in (DMZ). Only checks IP addresses and ports,
No deep inspection enabled : no analysis of the content of the data packets,
can’t examine the content of the packets => potential exploit for the
vulnerabilities of the server, run malicious commands on the server
With deep packet inspection activated, Forcepoint NGFW examines the content of
the traffic (header and payload)
The HTTP traffic is matched against the inspection policy that detects the transfer
of the malicious string and drops the connection
NGFW provides full deep inspection functionality, and this is included in the
NGFW license
System fingerprint situations correspond to known exploits.
A situation and vulnerability description is attached to each system fingerprint
situation.

Access control rules : These rules set the criteria for what traffic will be inspected.
For example, you might have a rule that inspects all incoming HTTP traffic.
Inspection policy : Each rule points to a specific policy that dictates how the
traffic should be inspected. This policy will contain various checks and actions
based on the type of traffic and potential threats.
Protocol-Based Inspection: The protocol associated with the service element
(like HTTP, FTP, etc.) determines the nature of the inspection. Different protocols
might have different inspection requirements.

Packet Payload Examination: The inspection policies look at the actual data being
transmitted (the payload) rather than just the metadata (like headers).

Whole Connection Analysis: Instead of just examining individual packets, the policy looks
at the entire connection to identify threats.

Predefined Policies in SMC: The predefined policies in the SMC are templates or starting
points that can help you set up your system's inspection rules. They are designed to cover
common scenarios and can be customized as needed.
The Firewall Inspection Template that enables deep inspection for all traffic is based on the
Firewall Template

It uses inspection rules defined in the High-Security Inspection Policy

an easy starting point to use the deep inspection you can use Firewall Inspection Template

Using your own templates or policy, you can fine-tune which parts of the permitted traffic
you want to inspect and what inspection policy you want to enforce

the difference between a Firewall Template and an NGFW (Next-Generation Firewall)

Inspection Template in Forcepoint firewall, we will focus on the Firewall Inspection
Template. Here’s a detailed summary:

Firewall Template
  Purpose: The Firewall Template is primarily focused on establishing the necessary
communication rules between the firewall and the Security Management Center
(SMC).
 Functionality: It contains automatic access rules that allow the firewall to
communicate with the SMC and, by default, deny all other traffic. This ensures that
the firewall is securely managed and controlled through the SMC.

NGFW Inspection Template

 Purpose: The NGFW Inspection Template, specifically the Firewall Inspection

Template, is focused on deep inspection of traffic.
 Functionality:
o Deep Inspection: By default, it enables deep inspection for all supported
protocols. This means that traffic is thoroughly analyzed for any threats or
anomalies.
o Continue Rules: Deep inspection is applied through "continue rules," which
means the inspection process continues for all matching traffic.
o High-Security Inspection Policy: The inspected traffic is matched against the
High-Security Inspection policy, ensuring stringent security measures are
applied.
o Customization: If your security policy is based on a Firewall Inspection
Template, you can customize it by creating specific rules. These rules can
override the default settings and disable deep inspection for particular types of
traffic if necessary.
o IPv4 and IPv6: Both IPv4 and IPv6 access rules are included, enabling deep
inspection for all supported protocols in both versions of IP.

IPS Role and Template

 IPS Template: For the Intrusion Prevention System (IPS) role, the IPS Template
similarly enables deep inspection by default for all supported protocols.
 Disabling Deep Inspection: Like the Firewall Inspection Template, deep inspection
can be disabled for specific rules if necessary.

Key Points

 Firewall Template: Primarily for establishing secure communication with the SMC
and denying all other traffic.
 NGFW Inspection Template: Focused on deep inspection of traffic, with the ability
to customize and disable deep inspection for specific traffic if required.
 IPS Template: Enables deep inspection for all supported protocols with the ability to
disable it for specific rules.
Introducing Inspection Policies

When implementing inspection on your network, starting with a predefined inspection policy
is the most common approach. However, these general policies might not perfectly fit your
specific network needs, so tuning is necessary. Tuning involves adjusting the policy by
activating or deactivating specific inspection checks based on what is found during the tuning
period and the particular needs of your network.

Predefined Inspection Policies

Forcepoint Firewall provides three main predefined inspection policies, each with different
levels of security and coverage:

1. Highest-Security Inspection Policy

o Purpose: Detects all identified threats with the most comprehensive set of
inspection rules.
o Characteristics:
 Terminates all suspected threats immediately.
 Provides maximum inspection coverage and evasion protection.
 Has a high risk of false positives, which means legitimate traffic might
sometimes be blocked mistakenly.
 Terminates connections if the security engine cannot fully analyze
them.
o Usage: Ideal for environments where the utmost security is required and
potential disruptions from false positives are acceptable.
2. High-Security Inspection Policy
o Purpose: Detects common threats with a strong set of inspection rules.
o Characteristics:
 Provides extended inspection coverage and robust evasion protection.
 Has a moderate risk of false positives.
 Terminates connections if the security engine cannot see the entire
connection.
o Usage: Recommended as the starting point for most networks, balancing
security with operational reliability.
3. Medium-Security Inspection Policy
o Purpose: Detects common threats with a basic set of inspection rules.
o Characteristics:
 Low risk of false positives, reducing the likelihood of legitimate traffic
being blocked.
 Designed to work well in networks with asymmetric routing, which
might not be immediately correctable.
o Usage: Suitable for environments where some level of security is needed but
minimizing disruption to legitimate traffic is crucial.

No Inspection Policy

 Purpose: Disables all inspection checks.

 Usage: Selected when inspection is not desired or needed for certain traffic flows or
scenarios.

Tuning the Policy

Tuning involves monitoring and adjusting the selected inspection policy over a period. This
helps to fine-tune the balance between detecting threats and minimizing false positives based
on the specific behavior and requirements of your network. By carefully adjusting the policy
settings, you can enhance the effectiveness of the firewall while reducing unnecessary
disruptions.

In Forcepoint firewall inspection policies, "Situations" are central elements used to define
traffic patterns and events that need detection. Here’s a detailed summary explaining this
concept:
Situations

Situations are used to specify the exact traffic patterns and events you want to detect within
your system through an inspection policy.

Context

 Definition: The context binds the situation to a specific type of traffic, which can
include protocol and direction of the stream.
 Function: It provides a framework for defining parameters for each situation.
 Usage: You can specify parameters using regular expressions or by selecting from a
set of fields and options, depending on the context chosen.
 Example: If you want to monitor HTTP traffic for specific patterns, you would select
the HTTP protocol as the context and then define the specific patterns to look for.

Tags

 Definition: Tags are a grouping system for situations.

 Function: Tags allow you to group situations under a common label, which simplifies
policy creation and management.
 Usage: By using tags in policies, you can create rules that apply to all situations
associated with a specific tag.
 Example: Using the tag “Windows” in a rule will make that rule apply to all situations
related to Windows systems, reducing the complexity of the policy.

Vulnerability

 Definition: Situations can be linked to known vulnerabilities.

 Function: These references are often from public vulnerability databases.
 Usage: When a situation matches a known vulnerability, it is logged and can be
viewed in the logs.
 Example: A situation related to a specific Windows vulnerability could be linked to a
CVE (Common Vulnerabilities and Exposures) entry, making it easier to track and
understand the threat.

Type

 Definition: The type determines the action taken when a situation is matched.
 Function: Based on the situation type, the firewall can take different actions:
o Terminated: The connection is blocked.
o Permitted with stored logging entry: The connection is allowed, but an entry
is logged for monitoring purposes.
o Not inspected: The connection is identified but not inspected further.
 Usage: These types are defined in the default system template rules.
 Example: A situation involving a benign traffic pattern might be set to "Not
inspected," whereas a suspicious pattern might be set to "Terminated."

In summary, situations in Forcepoint firewall inspection policies are used to define specific
traffic patterns and events for detection. The context specifies the traffic type and pattern, tags
help group and simplify policy management, vulnerabilities link situations to known issues,
and types determine the action taken upon detection. This structured approach allows for
precise and efficient traffic monitoring and threat management.

The rules tree is the main tool for controlling the deep packet inspection.

It consists of a hierarchy of situations, organized under various situation types

and sub-types. Each situation represents a specific network event or condition
that the firewall can detect.

You can define what kind of action the NGFW takes when situation matches are
found in traffic and how the match is logged.

the firewall performs a baseline level of inspection and action for all traffic, which
can then be customized as needed.

Scope of Checks: Unlike other firewall rules, the checks defined in the rules tree
cannot be limited by IP addresses or logical interfaces. This means the rules
apply universally to all traffic passing through the firewall.

You can edit the action or logging cell within a rule and select the appropriate
option

Inheritance and Overrides: By default, sub-items (sub-situations) inherit their

settings from their parent items. If a sub-item has different settings from its
parent, this difference is considered an override and is indicated in bold text.

You can change the default action for an entire situation type but set different
actions for specific situations within that type.

Botnet detection All botnet detection-related techniques are grouped into a

Botnet situation types in the inspection policy. Botnet detection includes
fingerprint-based detection, decryption-based detection, and message-length
sequence analysis.
inspection rules and exception rules can generate log or alert entries whenever
they match. The logging options available are similar to those in access rules, but
the inspection policy provides additional recording capabilities.

Excerpt Stores an excerpt of the packet that matched. The maximum recorded
excerpt size is 4 KB. This allows you to quickly view the payload in the Logs view.

Record Records the traffic up to the limit you set in the record length field. This
allows for storing more data than the excerpt option.

The NGFW (Next-Generation Firewall) Inspection policy aims to provide the highest
accuracy by ensuring that:
  Legitimate traffic passes through with minimal latency or bandwidth impact.
 Clearly malicious traffic is terminated.
 Suspicious traffic is usually allowed but logged for later analysis.

Predefined inspection policies are available, but they need to be tailored to specific
environments. A threat to one system might not be relevant in another, so tuning the
inspection policy to the network environment is crucial to avoid:

 False Positives: Legitimate traffic incorrectly flagged as malicious, which can occur if
the inspection patterns are not accurate enough.
 False Negatives: Malicious traffic not detected, which can happen due to:
o Attackers using techniques to bypass inspection.
o Permissive policies aimed at reducing false positives.
o Network configuration issues preventing the NGFW from seeing all traffic.
o Infrequent updates missing the latest attack signatures.

Properly configured, the NGFW Inspection policy can effectively notify and block malicious
traffic.

To verify and fine-tune inspection in Forcepoint firewalls, you generally start with a
predefined inspection policy. During a tuning period, gather information on detected events to
understand the nature of traffic in your network, including both malicious and harmless
traffic. This helps improve detection accuracy and reduce false alarms.

To assist in policy tuning, you can use:

1. Passive Termination: This feature logs instances where a connection is selected for
termination without actually terminating it. This allows for policy adjustments without
disrupting important business communications.
2. Inspection Rule Overrides: These overrides permit or terminate specific situations
contrary to the larger situation type. Use overrides for broad rules and exception rules
for more specific cases.
 3. Exception Rules in the Inspection Policy: These rules are processed before the main
rules and allow for detailed tuning. You can easily create exception rules by right-
clicking on log entries and using them as a basis.

exceptions are evaluated before the main rules. This is evident from the placement of the
exceptions panel above the main rules tree. Exceptions are primarily used to address false
positives by allowing certain patterns in specific parts of the traffic while still triggering
responses when encountered elsewhere.

Key features of exceptions compared to the main rules tree include:

 Creating exceptions based on source, destination, and protocol information. For

example, you might need an exception to prevent false positives between two internal
hosts without fully disabling inspection.
 Adding specific responses to matches, such as blocklisting connections on a Next-
Generation Firewall (NGFW) or setting up user notifications for certain events.
 Defining rules that apply only on specific days or times of the day.

The design principle for exception rules follows the same top-down reading order as access
rules. Specific rules must be placed above more general ones that match the same traffic.
However, in inspection rules, matching is primarily based on situation elements. Each
situation corresponds to a specific traffic pattern, so rules match the same traffic only if they
correspond to the same situation, even if they share identical source, destination, severity, and
protocol definitions
The examples :

1.1.1: Eliminates excessive logs for FTP anonymous logging to reduce noise.

1.1.2: Detects forbidden web browser versions, terminates connections, and

sends a response to the user, such as prompting them to update their browser
before reconnecting. User responses are also logged in the exceptions table.

1.1.3: Detects recent updates by testing newly added situations introduced by

dynamic update packages. These can be set to passive termination mode, which
only logs the traffic.

1.1.4: Permits information severity situations in the Anomalies tag.

inspection exception rules are used to reduce false positive events.

 Rule 1.1.1: New signatures from the last three update packages are temporarily
allowed for testing. Specific alerts are raised when these signatures match to identify
them easily and ensure they don't generate false positives.
 Rule 1.1.2: A specific false positive situation is allowed from a specific internal
network to a specific server. If this situation occurs in any other traffic, the inspection
rule base will terminate the connection
new exploit signatures are obtained through dynamic updates. You can set up the
management server to regularly check for and download these updates. After
downloading, the updates must be activated in the Security Management Center
(SMC) before they can be installed on the firewall engine. Installing these
updated signatures on the engine requires a policy installation, which can be
configured and automated in the Global System Properties dialog box.
file scanning process :

1. Initial Hash Check with McAfee GTI:

 oWhen a file passes through the firewall, its hash is sent to McAfee Global
Threat Intelligence (GTI).
o If the file is in McAfee’s database, a risk score is returned, which determines if
the file is allowed or blocked.
o If the file is not in the database (unknown), it proceeds to the next step.
2. Anti-Virus Scan:
o If Anti-Malware is activated, the file is scanned for viruses.
o Infected files are discarded.
o Clean files move to the next detection phase.
3. Advanced Malware Detection (AMD):
o The file hash is sent to Forcepoint Advanced Malware Detection.
o If the file is known, its reputation score is returned.
o If the file is unknown, it is sent to AMD for in-depth sandbox analysis, after
which the file's reputation score is returned.

This scanning process is managed by the file filtering policy of the NGFW

(NGFW) communicates with the Advanced Malware Detection (AMD) system by sending
file hashes. If AMD recognizes the file, it responds with a reputation score. Files that are
unfamiliar to AMD are forwarded for analysis in a controlled operating system environment.
After analysis, AMD provides a reputation score for these files based on their observed
behavior.

Additionally, through the Logs view in the Management Client, users can access an external
portal. This portal allows detailed inspection of reports generated by the Cloud Sandbox for
analyzed files. Users can utilize various analysis and reporting tools within this external portal
for further investigation and management of potential threats.
access control rules dictate which network traffic undergoes malware detection through File
Filtering Policies. Here are the key points:

 Enabling File Filtering: File filtering is activated either by enabling it in the action
options of individual access rules or by adding a rule with the "Continue" action to set
defaults for file filtering.
 Application of File Filtering: Traffic designated for file filtering in access rules is
routed to the File Filtering Policy. The protocol to which file filtering applies is
determined by the Service allowed in the access rule.
 Supported Protocols: File filtering is supported for FTP, HTTP, HTTPS, IMAP,
IMAPS, POP3, and POP3S. For encrypted protocols, decryption of traffic is necessary
to apply file filtering effectively.
 Default File Filtering Policy: Both the Firewall Template and the Firewall Inspection
Template utilize the rules defined in the Default File Filtering Policy by default. This
policy applies specific scanning methods and options based on file source, destination,
and type. It enforces antivirus checks across all file types if antivirus is enabled in the
engine editor and file filtering is activated in access rules. Additionally, the Default
File Filtering Policy incorporates sandbox scan settings defined for the engine by
default, applying them to relevant traffic.
the File Filtering Policy enables policy-based control over file types entering and leaving the
NGFW, incorporating malware detection capabilities. When a file transfer is detected, it
undergoes scrutiny against the File Filtering Policy's rules. The policy applies the first
matching rule to determine whether the transfer is permitted. If no match is found, the transfer
proceeds unhindered.

Key aspects of the File Filtering Policy include:

 Matching Criteria: Rules can be configured based on Source, Destination, and File
Type. Here, Source and Destination refer to the file's endpoints, not the network
connection's endpoints. For instance, if a file is downloaded by a client from an
Internet web server, the Source is the web server, and the Destination is the client's
computer.
 Malware Detection Options: Each rule within the File Filtering Policy allows
specific configurations for malware detection, which are executed sequentially:
1. File Reputation: Assessing the file based on its known history and reputation.
2. Anti-malware: Conducting traditional antivirus scans on the file.
3. Sandbox Scan: Subjecting the file to a sandbox environment to observe its
behavior and assess potential threats.
The Action defines how the engine handles the file:

▪ Allow: The file transfer is allowed without malware detection scanning. By default,
compressed files are decompressed, and the contents are matched against the File Filtering
Policy again.

▪ Discard: The file transfer is discarded without sending an ICMP error message or TCP reset
to the source.

▪ Allow After: This allows you to select options for malware detection, by specifying
malware detection scans are applied to the file.

 Specifies actions for malware detection on files.

 If a file meets the rule action options, it's allowed; otherwise, it's discarded.
File Content analysis:

 File Reputation Scan:

 Sends a checksum to either McAfee Global Threat Intelligence cloud or McAfee TIE
cloud.
 Returns a file reputation score.
o If the score is above the specified threshold, the file is allowed without further
scans.
o If the score is below the threshold, the file is discarded.
o If the score is inconclusive, the file proceeds to the next scan.

 NGFW Anti-Malware:

 Infected files are discarded.

 Clean files are sent to AMD inspection if configured.

the Advanced Malware Sandbox Scan feature works as follows:

 Checksum and Reputation Check: A checksum of the file is sent to a Forcepoint

Advanced Malware Detection sandbox server to check for a known reputation.
 Unknown File Handling: If the file is unknown, it is sent to the sandbox server for a
detailed scan.
 Reputation-Based Action:
o Discard: If the file reputation falls to the left of the slider, the file is discarded.
o Allow: If the file reputation falls to the right of the slider, the file is allowed.
 File Transfer Delay: If "Delay file transfer until the analysis results are received" is
selected, the file transfer is paused until the NGFW engine receives the analysis result
from the sandbox server and then decides to allow or discard the file based on its
reputation.
The "File Buffering Level" determines how the engine processes files during malware scans:

 None: No traffic buffering; traffic passes through before malware scans are complete,
minimizing delays but not blocking unknown malware.
 Low: Only the last packet of the connection is buffered until scans are complete. The
other packets of the connection are allowed through before malware scans are
completedFor SMTP traffic, this behaves like the High level.
 Medium: Part of the connection is buffered until scans are complete. For SMTP
traffic, this behaves like the High level.
 High: All traffic is buffered until scans are complete, offering the highest security but
potentially delaying traffic.

Forcepoint NGFW can be integrated with on-premises DLP servers like Forcepoint DLP to
scan files as part of a file filtering policy. This integration primarily aims to prevent sensitive
data from being sent out during outbound file transfers, supporting protocols such as FTP,
HTTP, HTTPS, IMAP, IMAPS, POP3, POP3S, and SMTP. Communication between NGFW
Engines and DLP servers is facilitated via the ICAP protocol. DLP scanning is configured
within the File Filtering Policy and is enabled in the Allow After action of a File Filtering
rule. DLP scans can be combined with other Anti-Malware scanners for enhanced security.
Alerts are notifications for important events that need the administrator’s attention. They are
generated by:

 Rules with the alert logging option enabled

 Failed tests
 Exceeded thresholds (User Alert, Overviews)
 Monitored elements becoming unreachable
 System functioning problems
 Communication failures between system components

Alerts differ from normal log entries because they are highlighted in the Management Client's
Active Alert view until acknowledged by an administrator. They can also be escalated
through external notification channels. Each alert is also recorded as a log entry and remains
even after acknowledgment. Normal log entries do not trigger notifications or escalation.
Alerts can be triggered by automatic test failures, unreachable monitored elements, or system
errors.
Alert Escalation in Forcepoint Firewall:

Alert escalation defines when and how administrators are notified about alert entries, which
indicate issues with SMC servers, NGFW Engines, failed tests, tasks, or matched rules.

Alert Process:

1. Alert Generation:
o Engine nodes send alert entries when a rule includes an alert element or when a
test fails.
o The SMC Server sends alerts for critical system events.
2. Alert Reception and Storage:
o The Log Server receives and stores the alerts, then forwards them to the
Management Server.
3. Alert Visibility and Matching:
o The Management Server displays alerts in the Active Alerts view.
o The alerts are matched against the Alert Policy rules on the Management
Server, determining which alerts are escalated through Alert Chains.
4. Alert Chains and Notifications:
o Alert Chains specify which administrators receive notifications, in what order,
and by which methods.
5. Acknowledging Alerts:
o Administrators acknowledge alerts in the Active Alerts view, removing them
from Active Alerts and stopping further Alert Chain processing for that alert.

This process ensures that administrators are promptly informed about significant events and
issues within the system.
 When a component generates an alert, it is shown in both the Active Alerts and Logs
views.

 Alerts are acknowledged by the administrator in the Active Alerts view, which aggregates
them by type and severity.

 Alerts remain on the Management Server until acknowledged.

 The Active Alerts view is accessible via the Monitoring Menu or the user notification icon
in the Management Client's bottom right corner.
Task 1: Define the Alert or Situation to escalate (optional)

System Alerts: Predefined for common alerts, based on specific situations (e.g.,
"Log Server: disk full").

Custom Alerts (optional):

 Naming and Describing: Create a custom alert element with a unique

name and description.
 Defining Triggering Rules: Use a rule to specify the traffic or situation
that triggers the alert.
 Setting Logging Level: Select "alert" as the logging level and specify the
custom or system alert name.
 Log Identification: Log entries will be identifiable by the alert's name.

Task 2: Define the rule triggering the Alert.

This step is identified as optional because system alerts are already defined and may be all
you need in some circumstances. Alerts are sent when there is a problem with the system,
when a test or task fails, or when a rule that is configured to trigger an alert matches. Alerts
can also be sent when a set threshold for a monitored item in Overviews is exceeded.
Task 3: Define Alert Chains

Alert Chains determine how, in what order, and to whom notifications about alert entries are
sent. These chains list actions executed sequentially from top to bottom. Each row in an Alert
Chain specifies a Channel and a Destination address for the notification.

Here are the key channels and their functions:

Custom Script: Executes a script stored on the Management Server. The Destination must be
the script's name.

DELAY: Adds a delay without any action. Useful for introducing a delay at the top of the
chain.
SMS: Sends a text message via a GSM mobile phone connected to the Management Server.
The Destination must be the recipient's phone number.

SMTP: Sends an email. The Destination must be an email address recognizable by the SMTP
server.

SNMP: Sends an SNMP trap. The Destination is not used.

USER NOTIFICATION: Adds a blinking icon in the Management Client's bottom right
corner. The Destination can be ANY or specific Administrator elements.

Additionally, each row includes three optional fields:

Threshold to Block: Limits the number of notifications sent within a specified time period.

Delay: Sets the number of minutes before processing the next row.

Comment: Allows a free-form comment for the rule.

Task 4: Define Alert Policies

Alert Policies are used to determine which alerts from various sources are escalated to
specific Alert Chains. Here's a detailed summary:

 Alert Policy Components:

o Rules for matching incoming alert and situation entries.
o Sources for alerts include security engines and SMC servers.
 Implementation and Changes:
o Changes to Alert Policies take effect when installed on a Domain (or the
Shared Domain if no specific domain is defined).
o You need to install the Alert Policy whenever you modify its rules or the Alert
Chains it uses.
 Default Behavior:
 o If no Alert Policy is installed on the Management Server, alerts are escalated
according to the Default Alert Policy.

This ensures that alerts are managed and escalated appropriately based on defined criteria.

To use the Alert Channels in the chains, you need to configure the corresponding Notification
parameters in the properties of the Management Server element first. The information
provided by the alert notification will vary depending on the Alert Channel used. For instance,
SMS alerts might be limited by the number of characters that can be sent.
Authentication can be performed in several ways. Combining several methods strengthens the
verification of the user. With authentication, a person can prove their identity using one or
more of the following:

• Something they are.

• Something they know.

• Something they have.

The most common type of authentication is something the user knows, such as a password, or
something they have, such as an authorization card.
predefined authentication method :

 Client Certificate ,

 LDAP Authentication(simple password authentication against LDAP databases on

external LDAP) ,

 Pre-Shared Key Method,

 user password (User Password is for simple password authentication against the
internal LDAP database, including user authentication in Forcepoint VPN Client
hybrid authentication)

Authenticate end-user access through firewalls to the SMC against external authentication
servers that support either the RADIUS or TACACS+ protocol

Predefined external authentication methods :

 network policy server

 radius
 tacacs

If you use an external authentication server, multiple authentication methods are available,
such as onetime passwords and token cards.

the Management Server includes an internal LDAP directory to store user information. This
integrated directory can be used to authenticate users using passwords or certificates,
providing a simple solution when there's no need for an external LDAP server.

Key Points:

1. User and Group Storage: The user and user group information is stored on the
Management Server. Each firewall node keeps a replica of this database, ensuring that
 any updates to the main database are promptly replicated to all firewall nodes. This
setup allows the firewalls to use their local copies of the directory, reducing the need
for constant network communication.
2. Management and Synchronization: Users are managed through the Management
Client, with their information residing on the Management Server. By default, the
internal user database is not automatically replicated to firewall nodes. To enable this
replication, administrators must enable the "User DB Replication" setting on each
firewall node. The "Reset User Database" command can be used to enforce
synchronization between the Management Server and firewall databases.
3. Access Restrictions: External components, such as external authentication servers,
cannot access the internal LDAP database.
4. Authentication Methods: Users can be authenticated using the methods provided by
the firewall, leveraging the internal LDAP directory for user data.

internal user accounts contain all the necessary information for authenticating users using the
firewall's authentication methods. These settings, such as user credentials for the User
Password method, are replicated across all firewalls.

Here's a summary of the internal user authentication process:

1. Replication: Firewalls keep a local copy of the Management Server's internal LDAP
database. Any changes made to the user database in the Security Management Center
(SMC) are automatically synchronized with the firewalls.
2. Authentication and Access Control: If the user authentication succeeds, the firewall
lists the user as an authenticated user, taking note of both username and authentication
method. When the user opens new connections, access rules that contain an
authentication requirement, now match. These rules use both the username and the
authentication method as criteria. If the user attempts to establish new connections,
these criteria are used to verify access permissions.
3. Session Expiry: The authentication session has a configured timeout. Once this
timeout is reached, the user is removed from the list of authenticated users. At this
 point, any access rules that require authentication will no longer apply to the user's
connections.

Forcepoint firewalls can integrate with external directory servers, such as Microsoft Active
Directory, to manage user and group information. This integration utilizes an LDAP client
built into both the Management Server and the firewall engines. Here's a detailed summary of
the process and its benefits:

1. External Directory Server Usage: Instead of relying solely on the internal user
database, the system can query an external directory server to obtain user and group
information. This eliminates the need to manually replicate user account data within
the system.
2. Automatic Synchronization: User and group elements from the external directory are
automatically imported into the Security Management Center (SMC), streamlining
user management and ensuring consistency.
3. Authentication Rules: With the integration, different authentication rules can be
applied to different users based on the information retrieved from the external
directory.
4. Direct Querying: The external directory server is queried directly for user
information. This query occurs both when viewing user elements in the Management
Server and when firewalls authenticate users. The information is not stored or
replicated within the internal directories of the Management Server or the local
directories on the firewalls.
5. Policy Configuration and Application: Through the Management Client,
administrators can browse users and groups in Active Directory and use this
information to configure firewall policies. These policies, along with settings for the
external directory server, are then installed onto the firewall.
6. Authentication Process: When a user attempts to authenticate, the Next Generation
Firewall (NGFW) queries the external LDAP server. The LDAP server can either
authenticate the user directly or redirect the authentication request to a third-party
authentication server, depending on the configuration and available methods supported
by the external directory server.
The integration with external directory servers, particularly Active Directory, is facilitated by
a dedicated element in the SMC, making the setup and management process more
straightforward.

the external directory server is queried directly by the Management Server when you view the
user elements and by the firewalls when a user attempts to authenticate.

In a Forcepoint firewall setup using Active Directory as the directory server, user
authentication can be performed via LDAP Authentication. The process involves the
following steps:

1. User Authentication Initiation: Users can authenticate either by establishing a

Client-to-Gateway VPN connection or through browser-based authentication.
2. User Verification: The firewall checks if the user exists within the LDAP domain.
3. Credential Verification: The default method for authenticating users in the LDAP
domain is LDAP Authentication. The firewall verifies user credentials by performing
an LDAP Bind on the directory server.
4. Authentication Success: If the credentials are correct, the firewall records the user as
authenticated, noting both the username and the method of authentication. This allows
the user to establish new connections that meet access rules requiring authentication.

Other authentication methods, such as NPS authentication or redirection to a third-party

authentication server, can also be used with Active Directory in this setup.
users can authenticate through a compatible VPN client or a web browser. Browser-Based
User Authentication allows end-users to log in to the Next-Generation Firewall (NGFW)
using any standard web browser. This method can integrate with external RADIUS or
TACACS+ compatible authentication servers, or utilize Client Certificate Authentication for
added security.

Administrators have the flexibility to customize the HTML pages (such as the login,
challenge, and status pages) that are displayed to users during authentication, allowing the
interface to match the company's branding.

Authentication can occur over either plain HTTP connections or encrypted HTTPS
connections, enhancing security. The firewall can restrict the interfaces through which users
can authenticate, and it supports both IPv4 and IPv6 for user authentication.

After successful authentication, users can be redirected manually or automatically to the

originally requested URL. This functionality requires enabling deep inspection and setting up
Inspection Exceptions
To configure an Active Directory server with LDAP authentication in Forcepoint Firewall:

1. No LDAP Schema Changes: The Active Directory (AD) server does not require
modifications to its LDAP schema for integration.
2. Use of AD Security Groups: AD security groups can be directly utilized in firewall
access rules.
3. Authentication: End-users can authenticate using Windows passwords through LDAP
Bind, compatible with Windows Server 2012 and later.

Configuration Steps:

 Create an Active Directory Server Element: This element represents the external
AD server, enabling the use of the AD user database as an external user database. It
includes both LDAP user database settings and authentication configuration, though
NPS authentication is optional. If using other external authentication servers, separate
server elements must be created for each feature.
 Define LDAP Settings: Configure user account information (Bind User ID), Base DN
(the LDAP tree where user accounts are stored), and connection security options like
LDAPS or Start TLS to secure communications with the AD server.
To configure authentication server settings in Forcepoint firewall, follow these steps:

1. Define Authentication Methods: Specify the allowed methods for authenticating

users stored on the Active Directory (AD) server.
2. LDAP Authentication: Optionally, use LDAP for simple password authentication.
The NGFW Engine sends the username and password to the AD server, which verifies
them and informs the firewall of the result.
3. Internet Authentication Service (IAS) / Network Policy Server (NPS): In Windows
Server, you can use IAS (older versions) or NPS (current versions) for authentication.
NPS must be configured as a RADIUS server, with each firewall engine set up as a
separate RADIUS client.
4. RADIUS/TACACS+: Authentication can also be redirected to a RADIUS or
TACACS+ authentication server for verification.

This setup ensures secure and versatile user authentication across different methods and
servers.
In Forcepoint Firewall, each LDAP server is associated with its own LDAP domain within the
Security Management Center (SMC). One of these domains can be designated as the default
LDAP domain. Users belonging to this default domain do not need to specify the domain
name (e.g., "username@domain") during authentication. This default domain can be set
individually for each Next-Generation Firewall (NGFW). Additionally, you can select default
authentication methods for all accounts within this LDAP domain, such as using LDAP
Authentication.
Example: A rule allows Jennifer and users in the "Mobile VPN users" group, who
authenticate via LDAP, to access the HQ network through a VPN tunnel. These users are
stored in Active Directory, and LDAP authentication uses their Windows account credentials.

access control by user allows the creation of rules based on specific users or user groups as
sources or destinations without needing user authentication. This feature requires either the
Forcepoint User ID Service (FUID) or the Endpoint Context Agent (ECA) to transparently
identify users and associate them with IP addresses. This setup simplifies the configuration of
access control and enhances the user experience by allowing seamless access to services for
trusted users in a secure environment. While user-specific rules provide convenience, they do
not replace user authentication. They can be used alongside user authentication rules to grant
specific user groups access to a service, while others might still require authentication.
The Forcepoint User ID Service gathers data on users, groups, and IP addresses from
Windows Active Directory (AD) servers and Exchange Servers. It can be configured for high
availability (HA) by installing it on multiple servers, with synchronization managed through
CockroachDB across the cluster. Additionally, you can deploy multiple instances of the DC
Agent. The service supports multiple AD domains and forests, ensuring broad integration
capabilities.

Forcepoint User ID Service 2.0:

1. Components:
o DC Agent: Monitors user logins to the domain and reports user and IP address
information to the User ID Service. You can install multiple DC Agents in the
same Active Directory (AD) domain. Each DC Agent can manage up to 30
domain controllers and 30,000 users.
 o User ID Service: Receives data from DC Agents and Active Directory
Servers, including domain, group, and user definitions, along with IP address
information. This service includes the UID Server and CockroachDB
components. Configuration and setup are managed through the Forcepoint
User ID Service Configuration Utility.
2. System Requirements:
o UID Service: Compatible with CentOS 7 and 8, and Red Hat Linux Enterprise
7 and 8.
o DC Agent: Compatible with Windows Server 2012, 2012 R2, 2016, and 2019.
3. Alternative Option:
o Integrated User ID Service: Can be used directly on NGFW (Next-
Generation Firewall) Engines for transparent user identification. This option is
mainly for demonstration and proof-of-concept testing.

The Forcepoint Endpoint Context Agent (ECA) is a Windows client application that provides
detailed endpoint information to the Forcepoint Next-Generation Firewall (NGFW). Here’s a
summary of its key functions:

 User Identification: ECA helps in identifying users and logging their actions.
 Access Control: The Forcepoint NGFW uses the data from ECA to enforce security
policies.
 Information Collected: ECA provides information on:
o User Details: Identifies and logs user actions.
o Application Information: Details about applications running on the Windows
endpoint.
o Operating System Information: Includes OS version, anti-malware status,
and local firewall status.

This data can be used to monitor, report, and enhance security measures based on endpoint
activity and conditions.
e Forcepoint firewall User Dashboard allows administrators to access detailed user-specific
information by integrating data from Active Directory (AD) and the Endpoint Context Agent
(ECA). Here’s a summary with all key details:

1. Home View: The Management Client's Home view features user dashboards that
provide an overview of user activity. This includes tracking suspicious behavior, such
as the use of certain network applications or attempts to access restricted networks,
and identifying users linked to attack situations.
2. User Activity: Active users who generate log data are listed. You can adjust the time
period for which user activity is monitored. In cases where privacy laws prevent
identifying users by name, IP addresses can be shown instead.
 3. Statistics and Details: The Statistics panes offer charts and general statistics on user
activities. Selecting a specific user provides more detailed insights into their activities.
4. Data Sources: If available, user information from AD and ECA is displayed in
separate panes in the Home view.
5. Logging Requirements: To monitor users by name, logging of user information in
the Firewall’s IPv4 and IPv6 access rules must be enabled.
6. Endpoint Information: Windows endpoint details, including OS version, anti-
malware status, and local firewall status, are also available.

This dashboard helps in tracking and analyzing user behavior, identifying potential threats,
and ensuring compliance with privacy regulations.

the User Behavior Events pane displays alerts related to User Alert Checks. Here’s a summary
of the checks available:

1. Bandwidth Check: Monitors the amount of bandwidth a user consumes, identifying

high usage that might involve non-business-related applications.
2. Web Content Check: Tracks the websites a user visits using URL Category and
Network Application elements.
3. Access Check: Monitors access to specific networks or resources, such as connections
to resources in a particular region.
4. File Transfer Check: Observes the types of files a user handles.
5. Attack Situations Check: Triggers alerts if a user is associated with any attack
situations.
6. Endpoint Check: Utilizes data from Endpoint Control Agent (ECA) to check
applications and other information about the user’s endpoint.

Alert thresholds vary based on the type of check:

 Single Event: Alerted on the first instance of exceeding the threshold.

 Event Count: Alerted after exceeding the threshold a specified number of times
within a set time period.
 Bandwidth Count: Alerted when a specified volume of data is used within a defined
time frame
Firewall includes built-in IPsec and SSL VPN capabilities to provide secure remote access to
enterprise networks and services. There are two main types of remote access:

1. Client-based IPsec and SSL VPN: This method is used for secure access to both
HTTP-based and non-HTTP-based services within the protected network. It requires
the installation of the Forcepoint VPN client software. The VPN client settings are
managed centrally through the Security Management Center (SMC) and are
automatically updated on the clients when they connect.
2. Clientless remote access via SSL VPN Portal: This option provides secure access to
HTTP-based services from standard web browsers without needing to install
additional software. It's ideal for users who only need to access web-based resources
securely.

IPsec VPN

 Technology: Internet Protocol Security (IPsec) is a suite of protocols designed to

secure IP communications by authenticating and encrypting each IP packet in a
communication session.
  Usage: Commonly used for site-to-site VPNs and remote access VPNs, particularly
when full network access is required.
 Client Software: Typically requires a VPN client installed on the user's device, which
is configured to connect to the VPN server.
 Transport: Works at the network layer, which means it can secure any IP-based
traffic, including non-web traffic like email, file sharing, and VoIP.
 Security: Provides strong encryption and secure data transmission, suitable for
protecting sensitive data.

SSL VPN

 Technology: Secure Sockets Layer (SSL) VPN uses SSL/TLS protocols to secure the
connection. It is similar to the security used in HTTPS for securing web traffic.
 Usage: Often used for remote access VPNs, especially for accessing web-based
applications. It can be configured to provide full network access or limited access to
specific applications.
 Client Software: May not require a client installation, especially for browser-based
access (clientless SSL VPN). When a client is required, it can often be lightweight and
simpler to manage.
 Transport: Operates at the transport layer, primarily securing web traffic
(HTTP/HTTPS). It is particularly useful for environments where access to web-based
applications is needed.
 Security: Provides secure, encrypted access to applications and data, and is often
easier to set up for users since it can use standard web browsers.

In summary, IPsec VPNs are more versatile and can secure a broader range of applications,
while SSL VPNs are more user-friendly and easier to deploy, particularly for web-based
applications. The choice between the two depends on the specific security requirements and
the types of applications or services that need to be accessed remotely.
Forcepoint firewalls support both SSL VPN and IPsec VPN tunnels simultaneously. Here's a
summary of the key details:

1. Mobile VPN Clients:

o Forcepoint VPN Clients are available for Windows, Android, macOS, and
Linux.
o On Android, macOS, and Linux, these clients are limited to SSL VPN
tunneling.
2. VPN Client IP Address Management:
o Virtual IP is mandatory for SSL VPN clients and recommended for IPsec VPN
clients.
o For IPsec VPN, the NAT Pool feature can provide "internal" IP addresses to
clients without needing a DHCP server.
3. NAT Devices and VPNs:
o NAT devices can disrupt IPsec tunneling by altering packet headers.
o Forcepoint Mobile IPsec has VPN NAT Traversal (NAT-T) enabled by
default, which encapsulates IPsec communications in UDP packets to navigate
NAT devices.
4. Firewall Configuration for IPsec:
o Open UDP port 500 for ISAKMP traffic.
o Allow IP protocol ID 50 for IPsec ESP traffic and ID 51 for AH
( authentication header) traffic.
o If using NAT-T, also open UDP port 4500.
5. SSL VPN Tunneling:
o SSL VPN can traverse firewalls more easily, typically using port 443, which is
commonly allowed.
The SSL VPN Portal in Forcepoint NGFW offers remote access to HTTP-based services
within a protected network via standard web browsers. To use the portal, end users must
authenticate. The portal serves as a proxy for connections, meaning users are not directly
connected to back-end services.

Users can access these services in two ways:

1. By entering the external URL of the specific service (e.g.,

https://ssl.example.com/intranet) into their browser, prompting them to authenticate
before being redirected to the service.
2. By connecting to the SSL VPN Portal's main URL (e.g., https://ssl.example.com),
where, after authentication, they can view and access all services they are authorized
to use.
In Forcepoint Firewall, the SSL VPN Portal Services map external URLs to HTTP-based
services within the protected network. This involves translating internal URLs of these
services to external URLs, ensuring all traffic to registered web resources is routed through
the SSL VPN.

There are three translation methods supported:

1. URL Rewrite: This method adds the name of the web service to the URL link,
simplifying setup. Incoming connections are routed based on the URL prefix, and
HTTP responses are rewritten to change outgoing URLs. No additional DNS entries
are required.
2. DNS Mapping: Each service is assigned its own DNS name. This method requires
more effort to set up but is beneficial for certain applications.
3. Freeform URL: Users manually enter the URLs they want to access.

Scenario

Imagine a company has an internal web service for employees to access their email, located at
an internal URL like http://intranet.company.com/email.

1. URL Rewrite

In this method, the external URL might be https://vpn.company.com/email. When an

employee accesses this URL, the SSL VPN rewrites it and routes the request to the internal
server at http://intranet.company.com/email. The outgoing response is similarly rewritten to
appear as if it came from https://vpn.company.com/email, ensuring seamless access without
additional DNS entries.
2. DNS Mapping

Here, each service has a unique DNS name. For example, the internal email service could be
accessed externally via https://email.vpn.company.com. This method involves setting up DNS
records to point email.vpn.company.com to the SSL VPN, which then directs the request to
http://intranet.company.com/email. This is more complex to set up but can handle more
specific application requirements.

3.Freeform URL

In a Freeform URL scenario, the external URL provided to users might be something like
https://vpn.company.com. After logging in, users can manually enter specific paths or
identifiers that the SSL VPN then translates to the appropriate internal URL.

For instance, if an employee wants to access the internal email system, they might enter a
URL like https://vpn.company.com/email after connecting to the VPN. The SSL VPN server
is configured to recognize /email and map it to the internal address
http://intranet.company.com/email. This setup allows users to access internal resources by
using familiar paths without exposing internal URLs directly.

configuring the SSL VPN portal involves several key components:

1. SSL VPN Portal Policy: This policy defines the rules for which users can access
specific SSL VPN Portal Services and the authentication requirements needed for
access.
2. Cryptographic Algorithms: The SSL VPN Portal supports specific SSL
cryptographic algorithms used to secure communications.
 3. NGFW (Next-Generation Firewall): The portal is hosted on a list of firewalls,
ensuring secure access.
4. Server Credential: This includes the certificate used to secure the portal's HTTPS
connections. The certificate's Common Name (CN) must match the SSL VPN Portal
hostname. It can be signed by an external certificate authority that clients trust, such as
a commercial CA or an internal company CA.

The SSL VPN Portal in Forcepoint Firewall provides secure, browser-based access to services
within a protected network. To set up the portal, you first define the services you want to
offer.

Task 1: Define the SSL VPN Portal Service

 SSL VPN Portal Services: These map external URLs to HTTP-based services within
the protected network.
 Link Translation Methods: You can choose from URL Rewrite, DNS Mapping, or
Freeform URL for translating links.
 External URL Prefix: This is the part of the URL used to access the service
externally.
 Internal URL: The URL of the service within the protected network.
 SSO Domain: Allows for single sign-on (SSO) across services that share the same
credentials.
 Client Trust: Specifies which certificate authorities (CAs) the engine trusts when
connecting to the internal URL via HTTPS.

Additional Configurations:

 Alternative Hosts: You can specify additional hostnames or IP addresses where the
services can be accessed.
 Appearance Customization: On the Look & Feel tab, you can set the title, icon, and
start page for the service as it appears in the SSL VPN Portal. You can also choose to
hide the service link from the portal if desired.
In the Forcepoint firewall setup for SSL VPN, it's essential to define which users are allowed
to connect. This can be done either by creating users in the firewall's internal user database or
by integrating with an external directory server. In this example, an internal user is defined
using the User password authentication method provided by the firewall. The specific user
credentials, including the username and password, are set in the user's properties.

Task 3: Create the SSL VPN Portal Policy The SSL VPN Portal Policy contains rules that
define which users can use each SSL VPN Portal Service and the authentication requirements
for accessing the SSL VPN Portal Services.
the SSL VPN Portal configuration involves several key components:

1. SSL VPN Portal Policy: Defines available services and user access rights within the
portal.
2. Hostnames: Specifies the domain names and IP addresses for the SSL VPN portal.
3. Server Credentials: Includes the private key and certificate for secure
communication, referenced from a Server Credentials element.
4. Target Engine: Lists the firewalls where the SSL VPN Portal is enabled, which can
also be specified in the Engine editor.
5. Look and Feel: Allows customization of the portal's appearance, including graphics,
styles, fonts, layout, and text. This requires manual editing of HTML and CSS files.

Additionally, in the Advanced tab, settings like session timeout and log level for the SSL
VPN portal services can be configured.
In Forcepoint Firewall, if you need to modify the SSL cryptographic algorithms supported by
the SSL VPN Portal, you can create a TLS Cryptography Suite Set element. This element
defines which cryptographic algorithms are allowed. By default, the firewall uses NIST (SP
800-52) Compatible SSL Cryptographic Algorithms, which adhere to the "NIST SP 800-52
Rev.1 Guidelines for the Selection, Configuration, and Use of Transport Layer Security
(TLS)." These settings are available in the engine properties. If the default algorithms are
sufficient, there's no need to create a custom TLS Cryptography Suite Set element.
VPNs (Virtual Private Networks) provide secure communication over insecure networks
using authentication, encryption, and integrity-checking mechanisms. They are commonly
used to connect corporate LANs with branch offices, partner offices, telecommuters, or
mobile workers. The devices that manage VPNs are known as VPN Gateways. In Forcepoint's
Next Generation Firewall (NGFW), VPN capabilities include IPsec VPNs and SSL VPNs for
mobile users.

There are two main types of VPNs: Policy-based and Route-based.

1. Policy-based VPNs:
o Traffic selection for the VPN is determined by the firewall's access rules.
o Site-to-Site VPNs: These connect two gateway devices, providing secure
access for other devices and supporting both IPv4 and IPv6 traffic.
o Mobile VPNs: These connect a gateway device with a VPN client installed on
a user's computer.
2. Route-based VPNs:
o The firewall's routing configuration determines which traffic is sent into the
VPN tunnel.
there are two types of site-to-site VPNs:

1. Policy-Based VPNs: Traffic is sent into the VPN based on firewall access rules.
These rules specify which traffic should enter the VPN and which traffic can exit.
2. Route-Based VPNs: Traffic routing into the VPN tunnel is determined by the
firewall's routing configurations, not by specific access rules.

The slides aim to introduce VPN-related terminology for the Next Generation Firewall
(NGFW). Here's a summary:

 Site-to-Site VPN: This VPN connects two or more gateway devices, allowing
multiple hosts within their internal networks to communicate securely.
 IPsec Standards: The NGFW Site-to-Site VPN adheres to these standards for
encryption and secure communication.
  VPN Tunnel: When traffic needs to pass through the VPN, the source gateway
initiates a connection with the destination gateway to establish a tunnel.
 Encapsulation/Deencapsulation: The original data packets are encapsulated
(wrapped) when entering the tunnel and deencapsulated (unwrapped) when exiting.
During transit, only encrypted packets are visible.
 Host Transparency: The communicating hosts are unaware of the VPN process as it
is handled transparently by the gateways.

VPN gateways are devices that provide VPN access and are categorized into three types:

1. VPN Gateways: These are Forcepoint NGFW (Next-Generation Firewall) engines

managed by the Management Server.
2. External VPN Gateways: These include third-party firewalls or NGFW devices that
are not managed by the Forcepoint Management Server or fall under a different
administrative domain.
3. Mobile Client Gateways: These encompass both Forcepoint NGFW and third-party
mobile VPN clients.

In VPN terminology for Forcepoint firewalls:

 Endpoints: These are the IP addresses of the firewall used for communication
between VPN Gateways. Essentially, they are the contact points for VPN connections
from other VPN Gateways.
 Site: This refers to the IP addresses and networks that are accessible through the VPN
behind a specific VPN Gateway. It represents the network resources available via that
VPN Gateway.
In VPN terminology for Forcepoint firewalls:

 Endpoints: These are the IP addresses of the firewall used for communication
between VPN Gateways. Essentially, they are the contact points for VPN connections
from other VPN Gateways.
 Site: This refers to the IP addresses and networks that are accessible through the VPN
behind a specific VPN Gateway. It represents the network resources available via that
VPN Gateway.

VPN topologies can be set up in Full-Mesh, Star, or VPN HUB configurations. Here's a
summary:

1. Topologies Supported:
o Full-Mesh: Every VPN Gateway connects to every other Gateway.
o Star: Gateways connect through a central hub.
 o VPN HUB: Similar to Star, but with more complex configurations.
2. Gateway Classification: Gateways are classified as either Central or Satellite:
o Central Gateways: Act as hubs and can connect to all other Gateways.
o Satellite Gateways: Connect to Central Gateways and may not connect
directly to other Satellites.
3. Tunnel Management: By classifying Gateways, you define which tunnels are
created. You can disable unnecessary tunnels to optimize your network.
4. Full-Mesh Setup: To create a Full-Mesh topology, configure all Gateways as Central.
This ensures that every Gateway connects to every other Gateway, enabling direct
communication between all sites.

This configuration allows for flexible and comprehensive network connectivity based on your
needs.

In a Star topology for Forcepoint firewalls:

 Central Gateway: There is one central gateway that acts as the hub of the network.
 Satellite Gateways: Several satellite gateways connect to the central gateway but not
to each other.
 VPN Connections: VPNs are created between the central gateway and each satellite
gateway. Satellite gateways do not form VPNs with one another.
 Configuration: Satellite gateways need to be configured specifically for their role in
the VPN setup.
 Topology Combinations: You can have multiple central gateways in a Star topology.
In this scenario, the central gateways are connected in a full mesh topology among
themselves, while satellite gateways connect only to all central gateways, not to each
other.
In a Forcepoint firewall with a VPN hub topology, a hub gateway is used to manage and
forward VPN traffic between various VPN tunnels. Unlike a full mesh VPN, where each
gateway connects directly to every other gateway, the hub VPN simplifies connectivity by
routing traffic through the hub gateway. This reduces the number of tunnels needed compared
to a full mesh setup.

Deploying new gateways in a hub VPN is easier since they only need to connect to the hub
gateway rather than to every other gateway individually. However, this setup places more
resource demands on the hub gateway, as it handles the forwarding of traffic between all
connected gateways.

clustering firewalls and deploying Multi-Link VPN for VPN high availability:
 1. Gateway Clustering: A VPN Gateway can be linked to a Firewall Cluster, which
provides redundancy and load balancing for the VPN Gateway.
2. Configuration: No additional configuration is needed compared to setting up a
gateway for a single firewall.
3. Single Endpoint: To other gateways, the firewall cluster appears as a single device
with a single IP address, known as the Cluster Virtual Interface.
4. Failover: If one node in the cluster fails, the remaining nodes take over the VPN
traffic handled by the failed node, ensuring continuous operation.
5. Enhanced Performance: In balancing cluster mode, the firewall cluster also offers
improved processing power for encryption and decryption tasks.

Multi-Link VPN Overview

 Purpose: Multi-Link VPN distributes outbound traffic across multiple network

connections, enhancing high availability and load balancing. It reduces link congestion
and mitigates VPN failures in case of ISP connectivity issues.
 Functionality: In a Multi-Link configuration, traffic can be routed through one or
more tunnels to reach the same destination. If any tunnel fails, the VPN service
continues to operate as long as one tunnel is available. This failover is seamless for
end users. Additionally, Multi-Link VPN provides load balancing across the links.
 Benefits: It offers a cost-effective way to secure communications and maintain
connectivity between offices, especially when connections are unreliable.
 Compatibility: This feature is specific to Next-Generation Firewalls (NGFW) and
requires NGFW gateways at both ends. While some benefits can be obtained with
external devices that support multiple VPN tunnels, not all Multi-Link features will be
available.
 Combination with Clustering: Multi-Link VPN can be used in conjunction with
clustering to further enhance VPN reliability.
Application Routing in Forcepoint Firewalls enables you to direct traffic based on the
detected network applications. Here are the key details:

 Routing Choices: You can choose specific VPN tunnels, ISP links, and proxy servers
for different network applications. For example, web applications like Office 365 and
YouTube might be routed directly to the internet, FTP connections through a VPN
tunnel, and voice traffic over MPLS.
 Application Detection: This feature is most effective with protocols where the client
initiates data transmission, such as web-based protocols. To use a Network
Application element in application routing, ensure it has the Application Routing tag.
 Use Cases:
o Traffic Routing: Route certain applications through a local internet
connection and other traffic through a different connection, like MPLS.
o Proxy Exclusion: Exclude specific applications from being routed through
proxies.
o Proxy Direction: Route some applications to one proxy and other web traffic
to a different proxy.
o ISP Connection: Direct traffic for a specific application to a particular ISP
connection, reserving others for more critical traffic. For instance, route
YouTube traffic through a cheaper ISP and critical business traffic through a
faster, more expensive ISP.

This approach helps optimize network performance and cost by aligning traffic routing with
application needs and connection types.
To set up a policy-based VPN between a Forcepoint NGFW engine and an external VPN
gateway not managed by the same Management Center, follow these steps:

1. Define the Gateways:

o VPN Gateway: Represents the NGFW engines managed by your Management
Server. A VPN Gateway element is automatically created for each NGFW in
the Firewall role.
o External VPN Gateway: Represents the third-party VPN device or NGFW
engines managed by a different Management Server. You need to define this
element manually.
2. Gateway Profile :
o Purpose: The Gateway Profile provides details on the features and options
available for VPN configuration. It helps in validating the VPN configuration
automatically.
o Authentication and Encryption Settings: These settings in the Gateway
Profile are used for validation purposes and do not directly influence the VPN
settings.
o Internal vs. External Security Gateways: For Internal Security Gateways,
the profile is selected automatically based on the engine software version. For
External Security Gateways, you must set the profile according to the
supported features and options of the third-party VPN gateway.

Key Points:

 Ensure you have correctly defined both the VPN Gateway (internal) and the External
VPN Gateway (third-party).
 Use the Gateway Profile to validate that the VPN settings match the supported features
of the involved gateways.
In Forcepoint firewall, to define the End-Points for your VPN Gateways:

1. Access Configuration: Go to the Engine Editor to configure VPN Gateway settings.

2. End-Points Menu: Lists IP addresses used as VPN endpoints when the firewall
operates as a gateway. These IP addresses are auto-defined based on the firewall’s
interface configuration.
3. IP Addresses: Both IPv4 and IPv6 addresses can be used as End-Points.
4. Automatic Selection: Endpoints are selected automatically based on the firewall's
routing. IP addresses for interfaces towards the Internet are selected according to the
default routing table.
5. Phase-1 Settings: Change the identification type if needed. The default is IP Address,
but it should be adjusted if the end-point is dynamic.
6. NAT-T (NAT Traversal): Enable NAT-T in the End-Point properties if the VPN
traverses a NAT device. NAT-T encapsulates encrypted VPN traffic in UDP packets
to prevent issues caused by NAT.
7. Manual Configuration: For External VPN Gateways, End-Points need to be
manually configured.

If the auto-defined settings are sufficient, there's no need for manual adjustments.
Task 3: Define the Site Content

1. Site Element: Specifies the internal IP addresses that can send or receive traffic
through the VPN.
2. Traffic Restrictions: Only IP addresses listed in the Sites element can communicate
through the VPN. Addresses not included cannot access the VPN.
3. VPN Gateway Elements: You can include a Site that is automatically updated based
on routing definitions.
4. External Gateways: For these, you need to manually define the protected IP
addresses in the Site associated with the Gateway.
5. Access Rules: While the Site element determines which IP addresses are valid for the
VPN, Access rules control the allowed connections entering and exiting the VPN
tunnel.
Here's a summary of the task for defining the Policy-Based VPN element in Forcepoint
firewall:

1. Define Policy-Based VPN Element:

This element collects Gateways and VPN Profiles.

It provides settings for defining the VPN topology and tunnels.

Configuration involves two stages:

 Define the Policy-Based VPN Element with basic VPN properties.

 Populate the VPN topology with Gateways and adjust the tunnels in the editing view.

2. Define VPN Profile (Optional):

 Each VPN uses a VPN Profile for IKE and IPsec settings, including integrity
checking, authentication, and encryption.
 You can select settings based on compatibility with all involved gateways.
 The VPN Profile can be shared across multiple VPNs if compatible.
 The VPN Profile includes settings for IKE Authentication Method:
 Pre-shared Key: Defined in Gateway-to-Gateway tunnel properties.
 Certificates: Requires certificates for gateway authentication.
 For internal VPN Gateways, the internal certificate authority (CA) can automate
certificate handling.
 External CAs can also be used by adding them to the list of trusted CAs. You need to
export the gateway certificate request and import the signed certificate.

This setup ensures proper configuration and management of VPN connections using
Forcepoint firewall.

defining the VPN topology involves organizing Gateways into either "Central" or "Satellite"
categories for each VPN. This is done through a drag-and-drop interface. While site and
network configurations for each Gateway are generally consistent across VPNs, you can
exclude specific site elements from a VPN if needed.

Tunnels between Gateways and end-points are automatically created based on this topology,
but you can customize these tunnels, including specifying which Gateways and end-points
connect and adjusting properties like the VPN Profile used. In Multi-Link VPN
configurations, you can also set up standby and active tunnels.

For authentication with external Gateways, you can either set pre-shared keys agreed upon
with your partner or export automatically generated keys for your partner's use.

creating Access rules is essential for directing traffic through a VPN. These rules specify
which traffic is allowed to enter and exit the VPN. Here's a summary:

1. Traffic Control: Access rules determine which traffic is sent to the VPN and which is
permitted out. This is in addition to the Gateways' Site definitions, which outline the
allowed source and destination addresses for each VPN.
2. Rule Configuration: VPN Access rules are configured like other Access rules. You
set matching criteria, and all traffic that meets these criteria is handled according to the
defined Action. The "Allow" action includes options to "Apply VPN" and "Enforce
VPN":
o Apply VPN: Directs traffic from local networks into the VPN tunnel and
allows incoming VPN traffic.
o Enforce VPN: Drops any non-VPN traffic from external networks that
matches the rule, preventing unauthorized access.
3. Non-VPN Traffic Handling: If "Apply VPN" is used, non-VPN traffic not matching
the rule is processed by subsequent rules.
4. Forward Action: Mainly used in a Hub topology, it directs traffic from one VPN
tunnel into another.
5. Rule Example: Typically, two rules are created to manage VPN traffic in different
directions.
6. NAT Rules: By default, VPN traffic bypasses NAT rules. To change this, NAT must
be enabled for the VPN, and Private Sites with translated addresses must be defined.
 7. Policy Application: The VPN configuration becomes effective once the policy is
installed on the firewall.

 Link Summary: You can review the IP addresses and settings for individual VPN tunnels
by right-clicking on them in the End-Point<->End-Point list and selecting "View Link
Summary." This is useful for verifying details in complex configurations, particularly when
external components are involved, to ensure IP addresses and settings match with the external
setup.

 VPN SA Monitoring: This view displays all currently negotiated VPN Security
Associations (SAs) in the firewall. It provides features such as filtering VPN SAs, creating
statistics, aggregating data by any field, and saving monitoring snapshots for further analysis.
Additionally, you can delete VPN SAs to reset VPN tunnels, which is particularly useful for
resolving issues with external third-party Gateway VPN tunnels that have stopped working.

Route-based VPN in Forcepoint Firewall

In a Route-based VPN, the routing of the firewall determines which traffic is sent into the
VPN tunnel. The setup involves creating VPN tunnels between firewall interfaces, known as
tunnel interfaces, which act as the tunnel endpoints. Traffic routed to these interfaces and
permitted by the Access rules is sent through the Route-based VPN.

Route-based VPNs can operate in either Tunnel mode or Transport mode, especially when
using additional tunnel types like GRE, IP-IP, or SIT:

 Tunnel Mode: In this mode, encryption is provided by a separately configured policy-

based VPN. This mode typically involves encapsulating the entire original IP packet
within a new IP header, along with encryption.
 Transport Mode: In this mode, only the VPN profile is configured within the Route-
based VPN setup. This profile is used to negotiate an IPsec tunnel, which secures the
traffic passing through the Route-based VPN tunnel.

In a VPN tunnel type configuration, there is no additional encapsulation beyond the standard
IPsec tunnel, meaning traffic is simply encrypted and sent over the IPsec tunnel.
In Forcepoint firewalls, log entries are primarily generated by Access rules, though other rule
types can also trigger logs. The system creates detailed Diagnostics logs and internal log
entries, including those related to policy installations.

Logs from firewalls, IPS engines, and Layer 2 firewalls are sent directly to the Log Server,
which either stores these entries or relays them for viewing. If administrative Domains are
configured, log, alert, and audit entries are domain-specific, meaning only entries related
to the specific Domain a user is logged into are visible or manageable. However, audit
entries from all Domains are accessible to administrators in the Shared Domain.

audit logs track system changes by recording administrator actions, including:

 Element configuration adjustments

 Actions on engine nodes
 Command line tool usage
 Certificate-related actions
 Administrator login authentication events
 Certain system-generated events
These logs are essential for troubleshooting issues due to undocumented configuration
changes. Administrators with unrestricted privileges can view, print, copy, and archive these
logs in the Logs view. Unlike other logs, audit logs are stored on the Management Server or
the Log Server that created them, rather than being centrally stored on log servers.

you can monitor logs from third-party devices directly within the Logs view. The Logging
Profile editor is a tool that defines how Syslog data from these devices is mapped to fields in
the Logs view. A validation tool is available to ensure that these mappings are correctly set
up. Additionally, if you are using IPFIX netFlow, it's necessary to enable log accounting to
ensure proper log file creation and managemen

Diagnostic Logs in Forcepoint Firewall

 Purpose: Diagnostic logs provide detailed information useful for troubleshooting.

  Usage: They should be enabled only during troubleshooting to avoid excessive log
generation.
 Information Provided: Logs include details on various components such as IPsec,
authentication, cluster protocol, protocol agents, and state synchronization.
 Immediate Effect: Once enabled, additional log entries start appearing for the
selected diagnostic options.
 Filtering and Exporting: You can create a filtering profile to manage and export
these logs for further analysis.
 Caution: Diagnostic logs generate a significant amount of data, so they should be
disabled after troubleshooting is complete.
 Note on Errors: Some error messages, like state synchronization errors in single-node
setups, are expected and not necessarily indicative of issues.

The Details arrangement in the Logs view of Forcepoint Firewall offers an overview of
individual events, making it particularly useful for reviewing alerts and records generated by
Inspection rule matches. Users can browse log entries one-by-one using the back and forward
icons in the toolbar.

the Statistics section of the Logs view provides interactive charts for visualizing multiple
events. This feature allows you to quickly generate reports based on logs that match an active
query. It includes many predefined statistical items and offers up to 500 customizable
statistical items for creating your own statistics. The chart area can display various types of
charts, including pie, bar, line, stacked line, and map charts, with the map charts leveraging
the SMC’s internal Geolocation database.

The Log Analysis feature in Forcepoint Firewall provides tools to analyze logs, alerts, and
audit entries based on the active Query. It allows you to:

1. Aggregate Events: Sort log data by specific fields without duplicating rows.
2. View Data as Charts: Use predefined statistical items to visualize data.
3. Visualize Data on Diagrams:
o Audit Map: Shows how administrators manipulate elements.
o Network Application Usage: Maps users and the applications they access,
indicating allowed and disallowed connections.
o Service Map: Displays access to services in the network.
o Attack Analysis: Identifies hosts, targets, and detected attack patterns.
o Network Application and Client Executable Usage: Shows a map of users,
applications, and reported executables, indicating allowed and disallowed
access.

You can zoom in on these visualizations and create filters for more detailed analysis.
you can view logs related to specific rules directly from the policy editor. To do this, right-
click on a rule and select 'Show Related Logs.' Conversely, in the Logs view, you can use the
'View Rule' action to display the rule associated with a specific log entry.

You can also create new rules or exceptions based on existing log entries, particularly those
tagged with a rule identifier. This feature allows you to modify a rule’s action or logging
options for specific sources, destinations, and services. Additionally, you have the flexibility
to edit the rules generated from these logs.
filters are defined using a flexible syntax for precise data matching. A filter consists of event
data fields (like source IP address, time of the event) and operations that define how to filter
the data. There are three types of operations:

1. Calculation operations - Perform mathematical calculations.

2. Comparison operations - Compare values against other values.
3. Logical operations - Combine different filtering criteria.

For complex filters, it's effective to start by creating a Filter element through a drag-and-drop
interface. This allows you to base the filter on specific criteria and edit it as needed, rather
than starting from scratch. Filters can also be saved locally as permanent Filter elements for
use throughout the Management Client.
managing capacity limitations involves configuring logging options to store only necessary
events. Instead of generating all logs and then removing unnecessary ones, it's more efficient
to adjust what logs are generated in the first place. This helps conserve system resources.

Log pruning uses two types of filters:

1. Immediate Discard Filters: Logs that match these filters are discarded immediately
by the Log Server.
2. Discard Before Storing Filters: If logs pass the first filter, they are displayed in the
management client. If they match this second filter, they won't be stored in the Log
Server.

Log pruning is useful when a rule generates both necessary and unnecessary logs, allowing
you to discard irrelevant logs on the Log Server. However, only logs can be pruned; alerts and
audit entries are always kept. Care should be taken when enabling log pruning, as overly
broad filters (like a "Match All" filter) can lead to the irreversible loss of important logs.

Log Servers can be configured to forward log data to external hosts. You can define which
type of log data you want to forward and in which format. You can also use Filters to specify
in detail which log data is forwarded. SMC provides predefined log forwarding formats to
facilitate the integration with SIEM systems. If log pruning is used, the Log entries must pass
the Immediate Discard filter to be forwarded from a Log Server to external servers. Note that
if you want to forward log data in the NetFlow or IPFIX format from the Log Server to
a third-party device, you must select Connection Closing with Log Accounting
Information in the logging option in the rule that creates the log data
a Policy Snapshot is created every time a policy is successfully uploaded to the engine. The
Management Server keeps the 100 most recent snapshots for each engine. These snapshots
allow administrators to compare the edited policy with the current one on the engine, which is
useful for reviewing changes made by others before uploading a new policy. Additionally,
policies can be restored from these snapshots if needed.
The rule search tool in Forcepoint firewall is available for Access rules, NAT rules, and
Exceptions within Inspection Policies. It enables users to search for rules by entering an IP
address or by dragging and dropping elements into designated cells. This tool also highlights
inherited rules and those in Sub-Policies. Additionally, in the Rules tree of the Inspection
Policy, a type-ahead search feature allows users to quickly locate specific Situations.
when a policy is installed, the entire configuration—including updates to routing information,
VPN settings, and engine configurations—is transferred to the Next-Generation Firewall
(NGFW) engines. This means that all aspects of the configuration are updated, not just the
changes made since the last installation. Additionally, the system includes a fail-safe
mechanism that automatically rolls back the installation if the new policies would disrupt
management connections, ensuring continuous manageability of the firewall.
monitoring is conducted through the Management Client. The Dashboard views provide a
comprehensive overview of the operational and connectivity status of Security Management
Center (SMC) components and third-party elements integrated for monitoring. Details on
active alerts are available, which highlight unresolved issues.

The status information is aggregated from data stored on Log Servers, which the Management
Server uses to create the Dashboard views. The Status Tree in the interface lists all
monitorable components, along with diagrams and groups containing these elements.
Selecting an item in the Status Tree shifts the main view to graphical monitoring, displaying
the status of the selected component and its connections within the system.

Specifically, choosing an engine node in the Status Tree switches the view to hardware
monitoring, showing detailed information about network port statuses. The Info panel offers
further specifics about selected components. Users can customize the information panes and
diagrams shown in the home view to suit their preferences.

the System Connections Monitoring feature allows you to view all connections between an
engine node and other system components. When an engine node is selected in the Status tree,
the Appliance Status Monitoring feature provides detailed information about the hardware
status, including network port statuses, fan speed, temperature, and NIC statuses. This
monitoring helps identify hardware problems early. Additionally, you can create custom
diagrams to visualize and monitor the status of various system elements
firewall's session monitoring views, you can observe the following:

1. Connections View: Displays all currently active connections.

2. Blacklist View: Shows the current blacklist entries.
3. VPN SAs View: Lists all active VPN tunnels.
4. Users View: Details all currently active users.
5. Routing View: Provides information on current static and dynamic routes.
6. Neighbors Monitoring: Displays directly connected network neighbors. Note that for
LLDP neighbors to be shown, LLDP must be enabled on the NGFW Engine;
otherwise, only ARP and IPv6 NDP entries will appear.

These views include tools for data visualization, like log aggregation and statistics.
Additionally, snapshots of session monitoring can be saved. You can manage connections,
VPN SAs, and user sessions directly from these views, allowing you to terminate connections,
delete VPN SAs, and close user sessions as needed.
The SD-WAN dashboard in Forcepoint Firewall is a tool for monitoring and managing SD-
WAN features, including Multi-Link and VPNs. It provides statistics and reports related to
these features. In the dashboard:

 Branches: Represent VPN gateways and NetLink elements associated with each
NGFW Engine. The dashboard shows the status of all branches and VPNs.
 Status Tree: Selecting a branch reveals detailed information about NetLinks, VPN
tunnels, and associated traffic. Selecting a VPN shows its configuration status.
 Customization: Users can customize the dashboard to display various statistics items
related to SD-WAN monitoring, which can also be used in reports and overviews.
The User Dashboard in the Forcepoint Management Client provides an overview of user
activities, highlighting potentially suspicious behavior, such as the use of certain network
applications, attempts to access specific networks, or associations with attack situations. This
dashboard is customizable and displays user activity data, which can be filtered based on a
configurable active period.

Users appear in the dashboard when their actions generate log data. In regions with privacy
laws, or when usernames are not stored, user activity can be tracked using IP addresses
instead of names. The dashboard includes statistics panes with charts and general user activity
data, and selecting an individual user provides more detailed information.

For comprehensive monitoring, Active Directory (AD) and Endpoint Context Agent (ECA)
data can be integrated, displaying in separate panes. To monitor users effectively, options in
the global system properties must be enabled, including logging user information in Firewall
IPv4 and IPv6 Access rules.

"Overviews" are monitoring views that provide real-time information on traffic and the
operating state of Security Management Center (SMC) components. These overviews include
predefined types like Access Overview, Inspection Overview, Application Usage Overview,
and VPN Overview. Administrators can customize these overviews by selecting from
hundreds of statistics reported by the Next-Generation Firewall (NGFW) engines.

Overviews are composed of one or more sections that display a wide range of system
information, including:

 Element status information

 Tables with traffic and counter data
 Reports
 Geolocation maps
 Various types of charts (pie, curve, stacked bar, stacked curves)

Sections can be of two types: Counters Statistics or System Summary. The statistics types
available for these sections include:
  Progress (displayed as curves or bars)
 Top rate (shown as pie charts or bars)
 Period total summary tables

you can set a threshold to enable automatic tracking of monitored items in Overviews. Here's
how it works:

1. Threshold Definition: You can define specific thresholds for monitored items.
2. Automatic Tracking: These thresholds activate automatic tracking. The monitored
items are checked periodically based on your configuration.
3. Alert System: If a monitored item exceeds the defined threshold, an alert is triggered.
4. Alert Escalation: The alerts generated can be escalated and managed just like other
alerts in the system.

This feature helps in proactively managing and responding to critical issues by automating the
monitoring and alerting process.
reports are tools that transform extensive log data and statistical monitoring information into
clear, easy-to-read formats. They process this data into diagrams, charts, and tables, helping
you to identify specific details from large datasets. Reports can be automated and scheduled
for various purposes such as customer service, supervision, troubleshooting, and intrusion
investigation.

You can generate reports based on NGFW engine logs, alerts, audit entries, and statistical
information. These reports can be viewed on-screen, printed, or exported as PDF files or tab-
delimited text files. PDF reports can be customized using specific templates. On-screen
reports allow interactive features, such as highlighting and selecting chart items for detailed
display. Additionally, reports can be automatically emailed from the SMC to designated
addresses and are also accessible through the Web Portal.

reports are organized into three key components:

1. Report Designs: Define the structure and content of a report, including the reporting
period and time resolution. There are predefined Report Designs for NGFW Engines
and system components.
2. Report Sections: Within a Report Design, Report Sections dictate how information is
graphically displayed. These sections can be reused across different Report Designs.
The SMC offers a variety of predefined Report Sections, and you can also create
numerous custom statistics sections.
3. Report Items: Each Report Section is composed of Report Items, which represent
specific data types from logs and monitoring statistics, like traffic load or connection
counts. Report Items align with log field values and are presented in the report
according to the properties set in the Report Sectio
reporting details:

1. Progress Summary (Bar/Curve Chart):

o Shows how events are distributed over a reporting period.
o Helps identify trends, like network traffic patterns over 24 hours.
2. Top Rate Summary (Bar/Pie Chart):
o Displays events with the highest frequency.
o Highlights the most common data points, such as the IP addresses with the
most connections yesterday.
o Requires a sorting criterion (e.g., Allowed connections by source IP address) to
rank and display the top occurrences.
3. Period Total Summary (Table):
o Provides exact counts of events in a simple tabular format.
o Useful for detailed data analysis or processing in other applications.
4. System Information (Table):
o Shows the current value of items in the database
Geolocations in Forcepoint firewalls help identify the geographical location of attackers:

 Map Diagrams: Available in Reports, Statistics, and Overviews, and can display Top
Rate data as a map.
 Database: The geolocation data is retrieved from a database included in the Security
Management Center (SMC), which updates during SMC upgrades.
 Log Records: Geolocations are shown in log records with country flags next to IP
addresses, aiding in anomaly detection by visually linking related log entries.
 Whois Records: For more details on traffic sources, you can look up Whois records
of IP addresses in log entries. This information is queried from Regional Internet
Registries (RIRs) such as ARIN, RIPE NCC, and APNIC.

the Security Management Center (SMC) can monitor the status of third-party devices using
various methods:

 Ping
 TCP
 SNMP (Simple Network Management Protocol): supports versions v1, v2, and v3

You configure a probing profile for each third-party device, which allows the SMC to display
the device status. For SNMP-based probing, you can also gather detailed statistics from the
device, including:

 Amount of free and used memory

 CPU load
 Interface statistics
Application health monitoring collects the connection quality metrics of monitored network
applications. NGFW engines monitor network and application layer latency, packet-loss and,
and retransmission rate by application. This data is sent to the log server and used for
displaying the application’s health status. All application health information is available via
Application Health Monitoring Dashboards. Application Health information can be viewed
per NGFW via NGFW Engines Dashboard.

the "Top Network Applications" option automatically discovers and ranks applications based
on traffic volume observed by NGFWs (Next-Generation Firewalls). To use this feature,
accounting logging must be enabled so that NGFWs can log traffic rates for each connection.
By default, the system monitors the top 10 applications, but the admin can adjust this number.

Alternatively, the "Network Applications" option requires the admin to manually define
which applications are monitored. Enabling accounting logging is also recommended with
this option to improve application visibility.
access rules are used to specify which traffic should be monitored for application health,
allowing you to focus on particular traffic types. For example, you might choose to monitor
only internet traffic and exclude internal traffic from this monitoring.

Network Application Latency Monitoring can be enabled in either "continue" or "allow"

rules, which determine whether traffic is allowed to proceed while being monitored for
latency.

You also have the option to disable application health monitoring in the Next-Generation
Firewall (NGFW) engine properties. This feature is useful if you want to apply the same
policy across multiple NGFWs but only monitor applications on specific ones.
the SMC (Security Management Center) provides various tools to diagnose issues. You can
use logs and monitoring data from your Next-Generation Firewall Gateways (NGFGWs).
Collecting traffic captures from each engine interface is straightforward. If you need
Forcepoint support, gather sginfos before making any changes, installing policies, or
rebooting the SMC server or NGFW.

The sgInfo command collects essential system information needed by Forcepoint support.
Note that NGFW Engine and SMC each have their own sgInfos. To maximize the usefulness
of sginfos and tcpdump captures, collect them while the issue is occurring. Forcepoint
Support might also request a backup of the management server to expedite problem resolution
and potentially provide a fix. Optionally, you can take a backup of the Management Server
and share it with Support.

various modules can generate log events, each logged with a facility field indicating its
source. Here's a summary of key log types and their details:

1. Packet Filter Logs:

o Generated when traffic matches an IPv4 or IPv6 access rule.
 o Logging must be enabled in the access rule or via a global setting using a
continue rule.
o Key field which is an important field in the log : Situation, which defines
patterns to identify events.
o When the traffic matches an access rule, the related actions are Connection
Allowed or Discarded depending on whether the traffic is allowed to pass or
not. A Connection Closed log can be also generated at the end of the TCP
connection..
2. Inspection Logs:
o Created when traffic matches an inspection rule in the NGFW inspection
policy.
o Generated for specific contents like attack patterns or banned URLs.
o Can also result from access rules matching application usage.
o Uses predefined or custom inspection rules with configurable logging levels.
o Actions include Connection Permit or Terminate depending on the traffic’s
handling.
3. Other Logs:
o Produced by modules like IPsec, authentication, DHCP, and cluster protocol.
o For detailed troubleshooting, diagnostics mode can be enabled to increase log
verbosity.
o Diagnostics generate more data and should be turned off after troubleshooting.

 Connection Closed Logs: By default, Forcepoint firewalls do not log the closing of
standard TCP connections. You need to enable this in the logging settings of the access rules
if you want to log connection closures.

 Logging Traffic Volume: To collect traffic volume information for reporting purposes,
you must enable logging with the "Log Accounting Information" option.

 TCP Reset: If a connection is closed due to a TCP Reset, a log entry is generated
indicating the source of the reset.

 Abnormal Closure: If a connection closes in an unexpected manner (not following the

standard TCP closing process), the log will note "connection closed abnormally." Frequent
abnormal closures or resets might suggest network issues, such as server overload.
a "connection closed" entry is generated when a connection times out. This is typically a
normal and necessary function, allowing the firewall to clean up inactive connections and free
up resources. However, if an application on your network requires long periods of inactivity
before resuming communication, this timeout could disrupt its operation. In such cases, you
can adjust the connection timeout settings in the Action options for the specific Access rule
that governs the connection.

a "connection closed abnormally" event with an "incomplete connection closed" message

occurs when the firewall detects an unsuccessful TCP connection attempt due to an
incomplete three-way handshake. This results in the connection being removed from the
firewall's connection tracking table.

The incomplete handshake can be due to various reasons, such as the destination server being
unavailable, the destination port being closed, or issues caused by asymmetric routing, where
the firewall cannot see the full handshake.

A high frequency of these messages ““incomplete connection closed messages’’ » could

indicate network or application issues. Analyzing traffic captures can help identify where
packet loss occurs. Additionally, these logs may result from malicious activity, such as SYN
packets being sent to random hosts to probe the network, leading to incomplete connections if
those addresses are accessible and routable.

The "Not a Valid SYN Packet" message in Forcepoint firewall logs indicates that a TCP
packet is not the first packet of a connection (missing the SYN flag) and isn't part of an
existing connection. This packet would typically be allowed if it were part of an established
connection. This issue can arise from:

1. Asymmetric Routing: The initial packet bypasses the firewall, but the reply
(SYN/ACK) does not, indicating a routing configuration error.
2. Network Scans or Attacks: Use of ACK or FIN packets can generate these logs,
often related to scanning or attack attempts.
3. Timed-Out Connections: If a server or client sends a packet after the connection has
timed out and been closed, this message may appear.
4. Idle Timeout: When a connection is idle beyond the defined timeout, it is removed
from the firewall's records. If communication resumes, packets may be discarded with
this log. Adjusting the timeout value in the access rule can help mitigate this issue.
you can capture network traffic data for troubleshooting purposes. This involves creating
a .zip file containing a tcpdump CAP file, which can be analyzed using tools like tcpdump,
WinDump, or Wireshark. The capture can include full packet information or just IP address
headers, and you can add a description and configuration details to the capture file. This tool
is available in the Security Management Center (SMC), and the captured data can be stored
on the Management Server or your local workstation for later analysis.

SMC sgInfo File:

 Contents: Contains configuration files for the Management Server, Log Server, and
Management Client, along with program trace files detailing logs of problem
situations.
 Exclusions: Does not include information on engine configuration, traffic passing
through the engines, or engine status.

Engine sgInfo File:

  Contents: Includes engine configuration files (accessible only if decrypted), latest
traffic logs, network information, and a snapshot of the current system and network
status, including load, ARP cache, connections, and routing table.
 Exclusions: Does not contain any information about the SMC’s configuration or
status.

Additional Notes:

 SgInfo can be run from the Management Client and retrieved on the client machine.
 It's crucial to collect SgInfo data when a problem is occurring to capture relevant
information, as older sgInfo files may not reflect the current situation.

The sginfo script in Forcepoint NGFW (Next-Generation Firewall) is a tool used to gather
comprehensive information from the NGFW environment, packaging it into a compressed
file. This script is included by default in all NGFW engines and management/log server
distributions. It is primarily used for troubleshooting purposes when requested by Forcepoint
support. The data collected provides a snapshot of the current configuration and status, so it's
crucial to ensure that any problematic configurations are active when the sginfo script is run
to capture the relevant issues.
An administrator who has unrestricted permissions can change any password in the
Management Center. In an emergency situation, there is the possibility to create a new
account with unrestricted permissions on the Management Server
To troubleshoot a connection problem between the Management Client and the Management
Server in Forcepoint Firewall:

1. Verify Management Server Address: Ensure the correct Management Server address
is entered on the login screen. If there's NAT between the client and server, use the
NAT address. "Locations" and "Contact Addresses" do not influence the correct
address selection for logging in.
2. Network and Firewall Check: Confirm that the network is functioning and routing
traffic properly between the client and server. Check for any server firewall or external
firewall blocking traffic on ports 8902-8913/TCP.
3. Check Management Server Status: If the Management Server is not running,
attempt to start it manually from the command line. Check the tmp directory in your
SMC installation for the latest file starting with "MGTSRV" and review the trace logs
for errors.
4. Gather Additional Information: If the issue persists, collect an SMC sginfo and, if
possible, obtain the Management Backup for further analysis
common issues with viewing logs in a Forcepoint firewall system:

1. Logs and Troubleshooting: Logs are essential for troubleshooting your NGFW
system. They help diagnose issues and monitor activities.
2. Logging Rules:
o Rules can generate log or alert entries when matched. By default, logging
options from a previous "Continue" rule are used.
o If there are no preceding rules, Firewalls and Layer 2 Firewalls log connections
by default, but IPS engines do not.
o Individual rules can be configured to override default logging settings.
3. Log Pruning: If you suspect missing log entries, check whether log pruning settings
are inadvertently removing the logs you want to see

The Forcepoint Next Generation Firewall (NGFW) sends logged data to the Log Server using
port 3020. If a firewall exists between the NGFW engine and the Log Server, the firewall
must permit this connection. If the logged data cannot be sent to the Log Server, it is
temporarily stored (spooled) on the NGFW engines.
If the Log Server in the Forcepoint firewall is not operational, it's crucial to determine the
cause. You can try to start the log server manually using the command line to gather more
information. If the issue is related to insufficient disk space for logs, the system will alert you
to this problem before the log server stops functioning.

To view logs on a Forcepoint firewall, the Log Server must be accessible from the computer
running the Management Client. If a NAT device is between the Management Client and the
Log Server, you need to select the appropriate Location for the Management Client in the
status bar at the bottom right of the Management Client window. This ensures that the
Management Client can properly communicate with the Log Server through the NAT.

 Log Server Certificate: If the Log Server’s certificate has expired, been deleted, or is
otherwise invalid, you need to re-certify the Log Server. This is done using the
sgCertifyLogServer script.

 Licensing: All Security Management Center (SMC) components must have a valid
license. If the license is bound to an IP address, that IP address must be active on the server.
 Software Version: All SMC servers must run the exact same software version to ensure
proper system operation.

 Certificates for Communication:

 SMC servers and Next-Generation Firewall (NGFW) Engines use certificates for
secure communication. These certificates are generated by an internal Certificate
Authority (CA) on the Management Server.
 SMC and NGFW certificates are valid for three years. SMC server certificates must be
renewed before or when they expire.
 You can certify again your log server or your management server by launching
respectively the sgCertifyLogServer or the sgCertifyMgtServer script.
 NGFW Engine certificates are renewed automatically by default.
 The internal CA used by the SMC is valid for 10 years.

 Troubleshooting: If you have issues with logs, collect cleartext sginfo from the NGFW
node and a SMC sginfo for further analysis.

Policy failure in Forcepoint firewalls can occur due to errors in the firewall configuration. The
Security Management Center (SMC) validates configurations when generating policies. If
there are any configuration errors, policy installation will be halted, and an error message will
clearly indicate the specific configuration issue.
firewall policy installation issue:

1. Early Installation Failure: If policy installation fails early, it's typically due to
connectivity problems between the Security Management Center (SMC) and the
Firewall.
2. Potential Causes:
o Incorrect IP Address: The engine or Management Server might be using the
wrong IP address.
o Certificate Issues: The engine and Management Server may be rejecting each
other's certificates.
3. Troubleshooting: If you can't resolve the issue, gather an sgInfo report from the
nodes that are refusing the configuration for further analysis.
 Initial Contact and Policy Definition: After the initial connection with the Management
Server, you set the policy for the firewall engine. This policy includes not only the security
rules but also the entire firewall configuration—like interface settings, routing, anti-spoofing
measures, and VPN settings.

 Policy Roll-back Mechanism: To prevent connectivity issues between the firewall engine
and the Management Server, there's a roll-back mechanism. After a new policy is installed,
the firewall engine applies the policy and waits for a confirmation from the Security
Management Console (SMC). If the SMC doesn’t contact the engine within a specified
timeout, the engine automatically reverts to the previous policy to maintain connectivity.

 Example Scenario: If the policy installation fails due to an incomplete configuration (like
missing default gateway), the firewall might not be able to communicate with the SMC. In
this case, it would roll back to the last working policy to avoid disruption.
 Ethernet Rules: The firewall first checks Ethernet frames against the policy's Ethernet
rules. The packet is processed until it matches a rule dictating whether to allow or discard it.

 Packet Sanity Checks: This phase includes dropping packets that fail sanity checks (e.g.,
TCP Segment-SYN-No-Options) and logging these drops. Note that not all invalid packets are
logged unless Packet Filter diagnostics are enabled.
 Anti-Spoofing: The firewall verifies that traffic is coming through the correct interface
based on routing and anti-spoofing settings.

 Connection Tracking: The firewall checks if the packet is part of an established

connection (e.g., a reply to a previously allowed request). It also enforces TCP SYN rate
limits and other DoS protection features at this stage.

 Access Rules Matching: If the packet isn't part of an existing connection, it is compared
against Access rules in the firewall policy. The packet is allowed or blocked based on
matching rules. If no match is found, the packet is discarded.

 Protocol Validation: For packets that are allowed either as part of an existing connection
or by Access rules, the firewall checks if the packet conforms to protocol standards (e.g., a
new TCP connection must start with a SYN packet). Non-compliant packets are dropped.

 Inspection and File Filtering Rules: The firewall applies Inspection rules to connections
selected for deep packet inspection or file filtering. These rules scan for patterns indicating
threats or anomalies and take actions based on rule definitions. This inspection applies to all
packets in a connection, regardless of whether they are part of an existing connection.

 NAT Modifications: Network Address Translation (NAT) rules are applied to IPv4 and
IPv6 connections. The packet's source and destination addresses are translated according to
the first matching NAT rule. If no rules match, the packet retains its original addresses. NAT
is typically not applied to traffic for policy-based VPNs.

 VPN: For policy-based VPNs, the firewall identifies the correct VPN tunnel from the
configuration. If the configuration doesn't match Access rules, packets may be discarded with
the message “VPN tunnel selection failed”.

 Routing / Route-Based VPN: If a Zone is used as the Destination in an Access rule, the
packet is checked against Access rules after routing. If NAT affects the routing, the packet
may be discarded. Packets routed to a tunnel interface are encapsulated as per route-based
VPN configurations. For GRE/IP-IP packets with policy-based VPN, the packet reverts to
policy-based VPN processing.

 QoS: The firewall allows packets through based on their priority and any applied
bandwidth limits or guarantees.