Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
And that has made all the difference.“The Road Not Taken” by Robert Frost
There are two distinct families of DansGuardian configurations: transparent-intercepting, and explicit-proxy. Right up front you need to choose carefully which one you'll use, as there are significant ramifications both now and in the future, and it's not easy to change later.
The specifics of DansGuardian differ depending on which configuration family you choose. Experiences with one configuration family are often a little different than experiences with the other. Sometimes advice for one is misleading (or even contradictory) for the other.
(You will probably also need to configure whatever proxy you use behind DansGuardian to match your choice: transparent-intercepting or explicit-proxy.)
The transparent-intercepting configuration captures and filters all network web traffic on the standard web port without any knowlege required of individual workstations. It's easy to deploy since you only have to touch a few servers, not every client workstation. And it can be made impossible to skip around (although it isn't automatically). But it can only filter port 80 (the un-encrypted web port); it can't even begin to filter (or even minimally control access through) port 443 (https:). And it can't use any sort of authentication that requires the local proxy to make a request (since end user workstations don't even know exists).
There's no way the current version of DansGuardian can be made to transparently intercept encrypted web traffic successfully. (If you try to redirect port 443 traffic into DansGuardian, the browser will just “hang”.) Because working traffic doesn't even go through DansGuardian, it's not possible to scan content nor check URLs nor even vett the name of the website. A few DansGuardian options (for example “Blanket SSL Block”) don't –and can't be made to– do anything at all in these configurations.
(This limitation isn't just in DansGuardian …transparently intercepting encrypted traffic is inherently impossible [well almost]. If you could interpose a “man in the middle” without the end workstation realizing it, the connection wouldn't really be “secure”, would it? The only way to do this –which isn't supported by the current version of DansGuardian anyway– is to obtain a “security certificate” for the filter machine itself, and to make that certificate acceptable to every end workstation. As this requires touching every end workstation anyway, it may negate the main advantage of the transparent-intercept configuration family.)
As far as an end user workstation knows, with the transparent-intercepting configuration its conversation is going straight to the destination website. If it were to get a request from the transparent-intercepting proxy for some kind of credentials (LDAP, Active Directory, etc.), it would just be very puzzled how this request from an apparent eavesdropper got into its network conversation. (Don't be concerned about this actually happening. With just minimal configuration, intercepting proxies know not to send such requests but rather to pretend their authorization requests come from the website itself. This however still doesn't work well, partly because the faked proxy authentication requests and any real website authentication requests can get mixed up, and partly because even a successful proxy authentication will last only until the end of that request rather than until the end of the browser session.)
The “intercepting” part of this family of configurations cannot be configured exclusively from inside DansGuardian; something like an IPtables rule is needed to redirect the network traffic in this way. Some distribution configuration tools disguise this with a single configuration application that really modifies two separate configurations. In other cases you may have to use a second configuration tool (or even a text editor) to make a system (i.e. non-DansGuardian) configuration entry.
End user configuration is especially simple (none at all is required) for guest computers and for computers that frequently move onto then back off of the network. Inability to even minimally police ports other than 80 (particularly https: on port 443) makes this configuration family not recommended for tightly filtered environments.
If you like block diagrams, here's what a common transparent-intercepting configuration would look like. (This diagram shows DansGuardian running on the gateway/firewall, which is not the only possible option.)
The explicit-proxy configuration on the other hand relies on the 'proxy' settings in every browser on every workstation. Depending on your environment, making settings in every workstation might or might not not be overly difficult. Making settings on every workstation will be particularly easy if your browser settings are already centralized. However if you have a very large number of workstations, or workstations that move on and off your network (including mobile web access devices such as iPhones), or multiple browsers on many workstations, or workstations that are time-consuming to change because they're “locked down”, or end users sometimes install additional browsers, requiring 'proxy' settings on every end workstation may not be reasonable. This configuration too can be made impossible to skip around (although it isn't automatically).
(The problem of computers that move on and off your network –especially mobile web access devices such as iPhones– may be solvable with a Network Billboard).
In this configuration family, DansGuardian's “bannedsitelist” and “exceptionsitelist” will apply to not only to http: but also to https: (encrypted web traffic on port 443) connections. However, even in the explicit-proxy configuration DansGuardian will have access only to the hostname, not to the rest of the URL and not to page content. [This access to the hostname is similar to something called “connect()”.] So DansGuardian won't be able to do any “content filtering” or any URL filtering or any regular expression filtering. Still, the ease of blocking website access over both http: and https: all at once using the same mechanism might be very useful.
End user configuration may not be entirely automatic [although clever use of proxy auto-detect (PAC, WPAD, etc.) might ameliorate this issue]. Https filtering, while improved, is still quite limited– https: hosts will be vetted by domain name, but the rest of the URL is still opaque and the encrypted content still cannot be scanned. This configuration family enables one of the tightest filtering environments possible at this time with open source software.
If you like block diagrams, here's what a common explicit-proxy configuration would look like. (This diagram shows DansGuardian running on the gateway/firewall, which is not the only possible option.)
You could set up the DansGuardian computer for a “transparent-intercepting” configuration and also make an explicit entry in the browser configuration as though for an “explicit-proxy” configuration. The question is what will happen. It turns out that in this situation the explicit-proxy configuration will take precedence for that browser.
You may be able to use this behavior to your benefit – If the DansGuardian computer is set up for a “transparent-intercepting” configuration, you can switch back and forth between the two configuration families just by changing some parameters in your browser configuration, without ever touching the DansGuardian computer or configuration not even remotely.