Pfsense GUI & Dansguardian woes …

amercer

Installed pfSense 2.1-RELEASE (i386) + Dansguardian 2.12.0.3-i386 + Squid 3.1.20 pkg2.0.6.

It worked - Dansguardian blocked using default settings.

Initially, I could make changes to the DG config files via the GUI and they took effect.

BUT something happened as lately and DG ignored any changes to the default config files.

The GUI Status –> services I could stop it, get the message that said it was stopped, yet the table below said it was still running, and users on the network were still being blocked by DG.

Decided to remove DG via the packages in the GUI, according to the GUI it is removed (only reference is now in available packages).

BUT it is still blocking users as per the default settings! so obviously it is stll running - but the GUI insists it is gone.

How do I get it back - and under control of the GUI? I am assuming there must have been 2 instances running, one that the GUI controlled and removed, the other that was actually controlling the network blocking and is still there "hidden" from the GUI.

TIA
Art

marcelloc

Reinstall the package and check if you do not have big lists on dansguardian acls.

squid(access and cache.log) and dansguardian(access.log) logs may help you too.

amercer

Well, I've reinstalled at least 6 times in the last 2 weeks, on two different machines (Dell Poweredge T300 and 1800 - 4Gb ram and 250 Gb HD) starting from scratch (pfSense + DG + Squid). I've removed/installed/and reinstalled DG (whatever package is current) and Squid packages (initially v3 then back to v2stable) in between OS re-installs.

pfSense has been solid. And DG and Squid worked (DG set to listen to LAN, Squid on localhost) with default configuration until LAN users exceeded 8 or so, then everything becomes intolerably slow. In an attempt to remedy this I used the web GUI to change disk and memory cache sizes to "tune" squid and/or alter the DG settings towards "larger site" settings - then the problems begin. Either squid quits or DG quits and refuses to restart. Most times I never got to the point of making any changes to the DG default filtering lists.

In the web GUI services, if you click stop DG, it proclaims DG has been stopped (in red banner at the top) but the table displays it (green) as still running, and the console shows it still running! If it stopped on its own, no way to restart it (at least I couldn't) - hence reinstalls.

Also, don't need av, DG in web GUI shows both av scanners as off, but console (TOP) shows clamav as running as process under DG. Confusing (at least to me a newbie with pfSense)

Left last night after clean reinstall of pfSense, DG, Squid2.1 and it was working for me (single user) - this morning no one could access the internet through that server - had to take it offline. (Yes, I know DG is beta.)

Is it necessary to restart DG after you make changes to any of its settings in the web GUI?

Is it necessary to restart Squid if you make changes to it in the GUI?

Thanks,

rjcrowder

I've installed dozensnof times and never had the problems you are describing. Can you provide any info about the setting changes you are making? Can you provide any squid or DG logs?

amercer

OK have removed DG and Squid, re-installed DG and Squid 3.1.2. via the web GUI,

It is working, browsers pointed at the proxy are filtered.

Using the web GUI in Services, Dansguardian, Report, I edited the report file (html template page announcing the site is blocked) to put our organization name in replacing the place holder, saved the file, but users still see the old template, even though the web GUI shows the file as changed.

Seems the file I edit in the GUI is not the one DG is using?

How do I fix that? (I would like to be able to do it from the GUI.)

TIA

rjcrowder

I assume you've cleared the browser history and made sure it is not just a client (browser) side issue? Double check that first…

However, you are correct about the GUI not editing the file "in place". The GUI saves what you edit as an encoded string in the config.xml file and then also updates the file on disk. It's possible that something is keeping it from writing the file to disk. I'll try to look tonight if you are still having the problem.

amercer

And now I no longer can access the internet, just tried through the DG/Squid proxy.

It worked yesterday, I haven't made any changes to either the workstation, browser, or the DG/Squid host machine. I just cleared the browser cache (Chrome latest version) and still no go.

In the gui, I added added to DG's ACL blocked list a new site, and immediately it took effect (browsing machine got back the site blocked page), but for unblocked sites it times out. So DG seems to be working, but is not getting out through squid?

Not sure what to do next, any suggestions?

rjcrowder

https://forum.pfsense.org/index.php?topic=73075.msg398731#msg398731

amercer

1.) Validate that Squid and Dans are both running… If so...
According to the webgui, both are.

2.) Try connecting the browser (via explicit proxy settings) to squid and make sure you can get out... If so...
Fails here - set squid to listen on the lan interface at port 3129, changed the browser proxy settings, and it times out.

