T Techclick ← Forcepoint hub
Forcepoint · Web / NGFW / DLP · Session factory · Interactive lesson

Forcepoint is a policy factory. User, policy, action, proof.

09:14 Slack: “Forcepoint is blocking Salesforce.” Half the floor hears down. Transaction Viewer already has a row — Action = Blocked, Policy = Finance-Standard, User = example\finance.user, Source IP = 192.0.2.25. That is not an outage. The factory picked a client, applied a policy, wrote an action, and logged it. This lesson is that chain for Web, NGFW and DLP — then how you prove it before anyone adds a global Allow.

20 min read · L2 primary · Quiz at end · Dummy lab only · Blog 2 · Evidence desk

⚡ Quick Answer

Forcepoint is a policy factory: user/IP → policy → action → log/incident. Web, NGFW and DLP share one sentence. Official help.forcepoint.com. Six-question quiz.

After this page you can

Quick answer

Forcepoint is a policy factory. A request arrives as a user and/or a source IP. The product picks one policy (Web policy, NGFW Access rule, or DLP policy + action plan). That policy writes an action. The action writes a log or a DLP incident. Web: Reporting → Report Center → Transaction Viewer quotes Action, Policy, User, Source IP. NGFW: Logs quotes Action + Rule Tag (for example @20.1). DLP: Data → Main → Reporting → Data Loss Prevention quotes ID, Policy, Action, Channel. A single Blocked / Discard / Block row is the product working. Empty Transaction Viewer usually means the request never landed. Test Filtering is a predicted URL-filter action, not a logged transaction.

Say this out loud

I name the user or the source IP, then the policy, then the action, then the log or incident. One Blocked row is not Forcepoint-down. Empty Transaction Viewer is not a missing category Allow. Audit only is not Block. I do not Save and Deploy a global Permit until I can quote that chain.

1. Why a Blocked row is not “Forcepoint is down”

The ticket is always the same sentence: “Forcepoint is blocking Salesforce” or “Forcepoint is down.” Those are two different factories jobs. A Blocked Transaction Viewer row with a named Policy is the product doing what the category filter asked. Mail-down thinking — disable URL filtering, add a Super Administrator permit exception for the whole org, or punch an any-any Access rule — is how a P3 SaaS ticket becomes a real incident.

The factory view stops that. You ask which client did Filtering Service (or SMC, or the DLP engine) think this was, which policy that client owned, and which action that policy wrote. Only then do you decide whether the recipe is wrong, the request never arrived, or a different product owns the hop.

Hero · the factory floor
Teaches: a user laptop request walks a cloud filter and receives a policy stamp before it is enforced
Notice: the laptop does not talk to Salesforce and then get judged. The request walks a filter, receives a policy stamp, and only then is enforced. The stamp is the lesson.

Control hit

One user, one URL or one upload, named Policy + Action. Dashboard / engines up. Peer users still browse. This is the product.

Platform ticket

Empty Transaction Viewer for every user, NGFW engine not installing, Policy Engine down, or PAC / GRE / endpoint never sending traffic. Now it is “Forcepoint is down.”

Concept

A policy is the recipe assigned to a client. A filter (Web) or an Access rule (NGFW) or an action plan (DLP) is how that recipe decides. An action is the disposition written on the request. A log or incident is the receipt. You never argue with “it was blocked.” You name the client, the policy, and the action. Official Web path: Policy Management → Policies. Official proof path: Reporting → Report Center → Transaction Viewer.

The lie every L1 repeats

“Salesforce is a business app, so add it to Permit All.” Permit All is a category-filter template, not a diagnosis. Official: if the active category filter is Permit All, Filtering Service permits the site — and you just turned the factory off for that policy. Name the current policy and the current action first. The evidence desk is the night-shift version of that order.

2. Mental model — four stations, three factories

Hold four stations. Interviews fail when people mix the products and skip a station.

1. The client is user and/or IP

Web: directory client (user, group, OU) or computer / network client (single IP or range). NGFW Source cells accept Network Elements and User / User Group. DLP Source is who moved the data. Empty User is data — cloud Help: Not available when authentication is bypassed.

2. The policy is the recipe

