Forcepoint NGFW Admin cheat sheet

Engine types: Firewall/VPN (single or cluster), IPS, Layer 2, and Virtual. A Master NGFW Engine runs the Management Server and can manage other engines; a non-Master engine is managed remotely.

Deployment on physical appliances uses the Forcepoint NGFW Installation Wizard from the appliance console or a USB drive; the wizard partitions disks, installs the engine image, and sets the management connection.

Virtual engines run on VMware ESXi, KVM, Hyper-V, and public clouds; the VM needs at least 2 vCPU, 4 GB RAM, and two virtual NICs (one management, one traffic) unless using a single-NIC management-only role.

Cluster installation: both nodes must run the same engine version and have identical interface configuration; the cluster heartbeat uses a dedicated interface or a VLAN, and the primary node is selected by priority, then node ID.

Before installation, record the management IP, default gateway, DNS, NTP, and license/proof-of-serial; the engine cannot reach the SMC without a correct management IP and route.

The Management Server (SMC) is installed on a dedicated appliance or VM; the engine contacts the SMC on TCP 443 by default, and the SMC pushes configuration over that channel.

Initial configuration wizard on the SMC creates the engine element, assigns interfaces, and generates the initial policy; the engine then shows as 'Configured' once it receives the first policy.

Upgrade path: install the new engine version via the SMC 'Upgrade' task or the engine's command line; the engine reboots into the new partition, and the old partition remains for rollback.

Licensing: a valid license or proof-of-serial must be installed before the engine passes traffic; an unlicensed engine drops traffic after the grace period.

Policy structure: a policy contains rules evaluated top-down; the first matching rule applies, so order rules from most specific to most general, ending with a deny-all.

Rule actions: Allow, Discard, Refuse, Continue, and Jump. 'Continue' evaluates the remaining rules without terminating; 'Jump' sends traffic to a sub-policy and returns.

NAT rules are separate from firewall rules: a NAT rule matches on source/destination and translates addresses; the firewall rule must still allow the translated (post-NAT) or original traffic depending on the engine's NAT order.

Inspection policies attach to firewall rules and enable IPS, anti-malware, URL filtering, and application control; an inspection policy without a matching rule passes traffic uninspected.

Template policies let you push a common rule set to multiple engines; engine-specific policies override or extend templates. Use templates for shared baseline rules.

The default 'Any' network and 'Any' service in a rule expand to all configured elements; avoid them in allow rules unless the rule is intentionally broad.

Logging is per-rule: set 'Log' to store matching connections; 'Log Summary' aggregates. The default action logs only denied traffic unless changed.

Policy validation runs before install; unresolved elements or missing interface assignments block installation, and the SMC shows the specific error.

Rule counters and the 'Policy Installation' history show which rules match; use them to tune before deleting rules.

Routing types: static routes, policy-based routing (PBR), and dynamic routing via OSPF, BGP, or RIP. Static routes have an administrative distance; lower distance wins.

The engine's routing table is built from directly connected networks, static routes, and dynamic protocols; the SMC 'Routing' view shows the active table per engine.

Policy-based routing matches on source, destination, and service, then forwards to a next-hop or interface; PBR rules are evaluated before the main routing table.

NAT and routing interact: after destination NAT, the engine routes to the translated destination; after source NAT, return traffic must be routed back to the engine.

Interface types: physical, VLAN, tunnel, and loopback. A VLAN interface requires the parent physical interface to be up and the VLAN ID to match the switch.

Cluster routing: both nodes share the same routing configuration; the active node forwards, and the standby node syncs state. Asymmetric routing breaks stateful inspection.

Dynamic routing with OSPF requires matching area IDs and authentication; BGP requires matching AS numbers and neighbor reachability on the management or traffic interface.

Multi-link and ISP redundancy use link selection rules to choose an outbound link based on source, destination, or probe status; probes must succeed for the link to be considered up.

The SMC provides centralized management: policy editing, engine monitoring, log browsing, and reporting. Role-based administration limits which domains and engines an admin can view.

Logs are stored on the engine and forwarded to the SMC log server; the Log Browser filters by engine, rule, source, destination, and action. Retention depends on disk size and log server settings.

Alerts and notifications: the SMC can send email or SNMP traps for engine down, policy install failure, license expiry, and high resource usage.

Monitoring views include engine status (CPU, memory, disk, connections), interface statistics, cluster node state, and VPN tunnel status.

Reports are generated from log data on a schedule; the report template selects the time range, engines, and metrics.

Admin accounts and roles are defined in the SMC; use separate accounts per administrator and enable strong authentication. Audit logs record configuration changes.

Backups: the SMC backup captures the configuration database; engine backups capture the local configuration. Schedule backups before upgrades.

SNMP monitoring exposes interface counters and engine health; configure the SNMP agent on the engine and the community string in the SMC.

First check: engine status in the SMC (Configured, Not Configured, Error), policy installation history, and the engine's connection to the SMC on TCP 443.

Use the engine command line: 'sg-reconfigure' for initial setup, 'sg-status' for service state, and log files under /var/log. The 'tcpdump' tool captures traffic on an interface for packet-level analysis.

Policy installation failure: read the error in the SMC install log; common causes are unresolved elements, missing interface assignment, or a rule referencing a deleted element.

Connectivity issues: verify routing with 'ip route' and the SMC routing view, check NAT rules, and confirm the firewall rule allows the traffic in the correct direction (pre- or post-NAT).

Cluster failover problems: check heartbeat connectivity, node priority, and state sync; a split-brain occurs when heartbeat fails and both nodes become active.

Upgrades: back up the SMC and engine, verify disk space, and use the SMC upgrade task. Roll back by booting the previous partition from the engine console.

Log analysis: use the Log Browser to confirm whether traffic is allowed, denied, or dropped by inspection; rule counters show which rule matched.

Maintenance tasks: rotate logs, update signatures (IPS, anti-malware, URL categories), renew licenses before expiry, and review admin accounts periodically.