Browser reports:

The following error was encountered while trying to retrieve the URL: http://www.badboys.com/

Unable to determine IP address from host name www.badboys.com

The DNS server returned:

Timeout
This means that the cache was not able to resolve the hostname presented in the URL. Check if the address is correct.

Your cache administrator is admin@localhost.

Generated Thu, 10 Apr 2014 18:30:40 GMT by localhost (squid/3.1.22)

~~Now what?~~

Oops - went back in the web gui to DG and changed the ip address of the proxy server (squid) to the ip of the LAN card (from localhost 127.0.0.1) and now it works.

But this makes no sense (because DG is listening on port 8080) does it?

OK on to step 3

3.) Try connecting the browser (via explicit proxy settings) to dans and make sure you can get out… If so...
Did this (same settings as before the problem started) and now it works!

4.) Add the redirect rule and delete your browser proxy settings.
I assume this if for setting it as a transparent proxy, I am not using transparent here, the win7 workstations are all pointed at the proxy via internet options in control panel.

This is maddening, why is it working once again, and for how long?

amercer

And I still can't edit the DG report template - changes I make in the webgui don't take effect.

(Although any changes I make in the webgui to the banned list in DG ACL take effect immediately.)

(And since DG/squid started working once again - the page now showing up when an attempt to visit a banned site is blocked is NOT the default anymore, but is one from an earlier install/remove!)

Can anyone figure this out?

rjcrowder

For the banned page, my guess is that you have somehow gotten the page in the GUI (which is saved in the config.xml) out of sync with the one that is stored on disk (and actually used by DG). Anyway… it can get a little confusing. Bottom line is that I'm not sure why as you edit it in the GUI it is (apparently) not updating the file stored on disk.. I'll figure out where that file is stored and you could validate that it is (or is not) being updated.

In the interim, I believe the one from the GUI (stored in config.xml) would be re-applied if you reboot the machine.

amercer

I rebooted from the GUI, but I am still seeing the same banned page (browser cache cleared), not the one that the GUI shows.

I did notice on the reboot that as it shut down this message briefly flashed on the console

"find: /tmp/* :no such file or directory"

although when the system came back up and I typed it (find /tmp/) at the shell prompt I get a listing of items in a tmp directory, note that typing "find: /tmp/" tells me too many arguments are being used.

I rebooted again (2nd time), same "find: /tmp/* :no such file or directory" message appeared on shut down, and same banned page in the browser after system came up (again browser cache was cleared).

Does that have any significance?

rjcrowder

The HTML template file is saved as "/usr/local/share/dansguardian/languages/ukenglish/template.html" (assuming you are using english as the language). This is a symbolic link to "/usr/pbi/dansguardian-amd64/share/dansguardian/languages/ukenglish/template.html"

Can you check that this file is being updated when you save the template via the GUI? It seems to be saving fine on my test machine…

amercer

The template at the symbolic link "/usr/local/share/dansguardian/languages/ukenglish/template.html" is the one in the GUI I edited/want, but the one at "/usr/pbi/dansguardian-amd64/share/dansguardian/languages/ukenglish/template.html" is the one being shown in the browser.

Now what?

TIA

rjcrowder

Not sure what is going on here or how this happened. There should be a symbolic link named "/usr/local/share/dansguardian/languages/ukenglish/template.html" that points to the file in the /usr/pbi… directory. If that is not a symbolic link, then you should probably delete the file and create the symbolic link....

amercer

How do I delete/recreate a symbolic link? (or how do I fix the problem?)

(newbie at FreeBSD)

rjcrowder

You'll need to get to the command prompt - either at the console or ssh to the box… then...


cd /usr/local/share/dansguardian/languages/ukenglish/
rm template.html
ln -s /usr/pbi/dansguardian-amd64/share/dansguardian/languages/ukenglish/template.html template.html

Check that the link is created and pointing to the file by doing


ls -al template.html

The go back in the GUI and make your changes… should work.

amercer

Worked perfectly, I can edit the template, save, and the changes take effect immediately!

Many thanks for your help.

The DG/Squid combo appears to be working nicely now, I don't notice any browsing difference going through the proxy compared to a direct connection except of course the filtering - but I am only 1 user. Monday I'll point a group of students at it - that's when the problems began last few times with timeouts, slowness, etc.. Hopefully it won't this time.

Again, thanks for your help.