Web: one named policy, built from category / protocol / cloud-app / limited-access filters plus exceptions. NGFW: an Access policy is a list of matching criteria and actions; Inspection is a different tab. DLP: a policy plus an action plan plus a channel.

3. The action is the stamp

Cloud Web: Allowed, Authentication Required, Blocked, Confirmed, Quota. On-prem also exposes Result (permitted / blocked). NGFW: Allow, Discard, Refuse, Continue, Terminate, Wait for further actions, Wait for authentication. DLP: Permit, Block, Audit only, Quarantine, Confirm — and more, channel-dependent.

4. Proof is the log or incident

Transaction Viewer is the Web receipt. NGFW Logs + Rule Tag is the firewall receipt. A DLP incident is a policy violation; an event is any transaction the engine saw. Test Filtering is a what-if. Real-Time Monitor is now, not the Log Database.

Flow 1 · one request, four stations, three factories
One sentence · user/IP → policy → action → log/incident 1 User / IP example\finance.user 192.0.2.25 Empty User = bypass 2 Policy Finance-Standard Access @20.1 PCI-Web-Outbound 3 Action Blocked / Allowed Allow / Discard Block ≠ Audit only 4 Log Transaction Viewer NGFW Logs DLP incident Web factory Filtering Service + filters Save and Deploy NGFW factory Access then Inspection Save and Install · Rule Tag DLP factory Policy + action plan + channel Incident ≠ event Default policy governs any client you have not assigned. Default on-prem precedence: User > Computer > Network > Group > OU. Hybrid / cloud always: User > Group > OU > IP (filtered location). Exceptions beat policies. Computer (single IP) beats a network range.

Read left → right, then the three factory cards. Same four stations on every product. Do not start in the policy editor.

Web. Official FAQ: policies and exceptions apply to directory clients (user, group, OU) or computer and network clients (IP or range). Filtering Service uses a precedence order. Default: User > Computer > Network > Group > OU. You can flip directory ahead of IP: User > Group > OU > Computer > Network. Hybrid always uses User > Group > OU > IP address (filtered location). A computer (single IP) policy beats a network (range) policy. If nothing else matches, the Default policy applies. Exceptions take precedence over policies; among equivalent exceptions, Blocked beats Permit.

NGFW. Official: Access rules are lists of matching criteria and actions. They are the main configuration for how the engine treats traffic. Source and Destination accept Network Elements and User / User Group. Action is the command — Allow, Continue, Discard, Refuse, plus Wait / Terminate on some trains. Rule Tag is not editable. It is two parts, for example @20.1: the first part is permanent and belongs only to that rule; the second part changes when the rule changes. The tag is the link between the log and the rule. Inspection Policy looks at traffic Access already allowed.

DLP. Official: an action plan is how the system responds when a breach is discovered. Path: Data Security module → Main → Policy Management → Resources → Action Plans. Incidents live at Data → Main → Reporting → Data Loss Prevention (or cloud Reporting → Report Center → Incident Manager). Quote ID, Policy, Action, Channel, Source. Channel is Email, Web, FTP, Endpoint application, Endpoint printing, Network printing — not “the DLP box.”

3. Decision flow — who, then which policy, then which action

Flowchart first. Do not open Policy Management, an NGFW Access policy, or an action plan until a diamond says so.

Path

Write user + IP + URL/port + UTC. Ask whether Transaction Viewer / NGFW Logs even have a row. If empty, stop — that is PAC / proxy / endpoint / GRE, not a category Allow. If a row exists, read User / Source IP, then Policy (or Rule Tag), then Action. Only then open an editor. DLP is a fourth click: incident ID + Channel, not the Web category.

