Enforce Google Safesearch
-
I am trying to get dansguardian to work but struggling, is there something special I need to do give the setup above?
I removed squidguard so just have squid and dansguardian.
-
I think its the forwarding rule that needs tweaking to 8080.
I have Dansguardian listening on the wan and parent proxy defaults 127.0.0.1 3128
My one and only subnet the one the wan is one is 192.168.0.1/24
I tried to create a rule to forward traffic from wan subnet to 8080 but it does not work and the internet breaks.
-
Going back to squidguard for now then!
But another issue the int error page does not work, nor any of the other block page options. The actual block works but I get a no response from 127.0.0.1 error page in my browser instead og the block page.
Is this because I only have a WAN interface?
-
Going back to squidguard for now then!
But another issue the int error page does not work, nor any of the other block page options. The actual block works but I get a no response from 127.0.0.1 error page in my browser instead og the block page.
Is this because I only have a WAN interface?
Sorry… wasn't watching the forums for a while.
For DG... In a normal setup it should be listening on the LAN interface port 8080. The setup would then be as follows:
1. DG connects to Squid running on the loopback (or LAN) port 3128 (setup in the DG config).
2. Configure squid to listen on the loopback and port 3128.
3. Configure the browser to go to the pfsense box port 8080 as the proxy sever.The only thing you need a rule for is if you want to make the proxy transparent. In that case, you forward all port 80 requests to 8080. I'm not sure how you would modify the above config to work in your situation.
Hope that make sense...
-
Many thanks for the respsonse, I think this is why I am having issues due to only having a wan interface, I tried all I can do isget them to listen on the WAN which does not work.
-
Could tell me how to setup the cron job, I have got the overide working now, sweet.
Hopefully no more accidents when the kids are searching on google!
Thought you might be interested in something I figured out this weekend… The override for "encrypted.google.com" does not work if someone browses to "https://encrypted.google.com". Not 100% sure of all the reasons why but I was able to figure out two options for solving the problem...
1.) You can block outbound access on port 443 to the IP addresses that encrypted.google.com resolves to. Unfortunately, this is a pretty long list so it's better to use an alias in your firewall rule.
2.) You can use the dns override and forward encrypted.google.com to a different ip address. It doesn't really block encrypted.google.com, but it sends the user to another site you trust - for example the address of opendns.comTo block using option #1, I ended up using the url table feature of the alias. It will read a text file at a URL and block all the IP addresses or networks that are listed. The nice thing is that there is a built-in cron job that re-reads the text file daily and updates the table in your firewall rules. In order to make sure the addresses were up to date in the text file, I wrote another little shell script the does an nslookup of whatever names you want (in this case encrypted.google.com) and writes their resolved ip addresses to a text file. I place the text file in my /usr/local/www directory so that it can be referenced by url in the alias. I just run my script 5 minutes before the built-in url update job runs.
This got me going on another track though... It seems that there are several encrypted search engines available that also provide image search capabilities. The ones I found were duckduckgo.com, ixquick.com and startpage.com. Unfortunately, these sites presented challenges with block option #1 because (for whatever reason) nslookup only returns one address for them - but it doesn't always return the same address! For example, you can do an nslookup multiple times in a 10 minute period and get multiple addresses back for ixquick.com! Because of that issue, I used option #2 to prevent access to these sites. Option #2 isn't perfect though - it would not stop someone if they were able to figure out one of the ip addresses of the site and browse there directly (via the ip address).