ClearFoundation

This is for a non-transparent proxy configuration.

I had the problem where if a site was filtered (let's say games.com) and a proxy client went there, it would redirect to the filtered.php page but they recurse and redirect that entire request to the filtered.php page again ad infinitum until a bad request was made.
Basically, it detects the bad URL (because even those requests are going through the content filter) within the URL it's going to so it tries to filter it out.

There are two fixes.

• Server side: Add the filter page's host (As defined in /etc/dansguardian-av/dansguardian.conf under accessdeniedaddress) to Exception Site List in the Content Filter web config


• Client side: Add the proxy to the browser's "No Proxy For" exception list, preferably the whole internal LAN subnet.

Hi J,

Welcome to Clear. Yes - I have added the proxy server address into the excluded list (deployed by group policy). I will be interested to see if I still need this work round with the 6 release.

David

Please can anyone confirm that this fix works on 6.2?

I implemented the fix on 5.2 and it did indeed solve the problem, but in my case at least, the fix is not working on 6.2.

Of course, it may be that I have done something wrong.

Many thanks

Doug

In theory in 5.2 this shouldn't happen - as the filtered.php page is served by the webconfig on port 82 (which is expressly passed through the squid ACLs)

In version 6.2 the filtered.php page has changed, and now handled by the content_filter app. I have no problem here with the transparent proxy in 6.2 can you elaborate on your config and how you replicated the problem?

My web proxy requires user authentication (non-transparent) which works fine. The content filter has a test policy which has a certain banned URL. It all works as expected except that it results in a 400 Bad Request having detected the banned site. Just as described in the first post.

I will re-test this using a transparent proxy

Many thanks, Doug