Path · prove versus change
Teaches: a decision diamond splits prove (evidence, validate, confirm) from change (revise, iterate, adapt)
Notice: the diamond is not allow/deny. It is “have I named the client, the policy and the action?” Path A is prove. Path B is change. Most tickets die on Path A.
Flow 2 · official Web order, then NGFW / DLP branches
Symptom first · factory second · field third 1 Request URL / port / file Landed? TV / Logs yes Identify client · then pick the policy User / Computer / Network / Group / OU Protocol filter non-HTTP first Recategorize then URL DB Exception beats policy Cloud app then CASB? Category or limited list Action + BW / type / KW NO row in Transaction Viewer → PAC / proxy / endpoint / GRE — do not invent a category Allow Security override: a permit exception can still Block if the URL is a security-risk category. Official default. Do not disable it as a reflex. no → empty TV NGFW branch — Access first Match Source / Dest / Service / User. Action Allow · Discard · Refuse · Continue. Inspection + File Filtering only after Allow. Click Rule Tag in the log to open the rule. DLP branch — violation, not browse Classifier hits a policy on a channel. Action plan writes Permit / Block / Audit / … Incident ID is the receipt. Event is any look. Web DLP Block is not a category Block. Official facts students invert 1. Filtering Service re-confirms enforcement order at each step of “Responding to a URL request.” 2. Test Filtering is Toolbox + user-or-IP + URL. It is predicted. It is URL filtering only. It is not Transaction Viewer. Sources: Responding to a URL request · How is a policy or exception assigned · Define Action options in Access rules · Possible actions for an action plan

Read the Web row left → right. Empty Transaction Viewer is the green “no” branch. NGFW and DLP are different factories with the same four stations.

#1 student trap — Test Filtering is not the log

Toolbox → Test Filtering asks for a fully qualified user or an IP, plus a URL, and returns category, action, and reason in a popup. Official note: it provides information only for URL filtering. It does not prove the browser request landed. It does not prove NGFW Discard. It does not prove a DLP action plan. If Test Filtering says Permit and Transaction Viewer is empty, the request never hit Filtering Service. Fix PAC / Content Gateway / endpoint / GRE. Do not add another exception.

4. How to choose the client, the policy, the action

You are not choosing a product SKU. You are choosing who the factory thinks is on the wire, which recipe they own, and which stamp that recipe is allowed to write.

ChoiceUse whenDo not use whenProof you were right
Assign policy to the user Directory identification works. You want the same recipe on every desk that person sits at. Auth is bypassed and User is Not available. Then you are really assigning to an IP. Transaction Viewer User = that account, Policy = the one you assigned.
Assign policy to a computer (single IP) Shared kiosk, printer, or lab jumphost. On-prem default: computer beats group. You meant “the finance group.” A single-IP computer policy will steal the request from the group policy. TV Source IP matches; Policy is the computer policy, not the group one.
Assign policy to a network (range) A subnet that should share a recipe when no user / computer policy exists. You need one host to differ. Computer (single IP) already beats the range. TV Policy is the network policy only when no higher client matched.
Assign policy to a group / OU Role-based web filtering. Hybrid / cloud: group beats IP. On-prem: only if you flipped precedence, or no computer/network policy exists. The user is in two groups and you forgot Use most restrictive group policy (Settings → General → Filtering). TV Policy matches the group you intended; if restrictive is on, any blocking group wins.
Leave them on Default Brand-new lab, or a client you have not classified yet. Official: Default governs until you assign another. Production “we’ll tune Default later.” Default is the catch-all for everyone you forgot. TV Policy = Default. That is a finding, not a success.
Category action = Block / Confirm / Quota You want Filtering Service to stop, warn, or spend quota on that category for this policy. You set Permit All on Finance-Standard because one SaaS ticket was loud. TV Action + Category match the filter. Confirm / Quota are not Block.
Permit exception for one URL One site must override the category for a named client. Policy Management → Exceptions → Add. You write a Super Administrator permit for the whole role to close one CEO ticket. Security override can still Block a security-risk URL. TV reason / exception name. Security-risk still Blocked = override working.
NGFW Access = Allow + inspect The connection must exist, then Inspection / File Filtering may look inside. You think a Discard rule will still run Inspection. Inspection only sees allowed traffic. Logs Action = Allow, Rule Tag of the Allow rule, then an Inspection hit if any.
NGFW Continue You want default log level / Protocol for many rules underneath. Official purpose of Continue. You put Continue as the last rule and wonder why traffic is silent. Continue does not allow. A later Allow / Discard still matches. Rule Counters move on both.
DLP action plan = Audit only Pilot. You want incidents without stopping the upload. You tell the CISO “we blocked payroll.” Audit only is review, not deny. Incident Action = Audit only, Channel = Web. The file still left.
DLP action plan = Block The channel and classifier are tuned. False-positive rate is known. You Block on a regex that matches every invoice number in the company. Incident Action = Block, same Policy, same Source as the user who complained.

