Edit common properties of several NGFW Engines at once

You can select several NGFW Engines and change the properties common to all of them.

The following limitations apply when you change the properties of several engines at once:

Properties specific to one individual NGFW Engines element, such as IP address definitions, are never available in the common properties.
If you select both single and clustered NGFW Engines elements, the cluster-specific options are not available.
If you select elements of different types, you can only set the Log Server, Location, SNMP Agent, and Comment options and some system parameters.

For more details about the product and how to configure features, click Help or press F1.

Steps

Select Configuration.
Shift-select or Ctrl-select the NGFW Engines that you want to edit.
Right-click one of the selected NGFW Engines, then select Common Properties.
Select the options you want to set for all selected NGFW Engines.
The options you see depend on how similar in type the selected NGFW Engines are
Click OK.

Common Engine Properties dialog box

Use this dialog box to define common properties for two or more engines.

Option	Definition
General tab
Log Server	Specifies the log server to which the engines send event data.
Location	Specifies the location for the engines or clusters if there is a NAT device between the engine and other SMC components.
SNMP Agent	Enables the engines to send SNMP traps.
Comment	An optional comment for your own reference.

Option	Definition
Advanced tab, System Parameters section
Encrypt Configuration Data	By default, the configuration of the engine is stored in an encrypted format. Only deselect this option if instructed to do so by Forcepoint support.
Contact Node Timeout	The maximum amount of time the Management Server tries to connect to an engine. If the engine has a dynamic IP address, the Contact Node Timeout is the maximum amount of time that the engine tries to contact the Management Server. If the connection to the Management Server fails, the engine automatically tries to reconnect to the Management Server. A consistently slow network connection might require increasing this value. The default value is 60 seconds. Note: Setting the timeout value too short or too long can delay or prevent contact between the Management Server and the engines.
Auto Reboot Timeout	Specifies the length of time after which an error situation is non-recoverable and the engine automatically reboots. The default value is 10 seconds. Note: Set to 0 to disable.
Policy Handshake	When selected, the nodes automatically roll back to using the previously installed policy if connectivity is lost after installing a new policy. Without this feature, you must switch to the previous configuration manually through the engine's boot menu. Note: We recommend adjusting the rollback timeout rather than disabling this feature completely.
Rollback Timeout	Specifies the time the engine waits for a management connection before it rolls back to the previously installed policy when the Policy Handshake option is active. The default value is 60 seconds.
Automated node certificate renewal	When selected, the engine's certificate for system communications is automatically renewed before it expires. Otherwise, the certificate must be renewed manually. Each certificate for system communications is valid for three years. If the certificate expires, other components refuse to communicate with the engine. Note: Does not renew VPN certificates. Automatic certificate renewal for internally signed VPN certificates is set separately in the VPN settings for the Firewall, Firewall Cluster, or Virtual Firewall engines.
FIPS-Compatible Operating Mode (Firewalls only)	When selected, activates a mode that is compliant with the FIPS (Federal Information Processing Standard) 140-2. Note: You must also select FIPS-specific settings in the NGFW Configuration Wizard on the command line of the NGFW Engine. For more information, see How to install Forcepoint NGFW in FIPS mode.
Log Spooling Policy	Specifies the settings related to adjusting logging when the log spool on the engines fills up or when the number of Antispoofing and Discard logs grows too high. Stop Traffic — The node goes offline. If the node is part of a cluster, the other nodes of the cluster take over the connections. Discard Log — Log entries are discarded in four stages, according to available space. Monitoring data is discarded first, followed by log entries marked as Transient and Stored, and finally log entries marked as Essential. The engine keeps processing traffic. Note: You can adjust the logging of Antispoofing and Discard logs also for specific interfaces.
Cluster Mode (Clusters and Master NGFW Engines only)	Specifies the settings related to the communications between cluster members and load-balancing between the nodes. Balancing — All nodes are simultaneously online providing enhanced performance and high availability in case of node failure. Balancing mode is the default mode. Standby — Only one node can be online at a time. It is recommended to have at least one other node on standby to allow automatic takeover in case of failure. Several nodes can be on standby at a time. A randomly selected standby node is turned online when the online node fails.
Heartbeat Message Period (Clusters and Master NGFW Engines only)	Specifies how often clustered engines send heartbeat messages to each other (notifying that they are up and running). Enter the value in milliseconds. The default value is 1000 milliseconds (one second). CAUTION: Setting this option too low can result in unnecessary heartbeat failures. Setting this option too high can cause unnecessary service outages when a failure occurs.
Heartbeat Failover Time (Clusters and Master NGFW Engines only)	Specifies the time from the previous heartbeat message after which a node is treated as failed. Enter the value in milliseconds. The failover time must be at least twice as long as the Heartbeat Message Period. The default value is 5000 milliseconds. CAUTION: Setting this option too low can result in unnecessary heartbeat failures. Setting this option too high can cause unnecessary service outages when a failure occurs.

