Every Service on Every Policy on a 500 Mbps Line

Separate the three symptoms - they have different causes, and fixing the wrong one wastes the maintenance window.

Likely causes, ranked:

1. The model is undersized for this service mix at this line rate. Datasheet throughput figures are per-service-mix and are not the same as 'all services, both directions, 500 Mbps'. If the unit's inspected-throughput rating is at or below the subscribed rate, no amount of tuning gets you to line rate - it just stops the collapse.
2. Single-core proxy saturation. 90-95% on one core with proxy memory pressure is the signature of proxy/AV processing, not of routing. Proxy services are the expensive ones; packet-level services are comparatively cheap.
3. A noisy workload poisoning the whole box. The scraper subnet is generating scan-triggering traffic and IPS/Geo log volume, consuming CPU and log bandwidth for everyone.

First three changes:

• Measure the ceiling. Run the same test with proxies and services toggled off on one policy, then on. That number tells you whether you are tuning or buying. Do this before changing anything.
• Scope the proxies. Move trusted-to-trusted and VPN traffic off proxy policies onto packet filters unless a requirement says otherwise; set AV scan size limits so large downloads are not fully buffered through the proxy.
• Isolate the scraper. Put it on its own policy with a tuned IPS profile, only the application signatures it needs, and rate limiting - so its noise stops degrading voice and browsing for everyone else.

Then revisit DNSWatch separately; see the next task.

DNSWatch only sees what is asked of it. In this design no client ever queries the Firebox: the DCs resolve for everyone and forward straight to 8.8.8.8. The Firebox is not in the DNS path, so there is nothing to log. The nearly-empty dashboard is correct behaviour, not a fault.

Fix without breaking AD:

1. On the two DCs, change the forwarders from 8.8.8.8 to the Firebox's internal interface address (or configure conditional forwarders if you only want certain zones inspected - but that limits coverage).
2. Confirm the Firebox allows DNS from the DC addresses to the firewall and out to the internet; DNSWatch needs the queries to traverse it.
3. Verify by querying a known-bad domain from a workstation and checking DNSWatch shows the query and the block, and that internal names still resolve (the DCs answer those from their own zones, so AD is unaffected).

Judgement points:

• Keep the DCs authoritative for AD; you are only changing where they forward. Do not point clients directly at the Firebox - that is what breaks domain joins.
• DNSWatch is essentially off-path for throughput purposes; the added load of being the resolver is trivial next to what you are already doing.
• If the customer will not allow DC forwarder changes, accept that DNSWatch covers only devices you can point at the Firebox (guest VLAN, IoT) and document the gap rather than pretending the subscription is protecting everything.

Split the eight services by where they operate, because that is what drives CPU.

Keep inline, everywhere (mandated):

• IPS - packet-level, relatively cheap per megabyte, and the requirement. Tune signatures to drop rather than block-with-logging-only where the log volume is the problem.
• Gateway AntiVirus - required. Keep it on the HTTPS proxy, but set scan size limits; AV scanning of large downloads is a top memory consumer.

Keep inline, cheap and high value (packet-level):

• Botnet Detection and Geolocation - both work at packet level, cost little, and directly reduce the noisiest traffic. Keep them on external-facing policies.

Narrow rather than remove:

• Application Control - keep on the user VLANs where acceptable-use matters, and use it on the scraper policy to allow only the applications it legitimately needs. Not mandated, so it must earn its CPU.
• APT Blocker - the heaviest of the set and only usable on proxy policies. Scope it to policies that carry file downloads and email-like traffic for real users; drop it from the scraper and server subnets where it produces volume without adding proportionate coverage.
• WebBlocker - keep where an acceptable-use policy exists; if there is no such policy, this is a candidate to remove on the busiest policies first.

Already off-path:

• DNSWatch - consumes no meaningful inspection throughput once DNS actually flows through the Firebox.

Present it as a table of service, layer, mandate status and CPU contribution, and note explicitly that the ordering judgement rests on proxy-layer services being the expensive ones. If the customer later adds a compliance requirement for APT everywhere, that becomes a sizing conversation, not a config change.