I was running pfSense with Squid Proxy Server (available in pfSense at the touch of a button via System -> Package Manager -> Available Packages) when I decided it would be nice to use SquidGuard to redirect some URLs based on blacklists. I tried using the well-known blacklist at http://www.shallalist.de/Downloads/shallalist.tar.gz, but no matter what I did, I could not get SquidGuard to redirect any URLs. It was maddening, because it seemed like it really should be working. After going down a lot of dead ends, and trying lots of tweaks, I finally got it working, and figured it would be worth memorializing in a blog post for others.

SquidGuard was running (confirmed in Status -> Services), and the SquidGuard Logs (Services -> Squid Proxy Server -> Real Time -> SquidGuard Table) showed the correct ACL request being processed when visiting a site in a blacklisted category or domain set to DENY, and yet I could still reach the sites that should have been blocked.

I could also see it working by running this at the Command Prompt (Diagnostics -> Command Prompt) which tested the effect of visiting “www.sex.com” from the IP 192.168.11.71:

echo "http://www.sex.com 192.168.11.71/ - - GET" | squidGuard -d

This domain set to DENY and redirect produced results indicating it was working, which ended with:

REDIRECT OK rewrite-url="www.somesafeplace.com"

When I’d put in an innocuous URL like “www.ge.com” it didn’t try to redirect me, so clearly it seemed to be working fine! Yet nobody actually browsing the web in my real world was being redirected…

The clue to an answer came in the Squid Cache Table log (Services -> Squid Proxy Server -> Real Time -> Squid Cache Table). Every time I went to a URL that was supposed to be set to “DENY” I’d see an error similar to the following:

ERROR: URL-rewrite produces invalid request": GET www.somesafeplace.com HTTP1.1

The problem is it needs to know what protocol to “GET” and that means prefacing the URL with HTTP://. Unfortunately, even when you type HTTP://  in front of domain names into SquidGuard via the pfSense GUI, it ignores it and continues to pass the URL to the rewrite process without the HTTP included. To fix it you have to manually edit the file that the pfSense interface is just a pretty front end for.

WARNING: Once you edit this file you’ll have to edit it manually forever, since the fields accessible via the pfSense interface (Services -> SquidGuard Proxy Filter) no longer have any effect. It will allow you to save your changes, and it seems to accept them, but they won’t actually do anything. For some reason, manually editing this file breaks the delicate link between it and the pfSense interface. For me, it’s an annoyance, but a small price to pay if it gets SquidGuard working right! (I’m too busy these days to troubleshoot this, but I’m sure if you poke around a bit you can get to the bottom of why this is happening. Feel free to comment below with the answer!)

So, click on Diagnostics -> Edit File, and load this file:

/usr/local/etc/squidGuard/squidGuard.conf

Scroll to the bottom and find all the URLs that you’re expecting to be redirected to. Put HTTP:// in front of them, and save the file.

Restart the SquidGuard service and test it out. Since you manually entered it into the .conf file it won’t automatically strip out the protocol and you should now see redirects working as expected!

I hope this saved you some of the hours of fruitless web searching and troubleshooting it cost me!

–Steve