Multiple group policies and no higher client: official Use most restrictive group policy on Settings → General → Filtering. Selected = any blocking group blocks. Not selected = any permitting group permits. All groups the same policy = that policy. Hybrid does not use the on-prem computer-beats-group default — group beats IP.

5. Runbook Side A → B → C

Do

Side A names the client and the factory. Side B assigns or reads the policy and the stamp (Save and Deploy / Save and Install). Side C quotes the receipt: Transaction Viewer, Rule Tag, or DLP incident. Predicted (Test Filtering) is not logged.

Lab values only. User example\finance.user, client 192.0.2.25, SaaS login.salesforce.com / 198.51.100.44, Web policy Finance-Standard, category filter Finance-Day, NGFW rule name finance-saas with Rule Tag @20.1, DLP policy PCI-Web-Outbound, action plan Block-Web-Upload, incident INC-LAB-1042. Nothing here is a live tenant.

Side A — who is on the wire (building the factory floor)

Primary source: Working with clients + How is a policy or exception assigned to a request. Path: Policy Management → Clients.

  1. Write the three identifiers before you click

    User, source IP, destination URL or port, UTC. If you cannot write those four, you are not ready for a policy editor. Shared NAT and hot-desks will lie; that is why both user and IP exist.

  2. Decide which factory owns the hop

    Browser / SaaS URL → Web. SYN never leaves the LAN or a port is Discarded → NGFW Logs. File / paste / upload of regulated data → DLP incident. A spinning Salesforce tab can be all three in sequence: NGFW first, Web second, DLP only if they uploaded.

  3. Confirm the client object exists

    Policy Management → Clients. Directory user example\finance.user, or computer 192.0.2.25, or the network that contains it. If the user is missing, Filtering Service will fall through computer → network → group → OU → Default (on-prem default order). That is a client problem, not a Salesforce category problem.

Side B — name the policy, then the stamp (printing the ticket)

Primary source: Creating a policy / Assigning a policy to clients / Define Action options in Access rules / Action plans. Web: Save and Deploy. NGFW: Save and Install.

  1. Web — assign, do not widen Default

    Policy Management → Policies → Finance-Standard → Apply to Clients. Mark the finance group (or the computer 192.0.2.25 if this is a kiosk). OK, then Save and Deploy. Official lesson text: the selected client now receives that policy. Leave Default as the safety net, not the production recipe.

  2. Web — set the category / exception stamp

    Policy Management → Filters for the category filter, or Policy Management → Exceptions → Add for one URL. Enter a unique Name. Scope the exception to the client, not the whole Super Administrator role, unless that is the documented intent. Security override still Blocks security-risk URLs permitted by exception — official default, leave it on.

  3. NGFW — write Access, then Inspection

    SMC policy editing view → IPv4 Access. Source = finance user or 192.0.2.0/24, Destination = the Salesforce elements you actually own, Service = HTTPS / Network Application, Action = Allow if the hop must exist. Put Discard / Refuse rules above the Allow only when you mean them. Save and Install on the engine. Inspection Policy and File Filtering Policy sit on a different tab and only see allowed traffic.

  4. DLP — policy plus action plan plus channel

    Main → Policy Management → Resources → Action Plans for Block-Web-Upload. Attach it to PCI-Web-Outbound on the Web channel. Audit only for the first week if you have not measured false positives. Do not call Audit only a Block in the ticket.

  5. Predict before you celebrate

    Toolbox → Test Filtering: user example\finance.user or IP 192.0.2.25, URL https://login.salesforce.com, Go. Read category, action, reason. Say the word predicted. Side C is the logged row.

Predicted Web action — Techclick dummy lab, not a live tenant 
Toolbox → Test Filtering
  Client : example\finance.user    (or 192.0.2.25)
  URL    : https://login.salesforce.com
  Go

Popup (predicted, URL filtering only):
  Category : Legal / Business
  Action   : Permit
  Reason   : Policy Finance-Standard · filter Finance-Day
  Cloud app: salesforce  ·  Monitor Only