Option	Definition
Advanced tab, Traffic Handling section
Connection Tracking Mode	Normal — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule. This mode is the default connection tracking mode for Firewalls. The engine drops ICMP error messages related to connections that are not currently active in connection tracking (unless explicitly allowed by a rule in the policy). A valid, complete TCP handshake is required for TCP traffic. The engine checks the traffic direction and the port parameters of UDP traffic. If the Service cell in the rule contains a Service that uses a Protocol Agent, the engine also validates TCP and UDP traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped. Strict — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule. The engine allows only TCP traffic that strictly adheres to the TCP standard as defined in RFC 793. The engine also checks the sequence numbers of the packets in pre-connection establishment states and for RST and FIN packets, and drops packets that are out of sequence. If the Service cell in the rule contains a Service that uses a Protocol Agent, the engine also validates the traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped. Loose — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule. This mode is the default connection tracking mode for Layer 2 Firewalls and IPS engines. The engine allows some connection patterns and address translation operations that are not allowed in the Normal mode. This mode can be used, for example, if routing is asymmetric and cannot be corrected or if the use of dynamic routing protocols causes the engine to receive non-standard traffic patterns. This mode is recommended for IPS engines, Virtual IPS engines, Layer 2 Firewalls, and Virtual Layer 2 Firewalls when they are configured by default to only log connections instead of terminating them. You can override this engine-specific setting and configure connection tracking for TCP, UDP, and ICMP traffic in Access rules.
Virtual Defragmenting	When selected, fragmented packets are sent onwards using the same fragmentation as when they arrived at the engine. When the engine receives fragmented packets, it defragments the packets for inspection. The original fragments are queued on the engine until the inspection is finished. If the option is not selected, the packets are sent onwards as if they had arrived unfragmented.

Option

Definition

Advanced tab, Traffic Handling section

Connection Tracking Mode

Normal — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule.
This mode is the default connection tracking mode for Firewalls.

The engine drops ICMP error messages related to connections that are not currently active in connection tracking (unless explicitly allowed by a rule in the policy). A valid, complete TCP handshake is required for TCP traffic. The engine checks the traffic direction and the port parameters of UDP traffic. If the Service cell in the rule contains a Service that uses a Protocol Agent, the engine also validates TCP and UDP traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped.
Strict — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule.
The engine allows only TCP traffic that strictly adheres to the TCP standard as defined in RFC 793. The engine also checks the sequence numbers of the packets in pre-connection establishment states and for RST and FIN packets, and drops packets that are out of sequence. If the Service cell in the rule contains a Service that uses a Protocol Agent, the engine also validates the traffic on the application layer. If a protocol violation occurs, the packet that violates the protocol is dropped.
Loose — When connection tracking is enabled, reply packets are allowed as part of the allowed connection without an explicit Access rule.
This mode is the default connection tracking mode for Layer 2 Firewalls and IPS engines.

The engine allows some connection patterns and address translation operations that are not allowed in the Normal mode. This mode can be used, for example, if routing is asymmetric and cannot be corrected or if the use of dynamic routing protocols causes the engine to receive non-standard traffic patterns.

This mode is recommended for IPS engines, Virtual IPS engines, Layer 2 Firewalls, and Virtual Layer 2 Firewalls when they are configured by default to only log connections instead of terminating them.

You can override this engine-specific setting and configure connection tracking for TCP, UDP, and ICMP traffic in Access rules.

Virtual Defragmenting

When selected, fragmented packets are sent onwards using the same fragmentation as when they arrived at the engine.

When the engine receives fragmented packets, it defragments the packets for inspection. The original fragments are queued on the engine until the inspection is finished. If the option is not selected, the packets are sent onwards as if they had arrived unfragmented.