Hi everyone. I've been helping some teams set up iboss for secure web gateway and cloud security, and one question that consistently comes up from newcomers—especially those migrating from simpler proxy setups—is about the core architectural components. Specifically, the difference between agents, forwarders, and cloud collectors. It can feel a bit tangled at first, so I thought I'd write up a practical breakdown from a workflow perspective.
Think of it like setting up security checkpoints for your company's internet traffic, whether people are in the office, at home, or on the road.
Here’s how I explain it:
* **Agents (like the iBoss Zero Trust Edge Client):** These are small software programs you install on individual devices (laptops, desktops, sometimes mobile). Their main job is to ensure that *all* web traffic from that device, no matter where it's physically located (coffee shop, home office, airport), is securely routed to the iboss cloud for inspection and policy enforcement. They're essential for protecting remote users. Without an agent, a laptop off your corporate network might bypass your security entirely.
* **Forwarders (like the Cloud Forwarder or Legacy Connector):** These are typically lightweight virtual machines or containers you deploy within your own network infrastructure (e.g., in your data center or private cloud). They act as a trusted, on-premises traffic hand-off point. Their primary function is to securely "forward" web traffic from your fixed office locations (where installing an agent on every desktop might be impractical) to the iboss cloud. They consolidate and manage the traffic from your entire office subnet.
* **Cloud Collectors:** This is the iboss cloud itself—the central brain and security engine. It's where all the traffic, whether sent by agents or forwarders, actually arrives for processing. This is where your security policies (blocking malicious sites, enforcing safe search, filtering content) are applied, logging happens, and reports are generated. You don't install this; it's the SaaS platform you subscribe to.
To visualize the flow:
- A remote employee's laptop (with the **agent**) sends its traffic directly to the **cloud collector**.
- An employee in your main office building has their traffic routed by your network to the **forwarder** you've deployed locally, which then sends it to the **cloud collector**.
- Both streams meet at the **cloud collector**, where identical security policies are applied, giving you consistent protection everywhere.
The key takeaway is that agents and forwarders are about *how* and *from where* traffic is delivered to the central security service. You'll often use a combination of both to cover all your users and locations seamlessly.
I hope this helps clarify the roles. If you're planning a rollout, my advice is to map out your user groups (remote vs. office-based) and network architecture first—that will tell you which components you need to focus on.
grace
The right tool saves a thousand meetings.
Ok, so agents are for remote devices to make sure traffic gets to the cloud. That makes sense. But you cut off mid-sentence when you started talking about forwarders! I was really following along there.
You mentioned the Cloud Forwarder or Legacy... something. Could you finish that part? I'm especially fuzzy on when you'd need a forwarder versus an agent, or if you need both. Is it about where your physical office traffic goes?
Yeah, I was hoping they'd finish that thought too. The way I'm starting to see it, an agent is for a single device like a laptop, but a forwarder is for a whole network location, like your office. So your physical office traffic could go through a forwarder appliance.
But I'm also confused on when you'd need both. If all your users are remote, do you just use agents and skip forwarders?
Still learning
You cut off because the original post was incomplete. Here's the workflow.
Forwarders are for traffic from a *physical location*, like an office network. It's an appliance or VM that sits on-site and tunnels all the local user traffic to the iboss cloud for inspection.
Agents are for individual *remote devices* (laptops, home users) to do the same job.
You need both if you have a hybrid setup: office users and remote users. If everyone is remote, you'd just deploy agents. If everyone is in one office, you could use just a forwarder and no agents.
The Legacy Forwarder just refers to the older on-prem hardware model vs. the newer Cloud Forwarder virtual appliance.
Optimize or die.
Good breakdown. You're spot on about the agents and you caught the cut-off point. The sentence was meant to end with "Legacy Connector appliances" - they were the physical boxes before the virtual Cloud Forwarder.
That's a perfect lead-in to what the third component, a Cloud Collector, is for. It's not about routing user traffic at all. While the agent and forwarder send traffic *to* the cloud for inspection, the Cloud Collector pulls data *from* the cloud for you. Its sole job is to fetch the audit logs, event data, and forensic detail from the iboss cloud back to your on-prem SIEM, data lake, or compliance archive. If you're in a regulated space and need those logs locally for Splunk or a long-term SOX archive, you deploy a collector.
Logs don't lie.
Thank you, that clarification about the Cloud Collector's role is exactly what I was missing. Pulling logs *from* the cloud, rather than sending traffic *to* it, makes the distinction much clearer.
It sounds like the collector is more of a backend data pipeline component, separate from the real time security enforcement. Does that mean it's optional for most deployments, and only becomes a hard requirement when there's a specific compliance or log retention policy that demands on-premises data storage? Or are there performance benefits to having a local collector even if you're not regulated?
You're right to focus on that specific cut-off point. The original poster was likely starting to talk about the difference between the physical Legacy Connector appliances and the newer virtual Cloud Forwarder - both serve that same 'office traffic' function.
Your instinct about physical office traffic is correct. That's the forwarder's domain. You'd need both components if, for example, you have desktop computers fixed in an office location (those route through the forwarder) and a sales team with laptops that travel (those get the agent). You only need agents if every single device, including desktops, is permanently remote.
—daniel
Exactly the analogy I use! Setting up the checkpoints. You hit the nail on the head.
That's a great start on agents and forwarders. Since you cut off at "Legacy Con," I figure you were about to contrast the older hardware appliances with the virtual Cloud Forwarder. We just went through that migration last quarter. The virtual forwarder is so much easier to scale up on our VMware cluster when we open a new small branch office.
One extra thing I'd add about the agent is how it handles those tricky split-tunnel VPN scenarios. It makes sure all the traffic gets checked, not just what's sent to the corporate network.
Always testing.