If this popup says Permit and the browser still spins, you do not have a category problem. You have a land-the-request problem, an NGFW Discard, or a DLP Block on the upload — three different factories.

Side C — prove the action in the receipt

Primary source: Transaction Viewer display options + Web attributes + What the Logs view shows + Viewing the incident list.

  1. Web receipt — Transaction Viewer

    Reporting → Report Center → Transaction Viewer. Filter User example\finance.user or Source IP 192.0.2.25, destination host login.salesforce.com, last 15 minutes. Open Detail View → General (user, group, policy, category) and Request Details (source / dest IP, full URL, port, protocol).

  2. NGFW receipt — Logs + Rule Tag

    SMC Logs. Filter Src Addr 192.0.2.25, Dst Addr 198.51.100.44, dest port 443. Quote Action and Rule Tag. Click the tag — official troubleshooting: it opens the rule that generated the log. @20.1 first half is permanent; if someone edited the rule, only the second half moved.

  3. DLP receipt — incident, not event

    Data → Main → Reporting → Data Loss Prevention → Incidents (last 3 / 7 days), or cloud Reporting → Report Center → Incident Manager. Quote ID INC-LAB-1042, Policy PCI-Web-Outbound, Action, Channel = Web, Source = the same user. An event with no incident is “the engine looked.” An incident is “a policy fired.”

  4. If the receipt is empty, do not add a permit

    Empty TV + empty NGFW log = the packet never arrived. PAC, explicit proxy, Content Gateway, SmartEdge / endpoint, GRE, or the wrong engine. That is the evidence desk, not a missing category Allow.

Green success on this runbook

Test Filtering predicted Permit on Finance-Standard. Transaction Viewer shows the same Policy and an Allowed (or on-prem permitted) action for example\finance.user / 192.0.2.25 on the Salesforce URL. NGFW Logs, if this hop crosses an engine, show Action = Allow and Rule Tag = @20.1. If they uploaded a payroll file, the DLP incident is a separate receipt — do not use the Web Allowed row to claim DLP is off.

6. Runtime — after Save and Deploy / Save and Install

Web: Save and Deploy pushes the recipe to Filtering Service. It does not create a Transaction Viewer row. The next real browser request does. Hybrid users outside the network are judged by the hybrid service, which always uses User > Group > OU > IP and ignores your on-prem computer-beats-group default. Cloud Help: a user’s home policy overrides the IP-based policy for enforcement actions.

NGFW: Save and Install compiles the Access policy onto the engine. Official: the engine blocks connections that have not been specifically allowed. Continue rules underneath a template set default log level or Protocol; a later rule’s own options win. After Allow, Inspection looks for Situations; File Filtering is a separate element. Clicking Rule Tag in Logs is how you walk from receipt back to recipe without guessing the ID.

DLP: deploying a policy / action plan does not invent incidents. The next matching transaction on that channel does. Cloud Web DLP Blocks on the Web Proxy Policy options log under Analyze → Logs → Web DLP (Forcepoint ONE wording) and still surface as incidents in Incident Manager. An Allowed Web row plus a Web-channel DLP Block is consistent: URL category said yes, content said no.

Flow 3 · runtime after the recipe is live
Recipe printed Deploy / Install Next real request browser / SYN / upload Action stamped Allow / Block / Discard Receipt TV / Logs / incident Runtime traps after a green deploy Test Filtering still shows the old action until you used the same client type the live request will use. Real-Time Monitor is this second. Transaction Viewer reads the Log Database. Empty TV + busy RTM is a reporting delay, not a missing Allow.

A green Save and Deploy is a printed recipe. Success is the next request’s receipt. Re-read Side C if you only have the toast.

Delegated administration: Super Administrator exceptions beat delegated ones unless the Super Administrator flipped that option. Exceptions on one client beat exceptions on a whole role. Custom categories and custom protocols beat predefined ones. If a user sits in groups owned by two delegated roles, Manage Role Priority decides. Quote those names in the ticket if two admins “fixed” the same user.

7. Traps + proof checklist

