Symantec ProxySG
Add CID222 as an external ICAP service on ProxySG, bind it in the Visual Policy Manager, and read the directory identity ProxySG forwards.
- Version: 0.4
- Feature: icap
- Role: admin_user
- Type: task
ProxySG dials external scanners the way CID222 expects, so the integration is one service entry and one policy rule. This procedure adds the service, scopes it to the provider hostnames, and enables the two headers that let an event name a person.
What do I need?
- Licence
- Any
- Role
admin_user
Prerequisites
- Symantec ProxySG on SGOS 6.7 or 7.x, Symantec Web Security Service, or Broadcom Edge SWG.
- Administrative access to the Visual Policy Manager.
- The CID222 ICAP listener published and reachable from ProxySG on TCP 1344 — see ICAP and third-party gateways.
- ProxySG's source address — every node of a cluster — admitted by the appliance's peer list.
Warning
Written from Symantec's own documentation and the CID222 inspection contract. Not verified against a live ProxySG. Console paths are a guide to the right screen, not a transcript.
Configure ProxySG
Add the inspection service
Under Configuration → External Services → ICAP, create a service named cid222 with the
URL icap://<appliance-ip>:1344/inspect and request modification as its method.
Selecting Test Service returns a healthy result within a couple of seconds. ProxySG discovers the rest of the capabilities from the service's own answer, so leave the sense settings at their defaults.
Enable the identity headers
In the same service, enable sending the authenticated user and the client address.
Events then carry both. ProxySG sends the username in a directory-URI form; CID222 normalises it to the bare username, so one person is one identity rather than several.
Scope it to the provider hostnames
In the Visual Policy Manager, add a rule in the web access layer whose destination is a
category holding the provider hostnames and whose action is external inspection through
cid222, then install the policy.
The rule becomes active within seconds. Include the hosts that carry uploaded file bytes, not only the conversation hosts.
Choose the failure behaviour per policy
Set bypass-on-failure to match the appliance's Fail closed (BLOCK) on timeout.
ProxySG can set this per service entry and per policy rule, so a high-security policy and a productivity policy can use the same service with different postures. Whichever you choose, the two ends must agree.
What CID222 advertises
ProxySG reads the service's capabilities from its answer to a capabilities request. CID222 reports request and response modification, a maximum of 1024 connections, support for the no-content reply, and a capability lifetime of 60 seconds. It deliberately advertises no preview, so ProxySG sends each body in full rather than withholding it.
Note
The short capability lifetime means ProxySG re-reads the capabilities every minute. That is intentional — a change on the appliance is picked up within a minute rather than an hour — and the extra round trip is negligible. Do not override it upward without a reason.
Verify
- From a managed endpoint, send a prompt containing a test identifier to a provider site. The model receives it masked, or the browser shows a block page.
- Select Detection & Filtering → All Detections and filter to browser traffic. The attempt
appears as
MESSAGE_MASKEDorMESSAGE_BLOCKED, carrying the username ProxySG forwarded. - On Browser Inspection, ProxySG appears in the connected-sources table.
If it fails
- Test Service fails → the listener is unreachable, or the peer list does not admit this node. In a cluster every node dials independently, so every node's address must be listed.
- Requests fail closed with a header error → the profile expects encapsulated sections other than the ones the method implies. Capture the exchange on 1344 before changing anything else.
- Events carry an unfamiliar username form → this is normal; CID222 stores the bare username and keeps the full form for forensic queries.
- Every caller arrives with the same address → Every ICAP caller arrives as the same docker bridge address.
Next steps
- ICAP and third-party gateways — the contract and the admission rules.
- Interception topologies — what this deployment cannot see.
Last updated on