Walkthrough: Configuring an authenticating proxy for outbound web.

I've seen a few threads here asking about forcing outbound web traffic through an authenticated proxy, usually in a corporate or lab environment where you need to tie HTTP/HTTPS requests to specific user identities for logging or policy enforcement. The vendor documentation often makes this sound like a simple checkbox exercise, but the reality involves several moving parts across proxy, authentication, and policy layers. I recently benchmarked the configuration overhead and packet processing latency impact of this setup on an M570, so I'll walk through the critical steps and the performance trade-offs you should expect.

The core requirement is intercepting outbound traffic, challenging the user for credentials, and then allowing that traffic based on who they are. This requires three main components working in concert: a proxy action, an authentication source, and a policy that ties them together. Here's the breakdown.

**1. Authentication Source Configuration**
You need a service that the Firebox can use to validate user credentials. In my lab, I used an internal RADIUS server (FreeRADIUS). The key is to ensure the Firebox can reach it and that the shared secret matches. You configure this under **Authentication > Servers**.

```xml

Internal-RADIUS
radius
10.10.10.10
YourSharedSecretKeyHere
5

```

**2. Proxy Action with Authentication Enabled**
Next, you create a proxy action that will handle the HTTP/HTTPS interception. The critical settings are enabling authentication and selecting your auth server. You'll also need to decide on the authentication method (typically Basic or NTLM). Note that HTTPS inspection requires you to deploy a trusted CA certificate to your client machines—a significant operational overhead often glossed over in sales materials.

* Go to **Policy Manager > Proxy Actions**.
* Create a new "Web” proxy action (or modify an existing one like “Standard Web”).
* Under the **Authentication** tab:
* Check “Require authentication for all requests.”
* Select your authentication server (e.g., `Internal-RADIUS`).
* Set the authentication method.
* Specify the authentication realm (what users see in the prompt).
* Consider setting “Auth Session Lifetime” based on your security needs.

**3. Policy to Trigger the Proxy**
Finally, you need a policy that catches the outbound traffic and applies the authenticated proxy action. This is a standard outbound policy (from internal interfaces to external) but with the proxy action selected.

* Create a new policy or edit an existing outbound HTTP/HTTPS policy.
* Set the **Action** to “Proxy.”
* In the proxy settings, select the proxy action you configured above (e.g., “Authenticated-Web-Proxy”).
* Apply to the relevant source and destination addresses (e.g., Any-Trusted to Any-External).

**Performance and Operational Notes from My Testing**
* **Latency Impact:** Introducing the proxy and authentication adds a non-trivial handshake delay. On the M570, I measured an average increase of 120-180ms for the initial connection (RADIUS lookup, challenge-response). Subsequent requests within the auth session are faster, but the first packet latency is the metric that matters for user-perceived slowness.
* **Throughput Cost:** Enabling HTTPS decryption/inspection is computationally expensive. My synthetic benchmark showed a 30-40% reduction in maximum sustained HTTPS throughput on the same box compared to a simple passthrough policy. Size your hardware accordingly.
* **Client Configuration:** This is the biggest hurdle. Clients must be configured to *not* use a direct connection. This is typically enforced via WPAD/PAC file, group policy pushing proxy settings, or transparent proxy (WCCP). Transparent mode is cleaner for the client but adds complexity on the Firebox and may break some applications that don't respect proxy env variables.
* **Troubleshooting:** Use `tail -f /var/log/proxy.log` on the Firebox CLI to watch authentication and proxy events in real-time. The most common issues are misconfigured client proxy settings, unreachable auth servers, and certificate errors for HTTPS inspection.

This setup is effective for tying web activity to individual users, but it is not a “set and forget” feature. The performance overhead and client-side management are substantial. I would only recommend it where the audit/compliance requirement strictly justifies the added latency and administrative burden. For simpler use cases, IP-based policies are far more efficient.