Proof · close the ticket on a named field
Teaches: operators close Forcepoint tickets with a verification checklist and a UTC timestamp, not a screenshot of a spinning browser
Notice: juniors paste a spinning tab. Seniors paste Action + Policy + User/IP (or Rule Tag, or incident ID) and a UTC stamp.
SymptomLooks likeActuallyFirst move
Salesforce spins, one user Forcepoint is down Named policy Blocked / Confirm / Quota, or NGFW Discard, or DLP Block Transaction Viewer for that user. Quote Action + Policy.
Empty Transaction Viewer Need a category Allow Request never landed (PAC / proxy / endpoint / GRE) Prove the hop. Do not add an exception.
Test Filtering Permit, browser still blocked Filtering Service is lying Predicted ≠ logged. Or a different factory owns the hop. TV, then NGFW Logs, then DLP incidents.
Group policy never hits Directory is broken On-prem computer / network policy is beating the group (default order) Check Clients assignments + precedence.
User = Not available Forcepoint lost AD Authentication bypassed. Cloud official wording. Treat it as an IP client. Fix auth, do not invent a user.
Two group policies, flip-flop actions Random bug Use most restrictive group policy on or off Settings → General → Filtering. Quote the checkbox.
Permit exception, still Blocked Exception did not deploy Security override on a security-risk category Leave override on. Recategorize or pick a different URL.
NGFW Allow, Inspection silent Signatures failed Traffic was Discarded earlier, or Inspection Policy not attached Rule Tag of the Access hit first.
DLP “blocked” but file left DLP is broken Action plan = Audit only / Confirm / Permit Incident Action column. Say the real verb.
Web Allowed, payroll still stopped Category filter is wrong Web-channel DLP Block after URL permit Incident Manager / DLP incident list. Different factory.
Proof checklist — Finance-Standard is actually working
Interview close you can steal

Forcepoint is a policy factory. Web, NGFW and DLP all do the same four stations: identify the user or IP, pick one policy, write an action, write a log or incident. On-prem Filtering Service defaults to User then Computer then Network then Group then OU. I prove Web in Transaction Viewer, NGFW with Action plus Rule Tag, and DLP with an incident ID and channel. I do not add a global Allow from an empty log.

Night shift: take the same four stations to the Forcepoint evidence desk — first tool + one official proof field per ticket.

Knowledge check

Six judgment questions. Map each miss back to the section named in the reason.

Q1

A director says “Forcepoint is three products.” What is the factory sentence you say back?

Correct: c. One sentence, four stations, three factories. Re-read Mental model.
Q2

On-prem Filtering Service, default precedence. A user is in the finance group, the PC has a computer policy, and the subnet has a network policy. Which policy wins?

Correct: a. Official FAQ default is User > Computer > Network > Group > OU. A computer beats a network. Hybrid is different (User > Group > OU > IP). Re-read Mental model and How to choose.
Q3

Transaction Viewer is empty for the complaining user. Test Filtering says Permit. What do you do first?

Correct: b. Test Filtering is predicted URL filtering only. Empty TV is usually a land-the-request problem. Re-read Decision flow and Side C.
Q4

An NGFW log shows Action = Discard and Rule Tag = @20.1. What is the Rule Tag for?

Correct: d. Official policy-editing view: Tag is not editable. Troubleshoot traffic: click the Rule Tag in the log. Inspection is a later factory. Re-read Mental model and Side C.
Q5

What is Toolbox → Test Filtering allowed to prove?

Correct: b. Official: enter a user or IP plus a URL; URL filtering only. Re-read the Test Filtering trap and Side B.
Q6

Incident INC-LAB-1042 shows Policy = PCI-Web-Outbound, Action = Audit only, Channel = Web. The file reached the SaaS. What do you tell the CISO?

Correct: c. Official action-plan list: Audit only = activity is audited and available to review. Permit / Block / Confirm are different verbs. Re-read How to choose and Side C.

Sources

Related: Forcepoint evidence desk — first tool + proof field · DLP architecture · DLP channels · DLP policies and rules · Forcepoint interview hub · All lessons

All console values on this page are fixed fictional lab data (example\finance.user, RFC 5737 addresses, INC-LAB-1042). Confirm current menu labels, permissions and privacy rules on the production release before you type on a live system.