Ran a quick test to see what each component actually does. Here's the breakdown.
Agents are the workers. They run on your endpoints (laptops, servers) and enforce policy. They're the local cops.
* Installed on the device.
* Blocks/Allows traffic based on rules from the cloud.
* Example agent config snippet (if managed):
```json
{
"agent_service": {
"policy_server": "tenant.ibosscloud.com",
"enforcement_mode": "filter"
}
}
```
Forwarders are the traffic routers. They sit in your network (like a VM or appliance) and direct web traffic to the correct place.
* Receives traffic from devices (often via PAC file or proxy settings).
* Sends it to the iboss cloud for scanning, or to a Cloud Collector if you have one.
* No filtering logic itself, just smart routing.
Cloud Collectors are your on-prem filter boxes. They do the scanning work inside your network instead of sending all traffic to the iboss public cloud.
* Deployed in your own data center or cloud (AWS, Azure, etc.).
* Gets policy updates from iboss cloud.
* Filters and logs traffic locally; only sends metadata/logs to the iboss cloud portal.
Simple flow: Device (Agent) -> Network (Forwarder) -> Scanning Location (iboss Public Cloud **OR** your Cloud Collector).
- bench_beast
Benchmarks don't lie.
That's a solid real-world test. Your "local cops" analogy for agents is spot on.
One thing I'd add from my own stack tinkering: the agent vs. forwarder decision often comes down to device mobility. Agents are essential for laptops that jump off the corporate network. But for a static device farm (like kiosks or call center PCs), just pointing them at a forwarder via PAC file is way less overhead than managing agents.
Also, Cloud Collectors are the secret sauce if you're worried about latency or data sovereignty. They keep your heavy traffic local.
one stack at a time
Absolutely agree on the mobility point. It's the single biggest factor in our client designs.
That "less overhead" for static devices is real, but I'll add a caveat from a painful migration: if those call center PCs have any local apps that make outbound calls, you better have that forwarder's IP range whitelisted in every single one of those app vendors' systems. The agent, because it tunnels, often appears as the device's own IP. With a forwarder, all traffic suddenly comes from a proxy IP, and it can break things you forgot about 😅
Cloud Collectors for data sovereignty... 100%. We had a client in Germany who couldn't let any traffic touch outside the EU. The Collector was the only way to make the cloud model work for them. Saved the project, honestly.
Implementation is 80% process, 20% tool.